[01:02] slangasek, boot-smoke tests, after a few reboots detects that network-manager fails to start. thus i am suspecting the new network-manager is toast. [01:02] Aug 02 00:59:46 normal nm-online[473]: Error: Could not create NMClient object: Timeout was reached [01:03] bdmurray, is that similar to what whoopsie saw ^ [01:03] cause e.g. it looks like NetworkManager-wait-online.service is affected [01:08] xnox: was the new nm toast before? [01:09] as per autopkgtest.ubuntu.com it did manage to pass with old systemd. [01:10] then what makes it toast now? [01:17] as far as i can see, it is racy, and when NetworkManager.service claims the bus, it is not yet ready to take connections, thus NetworkManager-wait-online.service fails. [01:18] i'm not sure if this is normal in unpriviledged container, but with network-manager installed, it boots degraded. [01:18] also i'm not sure if this is a valid test at all, to install network-manager and expect the system to boot non-degraded. i guess it is, even if NM is not managing anything. [01:20] also rtkit-daemon and systemd-hostnamed fail. === Guest52427 is now known as RAOF [03:25] xnox: no [05:17] -queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [146-1~ubuntu17.04.1 => 147-1~ubuntu17.04.1] (no packageset) [05:18] -queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [146-1~ubuntu16.04.1 => 147-1~ubuntu16.04.1] (no packageset) [05:22] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [147-1~ubuntu16.04.1] [05:22] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [147-1~ubuntu17.04.1] [06:04] -queuebot:#ubuntu-release- New: accepted libglvnd [amd64] (artful-proposed) [0.2.999+git20170201-4] [06:04] -queuebot:#ubuntu-release- New: accepted libglvnd [i386] (artful-proposed) [0.2.999+git20170201-4] [06:04] -queuebot:#ubuntu-release- New: accepted libglvnd [s390x] (artful-proposed) [0.2.999+git20170201-4] [06:04] -queuebot:#ubuntu-release- New: accepted mythtv [arm64] (artful-proposed) [2:29.0+fixes.20170728.696806310a-0ubuntu1] [06:04] -queuebot:#ubuntu-release- New: accepted mythtv [i386] (artful-proposed) [2:29.0+fixes.20170728.696806310a-0ubuntu1] [06:04] -queuebot:#ubuntu-release- New: accepted mythtv [s390x] (artful-proposed) [2:29.0+fixes.20170728.696806310a-0ubuntu1] [06:04] -queuebot:#ubuntu-release- New: accepted libglvnd [armhf] (artful-proposed) [0.2.999+git20170201-4] [06:04] -queuebot:#ubuntu-release- New: accepted mythtv [amd64] (artful-proposed) [2:29.0+fixes.20170728.696806310a-0ubuntu1] [06:04] -queuebot:#ubuntu-release- New: accepted mythtv [ppc64el] (artful-proposed) [2:29.0+fixes.20170728.696806310a-0ubuntu1] [06:04] -queuebot:#ubuntu-release- New: accepted libglvnd [ppc64el] (artful-proposed) [0.2.999+git20170201-4] [06:04] -queuebot:#ubuntu-release- New: accepted mythtv [armhf] (artful-proposed) [2:29.0+fixes.20170728.696806310a-0ubuntu1] [08:00] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.3] has been marked as ready [08:00] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.3] has been marked as ready [10:00] cyphermox, infinity - https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1708096 =( [10:00] Ubuntu bug 1708096 in The Ubuntu-power-systems project "Ubuntu16.04.3 Installation fails for JFS file system" [High,New] [10:02] xnox: Might be the prep-finddev (or whatever it is) thing not being clever enough. Probably has nothing to do with jfs. [10:03] infinity, i have a deja vu that it was fixed before with similar bug title. [10:04] xnox: Probably more likely to be the multi-disk setup. But I'll give it a spin on a VM and see. [10:04] e.g. https://bugs.launchpad.net/ubuntu/+source/partman-prep/+bug/1630017 [10:04] Ubuntu bug 1630017 in partman-prep (Ubuntu) "Ubuntu 16.10 installation with root as JFS file system fails" [High,Incomplete] [10:05] which is incomplete. [10:06] "grub-install: error: unknown filesystem." [10:06] Oh. [10:06] Maybe our grub isn't built with jfs support? [10:09] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (xenial-proposed) [2:13.1.4-0ubuntu2] [10:09] Not sure why we support installing to jfs anyway. Even IBM spent year advocating xfs over jfs (and they WROTE jfs). [10:10] s/year/years/ [10:10] jfs isn't in the signed image, but that shouldn't affect grub-install [10:10] (nor POWER ...) [10:11] AFAIK the jfs module is built unconditionally [10:11] my bet would be an endianness bug [10:11] or something like that [10:12] The bug looks even more whacky in that second one. [10:12] Things randomly dying and/or OOMing, but only with root on jfs. [10:12] to debug GRUB, I'd suggest making a loop fs on a real system of the right arch, and playing around with grub-fstest [10:13] (probably not actually endianness since ppc64el == x86 on that score) [10:13] cjwatson: If it's the same as the second bug above, I don't think it's grub at all, grub's just a victim. [10:13] Though, endianness bugs in an IBM-authored filesystem on ppc64el wouldn't be weird either. [10:14] Since there's a whole lot of ppc64 == be that's needed to be cleaned up. [10:14] yeah, I didn't look at all closely [10:15] the GRUB JFS module wasn't written by IBM [10:15] and it does appear to have at least some endian handling [10:16] but yeah, could be a bug in the filesystem that grub-install is running from, and as you say it's just a victim [10:28] infinity: if anything, I'll be doing some test runs for mythubuntu in some moments, just mentioning so not to duplicate testing too muchy [10:38] sil2100: Is "muchy" a Trump word? [10:38] sil2100: I look forward to you test results, bigly. [10:40] If it is then Trump is strange [10:40] (almost done with the changelog as well) [10:41] infinity, ok, i shall request logs and if it is OOMing for the report, they really should fix that. [10:42] xnox: I think OOMing was a suspicion of cyphermox's, but perhaps not the actual case. [10:42] xnox: Still, the original bug report lacks anyone actually finding a cause. [10:42] ok, but we do need logs from the installer. thus it is fair to request installer logs in the new bug report, and mark it incomplete. [10:43] cause we do need to see which system it is, how much memory it has, if there are OOM in syslog or not. [10:43] and the new one lacks details too. [10:45] The new one has logs. [10:51] win 18 [11:37] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [0.7.9-233-ge586fe35-0ubuntu1~16.04.1] [11:43] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (xenial-proposed) [1:16.04.8] [11:45] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (trusty-proposed) [1:0.196.24] [11:46] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (zesty-proposed) [1:17.04.5] [11:52] -queuebot:#ubuntu-release- Unapproved: accepted libapache2-mod-auth-pgsql [source] (xenial-proposed) [2.0.3-6.1ubuntu0.16.04.1] [11:53] -queuebot:#ubuntu-release- Unapproved: accepted libapache2-mod-auth-pgsql [source] (trusty-proposed) [2.0.3-6ubuntu0.1] [11:55] -queuebot:#ubuntu-release- Unapproved: accepted gtk+2.0 [source] (zesty-proposed) [2.24.31-1ubuntu1.1] [11:55] -queuebot:#ubuntu-release- Unapproved: accepted libapache2-mod-auth-pgsql [source] (zesty-proposed) [2.0.3-6.1ubuntu0.17.04.1] [12:12] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.3] has been marked as ready [12:12] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.3] has been marked as ready [13:22] apw: hey, ubuntu-image adt tests are failing on the snapcraft upload, which are not related to the snapcraft upload, sil2100 just told me there is an ubuntu-image upload which is unreviewed still which would fix it, since I fancy green results, is there a change you can accept it into -proposed? (1.1 has the fix) [13:23] Yeah, it seems that in the CVE quick-fix we made we missed adding fakeroot to the test deps [13:23] The new 1.1 that's in the queue should be good for everything [13:23] There's already a 1.1 in -proposed but it's busted because of other reasons ;p [13:23] So the re-upload is meant to fix the world [13:23] infinity: xnox: OOMing as the cause of JFS fails? I don't remember enough [13:24] oh, I see [13:26] apw, sergiusens: the ubuntu-image in the queue should be rather straightforward to review as 1.1 was already been reviewed and accepted once, this is the same changes + an autopkgtest skipped [13:27] cjwatson: IIRC, not endianness either, IIRC; I was also able to install with JFS on ppc64el; as I recall it only crashed for the reporter, and possibly only when multipath is in play [13:27] infinity: I think this matches what you saw? ^ [13:27] how often is artful sync'ed with debian? [13:28] infinity: oh, didn't know security could still push new packages to -updates/-security during the freeze - or is the webkit2gtk upload release-critical? [13:28] sil2100, security has a life of its very own [13:30] sil2100: Yeah, they never pay attention to my freezes. [13:30] sil2100: But we'll just pretend that didn't happen, unless there's a reason to respin. [13:33] ;p [13:35] clivejo: every six hours [13:35] arges: o/ [13:35] arges: I was about to start looking at SRUs. Realised I was still marked away. [13:35] -queuebot:#ubuntu-release- Unapproved: accepted gtk+2.0 [source] (xenial-proposed) [2.24.30-1ubuntu1.16.04.2] [13:36] arges: shall I leave it to you for a while? [13:36] do new packages go into Ubuntu new queue or bypass it? [13:41] clivejo: auto-synced new source packages bypass the new queue; the resulting binary packages require a semi-automatic rubber stamp [13:42] cool :) [14:26] -queuebot:#ubuntu-release- New binary: syslog-ng [ppc64el] (artful-proposed/universe) [3.10.1-3ubuntu1] (no packageset) [14:26] -queuebot:#ubuntu-release- New binary: syslog-ng [s390x] (artful-proposed/universe) [3.10.1-3ubuntu1] (no packageset) [14:28] -queuebot:#ubuntu-release- New binary: syslog-ng [amd64] (artful-proposed/universe) [3.10.1-3ubuntu1] (no packageset) [14:28] -queuebot:#ubuntu-release- New binary: syslog-ng [i386] (artful-proposed/universe) [3.10.1-3ubuntu1] (no packageset) [14:29] -queuebot:#ubuntu-release- New binary: syslog-ng [arm64] (artful-proposed/universe) [3.10.1-3ubuntu1] (no packageset) [14:29] -queuebot:#ubuntu-release- New binary: syslog-ng [armhf] (artful-proposed/universe) [3.10.1-3ubuntu1] (no packageset) [15:35] sil2100: lp:~sil2100/ubuntu-archive-tools/plus-sign-review, you made this code change locally and empirically tested that it fixed sru-review for gtk+2.0 (which is now no longer in the queue)? [15:36] slangasek: yes, used it to review it, tried a few others in the queue to see if the debdiffs are downloadable - works [15:36] I don't see a reason for the quote() there, but maybe I don't know the full story [15:36] sil2100: yeah, '+' is the only legal char in a package name that *might* be url encoded [15:37] sil2100: merged, thanks [15:37] slangasek: thanks for the review! [15:37] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (zesty-proposed/main) [1:0.4.22 => 1:0.4.22.1] (desktop-core, ubuntu-server) [15:49] sil2100,slangasek: I have filled in the archaeology that you were missing :) [15:53] (no changes required, you just may be interested) [15:53] cjwatson: righty-o [15:55] some day I must get my job title changed to Programmer-Archaeologist [15:56] ;) [15:56] Raiders of the Lost Archive [16:27] arges: Can you update your version of ubuntu-archive-tools to get the changes to sru-review? [17:10] -queuebot:#ubuntu-release- New binary: libjwt [ppc64el] (artful-proposed/universe) [1.8.0+dfsg-1] (no packageset) [17:11] -queuebot:#ubuntu-release- New binary: libjwt [s390x] (artful-proposed/universe) [1.8.0+dfsg-1] (no packageset) [17:11] -queuebot:#ubuntu-release- New binary: dtksettings [s390x] (artful-proposed/universe) [0.1.7-1] (no packageset) [17:12] -queuebot:#ubuntu-release- New binary: dtksettings [amd64] (artful-proposed/universe) [0.1.7-1] (no packageset) [17:12] -queuebot:#ubuntu-release- New binary: libjwt [amd64] (artful-proposed/universe) [1.8.0+dfsg-1] (no packageset) [17:13] -queuebot:#ubuntu-release- New binary: python-coloredlogs [amd64] (artful-proposed/universe) [7.1-1] (no packageset) [17:13] -queuebot:#ubuntu-release- New binary: python-dropbox [amd64] (artful-proposed/universe) [8.0.0-1] (no packageset) [17:17] -queuebot:#ubuntu-release- New binary: mathgl [ppc64el] (artful-proposed/universe) [2.4.1-2] (no packageset) [17:17] -queuebot:#ubuntu-release- New binary: libjwt [i386] (artful-proposed/universe) [1.8.0+dfsg-1] (no packageset) [17:19] -queuebot:#ubuntu-release- New binary: mathgl [s390x] (artful-proposed/universe) [2.4.1-2] (no packageset) [17:24] -queuebot:#ubuntu-release- New binary: dtksettings [arm64] (artful-proposed/universe) [0.1.7-1] (no packageset) [17:33] -queuebot:#ubuntu-release- New binary: libjwt [armhf] (artful-proposed/universe) [1.8.0+dfsg-1] (no packageset) [17:35] -queuebot:#ubuntu-release- New binary: libjwt [arm64] (artful-proposed/universe) [1.8.0+dfsg-1] (no packageset) [17:35] -queuebot:#ubuntu-release- New binary: mathgl [armhf] (artful-proposed/universe) [2.4.1-2] (no packageset) [17:36] -queuebot:#ubuntu-release- New binary: mathgl [amd64] (artful-proposed/universe) [2.4.1-2] (no packageset) [17:37] -queuebot:#ubuntu-release- Unapproved: pollinate (xenial-proposed/main) [4.23-0ubuntu1~16.04.1 => 4.25-0ubuntu1~16.04.1] (ubuntu-server) [17:40] -queuebot:#ubuntu-release- New binary: mathgl [i386] (artful-proposed/universe) [2.4.1-2] (no packageset) [17:46] -queuebot:#ubuntu-release- New binary: mathgl [arm64] (artful-proposed/universe) [2.4.1-2] (no packageset) [18:38] -queuebot:#ubuntu-release- Unapproved: pollinate (trusty-proposed/main) [4.23-0ubuntu1~14.04.2 => 4.25-0ubuntu1~14.04.1] (no packageset) [19:44] -queuebot:#ubuntu-release- New binary: gcc-7-cross-ports [i386] (artful-proposed/main) [3ubuntu2] (ubuntu-desktop) [19:47] "only" 1500 autopkgtests in the queue on amd64 [19:53] slangasek, just over 8.6k en-toto [19:54] that's good progress, hey; I estimated things'd be clogged until Friday [22:20] -queuebot:#ubuntu-release- New binary: gcc-7-cross-ports [amd64] (artful-proposed/main) [3ubuntu2] (ubuntu-desktop) [23:04] -queuebot:#ubuntu-release- New: accepted dtksettings [amd64] (artful-proposed) [0.1.7-1] [23:04] -queuebot:#ubuntu-release- New: accepted dtksettings [s390x] (artful-proposed) [0.1.7-1] [23:04] -queuebot:#ubuntu-release- New: accepted libjwt [arm64] (artful-proposed) [1.8.0+dfsg-1] [23:04] -queuebot:#ubuntu-release- New: accepted libjwt [i386] (artful-proposed) [1.8.0+dfsg-1] [23:04] -queuebot:#ubuntu-release- New: accepted libjwt [s390x] (artful-proposed) [1.8.0+dfsg-1] [23:04] -queuebot:#ubuntu-release- New: accepted mathgl [arm64] (artful-proposed) [2.4.1-2] [23:04] -queuebot:#ubuntu-release- New: accepted mathgl [i386] (artful-proposed) [2.4.1-2] [23:04] -queuebot:#ubuntu-release- New: accepted mathgl [s390x] (artful-proposed) [2.4.1-2] [23:04] -queuebot:#ubuntu-release- New: accepted python-dropbox [amd64] (artful-proposed) [8.0.0-1] [23:04] -queuebot:#ubuntu-release- New: accepted dtksettings [arm64] (artful-proposed) [0.1.7-1] [23:04] -queuebot:#ubuntu-release- New: accepted libjwt [armhf] (artful-proposed) [1.8.0+dfsg-1] [23:04] -queuebot:#ubuntu-release- New: accepted mathgl [amd64] (artful-proposed) [2.4.1-2] [23:04] -queuebot:#ubuntu-release- New: accepted mathgl [ppc64el] (artful-proposed) [2.4.1-2] [23:04] -queuebot:#ubuntu-release- New: accepted libjwt [amd64] (artful-proposed) [1.8.0+dfsg-1] [23:04] -queuebot:#ubuntu-release- New: accepted mathgl [armhf] (artful-proposed) [2.4.1-2] [23:04] -queuebot:#ubuntu-release- New: accepted libjwt [ppc64el] (artful-proposed) [1.8.0+dfsg-1] [23:04] -queuebot:#ubuntu-release- New: accepted python-coloredlogs [amd64] (artful-proposed) [7.1-1] [23:10] somehow my all proposed test is installing new systemd, but old udev. [23:11] -queuebot:#ubuntu-release- New binary: node-libs-browser [amd64] (artful-proposed/none) [2.0.0-1] (no packageset) [23:13] heh [23:44] slangasek, systemd and udev do not depend on each other, although both are priority important. In debian, udev is statically linked against libsystemd-private instead of dynamically to avoid a hard-dep between udev and systemd. [23:45] is it ok to dynamically link udev against libsystemd-private, and thus make a hard dep between bin:udev and bin:systemd? I believe bin:libudev1 should be unaffected by the change. [23:45] also, i think I need to change debian/tests/control to include udev everywhere. As testing new systemd with old udev makes no sense to me. [23:46] also i do not believe the two are truelly independant. [23:46] so the only test that failed for me on amd64 is boot-and-services which said that udevamd version is wrong 233 vs 234. [23:47] i ran the tests as: [23:47] autopkgtest -B systemd --apt-pocket=proposed --shell --shell-fail -ddd -- qemu ./adt-artful-amd64-cloud.img [23:47] hmm... missed --apt-upgrade [23:50] xnox: I don't understand why you would need to do this when they are from the same source package and should be affected by the same apt pin [23:50] is udev oddly blacklisted in the autopkgtest infra? [23:51] no idea. but, none of the debian/tests/control tests specify udev at all, only systemd. thus in theory we are not testing udev at all. thus all the apt mark pins stuff doesn't specify anything for udev. [23:51] a [23:51] ah [23:51] usually one does @ thing which means all built binaries. [23:52] i am thinking it is prudent to put udev into all the paragraphs in debian/tests/control, in addition to systemd. [23:52] well, why does having the mismatch cause things to fail? [23:53] if it causes things to fail because you actually are testing udev, then I guess you should depend on udev [23:53] udevadm --version reports wrong thing [23:53] there is test to make sure that udevadm --version matches the version specified in systemd.pc pkg-config file. [23:53] right, then the test should dep on udev :) [23:54] * xnox wonders if we ever managed to migrate new major systemd version without an override [23:54] also it uses nested kvm =/ [23:54] however, i do have green on ppc64el and s390x now =) so all arches i care about are perfect =) [23:56] xnox: i think i figured out the open-iscsi failure in a-p, there's a test to see if iscsid has started, and it will fail with the new systemd constraints on directories existing indicating iscsi is actually in use. Seems reasonable to just drop that test, right? I'm asking smoser about it as well, to be sure [23:56] is that because the tests skip on those arches? [23:56] but about shared link stuff, typically we do have both systemd and udev running, and linking libsystemd-private dynamically may reduce the size of udev binary. I shall check that. [23:57] nacc, which tests are these? the ones in src:open-iscsi ? and yes makes sense to drop it. [23:57] nacc, or the tests should setup the test bed, to make iscsi daemon _in_use_ and check that it is autostarted on reboot. [23:57] no? [23:57] * xnox ponders if that is at all possible to do within a scope of a single machine. [23:57] export and mount something on the same host?! [23:59] xnox: yeah, dep8 in open-iscsi [23:59] xnox: yeah, it uses nested kvm, i think, to do that [23:59] xnox: so we could defer the test until the iscsi disks are setup and then see if in the nested it is running/startable/stoppable