[09:34] -queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (xenial-proposed/multiverse) [5.0.36-0ubuntu1.16.04.2 => 5.0.38-0ubuntu1.16.04.2] (no packageset) [09:34] -queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.0.36-dfsg-0ubuntu1.16.04.2 => 5.0.38-dfsg-0ubuntu1.16.04.1] (ubuntu-cloud) [09:34] -queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (xenial-proposed/multiverse) [5.0.36-0ubuntu1.16.04.2 => 5.0.38-0ubuntu1.16.04.2] (no packageset) [10:10] -queuebot:#ubuntu-release- Unapproved: caja (zesty-proposed/universe) [1.18.1-0ubuntu1 => 1.18.1-0ubuntu2] (ubuntu-mate) [11:03] where are new releases announced? Mark's blog or ubuntu-announce? (me is looking for the new AA codename :) ) [11:04] Mark's blog is where the name comes out first [11:04] LocutusOfBorg, marks blog first ... [11:04] Then everyone goes AAAAAARGH and writes it into the 9999 places where it's hardcoded [11:04] and thinks "we should do this better next time" [11:04] loooool true sad story [11:05] and next time the code will be hardcoded in even more places [11:05] we have about a 30 step checklist just for the kernel when a new name comes [11:05] haha [11:06] anyway, now that buildinfo is fixed in lp, I really hope to see the new dpkg out, and pie enabled everywhere for 17.10 [11:06] But only if pumpkin pie. [11:06] when the toolchain is uploaded.... that would be a nice timing for doing it :) [11:06] * apw would settle for a name [11:07] He's trying to break the record for longest time without a codename. [11:08] probably :) === klebers_ is now known as klebers === RAOF is now known as Guest94094 [12:18] Ukikie: at least it's not May yet! http://markshuttleworth.com/archives/1468 [13:15] -queuebot:#ubuntu-release- Unapproved: ceph (trusty-proposed/main) [0.80.11-0ubuntu1.14.04.1 => 0.80.11-0ubuntu1.14.04.2] (core) (sync) [14:28] can cloud-init in xenial-proposed be released? [14:28] it's all green and had 9 days [14:49] xnox: I can take a look at that [14:49] Wow, that's a lot of bugs [14:56] xnox: it's on my plate, will release it once I browse through all the bugs, might take a minute as we have a meeting in 5 minutes [14:56] sil2100, cool. note that i guess you want to release yakkety at the same time as xenial. thus all the bugs need to be checked that they were tested for both releases...... [14:56] /o\ [14:57] Yeah, this is why it'll take a bit [15:13] xnox: hmmm, looking at LP: #1669504 now - seeing smoser's comment I see he tested it twice on xenial instead of once for xenial and once for yakkety [15:13] Launchpad bug 1669504 in cloud-init (Ubuntu Yakkety) "net/sysconfig.py is broken with ipv4 + ipv6 interfaces" [Medium,Fix committed] https://launchpad.net/bugs/1669504 [15:13] Let me get more info on that from him [15:25] Ok, all clear [15:25] (regarding this bug of course) [15:25] Still a few to go [15:32] slangasek, could you please try releasing systemd 232-21ubuntu3 from zesty-proposed into zesty? As per https://people.canonical.com/~ubuntu-archive/pending-sru.html all bugs are green. [15:33] however there are a few autopkgtests flagged up [15:33] snapd -> as far as I know they always fail, imho snapd should be ignored failure, no? [15:33] they are certainly not supposed to always fail [15:34] but they have been for most of zesty, i thought they are expected to only pass on xenial [15:34] that is not at all the expectation [15:34] given that core is not doing a zesty / 17 release [15:34] snapd is a package in the archive, it's how snaps are used on classic Ubuntu, and it is expected to work [15:35] please don't make excuses for failing autopkgtests - we will override them as necessary, but let's not make ourselves victims of low expectations [15:35] i'm pretty sure it is not a new regression caused by my systemd SRU. http://autopkgtest.ubuntu.com/packages/snapd/zesty/amd64 [15:35] also it looks like latest snapd did pass [15:35] * xnox ponders if I should rerun snapd+systemd together as triggers [15:35] snapd/2.24+17.04 was clearly bad. [15:36] running together would be nice [15:36] there is also dovecot/armhf open-iscsi/amd64 that look crazy [15:37] open-iscsi > grraaaaahh [15:37] xnox: can you take care of triggering the snapd reruns with 2.24.1+17.04+new systemd? [15:37] a timeout, hrm ... [15:37] yes [15:38] I'm retrying open-iscsi [15:39] slangasek, retriggered snapd with systemd&snapd triggers on amd64, i386 and ppc64el. snapd is failing on armhf and s390x (lxc/lxd runner problem? snapd tests should be marked as isolation-machine?) [15:40] they almost certainly should, yes [15:41] slangasek, looking at http://autopkgtest.ubuntu.com/packages/dovecot/zesty/armhf it appears to be unstable/flaky on armhf. As it flip flops between passing and failing. [15:41] yes, I've just retriggered that one again [15:42] it tries to create sockets, that should be allowed under lxd.... (to test imap4s protocol) [15:42] yes, and it does other network tests successfully before that [15:42] They have the appropriate restrictions as far as I know. [15:42] xnox: and then the systemd test failures are the infra issue mentioned? [15:43] and now let's talk about systemd failing tests. [15:43] amd64 failing only one test - upstream FAIL timed out. [15:43] which fails with [15:43] KVM: entry failed, hardware error 0x0 [15:43] EAX=00000000 EBX=00000000 ECX=00000000 EDX=000206a1 [15:44] due to nested kvm busted in on of the regions. But there is a confirmation from security team that tests no longer hang and all pass on the linked bug reprot. [15:44] also it passed here https://bileto.ubuntu.com/excuses/2719/zesty.html [15:45] .. [15:45] armhf has root-unittests failing (still unfixed, that test failure is not a regression as previously reported by you) [15:45] .. [15:46] armhf & s390x have "boot-smoke" test failing which reboots the "machine", lxc/lxd container in this case, and expects no jobs (i.e. units that neither failed or managed to start, aka "starting") to be running after a time-out [15:47] that fails in the containers, with spurious random things still not fully booted. [15:56] xnox: ok, as for cloud-init, still awaiting confirmation on some doubts on two of the verified bugs [15:56] xnox: systemd/armhf has been failing, revved my hint versions [15:57] xnox: fwiw I would also take mps against lp:~ubuntu-sru/britney/hints-ubuntu-zesty [15:57] Is there any chance someone's going to look at those failures? [15:59] well, i was fixing actually critical bug reports on supported architectures.... [15:59] * xnox pretends raspbery pi does not exist, and we don't have any products or clouds on armhf [15:59] slangasek, can we drop armhf because it is not 2038 year safe? [16:00] xnox: we do. armhf is a supported ubuntu-core IoT architecture [16:00] slangasek, correct, but it's not a product with support contracts. [16:01] that does not mean it's ignorable/droppable [16:01] sil2100, fair enough. thank you for review! [16:03] infinity, xnox: wrt not badtest'ing systemd for the infra issue, I did exactly that for the version prior to release so that the continuing failures wouldn't hamstring other migrations. I think that's equally correct here, and the hint should be dropped when the infra is fixed [16:03] last successful run was Mar 10 [16:03] slangasek: Well, it was also actually broken in systemd for the previous version. [16:03] slangasek: This upload fixes that, but not the infra. :P [16:03] slangasek: But I'm not picky. [16:04] actually broken how? I had it marked in my hint as 'regressed on infrastructure (timeouts)' [16:04] The timeouts were not an infrastructure bug [16:04] One is, one isn't. [16:04] slangasek, test-12 did actually hang and there is ADT fix to resolve the hang of test-12 -> bug in systemd tests, not infra bug [16:04] Because confusing. [16:04] The nested KVM failure we're now seeing is a kernel bug that you can arguably call infrastructure [16:05] they were a test behavior change not correlated with a code change in systemd [16:05] it's easy to see that one from logs [16:05] slangasek: It was a change in netcat that broke the test. [16:05] ok [16:05] netcat-as-infrastructure [16:05] slangasek, infinity: can we force good region for adt tests on amd64? [16:05] Netcat As A Service? [16:06] xnox: I don't think we have the ability to force regions, but ICBW. [16:06] * Laney doesn't answer as he wasn't asked [16:06] We can force VM sizes, which might accidentally pick a region, if only one has large? :P [16:06] well Laney did trigger the tests in specific region before. [16:06] Laney: Hey, can you answer the above? ;) [16:06] The answer is no, and no to the m1.large thing [16:06] I ran the tests manually [16:06] i see. [16:07] .... [16:07] It wouldn't be so hard to add a hack to autopkgtest-cloud for this though [16:07] If the region is lgw01 and the package is , don't pick it up [16:08] * xnox ponders to run the upstream tests twice, once with qemu and once with nspawn, such that we get results for both. And can exect fail qemu ones, if the nested KVM is borked. [16:09] Laney: is that a change you want to make, instead of me hinting the failure into oblivion? [16:09] I can probably do that quickly [16:09] Thinking of the nicest way to do it [16:09] Perhaps I extend the blacklist syntax to take a region [16:10] Laney: ok. if you're going to do that, can I ask you to retry the test for zesty once implemented? (and maybe you wanted that for a test case anyway) [16:10] sure [16:10] if you'll do that, then I'll ignore the current failure for letting through the SRU (and not twiddle hints) [16:11] slangasek, about armhf bug report.... i need shell on an armhf machine. I'm told there is something like diamond for armhf, no? [16:12] xnox: porter-arm64.internal? [16:12] and the armhf chroots therein [16:12] ... and porter boxes will not give me root, these tests fail under root only [16:12] you said shell [16:12] slangasek, ^ [16:12] if you need root, talk to dannf [16:12] root shell =) [16:12] dannf, could you please give me *root* shell on armhf? [16:13] xnox: you mean arm64, with armhf chroot ;) [16:13] (otherwise you're not reproducing the testbed accurately anyway) [16:14] dannf, that ^ [16:14] I'd like to fix that. I wonder if I can find time. [16:14] fix what? [16:14] ("that" being the lack of actual armhf VMs in scalingstack/autopkgtest) [16:14] It's not like it isn't doable, it's just a bit of effort. [16:14] and miss out on all the beautiful sigbus? [16:15] We can make it sigbus too. [16:15] For real armhf kernels, it's a proc twiddle. [16:16] xnox: any chance you want to help the other systemd SRUs through while you're at it? [16:22] slangasek, i could. [16:22] i did see them.... [16:22] * xnox needs to update packaging branches too, I guess to not loose it. [16:26] xnox: yeah, i should be able to give you access to a maas for that. [16:26] dannf, and a maas handbook =) [16:59] -queuebot:#ubuntu-release- Packageset: 6714 entries have been added or removed [17:21] slangasek: ok, done, and both open-iscsi and systemd retried and landed on lcy01 this time [17:22] annoyingly I think they landed there by chance and didn't actually exercise the new codepath [17:22] still, hope they work [17:23] guess I should try to do this for systemd-upstream too [17:24] Laney: Time to teach autopkgtest about artful. [17:24] Not now, time to go out. [17:24] I'll do things first thing tomorrow [17:25] I've not done a new release for autopkgtest before. Going to be fun. :) [17:25] Kay. I'll keep us frozen until that, because no britney = no fun. [17:25] But at least people will have a queue to throw things at. [17:27] * Laney gets scared at the lack of documentation for this on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure [17:27] Laney: You'll be fiiiiine. [17:27] I know about the seed-things-and-stuff script [17:27] Laney: I'm also sure that pitti won't mind taking some time to help you out. [17:27] Yeeeeeeeeeeah, what could go wrong? [17:28] It'll be okay, I can trigger test runs as long as the archive exists [17:29] The archive exists as of now. [17:29] It'll even be in a usable state a bit later than now. [17:29] Well job. [17:29] Right, ttyl [17:29] WOAH. [17:30] * Laney fixes that messed up commit first [17:37] Laney: Before you go... Remind me of something. [17:38] Laney: For things I upload today, before autopkgtesting is ready, can we tell britney tomorrow to trigger tests for it all? [17:38] Laney: Oh. Nevermind. I answered my own question, sort of. We can just not enable britney for artful until after autopkgtesting is good to go, then all those uploads will be "new" in britney's mind. [17:40] infinity: If there's a block-all source then tests won't get triggered either [17:40] Which there currently is. [17:41] So that works. [17:41] Super sick safe solid sound [17:41] BYE [19:06] so we're officially artful aardvark? say it's not true [19:06] aardvark never hurt anyone. [19:08] yes, but artful? now we set ourselves up for trouble if we don't have the most gorgeous release ever XD [19:09] wxl: artful ?? we gonna call it arty ? [19:09] yeah, that too [19:10] wxl: artful isn't just about art though [19:10] um [19:10] yes you can take liberties with the definition.. [19:12] https://en.oxforddictionaries.com/definition/artful [19:22] yeah, it's not so much taking liberties with the definition as, well, just being the definition. [19:23] think the artful dodger :) [20:02] question: do the bittorrents and/or zsync options that we publish use the published hash values to check the integrity of the downloaded file? [20:03] i.e. are that somehow susceptible to man in the middle attacks? [20:04] is the publisher stopped, or just saturated from artful opening? [20:08] mdeslaur: The latter. It's thinking very, very hard. [20:08] thanks infinity [20:08] wxl: torrents and zsync could be MitM, but you're meant to check the results against the signed hashes, just as you would for an http or rsync download. [20:09] wxl: The transport is not going to save you from actually looking at the result. [20:09] slangasek, just dovecot/armhf and systemd/armhf red now [20:10] retried tests are all green (e.g. snapd on the three good arches) [20:10] release? [20:10] xnox: dovecot just finished retrying and passed; systemd/armhf I had added a hint to but possibly forgotten to push; yeah releasing now [20:10] winning [20:10] infinity: ^^ do I need to worry about the forward-copy to artful-proposed? [20:11] slangasek: No. [20:11] ok [20:11] slangasek: I'll do the world in a batch once the archive is done hating me. [20:11] infinity: so I do need to worry about not deleting it out of zesty-proposed, which is more what I was getting at :) [20:11] slangasek: I'm smart enough to be able to fish things out of updates too. [20:11] ok [20:12] For some value of both "smart" and "enough". [20:12] xnox: btw looks like there was also a lost test for freeipa/armhf ... that shows up in update_excuses but not the pending SRU report [20:33] err, where are we getting the name artful from? I don't see a sabdfl blog post? [20:33] the repos, tumbleweed [20:33] so release team is now picking names? [20:34] * wxl shrugs [20:34] but yeah, I see we have https://launchpad.net/ubuntu/artful so I guess I can update distro-info-data appropriately [20:35] tumbleweed: Some of us talk to Mark via means other than his blog. [20:36] if there isn't a big reveal, does that mean we can get names out of him sooner? [20:36] tumbleweed: Can't say. :P [20:36] :P [20:37] tumbleweed: My process for pestering him (and his response to said pestering) changes subtly from release to release. I make no promises about the future. [20:37] sounds about right [20:37] So far, his response has not been "holy crap you're annoying and, also, fired", so I think I'm winning. [20:38] infinity: is publishing currently on hold during opening? imma waiting for an SRU to land [20:38] slangasek: Not on hold, just dog slow. [20:38] ack [20:38] slangasek: Methinks the LP DB servers need to learn to shove a whole new set of indexes in RAM/bcache. They should learn soon enough. [20:43] does October 12 sound reasonable as a release date? it's the second thursday [20:47] I'm happy to start writing the ReleaseSchedule page if nobody is already doing it. [20:49] tumbleweed: It should be 26 weeks from now, looking at our current cadence. [20:49] (April is meant to be 27 and October 25, but 17.04 was 26 due to Easter, so 26 for 17.10 would put us back on track) [20:51] cyphermox: Feel free to copy/waste and fill in the blanks. They should almost line up exactly with last cycle. [20:51] yup [20:52] tumbleweed: Assuming I can count, I think the 12th is right. [20:52] infinity: right, I think that makes October 12th correct [20:52] infinity: and EOL is then something like 2018-07-12 [20:53] EOL is always a bit fudgy anyway, but yeah that sounds close enough. [20:53] "Exactly 9mo" is certainly the date people should be expecting. [20:53] If I give them a free 3 days, that's a bonus. :P [20:59] tumbleweed: please let's do end of October [21:00] not my call :) [21:00] I'm just trying to predict what we'll do [21:00] I would like us to align better with https://wiki.gnome.org/ThreePointTwentyfive [21:01] GNOME pushed their release schedule forward a week this time just for Ubuntu (even before the Big Announcement) [21:03] if we pushed Artful back to at least Oct 19, then there's a full week to get 3.26.1 in (if we go GNOME 3.26) before the release [21:03] otherwise, it takes a few weeks to get the .1 SRUs published [21:07] jbicha: Oct 4 -> Oct 12 should be more than enough time to rev the world? :) [21:08] Well, Oct 4 -> Oct 7 or something. [21:08] Oct 2, if "tarballs due" really means they'll all exist. [21:09] Easter 2018 is Apr 1, so we could perhaps push back by a week across the board. I do want a 27wk cycle for 18.04, though. [21:09] Which had to still happen in April. [21:09] Because 04. [21:10] for 3.24.1, it looks like gdm and gnome-session tarballs appeared on Wednesday and gnome-shell/mutter appeared on Tuesday of 3.24.1 release week [21:11] zesty was released on Thursday so that felt way too risky to be messing with those components that late [21:12] (base)adconrad@nosferatu:~$ date -d 'october 12 27 weeks' [21:12] Thu Apr 19 00:00:00 MDT 2018 [21:12] (base)adconrad@nosferatu:~$ date -d 'october 19 27 weeks' [21:12] Thu Apr 26 00:00:00 MDT 2018 [21:12] So, if we do a 27wk schedule for 18.04, we release on the 26th. Which is doable. [21:13] Assuming a 27wk schedule for 17.10 [21:13] Then we'd go back to 25/27, ish. [21:13] Except that Easter keeps breaking that every couple of years. [21:13] Stupid 4-day weekend. [21:14] I would be happier if we never did early October again actually [21:14] The point of 25/27 is that we lose a ton of development time over the year-end break. [21:14] So 25/27 makes up for that, to a degree. [21:14] right, I remember the 10.10.10 release cycle; I'm skeptical of that theory though [21:14] (base)adconrad@nosferatu:~$ date -d 'Thu Apr 26 00:00:00 MDT 2018 25 weeks' [21:15] Thu Oct 18 00:00:00 MDT 2018 [21:15] Keeping that cadence would put us just past mid-October for 18.10. [21:16] And then back to Apr25 for the next 04. Which will break because Apr 21 easter. [21:16] But that can be another 26 to compensate. [21:16] Whee. [21:17] So, I think what works here is "27wk Oct 19, 2017", "27wk Apr 26, 2018", "25wk Oct 18, 2018", "26wk Apr 18, 2019" [21:17] And I refuse to plan further out than that. [21:18] ^--- Thoughts, emotional responses? [21:18] and I would be happy with that, thanks! :) [21:19] slangasek: ^-- Can I get a +1 on that? Note the 19.04 release is 26wk due to Easter being the following weekend, like this year. Easter 2018 is a more convenient Apr 1. [21:20] cyphermox: Please toss the above scratch notes in the comments for AA/ReleaseSchedule, so we can crib from it when expanding to proper wiki pages. [21:21] I think the SRU team would be happier with fewer big SRUs immediately after release [21:22] -queuebot:#ubuntu-release- Unapproved: gjs (zesty-proposed/universe) [1.48.0-0ubuntu1 => 1.48.2-0ubuntu0.1] (desktop-extra, mozilla, ubuntugnome) [21:22] jbicha: The SRU team would be happy if no one ever uploaded SRUs. Our users, however, would not. [21:22] Clearly, we should fire our users. [21:23] infinity: You or someone else should possibly consider updating that topic :P === infinity changed the topic of #ubuntu-release to: Released: Xenial 16.04.2, Zesty 17.04 | Archive: closed | Artful Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis [21:24] I feel like "Artful Release Coordination" is an accurate description of what we do, and the topic need never change again. [21:24] XD [21:25] On another releasey related thing, I've been getting this recently after running sudo apt update: W: Conflicting distribution: http://us.archive.ubuntu.com/ubuntu devel InRelease (expected devel but got artful) [21:25] (but before, s/artful/zesty/ [21:25] ) [21:25] Yeahp, that's a known misfeature. [21:25] Using devel in sources.list isn't entirely sane. [21:26] We might need to teach apt to relax that check or something, if people really want to use it. [21:26] infinity: Why isn't it sane? :P [21:26] And what's the issue? I want to file a bug. :P [21:26] Well, I'm unconvinced that the "devel" symlink existing at all is sane. But I lost the argument. [21:27] That aside, though, it's just slightly not sane because of the tool issues you've noticed. [21:27] How can we fix these tool issues? [21:28] Either by making apt less picky or by making the publisher right a separate Release file for devel (which would also imply devel not being a symlink anymore, but perhaps a hardlink farm) [21:28] It's not something any of us have wasted much energy planning to fix. [21:28] s/right/write/ I can't brain right now. [21:29] It gets trickier for PPAs, since they're not forced to republish like the primary archive is. [21:29] infinity: ack [21:29] Republish? [21:29] So PPAs that haven't been touched for 7 months have "devel" pointing to yakkety. [21:29] Which is super gross. [21:29] EEW [21:29] I agree. [21:30] This all came about when people were faffing on about "rolling" and how that was the New Hotness, and all cool distros "roll". [21:30] The devel symlink was the compromise. [21:30] But I consider it a failed experiment, and maybe we should just revert it. [21:31] Please reject gjs 1.48.1-0ubuntu1/zesty since it's been superseded by 1.48.2 [21:31] infinity: Side note, I think it would be Super Duper Awesome if PPAs could act as their own mini archive. Like, you turn on an option and it enables britney etc. Just putting the idea out there. :P [21:31] Anyways, shiny squirrel. [21:31] infinity: Well I like to keep my sources.list on devel because I like that illusion. :P [21:32] But hey, it's worth the discussion if you want, infinity? [21:33] tsimonq2: PPAs can do that, sort of. It's functionality external to LP. [21:33] tsimonq2: But it's something we're not currently dedicating resources to improving or making more widespread or self-serve. [21:35] jbicha: That's... Weird. The delta from 1.48.0 to 1.48.1 was 223K, the delta from 1.48.0 to 1.48.2 is only 22K. Did they revert a mess of stuff from .1 to .2? [21:36] Or maybe that's just all autotools vomit from .1 being built with a different version than .0 and .2 [21:36] I blame autotools [21:37] the good news (?) is that many GNOME modules will switch to meson for 3.26 or 3.28 so there won't be all that junk in the diffs any more [21:37] jbicha: Yeah, automake 1.14 versus 1.15, looks like. Whee. [21:37] can I talk you into accepting gjs while you're looking at it? [21:38] jbicha: I don't know what meson is, but if it's Yet Another Attempt to Replace Autoconf, I'll be skeptical. [21:38] cmake only took a decade to almost sort of work, ish. [21:38] http://mesonbuild.com/ [21:39] -queuebot:#ubuntu-release- Unapproved: rejected gjs [source] (zesty-proposed) [1.48.1-0ubuntu1] [21:40] it's written in Python and it's from Jussi Pakkanen [21:40] jbicha: Yeah, looks like it has the same goals as cmake. And will probably end up with the same mess of out-of-tree modules and horrible gotchas as people realise the default doesn't work for their use case. [21:40] jbicha: But oh well. [21:41] If it works for GNOME, cool for them. [21:41] ("written in python" and "fast" is a bit of a disconnect, though) [21:41] infinity: Would you be okay with me creating the ArtfulAardvark wiki page? [21:42] tsimonq2: Go for it. [21:42] mdeslaur: I see a bunch of security pockets doing publishy things now, you should be in a happier place soon. [21:46] jbicha: Do you want me to test this in a devirt PPA for you before I accept it and it fails? :P [21:47] infinity: yes please [21:48] jbicha: https://launchpad.net/~adconrad/+archive/ubuntu/staging/+packages [21:48] infinity: https://wiki.ubuntu.com/ArtfulAardvark [21:49] infinity: Looks like cyphermox already created the ReleaseSchedule page. [21:53] infinity: +1 on the release schedule question above; awkward that it throws us off the 25/27 right after we agreed to it, but seems like the right thing there [21:55] slangasek: Yeah, rules are made to be broken. [21:56] slangasek: Easter will forever be a thorn in our side (or crown?) unless we slip the whole shebang to 05/11 [21:57] not to be confused with heimdal's debian/rules, which makes libroken [21:58] I prefer libiberty. [21:59] infinity, slangasek: Question: Are there plans to align our release schedule with GNOME's a bit more, now that GNOME is going to be the default desktop? [21:59] Or is it already pretty aligned? [22:00] infinity: gjs built successfully :) [22:00] infinity: ah, yes, thanks! [22:00] jbicha: So it did. Yay. [22:01] tsimonq2: It's always been more or less aligned, ever since we worked with them to align us all when they were our default desktop. [22:01] -queuebot:#ubuntu-release- Unapproved: accepted gjs [source] (zesty-proposed) [1.48.2-0ubuntu0.1] [22:02] tsimonq2: But we have to shuffle things around here and there for things like long weekends, so it's never perfect. [22:02] tsimonq2: It's not a coincidence that we both release every 6mo in the same month. [22:05] jbicha: "make[1]: Nothing to be done for 'test'." [22:05] jbicha: That might explain it working everywhere. [22:10] jbicha: (As in, there is no testsuite being run) [22:10] infinity: ack :) [22:11] jbicha: So, I expect the same autopkgtest failure on s390x. Which, at a glance, looks like it might be an endian bug $somewhere. [22:26] /lastlog distro-i [22:26] Erm.