[03:08] cyphermox: can you push the latest version of `initramfs-tools` to git.launchpad.net? last I see is 0.125ubuntu2; yakkety has 0.125ubuntu5 === hikiko|off is now known as hikiko [05:47] good morning [06:09] Good morning [07:15] morning pitti: does openmpi need a hint to run autopkgtests with gerris 20131206+dfsg-11ubuntu1 ? [07:18] ginggs: yes, presumably; I'll try the same for vtk6 [07:19] half of the perl stuff will be the same I figure [07:19] pitti: thanks. do you know if there is anything different about the s390x environment for running autopkgtests? [07:20] ginggs: i386/amd64/ppc64el are running in nova instances, i. e. QEMU; armhf runs in lxd containers, s390x runs in lxc containers [07:20] 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] 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] ginggs: does it happen on armhf too? [07:23] no, only s390x [07:23] 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] pitti: would you ignore the s390x result for now, or should I try to work around that? [07:25] ginggs: for which package? (presumably I would ignore it, yes) [07:25] pitti: sorry, still on gerris [07:26] 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] doko: I'd work on merging latest dovecot in zesty if you are ok with that [08:06] IIRC last time we did that at the same time :-/, so double worth to ask this time === alan_g is now known as alan_g|afk [08:40] hi juliank does python-apt needs some updates for zesty?http://autopkgtest.ubuntu.com/packages/p/python-apt/zesty/i386 [08:41] and pitti fixed it ^^ [08:41] so, underscore testsuite has to run against python-apt/proposed [08:48] LocutusOfBorg: or rather, I'll let p-apt land, and retry the failures afterwards [08:48] 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 === seb128_ is now known as seb128 [08:50] This whole copy-last-distribution-and-change-name thing is a bit annoying. [08:59] doko: almost forgot - please ignore my former question I was looking at X instead of Y changelog [09:15] juliank: couldn't this be derived from distro-info-data somehow? [09:16] pitti, syncpackage distro-info-data? [09:17] Well, it could be merged into that [09:17] LocutusOfBorg: yep, indeed; doing [09:17] python-apt also keeps around mirror lists, information about components [09:17] And translate user-visible names for components and suites [09:18] $ distro-info -f --devel [09:18] Ubuntu 17.04 "Zesty Zapus" [09:18] juliank: yeah, the "supported/unsupported/partner" bits are not there indeed [09:18] Stuff like -proposed => Pre-released updates, -backports => Unsupported updates [09:19] 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] ta! [09:20] 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] hm... is launchpad known to be broken atm? cannot submit a new bug for inkscape [09:27] pff, it's broken half of the time I want to do stuff... [09:27] :) [09:28] (gitlab is far worse) [09:31] gitlab.com was upgrading this morning but has been working fine for me since the last hour or so [09:36] juliank: right, some kind of "template" with macros for short/long name, version etc. [09:36] Well. gitlab is so busy it tends to send out emails or git hooks 30 minutes after the event [09:39] juliank: yikes [09:52] I've been okay on gitlab for the last hour or so [09:53] poking around with mir stuff [09:54] xnox: your gerris retries should have used all-proposed=1.. [09:54] xnox: see conversation with ginggs earlier here [09:56] juliank, if I attach my own runner to my project, all of my issues tend to go away [10:03] 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] pitti, what's up with s390x? it seems unusual that it has the highest queue length. [10:04] 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] ah, i see. [10:04] fair enough. [10:04] xnox: I'm using some big hammers to try and get on top of the haskell+perl transitions [10:09] pitti, could you ingoretest openmpi to let it through. It's actually good, and is holding up starting boost transition. [10:10] unless it's two sizes too big of a hammer [10:10] xnox: ok; seems vtk6 is a victim of some mysql uninstallability [10:10] but indeed at some point it's easier to fix the fallout after these huge chunks landed [10:10] cpaelzer: please go ahead, the package belongs to the server team [10:14] thanks pitti [10:14] xnox, I did create a boost1.62 transition tracker, but I didn't fix it :/ [10:14] http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.62.html looks ok. [10:15] xnox: openmpi hinted [10:15] 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] xnox, this because you fixed it :) http://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/revision/430 [10:17] LocutusOfBorg: are you looking at mariadb ftbfs by any chance? [10:18] Laney, I don't know how to fix it :/ [10:18] but it is in the long todo [10:48] xnox: hinted gerris/390x as well now, so hopefully openmpi should land in the next iteration [10:49] 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] looks like there are still 8 potentially outstanding packages which would still clog it up. [10:50] xnox: ok, so s/land/not being blocked by tests/ :) [10:51] or maybe the tracker is bad. i'm not sure why it's bad to depend on mpich12 [10:51] xnox: indeed, e. g. bagel is missing its s390x build [10:54] *** Error in `../TestSuite': malloc(): smallbin double linked list corrupted: 0x000002aa0fdda070 *** [10:54] then it got stuck, then killed. === alan_g|afk is now known as alan_g === Guest95404 is now known as ahasenack === ahasenack is now known as Guest59736 [11:01] xnox, pitti: tracker is bad, bagel builds with mpich not openmpi [11:03] * xnox pushes tracker update. [11:03] well, we shall see what proposed-migration complains about now, if any. [12:00] pitti, vtk6 should be hinted through, the only regression is known to pass with all-proposed. [12:01] i would ask to hint boost1.60 over mongodb/armhf failure too. However, it does seem odd. [12:01] ditto boost1.61 [12:01] sigh [12:02] these three seem to be the ones that "Depends: openmpi" and thus block openmpi migrating. [12:03] oh mongo ftbfs [12:05] xnox: hinted liggghts/armhf [12:06] for mongo, i'm podering to sync the modern mongodb from experimental. [12:06] because 2.6 is acient. [12:06] even juju-mongodb moved to 3.2 [12:07] 2.6 has FTBFS in debian too. [12:07] https://tracker.debian.org/news/794834 looks sensible === mhall119_ is now known as mhall119 === timrc_ is now known as timrc [13:08] xnox: I think mongodb doesn't build on all the architectures these days but maybe that's ok? [13:11] jbicha, it fails on armhf, and i think that's ok. [13:13] mongodb 2.6 is eol upstream this month: https://www.mongodb.com/support-policy === ubuntu is now known as Guest74698 [13:17] jbicha, lirc is fine in Debian [13:18] totem works now, just sync from experimental when possible [13:18] LocutusOfBorg: thank you! [13:18] thanks to you, I plan to do a transition, it shoulnd't migrate without rebuilding reverse-dependencies [13:19] * LocutusOfBorg sets a ben file === zumbi_ is now known as zumbi === tyhicks` is now known as tyhicks === herb_ is now known as herb [14:09] doko: infinity: mdeslaur: we have a potential fix for LP: #1584485 (libnss-winbind / libpam-winbind static libraries). Anyone interested in reviewing the patch ? [14:09] Launchpad bug 1584485 in samba (Ubuntu Yakkety) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [High,In progress] https://launchpad.net/bugs/1584485 [14:10] caribou: you should ask someone from the SRU team [14:12] mdeslaur: well, yes, it will end-up on all releases so I guess that'd be better [14:18] apw: bdmurray: pitti: slangasek: ^^ [14:30] anybody wants to try the new sbuild? https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+sourcepub/7059276/+listing-archive-extra [14:31] 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] 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] caribou: which seems reasonable, as long as it doesn't make it unreasonably large [14:31] 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 === pavlushka is now known as pavlushka_ [14:32] pitti: thanks for checking. I'll check the difference in size before uploading === pavlushka_ is now known as pavlushka [14:33] 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] caribou: no, I wouldn't know why [14:33] didn't think so either, thanks [14:50] caribou: A breaks/replaces against what? :P [14:51] caribou: $package implicitly breaks/replaces/conflicts $package, cause, well, it's the same package. [14:51] sil2100: no, you didn't tell about the issue you have :-/ [14:51] infinity: B/R are still kind of nebulous to me so I'm always a bit worried to miss them [14:51] infinity: still needs to do the readings you suggested [14:51] is there a replacement for iptraf? [14:53] 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] 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] infinity: understood, I've already asked for the WAF customization to be upstreamed [14:54] 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] infinity: for the rest, they already stated that those should be packaged with samba-libs [14:56] infinity: here is the ML thread : https://lists.samba.org/archive/samba-technical/2016-October/116619.html [15:00] caribou: Hrm. Indeed, shipping them in samba-libs with the libnss/libpam packages only providing the config glue would work too. [15:01] caribou: That could be the path of least pain if upstream isn't keen on the static approach. [15:02] infinity: I still keep this in my LoS anyway [15:02] caribou: The pam and nss modules are tiny, so that approach wouldn't bug me too much. [15:02] k [15:03] And they'd be inert by default if we keep the configuration bits in the libpam-foo/libnss-foo packages. [15:03] infinity: there is a debian bug opened for that too, I'll bring it up there [15:03] 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] infinity: I learned a lot during the fall :) [15:04] Well, not a total loss then. ;) [15:04] THis would effectively just be a 4-line patch to the current packaging. [15:05] ie: remove the modules from the module packages, install them in the libs package, done. [15:08] 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] 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] sil2100: get things resolved when packages are rebuilt? [15:39] 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] No, a no-change rebuild of dbusada ends up with such a failure on the 3 arches, example log: [15:40] https://launchpadlibrarian.net/290714344/buildlog_ubuntu-zesty-s390x.dbusada_0.3.3-1build1~test1_BUILDING.txt.gz [15:40] There are also some 'obsolete' errors there for dependent libraries I guess, but the system.ads ones worry me the most [15:41] Similar issues when running dbusada autopkgtests [15:42] 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] doko: ACK [15:51] pitti, do you know why the new sbuild picks up dose and fails? [15:54] it is here btw https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa [15:57] infinity, kees, mdeslaur, stgraber: TB meeting in 3? [15:57] slangasek, stgraber, ... WHAT HE SAID. [15:57] slangasek: ack [15:57] :) [15:57] I notice the agenda wasn't updated [15:58] our next meeting is probably not Oct 11, 2016 [15:58] Potentially not. [15:59] But I'm likely the chair, since I wasn't there on the 11th. [15:59] So, meh. [16:17] Is anyone SRUing debootstrap to yakkety? [16:18] I hear that powersj has volunteered if not. [16:18] Does this need an SRU bug? [16:19] Looks like there have been SRU bugs in teh past. [16:19] arges, apw: ^? [16:20] rbasak, it would probabally want an SRU bug ... for tracking i'd say [16:21] i am not myself sru'ing it [16:26] powersj: ^ all yours. [16:27] ok [16:27] thx! [16:27] powersj: if you create the debootstrap and assign yourself, hopefully that'll flag a lock to others. [16:27] the debootstrap bug [16:27] ok [16:57] jbicha, pretty please, upload this lirc https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/debhelper [16:57] there is a typo that prevents smooth upgrades from debian [16:57] from xenial/yakkety I mean [17:01] LocutusOfBorg: why don't you upload that to experimental and we can sync from there? [17:01] jbicha, because the current one is broken [17:01] I want to fix it and in the meanwhile I already asked the maintainer to fix it [17:02] sorry, but it landed on -release, so I broke upgrade path [17:02] * LocutusOfBorg is doing rebuilds of reverse dependencies right now [17:02] those running zesty already should expect some breakage [17:02] jbicha, I prefer not from me :) [17:02] but as you wish [17:02] I might upload it tonight in debian, so expect a sync request tomorrow [17:03] 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] LocutusOfBorg: ok I uploaded it for you :) [17:09] 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] I don't have hurry now :) [17:09] too bad we didn't see that an hour or two ago before it migrated to -release [17:12] yep indeed [17:12] stupid typo [17:12] and people are running upgrades from sid to experimental, not sure why they didn't open a bug [17:19] 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] loool [17:19] ubuntu had a multiarch location, so the path didn't change [17:19] :) [17:19] I see ~5 reverse-dependencies failing to rebuild, will look at them [17:21] it looks like you don't have -proposed enabled for that ppa [19:44] tyhicks: fyi, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1580463/comments/29 [19:44] Launchpad bug 1580463 in im-config (Ubuntu Xenial) "Snap blocks access to system input methods (ibus, fcitx, ...)" [Medium,Fix committed] [19:45] jdstrand: thanks! I'm hoping to do the apparmor testing by EOD [19:46] good timing then :) [20:11] bdmurray: so webkit2gtk/yakkety is being blocked because of phased updates [20:12] https://errors.ubuntu.com/problem/31f280fa5539449d440e411a60b92bb28e48e41b has the same title at least as [20:12] https://errors.ubuntu.com/problem/53de313c8e0c7a05c093808248f8ce1ab17a1f21 (except the first is i386 and the second is amd64) [20:13] but the amd64 bug was found in the older webkit2gtk [20:16] 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] 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 :|