[09:12] <ricotz> RAOF, hi :), could you take a look at https://launchpadlibrarian.net/447970389/vala_0.40.17-0ubuntu1_source.changes -- https://bugs.launchpad.net/ubuntu/+source/vala/+bug/1803136
[09:35] <LocutusOfBorg> kirkland, your bikeshed package depends on bzr-fastimport, but fastimport has to disappear due to bzr->brz transition...
[09:35] <LocutusOfBorg> can you please do some update of the packaging?
[09:39] <enaut[m]> hey all, what is the best way to convert a git tree (with debian directory) to a deb package - without any source.tgz?
[09:40] <tarzeau> enaut[m]: create a source.tgz without debian directory
[09:40] <tarzeau> enaut[m]: if there's a dsc link dget that
[09:40] <tarzeau> enaut[m]: which software is that?
[09:41] <enaut[m]> the software is ltsp-manager kind of my own ;) however I think it is so complicated to build the deb-file locally for testing purposes.
[09:43] <enaut[m]> isn't there a switch for just building the whole directory with dh_make - I mean everything is there to build it just does not build automagically?
[09:44] <cjwatson> LocutusOfBorg: brz provides bzr-fastimport though
[10:36] <LocutusOfBorg> cjwatson, yes true, we should probably make that fastimport a transitional package? meh, don't care.
[10:39] <cjwatson> LocutusOfBorg: I mean ... it is
[10:39] <cjwatson>  bzr-fastimport | 0.13.0+bzr361+brz1     | focal-proposed/universe | source, all
[10:39] <cjwatson> LocutusOfBorg: Maybe you're looking in focal rather than focal-proposed
[10:55] <LocutusOfBorg> cjwatson, I just syncd it
[10:57] <LocutusOfBorg> i confused with bzr-webdav, that one probably needs to be kicked out
[13:39] <doko> marcustomlinson: any update with the libreoffice autopkg test?
[13:40] <marcustomlinson> doko: will be fixed tomorrow or thursday with the new version
[13:42] <doko> marcustomlinson: how do you know? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943401
[13:42] <marcustomlinson> doko: I will disable the test as Debian has done
[13:44] <marcustomlinson> could I just ask for a day so I can correlate the fix with the new release
[13:54] <doko> marcustomlinson: seriously disabling without checking for the issue?
[13:55] <marcustomlinson> doko: libreoffice is unfortunately not the only pain in my ass right now
[13:55] <doko> ;-P
[13:56] <doko> marcustomlinson: is this test run during the build as well, and if not, how can it be run?
[13:57] <marcustomlinson> doko: afaiu it does run during build yes
[13:58] <marcustomlinson> though, it looks like Debian have disabled it during build too. hmm, might have to as well
[13:59] <marcustomlinson> how can it be run > make check
[14:01] <doko> marcustomlinson: please could you enable building with the internal cppunit, and see if the problem persists? a stack trace would be good to have
[16:16] <cpaelzer__> ahasenack: I have synced postgresql-common 208
[16:16] <cpaelzer__> it was ready now and has the changes we need
[16:17] <cpaelzer__> I'll let it run tests over night as they auto-trigger, then we might need to go to p-migraton and check which older tests need custom triggers to properly work
[16:25] <infinity> cpaelzer__: A psql transition in the middle of unwinding the initial autosync?  You're brave.
[16:26] <cpaelzer__> infinity: it already started by exactly that thundering-herd autosync
[16:26] <cpaelzer__> doko: made me aware that several things were failing
[16:27] <infinity> Oh, as in stuff had been fixed to work with 12, but somehow not backward compatible with 11?
[16:27] <cpaelzer__> turned out libpq-dev was already pointing to 12 and postgresql-common to 11 still - and things being auto-synced broke on that
[16:27] <infinity> Oh, or that.  I thought psql-common was supposed to own libpq-dev for that very reason.
[16:27] <infinity> Maybe I gave the design too much credit.
[16:28] <cpaelzer__> infinity: I didn't say I wanted to transition now, but the syncs that already happened and the current state in debian made going back as painful as going forward
[16:28] <infinity> It very clearly comes from psql itself.  Special.  That seems entirely wrong.
[16:28] <infinity> cpaelzer__: Yup, agreed.  I missed the puzzle piece that libpsql-dev is coming from (IMO) the wrong source package. :P
[16:29] <cpaelzer__> yeah, agreed - there should be no two packages defining what is currently "the version"
[16:29] <cpaelzer__> but for now things are as they are
[16:29] <infinity> Makes the whole "default" selection in psql-common seem sort of pointless.
[16:35] <kyrofa> Hey juliank, regarding https://bugs.launchpad.net/ubuntu/+source/urdfdom-headers/+bug/1817595, there doesn't seem to be anything in -proposed yet. What is the next step there?
[16:44] <juliank> kyrofa: It's in the queue https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text= - bug some sru people (sru vanguard) about apporivng theme
[16:47] <kyrofa> Ah yes, thank you!
[18:05] <ahasenack> hi, I need some apt pinning help. I want to have trusty-proposed main in general downgraded (400, for example), but for one package that comes from it: ubuntu-advantage-tools
[18:05] <ahasenack> it's not working: https://pastebin.ubuntu.com/p/sVB7TCvTXZ/
[18:06] <ahasenack> i.e., I don't want dist-upgrade to suddenly upgrade to anything in proposed, but for that one package
[18:08] <sarnold> ahasenack: iirc proposed is handled funny, you have to use something like apt install package=version to use proposed
[18:08] <ahasenack> hm, wait a sec, it's saying the pin prio is 400, but dist-upgrade is pulling it in
[18:10] <ahasenack> sarnold: can't do that, this is part of a dist-upgrade from precise
[18:10] <rbasak> ahasenack: define "not working" please?
[18:10] <ahasenack> I want the dist-upgrade to precise to consider just u-a-t from trusty-proposed, not the rest
[18:10] <ahasenack> rbasak: I was expecting to see a "500" pin prio next to the u-a-t package from trusty-proposed, instead I see 400
[18:10] <rbasak> Your pastebin shows 500?
[18:11] <ahasenack> no
[18:11] <ahasenack> 19.6~ubuntu14.04.2 500
[18:11] <ahasenack>         400 http://br.archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64 Packages
[18:11] <ahasenack> that's 400
[18:11] <rbasak> Ah
[18:11] <ahasenack> oh, hm, what is the 500 next to the version?
[18:11] <ahasenack> is that the actual package-specific pin?
[18:12] <ahasenack> and the 400 below for the trusty-proposed line is the overall trusty-proposed pin prio?
[18:12]  * ahasenack uses better numbers
[18:12] <ahasenack> ok, yeah
[18:13] <ahasenack> https://pastebin.ubuntu.com/p/FFN7QKDwhh/ ok, I guess it is working
[18:15] <rbasak> I'm not sure what those two numbers mean
[18:16] <rbasak> "The APT preferences do not affect the choice of instance, only the choice of version."
[18:16] <rbasak> So it's the score by the version string that's important.
[18:16] <rbasak> I don't know what the score by the URL means
[18:17] <ahasenack> it's for the * package I guess
[18:17] <ahasenack> but yeah, I hadn't noticed the score next to the version ever before
[18:18]  * ahasenack tries another lengthy dist-upgade
[18:19] <gQuigs> can we clear our trusty-proposed except for the actively maintained bits (ua client)?  https://people.canonical.com/~ubuntu-archive/pending-sru.html
[18:23] <gQuigs> actually verification was done on https://bugs.launchpad.net/ubuntu/trusty/+source/gnutls26/+bug/1444656  before close of trusty...
[18:25] <gQuigs> I think the bcmwl  update should just be marked won't fix for Trusty and will proceed with doing that in a few...
[18:40] <mdeslaur> Skuggen: hi!
[18:42] <mdeslaur> Skuggen: I'm preparing a mysql 8.0.18 update for eoan, could you please sanity-check my changes before I upload it for building? There are a couple of new files, I want to make sure you agree with where I put them: https://paste.ubuntu.com/p/rcWrc4YDGK/
[18:49] <rbasak> mdeslaur: that looks reasonable to me
[18:49] <mdeslaur> thanks rbasak!
[18:49] <rbasak> mdeslaur: though I would like you to use QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index" please
[18:49] <rbasak> Saves extra noise in diffs
[18:50] <rbasak> mdeslaur: I'm assuming it passes dep8?
[18:50] <mdeslaur> rbasak: ah, thanks for the quilt config, I'll do that
[18:51] <mdeslaur> rbasak: haven't tested that yet
[18:52] <Skuggen> mdeslaur: Hi!
[18:53] <mdeslaur> Skuggen: hi there!
[18:53] <Skuggen> One thing: We support with_protobuf=system (as opposed to using the bundle-built ones), but we should probably test it out more to be sure, and we can make that change later
[18:53] <Skuggen> I think the protobuf version we build upstream is the same as the one in eoan
[18:53] <rbasak> Ah, so maybe we want that in Focal?
[18:53] <mdeslaur> Skuggen: sounds like a change for focal
[18:54] <mdeslaur> and only as long as he protobuf version won't change with point releases
[18:55] <mdeslaur> Skuggen: also, not sure if you care or not, but I had to disable the complete test suite on s390x on bionic with 5.7.28 as it was hanging: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+sourcepub/10686865/+listing-archive-extra
[18:56] <Skuggen> Yeah, I _think_ we'll change to use system protobuf for ubuntu in upstream packages as well, so should stay stable going forward.
[18:57] <Skuggen> About the ppc64el patch, you're sure it's not needed any more? I haven't really followed up on it, just see that our bug isn't closed
[18:57] <mdeslaur> Skuggen: most of the patch was already applied...a few parts weren't, but the package built and the test suite ran fine
[18:58] <Skuggen> Hm, maybe we have a duplicate bug for this I'm not aware of. I'll look into it and maybe get it closed, thanks :)
[18:58] <Skuggen> About s390x, do you know if there's any particular thing that hangs?
[18:59] <mdeslaur> unfortunately, I haven't had time to investigate further...
[18:59] <Skuggen> I think we only enforce the test results for amd64 and i386 for 5.7 builds
[18:59]  * mdeslaur orders s390x off of amazon
[18:59] <Skuggen> Hehe, yeah I don't really have anything except i386, amd64 and arm64 available :)
[19:00] <mdeslaur> and it runs fine with xenial and disco...
[19:01] <mdeslaur> I'm still awaiting autopkgtest results to make sure nothing regressed other than the test suite
[19:01] <Skuggen> Could it be related to the openssl change?
[19:01] <Skuggen> Though if it works on older releases maybe it's a change in a dependency that causes it
[19:02] <mdeslaur> I thought that may be the case, but I rebuilt the old one with openssl enabled, and it worked
[19:03] <mdeslaur> Skuggen: I'll figure out how to access an s390x builder box when I get a minute and if I figure it out, I'll let you know
[19:03] <Skuggen> Thanks!
[19:05] <mdeslaur> Skuggen: another question: with 8.0, when --skip-grant-tables is used, mysql 8.0 won't bind to a network port...is there any way to override that?
[19:06] <mdeslaur> "If the server is started with the --skip-grant-tables option to disable authentication checks, the server enables skip_networking to prevent remote connections. "
[19:06] <mdeslaur> this is causing php7.3 to FTBFS
[19:07] <Skuggen> Yeah, I saw. You could try --skip-networking=off, but I also mentioned it to rbasak that it didn't seem like skip-grant-tables was actually needed there
[19:07] <Skuggen> Since --initialize-insecure was used, the root user should be passwordless
[19:07] <mdeslaur> Skuggen: I tried --skip-networking=off and it didn't work
[19:08] <mdeslaur> oh hrm, interesting
[19:08] <mdeslaur> ultimately, we're starting an instance of mysql for nothing...none of the mysql tests even run since we moved to php7.0...
[22:21] <RAOF> ricotz: Hm. I think I may have a rather different opinion as to what goes into a bugfix-only release than the vala developers 😕
[22:34] <ricotz> RAOF, hmm?
[22:43] <RAOF> Oh, there just seen to be rather a lot of changes which don't fix a bug.
[22:43] <RAOF> (and are not obviously in the service of fixing a bug)
[22:43] <ricotz> RAOF, could you give an example?
[22:45] <ricotz> prevent asserts and correcting bindings might be easy, but fixing memory leaks are not that obvious to see in the plain diff, so are fixing c-warnings in the generated code
[22:47] <ricotz> RAOF, e.g. "Support static methods in error-domains" doesn't sound like bug-fix, but it actually is
[22:51] <RAOF> Aha!
[22:53] <ricotz> RAOF, irony?
[22:55] <RAOF> Oh, no. Just that it makes more sense.
[22:56] <ricotz> ok, the method implementations weren't emitted at all before
[22:56] <RAOF> I still want to know what the testing plan is (in the bug, please)
[22:56] <ricotz> of course the diff has grown a lot, given the age of the bug report
[22:57] <RAOF> Unless I've missed it!
[22:57] <ricotz> it is/was in the description which included a mass-rebuild at that time
[22:57] <RAOF> And quite a lot of the diff is generated code.
[22:58] <ricotz> use the link in the last comment
[22:58] <ricotz> https://gitlab.gnome.org/GNOME/vala/compare/0.40.8...0.40.17
[22:59] <RAOF> (the mass rebuild link appears to be broken?)
[23:01] <ricotz> I already commented including this information
[23:03] <RAOF> Ah, thanks. I didn't see that.
[23:05] <ricotz> RAOF, https://launchpad.net/~ricotz/+archive/ubuntu/vala-sru/+packages
[23:06] <RAOF> Ta
[23:08] <RAOF> Did you do any smoke testing on the resulting packages?
[23:10] <ricotz> RAOF, only a few in the past, many packages have a testsuite
[23:10] <ricotz> and a lot of the package are only generating a vapi from their gir
[23:26] <ricotz> RAOF, g2g, eod here
[23:27] <RAOF> Thanks for your clarifications!