[03:08] <lfaraone> cyphermox: can you push the latest  version of `initramfs-tools` to git.launchpad.net? last I see is 0.125ubuntu2; yakkety has 0.125ubuntu5
[05:47] <cpaelzer> good morning
[06:09] <pitti> Good morning
[07:15] <ginggs> morning pitti: does openmpi need a hint to run autopkgtests with gerris 20131206+dfsg-11ubuntu1 ?
[07:18] <pitti> ginggs: yes, presumably; I'll try the same for vtk6
[07:19] <pitti> half of the perl stuff will be the same I figure
[07:19] <ginggs> pitti: thanks. do you know if there is anything different about the s390x environment for running autopkgtests?
[07:20] <pitti> ginggs: i386/amd64/ppc64el are running in nova instances, i. e. QEMU; armhf  runs in lxd containers, s390x runs in lxc containers
[07:20] <pitti> there's some work to move s390x into scalingstack, i. e. to provide full VMs; but until that, we use some hand-crafted setup
[07:22] <ginggs> hmm, because I still see an error on s390x, which looks like the error when trying to run mpi programs in a chroot
[07:22] <pitti> ginggs: does it happen on armhf too?
[07:23] <ginggs> no, only s390x
[07:23] <pitti> lxc and lxd are not that much different wrt. isolation -- if anything, there should be *more* problems on lxd as it uses user containers which are a bit more "strange"
[07:25] <ginggs> pitti: would you ignore the s390x result for now, or should I try to work around that?
[07:25] <pitti> ginggs: for which package? (presumably I would ignore it, yes)
[07:25] <ginggs> pitti: sorry, still on gerris
[07:26] <pitti> ginggs: ah, yes; I'm currently doing a mass-retry against -proposed (for the perl transition and also your's) and once that settles I'll go through excuses.html and sort out the rest
[08:06] <cpaelzer> doko: I'd work on merging latest dovecot in zesty if you are ok with that
[08:06] <cpaelzer> IIRC last time we did that at the same time :-/, so double worth to ask this time
[08:40] <LocutusOfBorg> hi juliank does python-apt needs some updates for zesty?http://autopkgtest.ubuntu.com/packages/p/python-apt/zesty/i386
[08:41] <LocutusOfBorg> and pitti fixed it ^^
[08:41] <LocutusOfBorg> so, underscore testsuite has to run against python-apt/proposed
[08:48] <pitti> LocutusOfBorg: or rather, I'll let p-apt land, and retry the failures afterwards
[08:48] <pitti> but the queue is hopelessly long right now (I didn't even submit the non-s390x retries for perl), so settling this will still take a while
[08:50] <juliank> This whole copy-last-distribution-and-change-name thing is a bit annoying.
[08:59] <cpaelzer> doko: almost forgot - please ignore my former question I was looking at X instead of Y changelog
[09:15] <pitti> juliank: couldn't this be derived from distro-info-data somehow?
[09:16] <LocutusOfBorg> pitti, syncpackage distro-info-data?
[09:17] <juliank> Well, it could be merged into that
[09:17] <pitti> LocutusOfBorg: yep, indeed; doing
[09:17] <juliank> python-apt also keeps around mirror lists, information about components
[09:17] <juliank> And translate user-visible names for components and suites
[09:18] <pitti> $ distro-info -f --devel
[09:18] <pitti> Ubuntu 17.04 "Zesty Zapus"
[09:18] <pitti> juliank: yeah, the "supported/unsupported/partner" bits are not there indeed
[09:18] <juliank> Stuff like -proposed => Pre-released updates, -backports => Unsupported updates
[09:19] <pitti> juliank: but given that the only kind of information I poured into the above upload was to s/16.10/17.04/, s/yakkety/zesty/ and s/Yakkety Yak/Zesty Zapus/, this is all in d-i-d
[09:19] <LocutusOfBorg> ta!
[09:20] <juliank> That's true. All the other fields are defined per distribution though, and then you have ParentSuite and stuff. It would require a lot of work to more generically describe this thing in some kind of "default" section
[09:24] <stefanct> hm... is launchpad known to be broken atm? cannot submit a new bug for inkscape
[09:27] <juliank> pff, it's broken half of the time I want to do stuff...
[09:27] <stefanct> :)
[09:28] <juliank> (gitlab is far worse)
[09:31] <highvoltage> gitlab.com was upgrading this morning but has been working fine for me since the last hour or so
[09:36] <pitti> juliank: right, some kind of "template" with macros for short/long name, version etc.
[09:36] <juliank> Well. gitlab is so busy it tends to send out emails or git hooks 30 minutes after the event
[09:39] <highvoltage> juliank: yikes
[09:52] <Son_Goku> I've been okay on gitlab for the last hour or so
[09:53] <Son_Goku> poking around with mir stuff
[09:54] <pitti> xnox: your gerris retries should have used all-proposed=1..
[09:54] <pitti> xnox: see conversation with ginggs earlier here
[09:56] <Son_Goku> juliank, if I attach my own runner to my project, all of my issues tend to go away
[10:03] <xnox> pitti, ah, true! how do i do all-proposed=1 in the url construct? &all-proposed=1
[10:03]  * xnox did not know there is all-proposed.
[10:03] <xnox> pitti, what's up with s390x? it seems unusual that it has the highest queue length.
[10:04] <pitti> xnox: I mass-retried perl with --all-proposed on it (but not the other arches yet as they still have too much to catch up with)
[10:04] <xnox> ah, i see.
[10:04] <xnox> fair enough.
[10:04] <pitti> xnox: I'm using some big hammers to try and get on top of the haskell+perl transitions
[10:09] <xnox> pitti, could you ingoretest openmpi to let it through. It's actually good, and is holding up starting boost transition.
[10:10] <xnox> unless it's two sizes too big of a hammer
[10:10] <pitti> xnox: ok; seems vtk6 is a victim of some mysql uninstallability
[10:10] <pitti> but indeed at some point it's easier to fix the fallout after these huge chunks landed
[10:10] <doko> cpaelzer: please go ahead, the package belongs to the server team
[10:14] <LocutusOfBorg> thanks pitti
[10:14] <LocutusOfBorg> xnox, I did create a boost1.62 transition tracker, but I didn't fix it :/
[10:14] <xnox> http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.62.html looks ok.
[10:15] <pitti> xnox: openmpi hinted
[10:15] <xnox> it's too early to upload boost-defaults pointing at 1.62, as I usually like to have the new boost migrated into the release pocket, to avoid huge build ups in -proposed.
[10:15] <LocutusOfBorg> xnox, this because you fixed it :) http://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/revision/430
[10:17] <Laney> LocutusOfBorg: are you looking at mariadb ftbfs by any chance?
[10:18] <LocutusOfBorg> Laney, I don't know how to fix it :/
[10:18] <LocutusOfBorg> but it is in the long todo
[10:48] <pitti> xnox: hinted gerris/390x as well now, so hopefully openmpi should land in the next iteration
[10:49] <xnox> well. are all of these http://people.canonical.com/~ubuntu-archive/transitions/html/openmpi.html in zesty-proposed and not in release? i guess i should check if these need fixing first.
[10:49] <xnox> looks like there are still 8 potentially outstanding packages which would still clog it up.
[10:50] <pitti> xnox: ok, so s/land/not being blocked by tests/ :)
[10:51] <xnox> or maybe the tracker is bad. i'm not sure why it's bad to depend on mpich12
[10:51] <pitti> xnox: indeed, e. g. bagel is missing its s390x build
[10:54] <xnox> *** Error in `../TestSuite': malloc(): smallbin double linked list corrupted: 0x000002aa0fdda070 ***
[10:54] <xnox> then it got stuck, then killed.
[11:01] <ginggs> xnox, pitti: tracker is bad, bagel builds with mpich not openmpi
[11:03]  * xnox pushes tracker update.
[11:03] <xnox> well, we shall see what proposed-migration complains about now, if any.
[12:00] <xnox> pitti, vtk6 should be hinted through, the only regression is known to pass with all-proposed.
[12:01] <xnox> i would ask to hint boost1.60 over mongodb/armhf failure too. However, it does seem odd.
[12:01] <xnox> ditto boost1.61
[12:01] <xnox> sigh
[12:02] <xnox> these three seem to be the ones that "Depends: openmpi" and thus block openmpi migrating.
[12:03] <xnox> oh mongo ftbfs
[12:05] <pitti> xnox: hinted liggghts/armhf
[12:06] <xnox> for mongo, i'm podering to sync the modern mongodb from experimental.
[12:06] <xnox> because 2.6 is acient.
[12:06] <xnox> even juju-mongodb moved to 3.2
[12:07] <xnox> 2.6 has FTBFS in debian too.
[12:07] <xnox> https://tracker.debian.org/news/794834 looks sensible
[13:08] <jbicha> xnox: I think mongodb doesn't build on all the architectures these days but maybe that's ok?
[13:11] <xnox> jbicha, it fails on armhf, and i think that's ok.
[13:13] <jbicha> mongodb 2.6 is eol upstream this month: https://www.mongodb.com/support-policy
[13:17] <LocutusOfBorg> jbicha, lirc is fine in Debian
[13:18] <LocutusOfBorg> totem works now, just sync from experimental when possible
[13:18] <jbicha> LocutusOfBorg: thank you!
[13:18] <LocutusOfBorg> thanks to you, I plan to do a transition, it shoulnd't migrate without rebuilding reverse-dependencies
[13:19]  * LocutusOfBorg sets a ben file
[14:09] <caribou> doko: infinity: mdeslaur: we have a potential fix for LP: #1584485 (libnss-winbind / libpam-winbind static libraries). Anyone interested in reviewing the patch ?
[14:10] <mdeslaur> caribou: you should ask someone from the SRU team
[14:12] <caribou> mdeslaur: well, yes, it will end-up on all releases so I guess that'd be better
[14:18] <caribou> apw: bdmurray: pitti: slangasek: ^^
[14:30] <LocutusOfBorg> anybody wants to try the new sbuild? https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+sourcepub/7059276/+listing-archive-extra
[14:31] <sil2100> doko: hey, do you have some gnat related knowledge? I stumbled upon some issues with gnat when trying to run dbusada tests or even no-change rebuild dbusada on powerpc, ppc64el and s390x
[14:31] <pitti> caribou: the patch itself is fairly straightforward (well, I'm completely unfamiliar with the build system, but it basically says "link this statically")
[14:31] <pitti> caribou: which seems reasonable, as long as it doesn't make it unreasonably large
[14:31] <sil2100> doko: would you be able to help me out? To me it looks like this might be some toolchain issue, but I don't know ada at all
[14:32] <caribou> pitti: thanks for checking. I'll check the difference in size before uploading
[14:33] <caribou> pitti: I was wondering if this would require a Break/Replace on the previous version. Don't think so but just want to be sure
[14:33] <pitti> caribou: no, I wouldn't know why
[14:33] <caribou> didn't think so either, thanks
[14:50] <infinity> caribou: A breaks/replaces against what? :P
[14:51] <infinity> caribou: $package implicitly breaks/replaces/conflicts $package, cause, well, it's the same package.
[14:51] <doko> sil2100: no, you didn't tell about the issue you have :-/
[14:51] <caribou> infinity: B/R are still kind of nebulous to me so I'm always a bit worried to miss them
[14:51] <caribou> infinity: still needs to do the readings you suggested
[14:51] <doko> is there a replacement for iptraf?
[14:53] <infinity> caribou: So, the thing I'd like to see (once this is tested to DTRT, etc) is something upstreamable and upstreamed, so we don't have to carry a hideous patch forever.
[14:54] <infinity> caribou: Given the intense upgrade pain, I'm firmly of the belief here that if the rest of samba is linked dynamically (which is a reasonable option), those two bits should still always be static.
[14:54] <caribou> infinity: understood, I've already asked for the WAF customization to be upstreamed
[14:54] <infinity> caribou: So, the option should be there upstream to do it at the flick of a switch, and said switch should be proposed as the default (though if we have to differ with a --configure-option, so be it)
[14:55] <caribou> infinity: for the rest, they already stated that those should be packaged with samba-libs
[14:56] <caribou> infinity: here is the ML thread : https://lists.samba.org/archive/samba-technical/2016-October/116619.html
[15:00] <infinity> caribou: Hrm.  Indeed, shipping them in samba-libs with the libnss/libpam packages only providing the config glue would work too.
[15:01] <infinity> caribou: That could be the path of least pain if upstream isn't keen on the static approach.
[15:02] <caribou> infinity: I still keep this in my LoS anyway
[15:02] <infinity> caribou: The pam and nss modules are tiny, so that approach wouldn't bug me too much.
[15:02] <caribou> k
[15:03] <infinity> And they'd be inert by default if we keep the configuration bits in the libpam-foo/libnss-foo packages.
[15:03] <caribou> infinity: there is a debian bug opened for that too, I'll bring it up there
[15:03] <infinity> That seems to me a reasonable solution.  Wish I'd thought of it before I sent you down the static rabbit hole. :P
[15:03] <caribou> infinity: I learned a lot during the fall :)
[15:04] <infinity> Well, not a total loss then. ;)
[15:04] <infinity> THis would effectively just be a 4-line patch to the current packaging.
[15:05] <infinity> ie: remove the modules from the module packages, install them in the libs package, done.
[15:08] <infinity> caribou: Of course, it gets a bit more complex, because both also depend on libwbclient0, which should probably just move to samba-libs.
[15:29] <sil2100> doko: yeah, sorry, got preempted by a meetings - the issues I see are that when gnatbind-6 runs, it gets a lot of errors like: '"somethingsomething.adb" must be recompiled ("system.ads" has been modified)'
[15:39] <doko> sil2100: get things resolved when packages are rebuilt?
[15:39] <sil2100> doko: I saw that system.ads is part of gnat-6, not sure what they mean - since all those 'somethingsomething.ads' files seem to get built on during package build
[15:40] <sil2100> No, a no-change rebuild of dbusada ends up with such a failure on the 3 arches, example log:
[15:40] <sil2100> https://launchpadlibrarian.net/290714344/buildlog_ubuntu-zesty-s390x.dbusada_0.3.3-1build1~test1_BUILDING.txt.gz
[15:40] <sil2100> There are also some 'obsolete' errors there for dependent libraries I guess, but the system.ads ones worry me the most
[15:41] <sil2100> Similar issues when running dbusada autopkgtests
[15:42] <doko> sil2100: looks like you need to rebuild dbusads's deps. you may want to ask the debian-ada team about it. I would have to do the same here
[15:43] <sil2100> doko: ACK
[15:51] <LocutusOfBorg> pitti, do you know why the new sbuild picks up dose and fails?
[15:54] <LocutusOfBorg> it is here btw https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa
[15:57] <slangasek> infinity, kees, mdeslaur, stgraber: TB meeting in 3?
[15:57] <infinity> slangasek, stgraber, ... WHAT HE SAID.
[15:57] <mdeslaur> slangasek: ack
[15:57] <slangasek> :)
[15:57] <slangasek> I notice the agenda wasn't updated
[15:58] <slangasek> our next meeting is probably not Oct 11, 2016
[15:58] <infinity> Potentially not.
[15:59] <infinity> But I'm likely the chair, since I wasn't there on the 11th.
[15:59] <infinity> So, meh.
[16:17] <rbasak> Is anyone SRUing debootstrap to yakkety?
[16:18] <rbasak> I hear that powersj has volunteered if not.
[16:18] <rbasak> Does this need an SRU bug?
[16:19] <rbasak> Looks like there have been SRU bugs in teh past.
[16:19] <rbasak> arges, apw: ^?
[16:20] <apw> rbasak, it would probabally want an SRU bug ... for tracking i'd say
[16:21] <apw> i am not myself sru'ing it
[16:26] <rbasak> powersj: ^ all yours.
[16:27] <powersj> ok
[16:27] <powersj> thx!
[16:27] <rbasak> powersj: if you create the debootstrap and assign yourself, hopefully that'll flag a lock to others.
[16:27] <rbasak> the debootstrap bug
[16:27] <powersj> ok
[16:57] <LocutusOfBorg> jbicha, pretty please, upload this lirc https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/debhelper
[16:57] <LocutusOfBorg> there is a typo that prevents smooth upgrades from debian
[16:57] <LocutusOfBorg> from xenial/yakkety I mean
[17:01] <jbicha> LocutusOfBorg: why don't you upload that to experimental and we can sync from there?
[17:01] <LocutusOfBorg> jbicha, because the current one is broken
[17:01] <LocutusOfBorg> I want to fix it and in the meanwhile I already asked the maintainer to fix it
[17:02] <LocutusOfBorg> sorry, but it landed on -release, so I broke upgrade path
[17:02]  * LocutusOfBorg is doing rebuilds of reverse dependencies right now
[17:02] <jbicha> those running zesty already should expect some breakage
[17:02] <LocutusOfBorg> jbicha, I prefer not from me  :)
[17:02] <LocutusOfBorg> but as you wish
[17:02] <LocutusOfBorg> I might upload it tonight in debian, so expect a sync request tomorrow
[17:03] <LocutusOfBorg> that version fixes totem and upgrade path, this is why I prefer to see it uploaded right now, but one day might not make much difference
[17:08] <jbicha> LocutusOfBorg: ok I uploaded it for you :)
[17:09] <LocutusOfBorg> thanks, in the meanwhile I'm doing test rebuilds, and in case I'll upload a -3 in Debian with some build-fixes if there are some
[17:09] <LocutusOfBorg> I don't have hurry now :)
[17:09] <jbicha> too bad we didn't see that an hour or two ago before it migrated to -release
[17:12] <LocutusOfBorg> yep indeed
[17:12] <LocutusOfBorg> stupid typo
[17:12] <LocutusOfBorg> and people are running upgrades from sid to experimental, not sure why they didn't open a bug
[17:19] <LocutusOfBorg> jbicha, debian is not broken, because by chance, the library wasn't in multiarch location before, so the clash has been funnily avoided
[17:19] <LocutusOfBorg> loool
[17:19] <LocutusOfBorg> ubuntu had a multiarch location, so the path didn't change
[17:19] <LocutusOfBorg> :)
[17:19] <LocutusOfBorg> I see ~5 reverse-dependencies failing to rebuild, will look at them
[17:21] <jbicha> it looks like you don't have -proposed enabled for that ppa
[19:44] <jdstrand> tyhicks: fyi, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1580463/comments/29
[19:45] <tyhicks> jdstrand: thanks! I'm hoping to do the apparmor testing by EOD
[19:46] <jdstrand> good timing then :)
[20:11] <jbicha> bdmurray: so webkit2gtk/yakkety is being blocked because of phased updates
[20:12] <jbicha> https://errors.ubuntu.com/problem/31f280fa5539449d440e411a60b92bb28e48e41b has the same title at least as
[20:12] <jbicha> https://errors.ubuntu.com/problem/53de313c8e0c7a05c093808248f8ce1ab17a1f21 (except the first is i386 and the second is amd64)
[20:13] <jbicha> but the amd64 bug was found in the older webkit2gtk
[20:16] <bdmurray> jbicha: Okay, I'll get that error taken care of, what about https://errors.ubuntu.com/problem/18b5e69225bd63387d958707585693d52919b7c4? Its curious there aren't any crashes with 2.14.0-1.
[20:18] <jbicha> bdmurray: I don't know; I do know that the update fixes some crash bugs and I'm hoping it fixes more crashes than it creates :|