=== blackboxsw is now known as blackboxsw_away
[07:04] <mwhudson> so i'm using the git-ubuntu merge workflow, which is generally great but now i have conflict markers in a patch :(
[07:48] <mwhudson> xnox: why are the systemd autopkgtests such a pain?
[08:40] <mpt> bdmurray, done
[12:18] <doko> xnox: the fix for ubuntu-image doesn't work: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/arm64/u/ubuntu-image/20181107_212237_630e2@/log.gz
[12:18] <doko> py3.5 is still skipped, but it wants to run 3.6 and fails due to missing extensions modules
[12:21] <doko> the good news is that the 3.7 tests succeed
[13:41] <doko> coreycb, jamespage: python3-defaults migrated, "reverse-depends src:python3.6" now gives you a better overview of pending openstack issues
[13:43] <coreycb> doko: ok thanks. they are my main focus but keep getting side-tracked.
[14:09] <xnox> doko, hm. not what i expected. i expected py36-nocov to end up with InterpreterNotFound as well
[14:12] <xnox> doko, python3.6 is still preinstalled in the cloud image that runs the tests
[14:13] <xnox> i guess it will, whilst anything still supports python3.6 in the archive =/
=== blackboxsw_away is now known as blackboxsw
[14:40] <seb128> bdmurray, hey, could you have another look to the gnome-initial-setup SRU to bionic/cosmic, I just replaced the previous one in the queue to fix an error, the new SRU fixes a problem with the one currently in proposed so it would be good to have it in
[15:06] <cpaelzer> rbasak: I was able to confirm that scons fix to work
[15:07] <cpaelzer> rbasak: I'd push my branch implementing that fix on top of the current salsa to "my" salsa
[15:07] <cpaelzer> and I'd update the bug referring to all that
[15:07] <cpaelzer> rbasak: would you need anything else to consider NMU/TMU helping on the case?
[15:14] <bdmurray> seb128: I'll have a look today
[15:15] <seb128> bdmurray, thx!
[15:17] <seb128> bdmurray, oh, while you are around I was curious if there was a particular reason you converted https://errors.ubuntu.com/problem/de2163c7e1ac3121ceee359e1cc10fe3bb471d7c to a launchpad bug
[15:17] <seb128> bdmurray, there has been no report in 17.10 and newer series which suggest the issue is fixed, and the number of report in xenial is rather low so I don't think it would qualify as important enough to justify a SRU to LTS-1
[15:18] <bdmurray> seb128: Is 1800 low? Oh maybe over a couple of years
[15:19] <seb128> bdmurray, sounds low to be, "common" issues on LTS series usually collect to 10k report by week
[15:19] <seb128> -to
[15:19] <seb128> bdmurray, 1900 since 16.04 it's like 3 reports a day
[15:20] <bdmurray> seb128: Okay, so then don't worry about it.
[15:20] <seb128> bdmurray, :-) I was about to close the bug but I was wondering if you had special reasons to open in, thx for the reply
[15:41] <rbasak> cpaelzer: looks like the maintainer isn't a DM or DD, and all his recent uploads have been sponsored.
[15:41] <rbasak> cpaelzer: I wonder if contacting the sponsor would help?
[15:41] <rbasak> cpaelzer: he's listed in Uploaders
[15:42] <cpaelzer> rbasak: Laszlo ?
[15:42] <rbasak> Yes
[15:42] <rbasak> Perhaps Cc the bug
[15:43] <cpaelzer> Sure I can give it another ping - and we can still consider doing an NMU later on
[15:43] <cpaelzer> will ping him
[15:44] <rbasak> cpaelzer: also maybe write to ...-submitter@bugs.d.o as the original submitter is a package maintainer also and might have an opinion.
[15:45] <cpaelzer> rbasak: the original submitter knows
[15:45] <cpaelzer> rbasak: I'm in contact with him on gpsd
[15:46] <rbasak> Ah OK
=== dkessel_ is now known as dkessel
[17:00] <bdmurray> seb128: Something is wonky with the g-i-s in cosmic the diff is empty
[17:02] <seb128> bdmurray, sorry, looks like I did dput the wrong file
[17:02] <bdmurray> seb128: okay, rejecting
[17:03] <seb128> bdmurray, reupload, looks better this time, http://launchpadlibrarian.net/396496950/gnome-initial-setup_3.30.0-1ubuntu3_3.30.0-1ubuntu3.1.diff.gz
[17:11] <seb128> bdmurray, thx
[17:21] <rbasak> Laney: around? Thank you for the MP. So does this mean the imagemagick dep8 on Bionic regressed with the upload of imagemagick 8:6.9.7.4+dfsg-16ubuntu6.4 but the failure is correct, the test is working - just not glib2.0 that's breaking it?
[17:21] <rbasak> Or is it a false positive caused by the security update?
[17:22] <rbasak> FWIW this is the part that bothers me - it feels like I'm unnecessarily blocking the glib2.0 SRU even by having to ask the question and investigate.
=== osx is now known as Toyo
[17:24] <rbasak> I feel that it should be sufficient to verify that the failure isn't caused by the glib2.0 SRU and proceed on that basis, leaving imagemagick behind, but this seems to be in conflict with what I've been told to do (unless I'm not being told to do that, or I'm permitted to make an exception in this case, but that's what I'm not clear about).
[17:26] <Laney> rbasak: I didn't really dig into the failure. It seems likely that 6.4 broke it, but I don't think we're required to figure that out for releasing further SRUs that happen to trigger it.
[17:27] <Laney> If you wanted, we could perform a run with imagemagick as the only trigger to verify that it fails in that case in the same way.
[17:28] <Laney> and then without actually investigating we'd know that some change in <the autopkgtest system> + <imamgemagick and its transitive dependencies> between 2018-08-30 and 2018-10-17 broke it
[17:33] <Laney> I guess we can do a little bit better if you happen to know about ubuntu-security-proposed ppa runs: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-ubuntu-security-proposed-ppa/bionic/amd64/i/imagemagick/20180928_205901_0b4c9@/log.gz
[17:39] <Laney> Which looks a little bit like the security team might have investigated... :-)
[17:55] <rbasak> Laney: I'd like to clarify on the ML what to do in this case, but I'm out of time today :-/
[17:55] <rbasak> I'll post tomorrow. Sorry for the delay.
[17:55] <Laney> Alright, no worries.
[17:55] <Laney> sbeattie: ^- (pinging you since you uploaded imagemagick/bionic-security, not to blame) - what do you do with the autopkgtest results in triggered for security uploads?
[17:56] <Laney> It looks like that update made the tests go to red, so I'm wondering if that gets noted / assessed / something.
[17:56] <rbasak> For reference: http://autopkgtest.ubuntu.com/packages/imagemagick/bionic/amd64
[17:57] <rbasak> and https://code.launchpad.net/~laney/britney/hints-ubuntu-bionic-glib2.0/+merge/358449
[17:57]  * Laney nods
[17:58] <sbeattie> Laney: currently the autopkgtests on the security-proposed ppa are a new thing to us, so we don't often look at them. But we should change that.
[17:59] <Laney> ah, OK, that would be good :-)
[17:59] <Laney> I was pleased to see that they're being run
[18:00] <sbeattie> Okay, the failure there is due to the configuration change to disable pdf support by default in the policy definition for imagemagick.
[18:01] <sbeattie> (because that gets handled by ghostscript for imagemagick, and ghostscript unfortunately has had a ton of security vulnerabilities around handling things safely)
[18:02] <Laney> That's fine if it's deliberate, and it sounds like the right thing to do is to update the tests
[18:03] <rbasak> Sounds like a force-badtest is the right thing to do then.
[18:03] <Laney> (Not saying that has to be done now, but if there's a good way to stage it for the next upload ...)
[18:03] <Laney> Agreed
[18:36] <ahasenack> what's the appropriate way to fix a package that was uploaded to -proposed as part of an sru, verification failed, and the error was found, meaning a new upload has to happen, with regard to the changelog?
[18:37] <ahasenack> In this case (https://pastebin.ubuntu.com/p/mTCwhtDB7S/),
[18:37] <ahasenack> verification-failed is 2:4.7.6+dfsg~ubuntu-0ubuntu2.3
[18:37] <ahasenack> and the good one will be 2:4.7.6+dfsg~ubuntu-0ubuntu2.4
[18:37] <ahasenack> a) should I do it like it's in the pastebin?
[18:37] <infinity> ahasenack: That's fine, yes.
[18:37] <ahasenack> b) should I use the changelog message from 2.3 in the new 2.4?
[18:37] <ahasenack> (ignoring 2.3)
[18:38] <infinity> ahasenack: No need to erase 2.3 from history.
[18:38] <ahasenack> so like that is fine?
[18:38] <infinity> ahasenack: If there were a bug for the regression, you'd address that in the 2.4 upload, but if the bug was just noted in a comment on the original, the way you've done it is fine.
[18:38] <ahasenack> great, thanks
[23:21] <WoC> in a multi-arch installation, is there any tool that can grab the sources for the packages  installed on a system and create a local repository for the packages not in the public repositories ? (ppc64)
[23:24] <sarnold> do you mean, from ports.ubuntu.com or .. something else?
[23:35] <WoC> sarnold, yes
[23:35] <WoC> since there are no ppc64 pkgs pre-compiled
[23:37] <sarnold> WoC: hmm, can you specify what you mean? e.g. http://ports.ubuntu.com/ubuntu-ports/pool/main/b/bash/bash_4.4.18-2ubuntu3_ppc64el.deb is a precompiled ppc64 pacakge..
[23:38] <WoC> i got big endian
[23:38] <sarnold> oh.
[23:38] <sarnold> so you've got a big project ahead of yourself :)
[23:38] <WoC> ppc64el is incompatible
[23:38] <WoC> aye, ust trying to find out if there is already some tools for it
[23:39] <WoC> the Machine i got is a Dual cpu power mac g5
[23:39] <sarnold> WoC: wild guess time, try adding [arch=ppc64el] deb-src http://ports.ubuntu.com/ubuntu-ports/ ...
[23:40] <sarnold> then you might be able to use apt-get source ... to download the packages to the current working directory
[23:40] <sarnold> (is the arch bit even needed? hrm.)
[23:41] <WoC> ty, i'll try
[23:41] <WoC> hopefully it wont cross compile to ppc64el
[23:43] <sarnold> WoC: btw if you just want a working system, adelie linux has gone to some effort to support BE
[23:49] <WoC> Oh, never heard of, link ?
[23:50] <sarnold> WoC: https://www.adelielinux.org/about.html
[23:51] <WoC> ty
[23:52] <WoC> I do run ubuntu on all my other computers, so I would really like to run it on the G5 as well, but not as a 32 bit system