[02:27] <lamont> is it bad that I did a dist-upgrade on wily and time stopped on my topbar?
[02:27]  * lamont reboots for giggles
[06:58] <pitti> juliank, cyphermox: seb128 pointed  out the upower bug to me yesterday, but I wasn't aware of that reproducer, thanks!
[07:01] <pitti> cyphermox: I suppose bug 1547518 is just a duplicate of that
[08:22] <dholbach> good morning
[08:37] <doko> pitti, python3.5's libreoffice hint needs a version update
[08:42] <pitti> done
[08:59] <Mirv> is there someone to whom cookies, TLDs and rfc6265 ring a bell? something changed between Wed and Fri last week causing bug #1548686, and I'm wondering if it's Ubuntu or something on the Internet (but builders shouldn't have access to the network anyway so I guess nothing should normally change)
[09:04] <LocutusOfBorg> slangasek, probably :D
[09:10] <Mirv> well I'm testing a wily build now. if it succeeds, something changed in xenial. if it fails too, something changed in the world.
[09:39] <doko> sil2100, the last ubuntu-keyboard upload still depends on fonts-droid
[09:39] <sil2100> eh, let me get the dev
[10:48] <ginggs> pitti, xnox: what is the reason for keeping pybootchartgui around until *after* the LTS? LP: #1353587 It is one of the three packages remaining in Ubuntu that directly depend on python-support
[10:49] <pitti> ginggs: I thought xnox wanted to keep it for measuring ubuntu-touch
[10:49] <pitti> I don't mind removing it, we can always get it from wily or a PPA, though
[10:49] <pitti> on touch you can't directly apt-get install it anyway
[10:51] <ginggs> pitti: sounds good, what else needs to be done to get rid of python-support? LP: #1535318
[10:52] <ginggs> shall I add the rdepends as affected packages?  they are listed in the bug description
[10:54] <pitti> yeah, makes them easier to find
[11:03] <ginggs> pitti: launchpad had a few timeouts, but i've now added firmware-addon-dell and qdigidoc (but not the reverse-recommends bootchart and phablet-tools)
[11:07] <Mirv> ok qtbase succeeded on wily so the bug is on xenial
[12:05] <Odd_Bloke> rbasak: How is work on the git importer going?
[12:07] <rbasak> Odd_Bloke: check with nacc please
[12:07] <rbasak> Odd_Bloke: BTW, I have some tooling to import things manually, apart from one tweak to the format of the commit that cjwatson convinced me to make.
[12:07] <rbasak> (if that's helpful to you)
[12:16] <Odd_Bloke> rbasak: Ack, will do; I didn't see him online yesterday so didn't know if he was on VAC or somesuch. :)
[12:16] <Odd_Bloke> rbasak: We're happy to wait; just don't want to wait unnecessarily. :p
[12:32] <Saviq> pitti, hey, shouldn't the qtmir/qtmir-gles builds against proposed mir be proposed qtmir, too? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mir
[12:45] <pitti> Saviq: normally not, as they are separate packages
[12:46] <pitti> Saviq: you can either force that by versioned Depends:/Breaks: (if the new mir breaks qtmir, that's cleaner), or if this is a test-only issue I can also re-run them against all of -proposed
[12:47] <Saviq> pitti, I thought this was taken care of (like you guys marked mir and qtmir to always run together from -proposed)
[12:48] <pitti> Saviq: no, there's no way to mark that
[12:48] <pitti> Saviq: the way to say "foo/2 can only work with bar >= 3" is "Depends: bar (>= 3)" :)
[12:49] <Saviq> pitti, well, yeah, it'd have to be Breaks: in this case, since it's the old qtmir that fails with new mir
[12:49] <Saviq> and that's expected
[12:50] <Saviq> pitti, can you tell why the armhf version tested was the -proposed one, actually?
[12:50] <pitti> Saviq: it hasn't been tested yet
[12:50] <pitti> autopkgtest for qtmir 0.4.7+16.04.20160219-0ubuntu1: armhf: Test in progress
[12:50] <pitti> that version is meaningless
[12:50] <Saviq> ack
[12:50] <pitti> and I have a work item to not show it
[12:51] <pitti> Saviq: so, want me to re-run against all of -proposed?
[12:51] <doko> pitti, please hint diffoscape for python-setuptools
[12:51] <Saviq> pitti, well, can you please restart them with all of -proposed and I'll file a bug against mir to add Breaks: as part of a release
[12:52] <pitti> Saviq: queued
[12:52]  * Saviq always felt weird about Breaks:, not that I have a better solution...
[12:52] <pitti> doko: it already had a hint, bumped the version
[12:53] <pitti> that'd be another useful case of hinting diffoscope/ppc64el instead of a version
[12:53] <pitti> Saviq: well, it's weird in either case -- that means that Mir broke its ABI without bumping the soname?
[12:55] <Saviq> pitti, well, actually... the real problem is likely the dummy test qtmir has - it really just tries to rebuild the package, which fails against new Mir
[12:55] <Saviq> /likely/
[12:55] <Saviq> pitti, I meant to drop that test since it ~doesn't make sense in autopkgtest
[12:56] <Saviq> it was my try to find out when a package in proposed would break a downstream build
[12:58] <xnox> ginggs, pitti: indeed, touch uses upstart. i don't mind, we can drop it. Or like port it to dh_python[23] which should not be that hard.
[12:58] <Saviq> pitti, a Breaks: doesn't make sense here, either, exactly why you said - sonames are bumped as needed, so that will enforce dependencies to be correct
[13:16] <pitti> doko: FYI, before you waste time on the libgps21 NBS: I filed bug 1548811, will track that down
[13:21] <doko> pitti, I think I filed one too ... can't find it
[13:21] <doko> pitti: what was the outcome for gsoap, override the virtualbox test failure?
[13:24] <ginggs> xnox: how was firmware-addon-dell 'fix released'?
[13:26] <xnox> ginggs, it doesn't build-depend nor use python-support.
[13:27] <xnox> ginggs, Convert to dh_python2. -> since 2013. So no actions are needed for it.
[13:27] <ginggs> xnox: true, i only added it today because it is a reverse-depends of firmware-tools (see comment #34 in that bug)
[13:27] <xnox> ginggs, yeah, that one still needs fixing, which i'm doing.
[13:27] <xnox> ginggs, it doesn't make sense to add reverse-depends like that.
[13:28] <ginggs> xnox: noted.  the only other reverse-depends i added there was qdigidoc
[14:05] <pitti> doko: ah, can do
[14:21] <xnox> ginggs, once my uploads migrate, i believe we will be good to remove python-support.
[14:22] <ginggs> xnox:  \o/
[14:23] <ginggs> xnox: i see you uploaded rather than removing, what do you think of fixing firmware-extract which was removed?
[14:23] <ginggs> i believe it's a plugin for firmware-tools
[14:24] <xnox> ¯\_(ツ)_/¯ -> really not my problem =) and i have no clue what these tools are, and wether they work at all anymore.
[14:24] <doko> pitti, ta, python-setuptools now waits for britney to learn about the fixed python-pex
[14:26] <xnox> ginggs, i think all of that is replaced with uefi capsules updates these days, rather than firmware-tools stuff.
[14:26] <xnox> superm1, are firware-tools still in use/required to do things?
[14:27] <superm1> xnox: not on workstation or client
[14:27] <superm1> Possibly on server
[14:27] <xnox> superm1, well it gained brand new support for dh-python2 instead of python-support, so it will live another lts untouched, hopefully =)
[14:38] <sil2100> LocutusOfBorg: hey! Is there an LP bug for getting rid of fonts-droid ?
[14:41] <seb128> sil2100, see "Fonts-droid has been deprecated and removed, please update your dependency :)" on ubuntu-devel@
[14:41] <seb128> you replied to that discussion you should know about it?
[14:42] <seb128> there is a bug mentioned in the discussion as well
[14:45] <seb128> shrug, did optipng become slower on xenial? I remember it taking a while but now it takes ages it feels like
[14:51] <LocutusOfBorg> sil2100, nope, I didn't open any bug :)
[14:58] <sil2100> seb128: yeah, I know, I didn't remember seeing a bug on the initial e-mail
[14:58] <sil2100> But there was one later on I see now
[15:03] <smoser> hey. we're seeing server iso test failures
[15:03] <smoser> https://platform-qa-jenkins.ubuntu.com/view/smoke-default/job/ubuntu-xenial-server-amd64-smoke-default/59/
[15:04] <smoser> what seems key there to me is the syslog: https://platform-qa-jenkins.ubuntu.com/view/smoke-default/job/ubuntu-xenial-server-amd64-smoke-default/59/artifact/log/utah-10459.syslog.log
[15:04] <smoser> which shows failure to install packages because of
[15:04] <smoser> The following packages have unmet dependencies:
[15:04] <smoser>  libpam-systemd : Depends: systemd (= 229-1ubuntu2) but 229-1ubuntu4 is to be installed
[15:04] <smoser>  lxc : Depends: iptables but it is not going to be installed
[15:04] <smoser> Unable to correct problems, you have held broken packages.
[15:05] <smoser> the word 'held' seems probably important there. the install seems to have access to the archive, but I dont know why 'iptables' would not be available.
[15:19] <Kryczek> smoser: may I ask what tool chain do you use to build server ISOs? I tried to look at the log but I am guessing it is firewalled :)
[15:20] <smoser> Kryczek, fudge. i can pastebin the log for you.
[15:20] <smoser> i'm pretty sure its 'debian-cd'
[15:20] <smoser> but i've never actually touched any of that.
[15:21] <smoser> i'd have to ask cyphermox  or infinity for that info.
[15:21] <smoser> Kryczek, http://paste.ubuntu.com/15180824/
[15:22] <cyphermox> yes, CDs are built by debian-cd, among other things
[15:22] <cyphermox> that's not a cd build issue though
[15:23] <cyphermox> it happens regularly that systemd isn't done transitioning, that's usually fixed by the next build
[15:23] <Kryczek> ah ok, not the Debian Live (live-build) tool chain then? Just wanted to point out that it is unmaintained unfortunately
[15:23] <cyphermox> oh, missing iptables too
[15:24] <utlemming> pitti: er, seeing something really odd. If you define 'console=ttyS1' for the kernel CLI, then systemd just hangs
[15:24] <Kryczek> smoser: thank you for the paste
[15:24] <utlemming> pitti: the change happened about a week ago
[15:24] <cyphermox> Kryczek: some builds do use live-build, I'm not sure which precisely.
[15:25] <doko> pitti, barry, virtualenv still triggers test failure for tox
[15:25] <Kryczek> cyphermox: would be funny if it was "precise" ;D
[15:25] <smoser> cloud-image builds use live-build
[15:25] <cyphermox> there we go ;)
[15:25] <smoser> cyphermox, 'isnt done transitioning'
[15:25] <smoser> ?
[15:26] <smoser> as in only parts of systemd got into xenial/ from xenial-proposed  ?
[15:27] <barry> doko, pitti yeah, that makes no sense and i can't reproduce it locally :(  any thoughts on how to debug the problem?
[15:27] <pitti> manjo: what's the status on bug 1548120? it's "block-proposed", and thus blocks further uploads of i-t
[15:28] <cyphermox> smoser: the systemd failing to install in that paste means, IIRC, that systemd wasn't all done moving from proposed to releae at the time the CD was built, yeah. I may be oversimplifying this, but it's an issue that happens with the dailies and you don't have to do anything special.
[15:29] <pitti> barry: socket.timeout: timed out
[15:29] <pitti> barry: is that trying to call out to the interwebs without using the $*_proxy vars perhaps?
[15:31] <manjo> pitti, I need to test apw's version of the patch
[15:31] <barry> pitti: do you see that timeout in the tox test?  i don't
[15:32] <pitti> requests.packages.urllib3.exceptions.ConnectTimeoutError: (<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7faf4e29dd68>, 'Connection to pypi.python.org timed out. (connect timeout=15)')
[15:32] <pitti> barry: this looks pretty clear?
[15:32] <pitti> I mean that it tries to get stuff from the network, apparently not using the proxy?
[15:32] <barry> pitti: yes, but which log is that in?
[15:32] <apw> pitti, i made it block-proposed deliberatly because what is in the current -proposed isn't something i want out
[15:32] <pitti> barry: the one linked from excuses, e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/t/tox/20160222_203430@/log.gz
[15:33] <pitti> apw: ok; my upload isn't urgent at all, so ok for now
[15:33] <apw> pitti, if you want to send me over the diff i can merge it with the "next" one
[15:33] <apw> with the fixed fix for this mess
[15:34] <barry> pitti: i'm looking at 20160223_blah
[15:35] <barry> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/t/tox/20160223_151914@/log.gz
[15:35] <barry> it ends in pkg_resources.extern import error
[15:35] <pitti> ah, that's a different one indeed
[15:36] <barry> pitti: you'd expect that to be locally reproducible with, e.g.: `adt-run tox -- schroot xenial-amd64` yeah?
[15:36] <pitti> --apt-pocket=proposed -U tox
[15:36] <barry> (assuming of course -proposed is enabled in that chroot)
[15:36] <pitti> but I just run that (with qemu), and it works
[15:37] <barry> pitti: yeah, that's weird right? :)
[15:37] <smoser> cyphermox, hm.. well, it'd seem a general issue if we're moving parts of a source package at a time from -proposed.
[15:37] <smoser> i'd have thought that would be all at once for a source package.
[15:37] <cjwatson> it's not possible to move parts of a source package at once, so no, that doesn't happen
[15:38] <barry> pitti: the error happens when trying to install pytest>=2.3.5, pytest-timeout.  we have pytest 2.8.7.  yeah it passes for me too
[15:40] <smoser> cjwatson, not possible ?
[15:41] <smoser> as in only one binary package can be moved at a time?  or just as in not implemented.
[15:42] <cjwatson> what
[15:42] <cjwatson> no, the opposiute
[15:42] <cjwatson> the primitive operation here is "copy source package (with binaries)"
[15:42] <smoser> right.
[15:42] <smoser> thats what i would have thought.
[15:42] <smoser> so then it must be the 'held' part of the message that causes the failure ?
[15:43] <smoser> "Unable to correct problems, you have held broken packages."
[15:43] <cjwatson> not relaly
[15:43] <cjwatson> the message you quoted does not contain enough information to work it out
[15:43] <smoser> woudl you take a look at the link or the paste ?
[15:43] <cjwatson> "is not going to be installed" is apt-speak for "this package is available, but when I try to install it I get broken dependencies, and I'm not going to tell you why"
[15:44] <cjwatson> apt typically doesn't print enough information to diagnose this class of problem just from its output
[15:44] <cjwatson> you have to set up a matching environment (in chdist or whatever) and test-install things with increasing constraints until it gives you useful answers
[15:44] <cjwatson> however, in this case it could be that the squashfs base system is out of date
[15:45] <smoser> i'd guess you're right that the squashfs is out of date.
[15:45] <smoser> but then why wouldn't it pull whatever it needs from the archive.
[15:46] <cjwatson> well, we could spend hours investigating that, or I could go fix the stuck builds that are causing the OOD squashfs
[15:46] <cjwatson> the latter being the correct solution anyway :)
[15:46] <pitti> barry: I just ran it in production (manually), and get the socket timeouts again
[15:46] <sil2100> LocutusOfBorg: hey! Could you answer some questions regarding the fonts-droid deprecation to Elleo?
[15:46] <sil2100> LocutusOfBorg: Elleo is the person responsible for ubuntu-keyboard
[15:46] <cjwatson> the key bit of log output here is noting the presence of "Parallel build" near the top of http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/xenial/daily-20160223.log
[15:47] <sil2100> And it seems the switch of that is not as obvious
[15:47] <smoser> so what is to be done to fix stuck builds ? im' fine with that other than it just means this happens at some other point.
[15:47] <Elleo> LocutusOfBorg: heya, just removing fonts-droid we lose some characters we need for chinese, but it seems impractical to replace it with fonts-noto-cjk as that's nearly 100MB larger than fonts-droid (and space is a concern issue on touch images)
[15:47] <cjwatson> when more than one build is happening at once on cdimage, then we don't sync the archive because doing that in the middle of another build is bad news
[15:48] <cjwatson> this is normally allowable, but if it gets confused for some reason then we can end up *never* syncing cdimage's mirror
[15:48] <Elleo> LocutusOfBorg: unless you know of any other smaller font package that could do the job?
[15:48] <cjwatson> and that's bad, and eventually people notice due to this kind of thing
[15:48] <cjwatson> now, I fixed most of the common causes for this a while back
[15:48] <cjwatson> but I suspect that the reboot of nusakan the other day happened at a suboptimal time, and left some confusion around
[15:49] <cjwatson> because the semaphore of "how many builds are running" has a value two higher than it ought to be
[15:50] <LocutusOfBorg> Elleo, fonts-droid-fallback?
[15:50] <cjwatson> so I've manually decremented it twice ("semaphore decrement-test /srv/cdimage.ubuntu.com/etc/.sem-build-image-set" as cdimage@nusakan) and that should clear things once the build that's currently in flight finishes
[15:50] <barry> pitti: can you figure out what it's trying to download from pypi?  odd too that the timeout is completely different from the autopkgtest log traceback
[15:50] <LocutusOfBorg> or fonts-noto?
[15:50] <LocutusOfBorg> I don't know about the chinese issue, and I'm not understand why debian is not aware of it
[15:50] <Elleo> LocutusOfBorg: fonts-noto doesn't include chinese characters
[15:50] <barry> pitti: and *that's* strange because the traceback doesn't at all match the code i get locally when i create the tox environment form the `built` test
[15:51] <Elleo> LocutusOfBorg: will give fonts-droid-fallback a go and see if that has what we need
[15:51] <cjwatson> logs suggest that this situation started on the 20th, which would match up with nusakan's reboot on the 19th
[15:51] <pitti> barry: it's not, it's exactly the same log as https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/t/tox/20160223_151914@/log.gz
[15:51] <pitti> barry: as for that other error, I don't know what that means, maybe transient?
[15:52] <LocutusOfBorg> thanks Elleo
[15:52] <Elleo> LocutusOfBorg: I don't see a fonts-droid-fallback package anywhere?
[15:52] <barry> pitti: okay, but in that log file you just pasted, search for "socket".  the only 2 occurrences have nothing to do with socket.timeout
[15:52] <smoser> cjwatson, thank you. we'll hope it works itself out.
[15:52] <smoser> nuclearbob, ^ matsubara ^
[15:53] <cjwatson> I think maybe ideally we'd have a sort of multi-pid-file rather than a counting semaphore there
[15:53] <cjwatson> then it would be possible to automatically recover from this sort of situation
[15:53] <cjwatson> but fortunately it's not all that common after the fix I applied in December
[15:53] <cjwatson> (cdimage r1557)
[15:53] <pitti> barry: sorry, that was the link you posted; I meant https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/t/tox/20160222_203430@/log.gz
[15:53] <matsubara> thanks cjwatson for kicking things again
[15:53] <LocutusOfBorg> Elleo, https://launchpad.net/ubuntu/+source/fonts-android
[15:53] <matsubara> and you too smoser
[15:54] <LocutusOfBorg> fonts-droid-fallback_6.0.1r16-1_all.deb (1.7 MiB)
[15:54] <barry> pitti: ah 20160222
[15:55] <Elleo> LocutusOfBorg: ah, thanks
[15:55] <nuclearbob> smoser: fwiw, the problem seemed to be that the already installed version of systemd (presumably in the squashfs) was higher than the version of libpam-systemd in /pool on the cd
[15:55] <barry> pitti: so, if we ignore 20160223 and look at 20160222, then maybe i can make more progress, but it bothers me that we have two different failures, neither of which is reproducible locally ;)
[15:57] <cjwatson> nuclearbob: ah yes, that's why it doesn't just pull whatever it needs from the archive, because in this case that archive is on the ISO and the result would be a downgrade
[15:57] <barry> pitti: is there a way for you to run tests on production without an upload?
[15:57] <pitti> barry: yes (that's what I just did)
[15:57] <cjwatson> and apt doesn't do downgrades by default
[15:57] <smoser> but how would the archive have older ?
[15:57] <pitti> barry: I can also run it, use --shell, and then give you ssh to it
[15:57] <smoser> the cd was built from the archive
[15:57] <cjwatson> smoser: not quite
[15:57] <cjwatson> smoser: it was built from an rsynced mirror of the archive
[15:57] <cjwatson> smoser: which, due to the situation explained above, hadn't actually been rsynced for several days
[15:58] <cjwatson> smoser: but the squashfs is built on LP directly from the archive
[15:58] <barry> pitti: that could help.  what i'm thinking is that i could make an educated guess as to the failure, make a change and hand you a source package to see if production passes or not
[15:58] <smoser> ah.
[15:58] <smoser> ok. that makes sense then.
[15:58] <cjwatson> so if cdimage's mirror gets stuck this way then it's possible for it to be older
[15:58] <barry> pitti: but ssh would definitely let me poke around some more
[15:58] <barry> (i.e. put the "educated" in "educated guess" :)
[15:59] <cjwatson> in normal circumstances it isn't possible for it to be older, because we deliberately try to sync the archive after doing the squashfs build
[15:59] <cjwatson> for exactly this kind of reason
[15:59] <pitti> barry: ok, it'll take some minutes until the test finished
[16:04] <Elleo> LocutusOfBorg: fonts-droid-fallback seems to work thanks, still need to test it a bit more to be absolutely certain but it looks promising
[16:07] <LocutusOfBorg> wonderful!
[16:07] <LocutusOfBorg> thanks a lot for the feedback/fix
[16:15] <pitti> apw: the transitional linux-meta packages on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt -- these should be seeded, I suppose?
[16:19] <apw> pitti, a good point, do we have to seed them alllll explicity or is there something else we should be doing in the kerenl package
[16:19] <pitti> apw: they are just for upgrades from previous releases, they'll all go after xenial, right?
[16:20] <apw> pitti, that indeed
[16:20] <pitti> apw: so they won't be a dependency of anything, hence they need seeding, yes
[16:20] <pitti> apw: if *all* binaries from linux-meta should be in main, then seeds have a syntax for that
[16:22] <apw> pitti, i don't believe we have any primary packages (.deb) which are not for main in any of our packages
[16:23] <apw> pitti, but that they are listed explicity is worrysome
[16:23] <pitti> apw: in supported-kernel-common? yeah
[16:23] <pitti> apw: and a lot of them are obsolete too
[16:24] <pitti> supported-kernel-common: * linux-signed-generic-lts-quantal
[16:24] <apw> pitti, i would normally look at infinity at this point, as he would have gotten us as far as here
[16:24] <pitti> apw: I figure it'd be a lot simpler to just replace all of that with "all sources of linux-meta" (whatever the syntax was)
[16:24] <pitti>  * (srcpkgname)
[16:24] <pitti> perhaps?
[16:25] <apw> pitti, i can't see a reason that would be wrong these days, we did use to have split flavours once-upon-a-time
[16:25] <pitti> ah no, those were recommends
[16:25] <pitti> apw: aah, man germinate
[16:26] <pitti>  * %linux-meta
[16:26] <pitti> apw: ^ this should do it
[16:29] <apw> pitti, cool thanks for fixing our messes :)
[16:30] <pitti> apw: oh, I wasn't actually changing the seeds, but I can if you confirm that's the right thing
[16:30] <pitti> that == all binaries of linux-meta
[16:30] <apw> pitti, i'll take it and figure that out definatlvly and get back to you
[16:31] <apw> (or to me, depending)
[16:32] <pitti> apw: I figure we could start with replacing the entire supported-kernel-common with just %linux-meta, and then see what falls out of that?
[16:32] <pitti> i. e. wait for a publisher cycle and check component-mismatches
[16:32] <apw> pitti, if its not going to cause chaos, that sounds like a plan
[16:32] <pitti> apw: well, I figure kexec-tools and thermald should stay, but all others
[16:33] <pitti> apw: no, not at all; supported-* isn't defining images, just stuff that's in main despite *not* being on any image
[16:33] <pitti> apw: we might have soem linux-meta-$flavor which should stay in universe, all others should be there in the seed
[16:34] <apw> pitti, we have other linux-meta-foo sources which produce things whihc should be, but not from linux-meta i don't think any more
[16:34] <apw> 'should be in universe"
[16:37] <cjwatson> snakefruit (proposed-migration, people.canonical.com/~ubuntu-archive/, etc.) will be going down for reboot for a little while shortly; I've shut down archive cron jobs there in preparation
[16:53] <cjwatson> snakefruit back
[16:53] <cyphermox> pitti: could you point me to your bug about setting up multiple crypted drives in the installer you mentioned yesterday? I can't find it anymore
[16:54] <pitti> cyphermox: bug 1548252 ?
[17:03] <nacc> slangasek: now that FF is in effect, how do syncs with Debian work? e.g., for php7.0 to pass its autopkgtests, we need (at least) php7.0.3-6 (7.0.3-7 is in unstable as well). Do I need to file a bug to request the sync (technically it's mentioned in LP: #1547738)
[17:04] <nacc> slangasek: actually, i guess they are merges now, since we have a delta ... I can do that merge (and I think we can drop some of the delta now that xmlrpc-epi is in main). So would i put the resulting debdiff in that bug then? and mark it as a FFe?
[17:05] <cyphermox> pitti: thanks
[17:14] <jdstrand> tyhicks: fyi, not sure if you noticed but your apparmor upload got stuck
[17:15] <jdstrand> tyhicks: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says 'autopkgtest for systemd 229-1ubuntu4: ppc64el: Test in progress'
[17:15] <jdstrand> tyhicks: iirc, it has said that for days
[17:18] <pitti> ah, that's not tyhicks's bug
[17:18] <pitti> sorry, I'll unstick it
[17:19] <tyhicks> thanks pitti!
[17:21] <pitti> i. e. I re-run the test, the reason for the temporary failure got fixed
[17:21] <jdstrand> cool
[17:21] <jdstrand> thanks pitti :)
[17:22] <jamespage> pitti, thanks for working the tomcat8 transition through btw
[17:23] <doko> nacc, slangasek: it's not yet available for syncing, doing it later
[17:25] <nacc> doko: 7.0.3-6 is available, i think ... but we can wait for -7, do you want a debdiff for the merge to do it?
[17:26] <cjwatson> smoser: OK, I might have accidentally slipped and rewritten cdimage's locking code so that it tracks multiple pids rather than just a count and automatically removes dead processes from its tracking.  Not committing it quite yet because there are builds in progress, but I'll deploy it once everything's quiet.
[17:26] <cjwatson> http://paste.ubuntu.com/15181704/
[17:29] <doko> nacc, no, will sync it when I'm back home tonight
[17:29] <nacc> doko: ok, thanks!
[17:38] <xnox> pitti, doko, cjwatson: please RM python-support
[17:38] <xnox> https://bugs.launchpad.net/ubuntu/+source/python-support/+bug/1535318
[17:38] <pitti> w00t!
[17:38] <xnox> all clear.
[17:39] <doko> me, me ...
[17:39] <pitti> doko: do you want to ... have the honor?
[17:39] <pitti> yeah, I'll leave it to doko, he really deserves it more
[17:40] <pitti> . o { https://launchpad.net/~ubuntu-cruft-busters ! }
[17:46] <doko> Comment: fiiiiinally, lp: #1535318, remove python-support
[17:46] <doko> 1 package successfully removed.
[17:51] <xnox> doko, i see that landscape client is python2 and twisted, do we have working python-twisted-conch|-core|-web in python3 yet?
[17:52] <xnox> i see that those bits are in python3-twisted.
[17:55] <doko> xnox, yes, everything which is in the package should be supported
[18:00] <Pharaoh_Atem> nacc: did you see my message on LP #1547738?
[18:05] <seb128> bdmurray, hey, do you have any opinion on https://code.launchpad.net/~seb128/software-properties/newtab-enable-proposed/+merge/286626 ? I know you suggested dropping it but that let a graphical way to enable proposed and that's what willcooke suggested doing after talking to ara and mpt
[18:05] <nacc> Pharaoh_Atem: yeah
[18:05] <seb128> I've no opinion either way, I think it's better than we have now so I'm trying to land it, we can still do other changes later if something else is decided
[18:07] <bdmurray> seb128: I think I suggested dropping it if the release is still in development, but I didn't see an easy way to do that. And yes this does seem like an improvement.
[18:13] <nacc> Pharaoh_Atem: it should get sync'd tonight
[18:15] <xnox> barry, is there 2to2and3 tool yet? cause the output 2to3 generates is questionable.
[18:15] <xnox> e.g. ideally i want "from __future__ import print function" et.al.
[18:16] <barry> xnox: http://python-future.org/automatic_conversion.html
[18:17] <xnox> omg, i love this "pasteurize"
[18:17] <barry> cute, huh? :)
[18:25] <nacc> slangasek: doko: if we want to pull the xmlrpc binpkg back in, when we sync with 7.0.3-7, would you want a bug & debdiff for that?
[18:49] <Pharaoh_Atem> nacc: is that tonight in US timezone or UK timezone?
[18:50] <nacc> Pharaoh_Atem: doko's timezone :)
[18:50] <Pharaoh_Atem> so CEST+1
[18:51] <Pharaoh_Atem> which means it'll sync now?
[18:51] <Pharaoh_Atem> ;)
[18:51] <nacc> Pharaoh_Atem: it'll sync when it syncs :)
[18:56] <nacc> Pharaoh_Atem: would you have some time to look at LP: #1548442 ?
[19:07] <Pharaoh_Atem> nacc: yeah, sure
[19:08] <nacc> Pharaoh_Atem: thanks, working on package builds and stuff
[19:55] <Pharaoh_Atem> errm
[19:56] <Pharaoh_Atem> I'm getting hash sum mismatch errors for "apt update" in universe
[19:57] <sarnold> try again in a few minutes
[19:57] <nacc> Pharaoh_Atem: yeah, it happens :)
[20:44] <coreycb> arges, bdmurray, Hi, we have a ceilometer SRU in the wily queue that could use a review
[20:48] <arges> coreycb: ok
[20:51] <coreycb> arges, thanks
[20:52] <Pharaoh_Atem> nacc: welp, I'm getting two different errors on two different machines (ubuntu 16.04 + php7.0-7.0.3-3, CentOS 7.2 + php70-7.0.3-1.el7.remi)
[20:52] <Pharaoh_Atem> and the best part? neither of them are giving me the error you got
[20:56] <Pharaoh_Atem> I'm compiling php7.0-7.0.3-6 for debian 8 and giving it a go to figure out what's going on here
[21:05] <arges> coreycb: so bug 1530913 is going to be superceedd by this
[21:06] <coreycb> arges, yes, that was the prior point release
[21:07] <arges> coreycb: well it is still in proposed, does it need to be released first, or is this bug fixing something with that
[21:07] <coreycb> arges, oh..  I didn't realize that.  no as far as I know the old one was tested and is ok.
[21:08] <arges> coreycb: ok
[21:08] <coreycb> arges, thanks, let me know if it's stuck for a reason
[21:08] <arges> coreycb: ok done
[21:09] <coreycb> arges, thanks1
[21:09] <coreycb> explanation point fail
[21:09] <coreycb> I can't type
[21:49] <nacc> Pharaoh_Atem: ok, thanks, the above was seen was with 7.0.3-5
[22:11] <slangasek> nacc: FFe is only needed if the changes you're making (whether by merge from Debian or otherwise) are features.  If this is just bugfixes, no FFe is required.
[22:12] <slangasek> doko: sorry, don't know why you hightlighted me, what was not available for syncing?
[22:13] <nacc> slangasek: i think php7.0.3-7, just for your reference
[22:13] <slangasek> ok
[22:13] <slangasek> which I think is not meant to be a sync anyway
[22:13] <nacc> slangasek: ok, it could be a bit of both? as php7.0 is under active dev, but will wait to see what doko says
[22:13] <nacc> slangasek: right, it'd be a merge now, aiui?
[22:14] <slangasek> yes
[22:15] <nacc> slangasek: ok, so for pkg-php-tools, looks like one fix is upstream already (in debian's git). I am sending the other one in now
[22:16] <slangasek> excellent
[22:16] <slangasek> nacc: I'm probably not available to help with sponsorship for the next day or so fwiw
[22:16] <nacc> slangasek: not sure how to make the test make sense for them, as the error message will vary between php5 and php7, and it's a phpunit comment that provides the matching string, but they'll know what to do
[22:16] <nacc> slangasek: ok, np
[22:19] <nacc> slangasek: would it be better for me to provide a debdiff from what is currently in xenial to a level that works or request a fresh sync and provide a debdiff to that?
[22:21] <slangasek> nacc: a sync is *only* ever for a package that we want to have a package uploaded to Ubuntu that's identical to the one in Debian.  Otherwise it's a merge; for a merge you can provide a debdiff against either the existing Ubuntu package (xenial-proposed or xenial), or against the new Debian version that you're asking to have merged
[22:21] <slangasek> nacc: and merges.ubuntu.com is your friend
[22:22] <nacc> slangasek: got it, thanks
[22:25] <xnox> slangasek, i have things in NEW, do that need FFe or not?
[22:26] <slangasek> xnox: source NEW - no, it just requires securing an AA's time
[22:26] <xnox> slangasek, gotcha. hope you are having fun =) and not spending too much time on irc =)
[22:27] <slangasek> xnox: yeah, I'm about to run away ;)
[22:27] <xnox> \o/
[22:27] <Unit193> Alright, I give up.  How do I specify the filesystem that filesystem.squashfs should be mounted udf, not iso9660?
[22:29] <xnox> Unit193, filesystem.squashfs is a squashfs =)
[22:29] <Unit193> xnox: I know, but it sits on media, which has a filesystem.
[22:30] <Unit193> And I don't know how to continue boot from busybox after remounting /cdrom with -t udf.
[22:34] <Unit193> Ooh, worked to recover from busybox this time.  Though it's still trying iso9660 which is not going to work.
[22:45] <barry> doko, pitti: new tox syncpackaged.  let's see if that gets us past proposed
[22:45] <Unit193> xnox: So, no ideas?
[22:54] <stefanct> hi there. i am the upstream maintainer of flashrom. the debian maintainer has not updated his package for a while but did so now... however as you know the LTS freeze is in place and we would need an exception
[22:55] <stefanct> the now published debian package is of an upstream rc and thus will probably become outdated in a week when we do a full release
[22:56] <stefanct> id like to know what is preferable... getting an exception for the rc now and request a pull in about a week or if we should wait till the full upstream release is done and packaged for debian in about a week
[23:08] <tarpman> stefanct: freeze? debian isn't in any freeze right now AFAIK
[23:09]  * tarpman looks at what channel he's in and shuts up
[23:09] <stefanct> :)
[23:09] <stefanct> flashrom was always pulled in from debian
[23:09] <sarnold> stefanct: i'm guessing a week's delay would be fine, though it might not be a bad idea to start the paperwork early
[23:10] <stefanct> sometimes with a sponsored upload after a freeze... but we never had to build a package (someone of you always helped out so far ;)
[23:10] <stefanct> but yes, the bug report is there but we need to fill it
[23:21] <nacc> doko: fwiw, the merge with -7 isn't exactly straightforward (and the delta changes, i'm testing my debdiff now, but i can file a bug and send it your way if you want)
[23:40] <doko> nacc, ta, I'm just back, best thing would be a bug report, and subscribe me
[23:40] <nacc> doko: will do, want to make sure the build works fine, then will file, is it ok if i use the bug report that was already filed requesting we pull in the debian fixes?
[23:48] <nacc> Pharaoh_Atem: around?
[23:52] <stefanct> oh wow... s390 O_o why was that added? :)
[23:53] <sarnold> because someone wants to sell them :)