[00:45] rbasak: ruby-mysql, ruby-mysql2 retests triggered now; sorry, had not noticed the discussion here until I went looking at update_excuses again [00:45] xnox: what came of your strongswan investigations? [00:45] slangasek: np. I think there are a couple of bugs remaining in the ruby-mysql2 dep tests. I fixed one, am struggling with the second (Ruby). [00:45] Anyone around who knows rspec? [00:46] only the Aretha Franklin version [00:46] and that has more letters [00:47] This is just me not knowing the language I think :-/ [00:56] the strongswan/s390x looks like a flaky test to me; retried (xnox) [00:56] it's also absolutely not testing the mysql plugin which is not being installed, so we can skiptest that [01:00] oh look it passed [01:01] rbasak: and yeah, ruby-mysql2 still stuck [01:01] * rbasak is really starting to hate Ruby [01:04] rbasak: my read of the test output is that the test wants to connect with ubuntu@localhost and no password, and the server is rejecting it? [01:04] slangasek: yeah I fixed that, but that led me to a second failure (oddly) [01:05] I have a fix for the second failure I just can't get it to compile. [01:05] rbasak: ah, is that fix only local? the latest test results still show it [01:06] Yes only local [01:06] http://paste.ubuntu.com/15662716/ [01:06] First fix is line 33 [01:06] ok [01:06] Need it to connect with root, not ubuntu. Apparently with 5.7 something changed so it actually needs credentials for that test, which it wasn't previously using. [01:07] Second failure seems sort of legit - after a call to close, Threads_connected doesn't go down again. [01:07] I suspect it may be because in 5.7 Threads_connecting is not updating synchronously, so I'm trying to add a sleep to see. [01:07] But apparently that's not valid Ruby/rspec. [01:08] ok well I'm no help, I don't even know how to run the tests [01:09] I don't know that either. I'm just throwing it at adt-run :) [01:09] yeah, that failed here [01:09] debian/tests/ ENOENT and I don't know how to trigger the magic [01:10] though I see Testsuite: autopkgtest-pkg-ruby, maybe that's a clue [01:10] I found a pitti blog on it [01:10] But didn't go any further. I've just been hitting adt-run [01:10] (which after five iterations or so turns out isn't exactly efficient) [01:11] adt-run [01:11:05]: @@@@@@@@@@@@@@@@@@@@ unbuilt-tree . [01:11] adt-run [01:11:05]: testing package ruby-mysql2 version 0.4.3-2ubuntu2 [01:11] adt-run [01:11:05]: build not needed [01:11] * SKIP no tests in this package [01:11] adt-run [01:11:05]: @@@@@@@@@@@@@@@@@@@@ summary [01:11] * SKIP no tests in this package [01:11] I'm giving adt-run the .dsc. Could that have a different result? [01:11] could. didn't for me ;) [01:12] no idea where that magic lives [01:12] and I don't speak ruby anyway, sorry [01:31] slangasek: it seems that dpkg-dev needs to be installed since gem2deb-test-runner needs it. Then it works. I'm not sure what changed locally, but without this I can't even run the test here any more. When I added dpkg-dev by hand and ran locally, then my first fix worked and the second wasn't needed (perhaps a race). [01:31] So I'll perhaps upload an ubuntu2 with the first fix only, and hopefully that'll pass on scalingstack. [01:35] rbasak: I have both of those packages installed already [01:42] slangasek: ^ if you don't mind please. I'll go to bed now I think and see how it turned out in the morning. [01:44] rbasak: got it [03:45] rbasak, slangasek: Will see if I can figure out the remaining ruby-mysql2 test once I get to the office [03:46] The armhf rebuild for ruby-mysql 2.9 (man that's confusing) just looks like it hasn't been triggered yet? [06:03] Valid candidate \o/ [06:03] huh, so it was [06:03] that was sudden ;) [06:25] slangasek: Yeah, I was just about to start digging into the remaining failures, and they weren't there any more. [06:26] On to the packages that are still failing to build with MySQL 5.7, then :) [07:34] ls [07:34] Gah, sorry [07:57] ^ systemd: might look a bit scary, but it's just a merge to get back to a minimal git rebase against debian [07:57] and we already had half of the fixes [07:58] so the net change is just three bug fixes and an additional autopkgtest [11:09] rbasak: That seems suboptimal. [11:09] rbasak: Do we not want to explode if an upgrade actually fails? [11:09] (Which, hopefully, returns something other than 2...) [11:10] infinity: Skuggen filed upstream (http://bugs.mysql.com/bug.php?id=80995) but for now we can't tell the difference :-( [11:10] infinity: alternatively we could patch mysql_upgrade I suppose. [11:11] rbasak: According to the bug, "2" == "ALREADY_UPGRADED", so you should test for "$?" = "2" instead of using || true. [11:11] OK, I can do that. [11:12] ie: "if ! mysql-upgrade; then if [ "$?" != "2" ]; then echo "Database upgrade failed!" >&2; exit 1; fi; fi [11:12] rbasak: Ish. [11:17] Oh, but if resets the return. [11:17] So: mysql-upgrade || if [ "$?" != "2" ]; then echo "Database upgrade failed!" >&2; exit 1; fi [11:17] That works. [11:18] infinity: I did: http://paste.ubuntu.com/15667326/ [11:18] Does that look OK to you? [11:19] rbasak: That works too. The test for 0 is redundant. [11:19] Oh. No it's not the way you wrote it. [11:20] Carry on. [11:20] (That's why my if was part of the ||) [11:20] rbasak: Your works. Go for it. [11:20] Let me just quickly test. I'll hack up a deb to save time. [11:21] rbasak: I tested here with this: http://paste.ubuntu.com/15667482/ [11:21] rbasak: And just twiddled the return in foo.sh to test 0,1,2,3 [11:21] rbasak: Seems to DTRT. [11:24] Yeah, it defines a list of return values for different conditions. As I note in the bug it's not really documented, but 2 seems to be the only one that isn't a proper error [11:24] Though 0 also needs to be accepted [11:26] Skuggen: Right, 0 obviously needs to be accepted. :) [11:27] I'm getting some other weird error while testing. [11:27] good morning [11:30] rbasak: Yay weird errors. [11:31] cyphermox: Guten Morgen. [11:31] well, I lied, it's not good, there once was no more snow, and then snow again [11:31] but I'll survive if I can order lunch ;) [11:33] cyphermox: Snow? [11:33] cyphermox: https://weather.com/weather/tenday/l/CAXX0054:1:CA [11:33] cyphermox: And that next week looks cold compared to the one we just had... [11:34] heh [11:34] So with my new postinst, the daemon no longer starts. Which is odd. I haven't yet figured out if it's because I hacked my binary deb or if there's some other reason. [11:34] there was no snow anywhere here. it was that weather last week [11:34] and then yesterday, snow around 4pm, and now this morning there are three inches everywhere. [11:35] cyphermox: Pretty. I love spring snow. [11:35] three inches of pain and suffering. [11:35] cyphermox: And we've had pretty much no winter here. It's snowed like 4 times in the last 4 months. :( [11:35] ;) [11:35] I'm happy to fax it over to you [11:35] No snow at all here this year. [11:35] and to you. additional fees may apply ;) [11:35] Oh, I lie, I think there was like ten minutes of it when I was in Uruguay. [11:36] I can't wait to tell my grandkids all about snow and ice. [11:36] infinity: when it really doesn't exist anymore? [11:36] cyphermox: Aye. [11:37] Granted this year was mostly El Nino, not climate chnage, but it's still been the hottest El Nino I remember too. [11:37] We were hitting 25+ in January. [11:37] infinity, remember the docs upload for xubuntu i asked about before? it seems like we have a few string changes anyway, would you prefer some paperwork for that? [11:37] infinity, fwiw, i can ACK the upload on behalf of all documentation teams [11:38] knome: If the only people it affects is your own team, I don't need paperwork. [11:38] cheers, that's it indeed [11:38] Ah [11:38] Well that was stupid. [11:38] rbasak: The mating call of the software engineer? [11:39] cjwatson: that was in december: https://goo.gl/photos/2eaLrkJ7RWRJmNDB7 and it stuck around (with slightly varying quantities) until a few weeks ago. [11:39] :) [11:40] Mm, we had about a foot a couple of years ago and somebody actually built an igloo not far from here [11:40] cyphermox: Yeah, I was pretty jealous of all your snow out east while I was suffering through summer in the middle of winter. [11:40] move to lapland, you'll have snow (: [11:40] it's fun for a while, but it gets old. [11:40] and cold. [11:40] yeah [11:41] You miss it when you don't have it. Trust me. [11:41] 5 years in Australia without proper winter drove me nuts. [11:41] not if you have it five months a year ;) [11:41] i prefer cold to hot, but of course something in the middle - like 10-15°C is the best [11:41] OK it works. [11:41] in any case, back to ltrace ;) [11:42] knome: +1 [11:42] have fun hacking [11:42] back to coffee [11:43] Oh hey, my coffee shop opens in 18 minutes. [11:43] Yay. [11:43] hooray [11:43] oh, coffee. [11:44] Incoming [11:44] Review/accept mysql-5.7 or coffee first? :) [11:45] rbasak: Heh. Review when it lands, then walk for coffee while it builds. :) [11:47] So, TIL. When hacking a binary deb with a new postinst to save build time, patch the existing postinst since the source postinst doesn't have debhelper expansions. [11:47] rbasak: Yeah, just dpkg-deb -R and edit directly. [11:48] I did, but I copied in the postinst from my source tree. Which was a mistake. [11:48] Which I do far too often. [11:48] rbasak: Oops. ;) [11:48] Instead I grabbed the diff and used patch. [11:48] That worked better. [11:48] I don't trust myself to edit it identically. [11:48] rbasak: I go the other direction, but same result. [11:49] (edit the unpacked one directly, and when it works, diff and apply to source) [11:49] That's a good idea, thanks. [11:52] cjwatson: We have a fair few commits stacked up there, might be time for an sbuild release to unstable. [11:52] infinity: is libmysqlclient18 now NBS in the release pocket? [11:52] I was expecting to fix more FTBFS before 5.7 migrated. [11:52] libmysqlclient18 | 5.6.28-1ubuntu3 | xenial | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x [11:53] mysql-5.6 hasn't been removed yet. [11:53] Ah [11:53] infinity: I was sort of hoping Johannes would explode with frustration and do it. :) [11:53] OK, we'll work on that. [11:53] cjwatson: Heh. [11:54] cjwatson: I was considering a release, but I had a text editor open here with some other bits I was working on first. [11:54] cjwatson: And then I forgot and rebooted. [11:54] cjwatson: And now I have no idea what I was doing to sbuild. :P [11:54] Something fancy, I think. [11:54] your text editor doesn't autosave? [11:54] Oh. I was going to fix the misfeature that we're carrying a revert for. [11:55] It doesn't autosave when I intentionally exit without saving because I tihnk I'm smart enough to remember where I was. [11:55] (It was a cursor placement reminder, not lost changes) [11:55] eg. always? :P [12:11] coreycb, python-keystoneauth1 is dep-wait [12:12] doko, ok I'll take care of it today [12:12] doko, thanks [12:14] hecking compiler aarch64-linux-gnu-gcc-4.7 -g -O2 -Wformat -Werror=format-security -fstack-protector -O3 -Wdate-time -D_FORTIFY_SOURCE=2... no [12:14] configure: error: could not find a working compiler, see config.log for details [12:14] doko: All the gmp-gcc4 builds failed with gcc-4.7 hatred. [12:14] (except for ppc64el, which uses gcc-5) [12:15] infinity, I'll have a look tonight, afk now [12:15] doko: If I build it in a PPA and confirm the deps are << 4.7, do you mind if I just switch to gcc-5? [12:16] infinity,doko: that's my bug, not doko's [12:16] and I'm just test-building a fix [12:16] cjwatson: Oh, you broke it somehow? [12:16] dpkg-buildflags changes broke it [12:17] Ahh. [12:17] DEB_CPPFLAGS_MAINT_STRIP = -Wdate-time should fix it, just testing [12:17] doko: Nevermind, then. [12:17] And switching to gcc-5 would be rather against the whole point of the package. [12:17] cjwatson: Well, no. As long as it doesn't link symbols from a newer libstdc++. At least, that's how I'm reading the changelog. [12:18] * infinity shrugs. [12:18] But if that's the case why not just use the normal gmp? [12:18] Yeah, I dunno. :) [12:18] Fix away. [12:21] infinity, no gcc-4.7 needs a gmp built with a gcc not newer than 4.8 [12:21] doko: Check. [12:21] doko: Looks like Colin's on the case anyway. [12:21] would be good to have this dropped before the lts [12:21] "Before the LTS" is kinda... Now. [12:21] We'd need to drop the Android kernels (or fix them). [12:21] Not sure what else. [12:22] Actually, just the Android kernels, looks like. [12:22] Oh, and u-boot-linaro... [12:23] Which I'm not sure if we even care about anymore. [12:23] Probably not. [12:23] apw: Any idea what the status of flo, goldfish, hammerhead, and manta are? [12:23] apw: They're literally the only thing keeping gcc-4.7 in the archive now. [12:24] but before you remove it, I'd like to copy it to a ppa [12:24] Oh. And Android itself for the stupid 4.7 cross. [12:24] Argh. [12:25] doko: Can you hunt down whoever is still respondible for the Android source package and yell at them if you want 4.7 removed? I think that'll be a harder sell than pulling the ancient device kernels. [12:25] sure, I can try [12:26] Yeah, that was the problem. Fix uploaded. [12:26] cjwatson: Ta. [12:26] Given that modern AOSP builds with clang and gcc-5 (maybe even 6), I can't sort out how we're stuck on an old Android that "requires" 4.7. [12:28] infinity: pure-ftpd is using a symbol (my_make_scrambled_password) in libmysqlclient that is no longer exported by MySQL 5.7 (libmysqlclient.so.20). The symbol is there, but it's not exported. We've decided upstream to add it back in 5.7 (probably 5.7.13) to give pure-ftpd some more time to rewrite their code. Ubuntu can apply a patch right now. [12:28] Currently: MySQL 5.7.11 contains libmysqlclient.so.20.2.0 [12:28] After fix: MySQL 5.7.13 contains libmysqlclient.so.20.3.0 (with symbol my_make_scrambled_password@@libmysqlclient_20.3) [12:28] But Ubuntu can't wait for MySQL 5.7.13. My suggestion: add symbol my_make_scrambled_password@@libmysqlclient_20.3 now, but don't bump the library number. That means Ubuntu will have a slightly different library until upgrading to 5.7.13, but after that the patch will be dropped and the library will be the same as upstream. [12:29] ryeng: As long as the symbol version is correct in the patch we carry, the rest is moot. I'm fine with that. [12:29] infinity: Yes, the symbol version has to be correct. [12:30] We'll do it this way, then. [12:30] tnx [12:34] hmm, i have a script in livecd-rootfs that creates a link from a chroot hook ... in the resulting tarball there is no link ... but ... [12:34] ogra@anubis:/datengrab/generic-initrd/xenial-chroot/boot$ ls -lh /mnt/boot/initrd.img-core* [12:34] -rw-r--r-- 1 root root 23 Apr 7 13:55 /mnt/boot/initrd.img-core [12:34] -rw-r--r-- 1 root root 3,1M Apr 7 13:55 /mnt/boot/initrd.img-core-0.7.39 [12:34] ogra@anubis:/datengrab/generic-initrd/xenial-chroot/boot$ file /mnt/boot/initrd.img-core [12:34] /mnt/boot/initrd.img-core: LZMA compressed data, streamed [12:34] so there seems to be a link but it isnt reflected in the fs [12:37] does anyone have an idea how that can happen ? (the code simply runs ln -s in the /boot dir ... ) [12:39] OK, so the score for different build-dep resolutions when adding in universe, at least on amd64 and i386, is: https://paste.ubuntu.com/15668677/ [12:39] slangasek,infinity: ^- [12:39] let me see about finishing the germinate review and deployment [12:47] oh, i see ... [12:47] P: Begin executing hacks... [12:47] gzip: chroot/boot/initrd.img-core: not in gzip format [12:49] cjwatson: Weird that indicator-datetime has that alt dep at all. [12:50] cjwatson: But all looks close enough to sane to me. [12:50] hmm, i'm building with --initramfs=none ... so why does lb_chroot_hacks try to touch it [12:56] infinity: Yeah, I don't know quite what it's doing there, but it doesn't seem worth worrying about. [13:02] infinity, cjwatson, the langpack build-depends was added in https://code.launchpad.net/~charlesk/indicator-datetime/lp-1256061/+merge/198968 because tests need 12/24 hours locales apparently [13:03] seb128: that explains the language-pack-en-base b-d, but not the language-pack-touch-en preferred alternative [13:07] ah [13:12] cjwatson, the alternative depends seems like that's because the touch/desktop langpacks conflict and it allows touch devs to build the package without having to swap out the langpacks, the order probably doesn't matter [13:13] Fair enough [13:13] I thought it was probably inconsequential [13:13] But thanks for confirming [13:13] yw [13:29] * ogra_ sees the live-build code and sighs [14:29] * ogra_ curses ... how do i convince live-build to not blindly try to re-compress ebverything it finds in /boot [14:30] * ogra_ tried LB_INITRAMFS_COMPRESSION="none" ... but i still see it trying to re-compress the initrds in /boot [14:31] ogra_: I can fix it for you. [14:31] in live-build ? [14:32] ogra_: FWIW, LB_INITRAMFS_COMPRESSION=gzip would work, but that's silly. We probably want to not recompress at all when you're using LB_INITRAMFS=none, since that implies you know what you're doing. [14:32] right ... thats the ciode i'm looking at ,,, [14:32] ogra_: Yeah, I'll fix live-build to stop being silly when LB_INITRAMFS=none, assuming you only need this for xenial? [14:32] i dont get why ="none" doesnt also have the same effect as gzip [14:33] the case should sumply not match and skip it altogether [14:33] ogra_: Oh, actually, yeah, any garbage option to LB_INITRAMFS_COMPRESSION should work. [14:33] right, it doesnt [14:33] I think that implies you're not setting it correctly. ;) [14:34] But I'll just fix this to stop being silly instead. [14:34] http://paste.ubuntu.com/15670601/ [14:34] i'm exporting it in live-build/auto/config [14:34] i would expect that part to be in the env during the whole build then [14:34] Nein. [14:34] You expect incorrectly. [14:34] ah [14:35] btw, as you might guess from the paste ... that also makes us get rid of the generic initrd package ... and thus of the fakechroot mess [14:36] Heh. [14:37] ogra_: FWIW, if you want to find out how an UPPER_CASE_VAR maps to auto/config, grep for it in scripts/build/lb_config [14:38] ogra_: In this case, it would be adding --initramfs-compression to the cmdline. [14:38] oh man ... i *could* have guessed from the other options we add indeed [14:38] ogra_: Maybe that's better for your quick hack now, while I decide if COMPRESS should be skipped entirely for all INITRAMFS=none cases. [14:38] yeah, sounds good to me [14:46] apw, infinity - the spl dkms fix did not work, as in the test still fails =( [14:46] what shall we do, disable the test / make it return true? [14:50] xnox: We'll fix it. [14:51] it did pass on my adt run in qemu =/ [15:16] infinity: when do you want the final xenial langpacks? apr 14 like on https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule? [15:16] infinity, GRRR ! [15:16] this will need a manual full export by wgrant, so this needs to be coordinated a bit [15:16] * ogra_ starts over with his livecd-rootfs package in the PPA with a new version number [15:18] pitti: Apr 15, to let the world settle after the hard freeze is announced. [15:18] infinity: ack, so I'll see to getting an export on Apr 14, and build/test/upload the debs on Apr 15 [15:19] wgrant, cjwatson: is either of you around on Apr 14 to kick off a manual xenial langpack export? (cron runs on Apr 10 and 17) [15:19] pitti: Well, I meant export on 15, upload when it's done. Assuming you don't mind uploading Friday night or Saturday morning. [15:20] ok, WFM [15:47] Can someone retest mysql-5.7 i386 dep8 please? [15:47] I don't see what might have regressed so perhaps it's spurious. [15:48] rbasak: You can. [15:48] rbasak: If you have upload rights. [15:48] rbasak: Click the little recyle icon next to the regression. [15:48] (on excuses) [15:51] geez, so this livecd-rootfs uploads even made the image builds explode with hash sum mistmatches (superseding a PPA package in the middle of an image build seems to cause bad things) [15:51] *upload [15:56] Ah of course, sorry. [16:22] pitti: I will be, though you can always pick the invocation out of lp:lp-production-configs and ask webops for it, since that's what we have to do anyway :-) [16:30] I can't seem to get a retry of mysql-5.7 i386 dep to go. [16:30] It says request submitted, but http://autopkgtest.ubuntu.com/packages/m/mysql-5.7/xenial/i386/ doesn't show anything. [16:33] Re-running my build-dep analysis now that gmp-gcc4 is in. [16:41] germinate 2.24 pre-release deployed on pepo (new approach: not bothering with the package, just running germinate from git now) [16:41] Hm, maybe I should do the same on labbu. [16:42] pitti: around? [16:42] rbasak: It shows on "running". [16:42] Oh [16:42] Where's that? [16:42] http://autopkgtest.ubuntu.com/running.shtml#pkg-mysql-5.7 [16:42] rbasak: The results pages only show completed runs. [16:42] Ah, I didn't know about that page. Thanks! [16:42] (Which isn't super intuitive and probably needs fixing, but there you go) [16:42] rbasak: That page is linked from the header of all autopkgtest pages. [16:44] I'm not 100% sure I'm reading it right, but it looks like main.xa_prepared_binlog_off failed, ran a second time and passed, and ran a third time and passed [16:45] infinity, would you be able to accept python-keystonemiddleware for xenial? we need that to build before any of our core packages that use it get built. we have manila and aodh in the queue too which will need keystonemiddleware. [16:47] coreycb: What's it worth to you? [16:47] infinity, a lot! :) [16:47] infinity, aodh and manila can be rejected if there's a chance they'd get accepted too soon [16:49] coreycb: I think I can keep track for half an hour. [16:49] Maybe. [16:49] infinity, ok thanks [16:55] ogra@styx:~$ sudo mount Downloads/livecd.ubuntu-core.os.snap /mnt [16:55] ogra@styx:~$ ls -lh /mnt/boot/initrd.img-core* [16:55] lrwxrwxrwx 1 root root 22 Apr 7 18:38 /mnt/boot/initrd.img-core -> initrd.img-core-0.7.39 [16:55] -rw-r--r-- 1 root root 3,1M Apr 7 18:37 /mnt/boot/initrd.img-core-0.7.39 [16:55] YAY ! [16:55] infinity, thanks for the help, works now [16:55] * ogra_ uploads livecd-rootfs [16:56] ogra_: NP. [16:58] grmpf ... and why is my branch now diverged ? [16:58] Because you bzred incorrectly? [16:59] bzr gooder. [16:59] infinity: that's gooderer. get it right, dude. [16:59] wxl: More goodestly? [17:00] Goodest is an ideal to work towards, not something one can achieve [17:00] hahahah [17:00] goodestlier? [17:00] more goodest? [17:00] heh ... because i once ran "bzr push ..parent" for whatever reason (fun how ls hides that :P ) [17:03] your colon fell over while you were typing? [17:03] or is that a compose sequence? [17:04] slangasek: ouch, that sounds painful. [17:33] infinity, ^^ that leaves an NBS package behind now (ubuntu-core-generic-initrd) ... do you need a removal bug for that ? [17:34] ogra_: No. [17:34] k [17:38] WAT. [17:39] backport early, backport often ? [17:39] apw: Uhm, is LBM returning, and why has this not come up? [17:41] cjwatson: exciting progress. did I understand you to say that you're taking care of getting germinate backported onto ftpmaster as well? [17:57] slangasek: ftpmaster is running germinate from git currently. [17:57] slangasek: (so, yes) [17:57] "backported" [17:57] ooooh snazzy [17:58] infinity: is that a recent change? when I looked before I thought I saw it using a backport package [17:59] 10:41 < cjwatson> germinate 2.24 pre-release deployed on pepo (new approach: not bothering with the package, just running germinate from git now) [17:59] slangasek: Very recent. [18:00] aha :) [18:00] so does that mean we're done? :) [18:01] Not sure. The tall redheaded fellow probably has a better idea. [18:03] http://people.canonical.com/~ubuntu-archive/component-mismatches is not yet asking us to demote the world [18:04] * slangasek exercises patience [18:14] slangasek: I want to finish my reanalysis of build-dependencies first, which is still running; and there's a slightly suspicious complaint in the publisher log that I want to look into [18:15] ok [18:15] slangasek: pPretty close though [18:15] as I said, I'm exercising patience ;) [18:19] Could possibly just ignore that publisher warning, since I don't think its''s harmful. [18:22] cjwatson: The "already imported" warning? [18:22] Yeah [18:23] It doesn't much like having germinate in two places on the module path [18:24] But I think it's picking the right one [18:25] cjwatson: Why have two? [18:25] cjwatson: Oh, packaged and not? [18:26] cjwatson: If the only consumers on pepo are not using the git one, the simple solution would seem to be to ask IS to purge the package. [18:27] s/not/now/ [18:27] That's the most confusing typo, and I make it all the time. :/ [18:30] Yeah, I might do that at some point. [18:31] Made more sense for it to be installed from the package when the code was part of LP rather than the Ubuntu publisher hooks. [18:31] Slightly. [18:31] It generally makes sense for it to be installed from the package right up until you decide to mangle it in ways you can't/won't SRU. [18:32] Then the world goes all topsy-turvy, and you wonder if maybe those devil-may-care github types have a point. [18:32] It's been a bit of a pain for a while. [18:32] And you go drink that thought away. [18:32] Eventually I suppose it'll be one of the elements collected by a Mojo spec [18:34] w/win 38 [19:15] slangasek: heads up the team tells me they've gotten updates uploaded for light evening reading. [19:16] slangasek: and we're locking down the 2.0 release today with the release process kicking off monday to get the final debs for xenial early next week. [19:16] well, locking the tree with last minute bug/help doc updates for release monday [19:31] rick_h_: yes, I saw the new juju-core-1 upload come in, thanks - I expect to get that re-reviewed this afternoon. I've also started looking at the juju 2 that's in the queue; I think there are going to be some packaging changes needed there as well and will get that feedback to y'all ASAP [19:32] slangasek ty will keep an eye out so I can poke balloons and company on that. [19:36] would be nice if someone could review that lxd upload, I'll take care of a bunch of stuff from the queue in exchange, looks like we got a bunch of openstack bits in there. [19:41] ogra_: your livecd-rootfs upload's changelog doesn't say anything about that --initramfs-compression=none, what's that for? [19:41] ogra_: and is that in an ubuntu-core specific code path in that hook? kinda hard to tell with the limited diff context [19:47] slangasek: OK, I'm happy with the analysis output now [19:50] slangasek: so I think it's up to you to flip the switch :-) in LP, it's a matter of "xenial = lp.load('/ubuntu/xenial'); xenial.strict_supported_component_dependencies = False; xenial.lp_save()' - and I presume I can leave the seeds up to you [19:50] slangasek: pepo, nusakan, and snakefruit all have current germinate [19:53] slangasek: caveat: I will shortly be deciding that the pub is a more fun place to be [19:53] cjwatson: cool - otp, can you hang around 10-15 minutes before pubbing? [19:54] I imagine that would be tolerable [20:10] cjwatson: ok, launchpading done \o/ [20:11] cjwatson: now, sorry, what did you mean regarding seeds? Are there specific things your analysis points to needing changed, or do you just mean about explicitly seeding things we decide we don't actually want to drop? [20:11] rick_h, slangasek, I realized juju-core 2.0~beta3-0ubuntu2 is still in the queue. stokachu is going to upload the updated version of that one now too. So hopefully the changes needed will be small -- I believe Martin carried over your other feedback [20:11] So 2.0~beta3-0ubuntu2 can be rejected [20:11] uploading now [20:25] slangasek: there's a follow-build-depends flag in the seeds, which xnox's patch adds [20:25] I mean adds support for [20:25] that was half the point of the germinate upgrade [20:25] cjwatson: ohhh yes, that bit :) [20:26] right, I'll bzr commit now ;) [20:26] (done) [20:27] https://launchpadlibrarian.net/252195150/buildlog_ubuntu-xenial-amd64.libvirt_1.3.1-1ubuntu9_BUILDING.txt.gz [20:27] looks promising [20:27] not specifically libvirt I mean, but "deb http://ftpmaster.internal/ubuntu xenial main universe" [20:28] oh yeah, no-follow-build-depends, not follow-build-depends [20:29] all right, so the LP bit looks good, I don't see this going horribly wrong from here; c-m should all update in a bit, SMS me if there's some kind of explosion [20:31] cjwatson: have a nice pubbing! [20:31] cjwatson: and thanks :) [20:44] slangasek: np. hopefully tomorrow, to cap off the week, we can flip the switch on advertising by-hash too [20:53] cjwatson: nice! [21:32] cyphermox, infinity, here is a mockup of that thing we talked about using Provides some time back for signed packages so you don't need to rebuild -signed if EFI binary didn't change. http://paste.ubuntu.com/15679345/ [21:32] comments welcome [21:33] (obviously hashes to build against would be notated in debian/hashes.mk and be what gets updated in -signed packages) [22:01] infinity: when do release notes for a release get created? [22:10] Binary only movements to universe (ubuntu-server) [22:10] [...] [22:11] golang-1.6 [22:11] oops [22:11] well, you got what you asked for with that new policy :) [22:11] but yeah, that one probably should be seeded in supported or something :) [22:11] I thought we determined that one was a false-positive due to wrong built-using [22:12] is C-M aware of built-using? [22:12] yes [22:12] ah, neat [22:19] micahg, Laney: bug 1567682 [22:19] bug 1567682 in trusty-backports "Please backport cgroup-lite 1.11 (universe) from xenial" [Undecided,New] https://launchpad.net/bugs/1567682 [22:20] I'll need that one acked before I can backport LXC 2.0 to trusty, AFAIK it's the only bit that needs backporting to unblock 2.0 [22:40] bdmurray: gah, my SRU FTBFS :( ^^ fixed python-setproctitles in the queue. I used -v, so the LP bug is still included in the changes. I can't remember if that's correct? [22:41] holding off on those maas binaries, they're empty (template + postinst only for d-i) so arch:any seems a bit wrong [22:43] oh well, apparently someone else was happy with them :) [22:44] tumbleweed: the LP bug was included [22:45] bdmurray: yes [22:45] tumbleweed: I was trying to say yes that seems correct. [22:45] ah, thanks :) [22:56] slangasek: well, that sure is a lot of demotions [22:57] :-) [23:09] slangasek: are you going to announce this change? seems -devel-announce worthy [23:10] cjwatson: yes, planning to. Had thought to only announce it on ubuntu-devel, but happy to be persuaded it's u-d-a material [23:10] yeah, looking at recent archives I can see it's a good fit [23:12] I'm thinking it's the sort of thing developers who aren't paying attention to everything day-to-day would want to know about in case it affects their builds, or to remember to undo Ubuntu-specific bodges in merges [23:14] * nacc agrees with the latter [23:21] can someone point me to docs on "built-using" ? [23:22] my google queries are not coming back with anything useful. [23:23] Kamilion: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using [23:23] tumbleweed: thanks. [23:24] hi all - how can I get the mir upload approved? === s8321414_ is now known as s8321414 [23:38] how did libquvi suddenly build? [23:40] ahh, it's libquvi-scripts which still has the deb-waits [23:45] doko: archive reorg happened, and I retried it because I knew that's what was sticking it [23:45] don't worry, no lua promotions ;) [23:49] bdmurray: A long time ago. [23:50] slangasek: I don't see golang trying to demote. [23:51] infinity: I seedededed it [23:51] seems a worthy top-level package to have in the development seed [23:53] slangasek: I like that all the dh-* helpers fall out too. We might want to seed a few of those. :) [23:54] Like dh-autoreconf, dh-systemd, etc. [23:54] Basically, anything that isn't a dh-$language addon. [23:54] infinity: well, if you wish, though I'm not sure why you care about security support for dh-autoreconf ;) [23:55] * rbasak thinks up ways to inject malicious code via dh-autoreconf [23:55] rbasak: more malicious than injecting m4 into the developer's eyeballs? [23:56] :-) [23:56] slangasek: I was thinking less about *security* support and more about a statement of supported tools in general, but meh. [23:57] infinity: right, so feel free, honestly. I'm not sure how weight that particular meaning of "main" carries nowadays, especially in light of the change we just made, but it's not like we *have* to demote all of these [23:58] slangasek: Sure. We might want to have a quick pow-wow where $more_than_one_sane_person just runs down the list and makes a quick argument for demote-vs-seed before we demote the lot. [23:58] infinity: *-perl: demote [23:59] slangasek: Or, decide that we don't care and it can all go, and skip the rest of the meeting. [23:59] anything on this list that's owned by Foundations: demote ;-) [23:59] slangasek: See, I don't care about perl modules because they also happen to be very well maintained both in CPAN and Debian, and almost never break. [23:59] slangasek: But a lot of build tools, we touch a lot, so we're clearly "supporting" them. ;)