[01:32] -queuebot:#ubuntu-release- Unapproved: zim (eoan-proposed/universe) [0.69.1-1 => 0.72.0-1] (no packageset) (sync) [01:33] -queuebot:#ubuntu-release- Unapproved: accepted zim [sync] (eoan-proposed) [0.72.0-1] [02:15] -queuebot:#ubuntu-release- Unapproved: variety (eoan-proposed/universe) [0.7.2-1 => 0.7.2-2] (no packageset) (sync) [02:16] -queuebot:#ubuntu-release- Unapproved: accepted variety [sync] (eoan-proposed) [0.7.2-2] [05:19] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (eoan-proposed/main) [2.619 => 2.620] (desktop-core) [05:20] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (eoan-proposed) [2.620] [05:47] -queuebot:#ubuntu-release- Unapproved: ghdl (eoan-proposed/universe) [0.35+git20181129+dfsg-4 => 0.35+git20181129+dfsg-4ubuntu1] (no packageset) [05:47] -queuebot:#ubuntu-release- Unapproved: accepted ghdl [source] (eoan-proposed) [0.35+git20181129+dfsg-4ubuntu1] [06:00] -queuebot:#ubuntu-release- Unapproved: golang-gopkg-lxc-go-lxc.v2 (eoan-proposed/universe) [0.0~git20190625.f4822c6-0ubuntu1 => 0.0+git20190625.f4822c6-1ubuntu1] (edubuntu) [06:01] -queuebot:#ubuntu-release- Unapproved: accepted golang-gopkg-lxc-go-lxc.v2 [source] (eoan-proposed) [0.0+git20190625.f4822c6-1ubuntu1] [06:04] -queuebot:#ubuntu-release- Unapproved: nftables (eoan-proposed/universe) [0.9.2-1ubuntu1 => 0.9.2-2] (no packageset) (sync) [06:04] -queuebot:#ubuntu-release- Unapproved: accepted nftables [sync] (eoan-proposed) [0.9.2-2] [06:09] -queuebot:#ubuntu-release- Unapproved: libapache2-mod-perl2 (eoan-proposed/main) [2.0.10-3ubuntu1 => 2.0.11-1ubuntu1] (ubuntu-server) [06:17] LocutusOfBorg: The mod_perl2 delta to use locales in build-deps is obsolete, we've had locales-all in Ubuntu for years now. [06:21] -queuebot:#ubuntu-release- Unapproved: rejected libapache2-mod-perl2 [source] (eoan-proposed) [2.0.11-1ubuntu1] [06:40] so, reuploaded thanks [06:40] -queuebot:#ubuntu-release- Unapproved: libapache2-mod-perl2 (eoan-proposed/main) [2.0.10-3ubuntu1 => 2.0.11-1ubuntu1] (ubuntu-server) [06:43] -queuebot:#ubuntu-release- Unapproved: accepted libapache2-mod-perl2 [source] (eoan-proposed) [2.0.11-1ubuntu1] [06:44] I think we can now upstream the change in Debian... opening a bug [06:45] LocutusOfBorg: Sure. If they take the change, don't bother syncing into eoan, since we'll be starting a perl transition in under a week in FF, may as well sync then. [06:45] Free rebuilds are a nice side-effect of syncs. :P [06:46] yep, this is the reason for me stopping syincing perl libraries... [06:46] I sync/merge only in case of CVE fixes now :) [06:47] reverse-depends -r unstable dwww [06:47] Not a lot of results there. [06:47] It seems vaguely last century to have that dep at all. [06:48] yep :) [06:48] hi release team, happy release week [06:48] could someone have a look at bug 1847898? [06:48] bug 1847898 in ubiquity (Ubuntu) "System doesn't boot after installation - Legacy mode / 2 disks" [Critical,New] https://launchpad.net/bugs/1847898 [06:49] jibel: Not linked in the tracker? Naughty. That's where I was looking this morning. [06:49] (But yeah, I should check rls-ee* when I get into the office) [06:49] yeah, my fault been lazy during the w-e [06:49] doing it now [06:49] being* [06:53] jibel: I blame the last person to touch disk/fs-related stuff in ubiquity. [06:53] jibel: *stare* [06:53] But actually, I have no idea. Will spend more brainpower on it later. [06:54] jibel: If you can cook up a qemu reproducer, that might be nice, since I don't have a pile of laptops I can wipe out to try it on, and you're not coming in with that one to help. :P [06:54] infinity, sure, i'll prepare something [06:54] <3 [06:55] jibel: Of course, if it can't be reproduced in qemu, it might be specific to that BIOS, and then I'm not sure where we are. [06:55] infinity, I'll have a patch to ubiquity today to fix (or attempt to) bug 1847748 [06:55] bug 1847748 in ubiquity (Ubuntu) "installer crashed - Cannot resolve path /dev/sdN - Failed to mount /target" [Critical,Triaged] https://launchpad.net/bugs/1847748 [06:55] it's an issue with the refresh of the partition table [07:05] infinity, I cannot reproduce in a VM with 2 disks [07:09] infinity: dod you think this bug should be tagged for the release and/or tracker https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1847806 ? [07:09] Launchpad bug 1847806 in debian-installer (Ubuntu) "eoan: ppc64el install on pseries-eoan VM fails to install" [Undecided,Incomplete] [07:09] s/dod/do/ [07:10] It is (to me) not yet clear if it is eoan or the newer TCG that is broken - the former being more "eoan relese crit bug" the latter probably just being "pfff, tcg isn't important" [07:10] so I'm unsure about marking that for the release Team or not [07:16] cpaelzer: Can it be reproduced with a machine set to P8? And why on earth would we change our default VM to P9 when most of the hardware we have to run on is P8? [07:16] (And our ISA baseline is P8, etc) [07:16] infinity: I have the p8 run ongoing atm (slow as TCG is) [07:16] probably 20 minutes for that result [07:17] "TCG"? [07:17] infinity: and we switch to P9 as that is what upstream did [07:17] Upstream isn't always right. :P [07:17] this is only happening (it seems) when you install ppc64le in qemu TCG (instruction emulation) [07:17] Unless they're trapping and perfectly emulating instructions, having our base VM type use a CPU that we can't run on the hardware we target is daft. [07:18] Oh, if this doesn't happen at all under KVM, my carefactor is super low. [07:18] well p9 is supposed (tm) to be p8 compatible right :-) [07:18] infinity: we seem to agree on that, see my "pfff, tcg isn't important" above [07:19] cpaelzer: Sure, P9s are P8 compatible. But if you boot on something that claims to be a P9, glibc will jump into P9 code. If it fails to actually be a useful P9, it'll sigill. [07:19] yep, that is exactly my assumption atm [07:19] like qemu enabling P9 by default as some tests worked and later a newer glibc started to run more exotic P9 code and -> sigill [07:20] cpaelzer: Anyhow, I'd still argue that having a default VM type of P9 in any mode, is probably premature, and moreso if it's also obviously broken. So patches welcome to fix that. [07:20] cpaelzer: But probably also not RC if it doesn't affect real hardware, LPARs, or KVM, which is about 107% of real installations. [07:21] I'd not object P9 being the default (in fact I prefer that it is the default), but I'd want it to work :-) [07:21] The bug might end up being pushed to IBM to fix TCG [07:21] It's a weird default when KVM people are more likely to be P8 still. [07:21] That might not be true in a year, but I suspect it is now. [07:22] So emulated people should likely see the same baseline without asking for another. [07:22] * infinity shrugs. [07:22] TBH most people I talked and myself recently are clearly P9>P8 in terms of usage [07:22] anyway, thanks for guidance on the "tag crit for Eoan or not" [07:22] that was the real question for now and we seem to agree that we don't have to do so [07:23] Again, don't really care deeply about software emulation (from a release standpoint), though, so fix as you see appropriate for SRU (or opportunistic upload for final release if you're quick and it's simple) [07:23] yep [07:24] cpaelzer: I'll concede that P9 hardware might have passed P8 hardware in sales. And not everyone runs clouds like I do. But in my world, if I have a mix of P8 and P9 in a cloud, I clamp all the VMs to the same CPU type to avoid going slowly insane. [07:25] cpaelzer: Though, if PPC qemu is as bad at that as x86 is, sometimes -cpu=host is the only way to avoid going insane from confusing bugs in the capability masking. P [07:25] YMMV. [07:49] jibel: for the OEM from recovery install... Is there example gold image I can play way? [07:49] Or like steps to recreate that config? [07:50] xnox, that's a question for mario [07:50] I don't have such image [07:50] I'll ask Taipei [07:55] -queuebot:#ubuntu-release- Unapproved: freeipa (eoan-proposed/universe) [4.8.1-2 => 4.8.1-2ubuntu1] (no packageset) [07:56] -queuebot:#ubuntu-release- Unapproved: accepted freeipa [source] (eoan-proposed) [4.8.1-2ubuntu1] [08:06] infinity: glib2.0> Just remove it for now [08:06] if I can fix it then I can re-upload, no point in blocking other things on it though [08:07] Laney: Sure, we can remove. Will need rebuilds of vte and gdk-pixbuf [08:07] I love reubuilds [08:08] I love spelling too [08:09] hehe [08:14] jibel: commented https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1847944 [08:14] Launchpad bug 1847944 in partman-auto (Ubuntu Eoan) "partman-auto 134ubuntu11 prevents installation from recovery partition" [Critical,Triaged] [08:15] jibel: i do wonder how recovery partition is created, i.e. is it still iso mount, or if it's ext4 [08:15] jibel: etc. [08:16] xnox, I'm trying to get you an iso, you'll have all the information you need. [08:18] jibel: tah [08:19] infinity: https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1847944/coe fixing this?mments/1 how should i b [08:19] Launchpad bug 1847944 in partman-auto (Ubuntu Eoan) "partman-auto 134ubuntu11 prevents installation from recovery partition" [Critical,Triaged] [08:19] * xnox ponders life [08:19] infinity: so, we have an issue for ZFS with latest iso (ubiquity with manual mark-install for zfsutils-linux & zfs-initramfs). Both are listed in the livecd-rootfs remove file, so pure ext4 installation is good. However, zfs-initramfs is still purged on the final system [08:19] infinity: so, installation isn't bootable… [08:20] -queuebot:#ubuntu-release- Unapproved: pygalmesh (eoan-proposed/universe) [0.4.0-1 => 0.4.0-1ubuntu1] (no packageset) [08:20] didrocks: That shouldn't be the case... [08:20] didrocks: Bug#? [08:20] yeah, we double check with jibel and there is no typo in apt-install [08:20] let me file one, just found it [08:20] didrocks: Definitely 20191012? [08:20] -queuebot:#ubuntu-release- Unapproved: accepted pygalmesh [source] (eoan-proposed) [0.4.0-1ubuntu1] [08:20] infinity: yes, and good ubiquity version manually checked [08:21] I would expect anyway having both zfsutils-linux & zfs-initramfs or none of them [08:21] not just one [08:25] didrocks: that sounds like the lvm / cryptsetup bug where we added mark everything as autoremoval and purge that as part of the install [08:25] infinity: let me redo a third install and get logs (I pressed enter on my terminal on the second one when ubiquity got the focus for "reboot now" :/) [08:25] and like even if tools are "installed" one has to mark them as manually installed [08:25] xnox: but infinity told that was fixed by Michael? (it's not done in a generic way?) [08:25] but yeah, smells like it [08:25] hm [08:26] yes infinity is saying so now to me [08:26] It is very much done in a generic way. [08:26] bug #1847970 [08:26] bug 1847970 in ubiquity (Ubuntu) "20191012 does remove zfs-initramfs on targetted system" [Undecided,New] https://launchpad.net/bugs/1847970 [08:26] I'll redo an install and attach logs [08:26] Ta. [08:26] see if I can find anything [08:34] jibel: Have you seen bug 1847785? [08:34] bug 1847785 in ubiquity (Ubuntu) "eoan: zfs install option - don't install on systems less than 4GB of memory" [High,Confirmed] https://launchpad.net/bugs/1847785 [08:37] xnox: infinity: logs attached to bug #1847970, I can't find anything relevant in syslog or debug logs. Seems to be reliably reproducible on vm [08:37] bug 1847970 in ubiquity (Ubuntu) "20191012 does remove zfs-initramfs on targetted system" [Undecided,New] https://launchpad.net/bugs/1847970 [08:41] bdmurray, yes [08:42] bdmurray, you're up early [08:42] jibel: I'm in London. Why aren't you? [08:44] jibel: so i think we might have a fix, but will need the oem image to verify changes. [08:45] bdmurray, I am not === andrewc is now known as Guest6870 [08:54] infinity, bug 1847898 [08:54] bug 1847898 in ubiquity (Ubuntu) "System doesn't boot after installation - Legacy mode / 2 disks" [Critical,New] https://launchpad.net/bugs/1847898 [08:54] infinity, confirmed on another DELL machine [09:08] rbalint: hey, I see that systemd ubuntu3 still has autopkgtest failures, looked at the knot-resolver one and it looked a bit weird [09:10] rbalint: I don't know much about these packages but this failure looks like a regression? Like, it was previously treating the failed server query as a warning and now it's an error - can that be somehow related to systemd? [09:11] didrocks: Just did an install here, and both get marked manual... [09:12] Oh, wait, but that's not specifically what you claims. It's not about auto/manual, but about the removal step removing one of them, right? [09:12] infinity, yes, it removes zfs-initramfs [09:14] indeed [09:14] /target doesn't have zfs-initramfs before rebooting [09:14] and you can imagine that it doesn't go well then :p [09:14] How do I mount this beast without rebooting? [09:16] infinity: zpool import -R /target /dev/vda6 (or whatever) [09:16] zpool import -R /target /dev/vda2 (bpool is on the second partition IIRC) [09:16] you mount grub as a traditional ext4 partition on the chroot if you want it as well [09:20] didrocks: That didn't seem to work. :P [09:20] infinity: yeah, easier, it does still have the pool name in its cache, so: [09:20] zpool import -R /target rpool [09:20] zpool import -R /target bpool [09:21] didrocks: That worked better. [09:21] infinity: and grub is on vda1 (as ext4) [09:21] didrocks: So... zfs-initramfs is in /target too here. [09:22] hum, Wimpress confirmed on Mate… [09:22] * infinity reboots after confirming that. [09:22] rbalint: anyway, just in case I now re-ran amd64 against release only, maybe something else broke it [09:23] no, it's not in my chroot here :/ [09:23] I kept the default by disabled installing ugprades [09:23] the iso is 20191012 [09:24] (legacy mode) [09:26] infinity: oh, the packaged is installed for dpkg, but the files aren't there [09:26] bdmurray: hey, do you have any clue why some of the top crashes in https://errors.ubuntu.com/?release=Ubuntu%2019.10&package=gnome-shell&period=month have no symbols? [09:26] have you only checked dpkg status? [09:26] didrocks: Hah. Yes. And that's speeeecial. But I also know where that code lives, ish, so maybe I can hunt down WTF went wrong. [09:26] infinity: phew, better that we see the same thing :) [09:27] keep me posted if you need any tests [09:29] didrocks: I mean, I suspect we're seeing the same behaviour, because dpkg said it was there, but it doesn't reboot. :P [09:29] -queuebot:#ubuntu-release- Unapproved: uim (eoan-proposed/universe) [1:1.8.8-4ubuntu2 => 1:1.8.8-5ubuntu1] (no packageset) [09:29] got it :) [09:30] didrocks: Anyhow, the magic code to delete files without dpkg being involved might be doing something silly here as far as it interacts with the bit that mwhudson fixed. [09:30] -queuebot:#ubuntu-release- Unapproved: accepted uim [source] (eoan-proposed) [1:1.8.8-5ubuntu1] [09:31] yeah, sounds like it. I hope we can fix that without harcoding any file names… [09:32] Don't see why we wouldn't be able to. [09:32] I just need to remember where that mess is. I had to learn it intimately a couple of cycles ago. [09:33] so, it's not on the "filtering files to copy" part of ubiquity, but on the removal later on? (I thought the removal only had packages removal at this stage, but didn't dive too deep into it… fortunately it seems) [09:34] -queuebot:#ubuntu-release- Unapproved: sdaps (eoan-proposed/universe) [1.9.7-0.1 => 1.9.7-0.2] (no packageset) (sync) [09:35] -queuebot:#ubuntu-release- Unapproved: accepted sdaps [sync] (eoan-proposed) [1.9.7-0.2] [09:40] -queuebot:#ubuntu-release- New binary: uim [amd64] (eoan-proposed/universe) [1:1.8.8-5ubuntu1] (no packageset) [09:41] glib2.0 is passing when I'm running it manually (in scalingstack) now ¬_¬ [09:41] * Laney tries in a silo [09:42] please accept that transitional package ^^ it fixes debian bug: #939588 [09:42] Debian bug 939588 in uim "uim package lacks 2 files" [Normal,Fixed] http://bugs.debian.org/939588 [09:45] infinity: you mean scripts/install.py the blacklist stuff probably? [09:45] * Laney remembers fiddling with this recently too [09:48] sil2100, yes, systemd faced a few strange new regressions, looking [09:52] it's excluded by that "Not copying" step [09:53] https://paste.ubuntu.com/p/BSbH8g5jPq/ [09:59] -queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (eoan-proposed/main) [3.34.0-1ubuntu1 => 3.34.1-1ubuntu1] (ubuntu-desktop) === andrewc is now known as Guest18566 [10:09] seb128: Why do you hate Laney and keep deleting his changelogs? :P [10:09] seb128: (re: g-s-d in unapproved) [10:09] -queuebot:#ubuntu-release- Unapproved: gdk-pixbuf (eoan-proposed/main) [2.40.0+dfsg-1 => 2.40.0+dfsg-1build1] (core) [10:09] -queuebot:#ubuntu-release- Unapproved: vte2.91 (eoan-proposed/main) [0.58.2-1ubuntu1 => 0.58.2-1ubuntu2] (ubuntu-desktop) [10:10] infinity, nothing personal, I just don't keep old changelog entries when merging :) [10:10] seb128 is a rebaser rather than a merger [10:10] that's a way to state it ;) [10:10] seb128: I believe that's technically against our policy. If only I could find said policy. [10:11] (it's also just confusing to read) [10:11] -queuebot:#ubuntu-release- Unapproved: accepted gdk-pixbuf [source] (eoan-proposed) [2.40.0+dfsg-1build1] [10:11] next time I do a sync and do another upload on top saying "ups, restore change dropped by mistake" [10:11] -queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (eoan-proposed) [0.58.2-1ubuntu2] [10:12] :) [10:12] * infinity smirks. [10:12] -queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (eoan-proposed) [3.34.1-1ubuntu1] [10:12] thx for reviewing/approving! [10:14] I think zsys-setup is marking the packages too late [10:14] they're not in the list of packages to keep when ubiquity queries it [10:21] can someone mark ubuntu-drivers-common autopkgtests are invalid on i386? another one that tries to install kernel headers and fails now [10:28] Yeah that fixes it [10:32] seb128: done [10:32] Laney: Oh nice, just reordering it to not be in the 'finalize' step fixes it, or..? [10:32] infinity: Yeah, just whack it at the end of the init bit [10:33] I'll do a MP [10:33] Laney, thx [10:33] Laney: +1 from me if that's tested. [10:33] Laney: And thanks. [10:33] Laney: Are you coming in this afternoon or tomorrow or...? [10:34] ubuntu-drivers-common should probably just enable multiarch to make the tests still work. [10:34] But I guess badtesting works for now. [10:34] While we decide if it's a package that will get dropped anyway. [10:35] Laney: I don't think I need a formal MP for that, but if that workflow works for you, go for it. [10:36] infinity: Tomorrow [10:36] OK, I'll just push it then [10:36] Not uploading though, since it seems like there's going to be other fixes coming [10:37] sil2100, i'm checking what broke with systemd, and i see many :amd64 packages in the i386 autopkgtest vm: https://pastebin.ubuntu.com/p/RNscBQhw8r/ [10:38] infinity, ^ [10:38] Laney: Lemme grab your commit and apply it to a live session here and make sure it DTRT for me too. [10:39] rbalint: Yes, and? [10:39] Shore [10:39] as i see in the livecd-rootfs source we enable amd64 but don't pin amd64 packages down to prefer i386 [10:39] rbalint: Pinning to prefer an arch isn't necessary. [10:39] Just cut 'n' paste those two lines to above the "touch" [10:40] rbalint: Those are almost certainly all there because of linux-* [10:40] infinity, the problem i see is libsystemd0:amd64 in the vm, thus systemd does not upgrade [10:40] rbalint: "Thus systemd doesn't upgrade". Why? [10:41] rbalint: Which test are you looking at? [10:41] https://pastebin.ubuntu.com/p/j32Gwr4srW/ [10:41] infinity, systemd:i386 [10:41] https://people.canonical.com/~laney/weird-things/zfs.png [10:42] rbalint: Okay, so either an autopkgtest pinning bug or an apt bug (probably not an apt bug). [10:43] infinity, ok, looking a bit more [10:43] rbalint: It's being held back because they need to upgrade in lockstep, but there's no reason they shouldn't. [10:44] infinity, they are held back because also removing libdbus-glib-1-2:amd64 imo [10:44] infinity, and indeed, pinning is involved when pulling systemd from -proposed [10:45] infinity: given a partition ie. sda1 is there a reliable way to find the parent device? i.e. sda ? [10:45] rbalint: I don't understand what you mean by that sentence. :P [10:45] infinity: including things like nvmen0p1 -> nvmen0 stuff [10:45] xnox: Strip p?[0-9]* off the end? [10:45] but nothing in like /proc/* partition map? [10:46] /proc/partitions [10:48] xnox, udisks2 has some knobs for that but that indeed means you need to have it available (i.e. not on server afaik) [10:49] infinity: something like $ basename $(dirname $(find /sys/devices -name nvme0n1p5)) ? [10:49] infinity, let me check how it works in lxc then i come back with different sentences :o) [10:52] missing build on arm64: diamond-aligner (from 0.9.22+dfsg-2) [10:53] that package moved from arch:any to arch:all, and has not been cleaned up for 73 days... is something wrong on report tools? [10:56] LocutusOfBorg: it's not arch:all, it's restricted to amd64 only, LP: #1846352 [10:56] Launchpad bug 1846352 in diamond-aligner (Ubuntu) "Please remove diamond-aligner everywhere except amd64" [Undecided,New] https://launchpad.net/bugs/1846352 [10:58] oops thanks [10:58] xnox: $ for i in /sys/block/*/sda2; do [ -d "$i" ] && echo $(dirname $i); done [11:00] -queuebot:#ubuntu-release- Unapproved: cctools (eoan-proposed/universe) [7.0.9-2 => 7.0.9-3] (no packageset) (sync) [11:01] -queuebot:#ubuntu-release- Unapproved: ddd (eoan-proposed/universe) [1:3.3.12-5.1build4 => 1:3.3.12-5.2] (no packageset) (sync) [11:01] -queuebot:#ubuntu-release- Unapproved: accepted cctools [sync] (eoan-proposed) [7.0.9-3] [11:01] -queuebot:#ubuntu-release- Unapproved: accepted ddd [sync] (eoan-proposed) [1:3.3.12-5.2] [11:07] -queuebot:#ubuntu-release- Unapproved: appstream (eoan-proposed/main) [0.12.8-1 => 0.12.9-1] (core) (sync) [11:07] -queuebot:#ubuntu-release- Unapproved: highwayhash (eoan-proposed/universe) [0~git20190222.276dd7b-1 => 0~git20191002.0aaf66b-1] (no packageset) (sync) [11:07] -queuebot:#ubuntu-release- Unapproved: accepted highwayhash [sync] (eoan-proposed) [0~git20191002.0aaf66b-1] [11:08] -queuebot:#ubuntu-release- Unapproved: kylin-video (eoan-proposed/universe) [2.0.0-1 => 2.0.1-1] (ubuntukylin) (sync) [11:08] -queuebot:#ubuntu-release- Unapproved: mlpack (eoan-proposed/universe) [3.1.1-1 => 3.2.1-1] (no packageset) (sync) [11:08] -queuebot:#ubuntu-release- Unapproved: accepted mlpack [sync] (eoan-proposed) [3.2.1-1] [11:09] -queuebot:#ubuntu-release- Unapproved: node-babel-plugin-transform-define (eoan-proposed/universe) [1.3.0-2 => 1.3.0-3] (no packageset) (sync) [11:09] -queuebot:#ubuntu-release- Unapproved: node-graphlibrary (eoan-proposed/universe) [2.2.0+dfsg-1 => 2.2.0+dfsg-2] (no packageset) (sync) [11:09] -queuebot:#ubuntu-release- Unapproved: accepted node-babel-plugin-transform-define [sync] (eoan-proposed) [1.3.0-3] [11:09] -queuebot:#ubuntu-release- Unapproved: accepted node-graphlibrary [sync] (eoan-proposed) [2.2.0+dfsg-2] [11:10] -queuebot:#ubuntu-release- Unapproved: node-grunt-legacy-log-utils (eoan-proposed/universe) [1.0.0-1 => 1.0.0-2] (no packageset) (sync) [11:10] -queuebot:#ubuntu-release- Unapproved: accepted node-grunt-legacy-log-utils [sync] (eoan-proposed) [1.0.0-2] [11:11] -queuebot:#ubuntu-release- Unapproved: node-grunt-legacy-util (eoan-proposed/universe) [1.0.0-1 => 1.0.0-2] (no packageset) (sync) [11:11] -queuebot:#ubuntu-release- Unapproved: node-inquirer (eoan-proposed/universe) [3.3.0-2 => 3.3.0-3] (no packageset) (sync) [11:11] -queuebot:#ubuntu-release- Unapproved: node-hash-sum (eoan-proposed/universe) [1.0.2-1 => 1.0.2-2] (no packageset) (sync) [11:11] -queuebot:#ubuntu-release- Unapproved: node-object-key (eoan-proposed/universe) [0.2.0-2 => 0.2.0-3] (no packageset) (sync) [11:11] -queuebot:#ubuntu-release- Unapproved: accepted node-grunt-legacy-util [sync] (eoan-proposed) [1.0.0-2] [11:11] -queuebot:#ubuntu-release- Unapproved: accepted node-inquirer [sync] (eoan-proposed) [3.3.0-3] [11:11] -queuebot:#ubuntu-release- Unapproved: node-source-map (eoan-proposed/universe) [0.7.0++dfsg2+really.0.6.1-3 => 0.7.0++dfsg2+really.0.6.1-4] (kubuntu) (sync) [11:11] -queuebot:#ubuntu-release- Unapproved: accepted node-hash-sum [sync] (eoan-proposed) [1.0.2-2] [11:11] -queuebot:#ubuntu-release- Unapproved: node-stats-webpack-plugin (eoan-proposed/universe) [0.6.1-1 => 0.7.0-1] (no packageset) (sync) [11:11] -queuebot:#ubuntu-release- Unapproved: accepted node-object-key [sync] (eoan-proposed) [0.2.0-3] [11:12] -queuebot:#ubuntu-release- Unapproved: node-terser (eoan-proposed/universe) [4.1.2-3 => 4.1.2-4] (no packageset) (sync) [11:12] -queuebot:#ubuntu-release- Unapproved: node-webpack-merge (eoan-proposed/universe) [2.2.0-2 => 2.2.0-3] (no packageset) (sync) [11:12] -queuebot:#ubuntu-release- Unapproved: accepted node-stats-webpack-plugin [sync] (eoan-proposed) [0.7.0-1] [11:12] -queuebot:#ubuntu-release- Unapproved: accepted node-webpack-merge [sync] (eoan-proposed) [2.2.0-3] [11:12] -queuebot:#ubuntu-release- Unapproved: accepted node-terser [sync] (eoan-proposed) [4.1.2-4] [11:13] someone turned auto-sync back on eh [11:13] -queuebot:#ubuntu-release- Unapproved: patroni (eoan-proposed/universe) [1.6.0-1 => 1.6.0-4] (no packageset) (sync) [11:13] -queuebot:#ubuntu-release- Unapproved: accepted patroni [sync] (eoan-proposed) [1.6.0-4] [11:14] -queuebot:#ubuntu-release- Unapproved: python-dugong (eoan-proposed/universe) [3.7.4+dfsg-1 => 3.7.4+dfsg-2] (no packageset) (sync) [11:14] Laney: I believe LocutusOfBorg thinks he's autosync. [11:14] -queuebot:#ubuntu-release- Unapproved: accepted python-dugong [sync] (eoan-proposed) [3.7.4+dfsg-2] [11:14] Laney, I'm syncing all the packages that are stuck in proposed because of build failures or test failures [11:15] e.g. nodejs packages were stuck since long time, and now they have been fixed in debian [11:15] -queuebot:#ubuntu-release- Unapproved: python-parameterized (eoan-proposed/universe) [0.6.1-2 => 0.7.0-1] (no packageset) (sync) [11:15] and some python packages have got testsuite fixes [11:15] is that a problem? I'm not syncing new features, and looking only to packages that are not migrating [11:15] -queuebot:#ubuntu-release- Unapproved: accepted python-parameterized [sync] (eoan-proposed) [0.7.0-1] [11:16] its a *complete* manual thing... [11:19] some of them still requires fixes, but they should mostly all migrate and finish some transitions, e.g. sdpa, node-loadsh autopkgtest failures, pytest migration [11:19] and something more [11:20] Nah, if you're actually verifying that things are getting fixed then it's cool. I was just joking. [11:21] ^ [11:21] Soooooooooooooooo I just ran glib2.0/i386 out of a bileto ppa and it worked. [11:21] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-ci-train-ppa-service-3820/eoan/i386/g/glib2.0/20191014_111536_fbd04@/log.gz [11:21] Laney: Because of course it did... [11:22] Laney: We ran it a whole mess of times on the primary archive, I swear. :/ [11:22] well I was suspicious because it worked locally here too [11:22] and on Friday it was failing for me here and on scalingstack [11:22] Laney: Is that a new build in the PPA, or a binary copy from primary? [11:23] the latter [11:23] Grr. [11:23] Laney: Well, now that the things it was blocking have built, we can just binary copy it back in and try harder... [11:23] I think... [11:24] that if we copy it back britney should find the previous results and not re-run the world [11:24] ... [11:24] I believe that's true. [11:24] Maybe. [11:24] Confidence level of some on a scale of one to many. [11:26] It could be a pinning thing, as the primary archive runs will be running with --apt-pocket=proposed=src:glib2.0 [11:26] infinity, Laney thanks for understanding and confirming, to do that I do: grep all the packages that have " to " in the update excuses page and add packages that have "Regression", sum them and list | sort |uniq [11:26] * Laney eyes the logs closer [11:26] and then compare with auto-sync log [11:27] for all of them that are in both lists I find the reason for missing migration, and if the fix is in a new release I 99% discard the sync and look at the diff, or if it is rust I discard and so on [11:27] for the ones that are actually fixing stuff without dropping python-foo and so on I sync [11:28] the worst case is something that didn't migrate that is still not migrating [11:30] stuff like highwayhash will require some AA power to kick out arm64 I think, but at least now ppc64el is building fine [11:32] appstream if accepted can probably end the ldc transition nightmare [11:40] xnox: Is bug 1845543 already fixed? [11:40] bug 1845543 in subiquity "Failed attempts to umount cdrom" [Undecided,New] https://launchpad.net/bugs/1845543 [11:46] -queuebot:#ubuntu-release- Unapproved: glib2.0 (eoan-proposed/main) [2.62.0-1 => 2.62.1-1] (core) (sync) [11:48] -queuebot:#ubuntu-release- Unapproved: accepted appstream [sync] (eoan-proposed) [0.12.9-1] [11:50] Laney: +1 on the ubiquity change, hand-hacked install here went well. [11:50] Laney: What other changes were we waiting on? Looks like jibel's landed. [11:53] -queuebot:#ubuntu-release- Unapproved: pnetcdf (eoan-proposed/universe) [1.12.0-1 => 1.12.0-1ubuntu1] (no packageset) [11:54] -queuebot:#ubuntu-release- Unapproved: accepted pnetcdf [source] (eoan-proposed) [1.12.0-1ubuntu1] [11:55] infinity, nothing from me [11:55] I'm testing Laney's fix [11:55] it hsould be done soon [11:55] should* [11:56] -queuebot:#ubuntu-release- Unapproved: node-terser (eoan-proposed/universe) [4.1.2-4 => 4.1.2-4ubuntu1] (no packageset) [11:57] jibel: The same one infinity already tested? [11:57] -queuebot:#ubuntu-release- Unapproved: accepted node-terser [source] (eoan-proposed) [4.1.2-4ubuntu1] [11:58] bdmurray, yes [11:58] and it's a pass, so double confirmed [11:59] jibel: okay, great [11:59] well, the system even boots after installation [12:01] bonus! [12:02] uh, booted on the wrong disk though. [12:02] * jibel tries again [12:11] infinity: thanks for diamond-aligner removal! there were a couple of others i filed, would you be able to look? [12:13] ginggs: Yeah, I have the bug list open, will get there this afternoon. [12:13] infinity: ta! [12:29] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1059.68] (kernel) [12:39] infinity, proteinortho/arm64 unsatisfiable Depends: diamond-aligner [12:40] -queuebot:#ubuntu-release- Unapproved: rejected glib2.0 [sync] (eoan-proposed) [2.62.1-1] [12:41] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1059.68] [12:41] LocutusOfBorg: Oh joy, I should have looked before removing. Whee. [12:41] -queuebot:#ubuntu-release- Unapproved: accepted kylin-video [sync] (eoan-proposed) [2.0.1-1] [12:41] -queuebot:#ubuntu-release- Unapproved: accepted node-source-map [sync] (eoan-proposed) [0.7.0++dfsg2+really.0.6.1-4] [12:42] LocutusOfBorg: Although, I don't see that in reverse-depends. Curious... [12:42] LocutusOfBorg: Or is that in proposed only? [12:42] Looks like proposed only. [12:43] yes [12:43] And it build-deps on diamond-aligner, so a quick rebuild will clear that up. [12:43] Would have been fine if I'd done the removal 11 days ago. :P [12:43] do you want me to upload a rebuild? [12:43] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (disco-proposed) [1.178.5] [12:44] LocutusOfBorg: Yeah, go for it. [12:44] . [12:46] -queuebot:#ubuntu-release- Unapproved: proteinortho (eoan-proposed/universe) [6.0.8+dfsg-1 => 6.0.8+dfsg-1build1] (no packageset) [12:46] -queuebot:#ubuntu-release- Unapproved: accepted proteinortho [source] (eoan-proposed) [6.0.8+dfsg-1build1] [12:47] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (bionic-proposed) [1.173.11] [12:50] infinity, do you think you can do something for highwayhash/arm64? Debian has the same failure but didn't remove the binary yet [12:51] no rdeps, no care, double rc buggy [12:54] should LP: #1828409 really be won't fix? [12:54] Launchpad bug 1828409 in htslib (Ubuntu) "please remove htslib on i386" [Undecided,Won't fix] https://launchpad.net/bugs/1828409 [12:57] infinity: can you please review patches on https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1847944 [12:57] Launchpad bug 1847944 in partman-auto (Ubuntu Eoan) "partman-auto 134ubuntu11 prevents installation from recovery partition" [Critical,Triaged] [12:57] infinity: you may want to pull partman-base to see more context, as to which block of code is being fixed up. [12:58] bdmurray: 1845543 not fixed. Was attempted, regressed, reverted. Postponed to ff-series [12:59] * xnox will try to test that code more now, with and without some of the preseed keys; and cdroms vs usb sticks. [13:07] LocutusOfBorg: I was very tempted to just fix it, but then I looked at the code and how upstream determines architectures and arch features and decided I really didn't care any more. [13:07] lol same for me, there is an upstream issue about that, nobody cared so far [13:07] so fixing downstream might be a pita to maintain for no reasons [13:13] infinity: weren't you working on some partman things there? [13:14] Laney: Oh, Dmitri is. See above. [13:14] xnox: ok, looked at the partman patches [13:14] Yeah, so that's what I thought we were waiting for :-) [13:14] xnox: looking good, I might just recommend break'ing after we find a partition in /sys/block/*/$block, or is there a reason to continue looking? [13:15] Not a biggy anyway [13:15] and the two disks thing? [13:16] The two disks thing, I might have been waiting on jibel to give me a qemu reproducer. [13:16] Unless that happened and I missed it. [13:19] infinity: there was no message here with qemu in it since we last talked this morning [13:21] -queuebot:#ubuntu-release- Unapproved: partman-base (eoan-proposed/main) [206ubuntu5 => 206ubuntu6] (core, i386-excludes) [13:21] cpaelzer: Your IRC client is full of lies: [13:21] 00:54 < infinity> jibel: If you can cook up a qemu reproducer, ... [13:21] 00:54 < jibel> infinity, sure, i'll prepare something [13:22] nope, we talked after this [13:22] and I said nothing since then [13:22] -queuebot:#ubuntu-release- Unapproved: rejected partman-base [source] (eoan-proposed) [206ubuntu6] [13:22] cpaelzer: Oh, I see what you mean. [13:22] Yeah, he didn't give me a reproducer on IRC or in the bug,. [13:22] which does not mean that the messages aren't full of lies :-) [13:39] -queuebot:#ubuntu-release- Unapproved: glib2.0 (eoan-proposed/main) [2.62.0-1 => 2.62.1-1] (core) (sync) [13:41] I'm assuming that was rejected because I forgot --include-binaries, can't see any mail about it [13:44] Laney: Almost certainly. [13:45] 🙊 [13:45] -queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [sync] (eoan-proposed) [2.62.1-1] [13:55] did the proteinortho removal fail? [14:05] LocutusOfBorg: No? [14:05] How would a removal fail? [14:06] Oh, if by "removal" you mean "NBS cleanup", I haven't done that yet. [14:12] infinity: linux-raspi2 is blocked in -proposed, it's not critical we get it updated for the release but would be nice to have it in sync with the master kernel if we can [14:12] sforshee: I know, I was going to let it migrate before the next raspi images build. [14:12] infinity: great, ta [14:31] oh... ok :) [14:35] -queuebot:#ubuntu-release- Unapproved: u-boot (eoan-proposed/main) [2019.07+dfsg-1ubuntu2 => 2019.07+dfsg-1ubuntu3] (core) [14:35] -queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1023.23~18.04.2] (kernel) [14:36] infinity: u-boot fix for the ram issue sponsored ^ [14:38] -queuebot:#ubuntu-release- Unapproved: base-files (eoan-proposed/main) [10.2ubuntu6 => 10.2ubuntu7] (core) [14:43] -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (eoan-proposed) [10.2ubuntu7] [14:44] -queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (eoan-proposed) [2019.07+dfsg-1ubuntu3] [15:01] * xnox twiddle thumbs [15:05] -queuebot:#ubuntu-release- Unapproved: partman-auto (eoan-proposed/main) [134ubuntu11 => 134ubuntu12] (core, i386-excludes) (sync) [15:05] -queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.19 => 19.10.20] (core) (sync) [15:05] -queuebot:#ubuntu-release- Unapproved: partman-base (eoan-proposed/main) [206ubuntu5 => 206ubuntu6] (core, i386-excludes) (sync) [15:10] -queuebot:#ubuntu-release- Unapproved: rejected partman-auto [sync] (eoan-proposed) [134ubuntu12] [15:10] -queuebot:#ubuntu-release- Unapproved: rejected ubiquity [sync] (eoan-proposed) [19.10.20] [15:10] -queuebot:#ubuntu-release- Unapproved: rejected partman-base [sync] (eoan-proposed) [206ubuntu6] [15:15] -queuebot:#ubuntu-release- Unapproved: partman-auto (eoan-proposed/main) [134ubuntu11 => 134ubuntu12] (core, i386-excludes) [15:15] -queuebot:#ubuntu-release- Unapproved: partman-base (eoan-proposed/main) [206ubuntu5 => 206ubuntu6] (core, i386-excludes) [15:16] -queuebot:#ubuntu-release- Unapproved: ubiquity (eoan-proposed/main) [19.10.19 => 19.10.20] (core) [15:19] sil2100: ^^^ [15:22] -queuebot:#ubuntu-release- Unapproved: accepted partman-auto [source] (eoan-proposed) [134ubuntu12] [15:22] -queuebot:#ubuntu-release- Unapproved: accepted partman-base [source] (eoan-proposed) [206ubuntu6] [15:26] -queuebot:#ubuntu-release- Unapproved: sfcgal (eoan-proposed/universe) [1.3.7-2 => 1.3.7-2ubuntu1] (no packageset) [15:27] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (eoan-proposed) [19.10.20] [15:27] -queuebot:#ubuntu-release- Unapproved: accepted sfcgal [source] (eoan-proposed) [1.3.7-2ubuntu1] [15:28] hello, I'd like to test Eoan with subiquity for ppc64le, but here it just points to kvm/guest test: Eoan Final -> Product (Ubuntu Server Subiquity) -> Ubuntu Server Subiquity ppc64el : http://iso.qa.ubuntu.com/qatracker/milestones/407/builds [15:29] if someone could please give me the right URL ^ [15:30] the same also happens to arm64 ^ === andrewc is now known as Guest10781 [15:32] xnox: ^ [15:34] patriciadomin: you can submit your test case under kvm/qemu, despite doing bare-metal install [15:34] patriciadomin: currently we don't have arch specific install test cases, i.e. "Virtual CD-ROM" would make sense for a subiquity ppc64le test case [15:34] xnox: yes, but I'd like to test it in a baremetal not a guest === Guest10781 is now known as acloke [15:36] acloke, xnox - does the lack of test cases in the ISO tracker for arm64 and ppc64el infer that we should prioritise testing for the "daily" d-i based images? [15:36] xnox, the d-i based installation methods appear to have a full list of test cases in the QA tracker for those archs [15:37] xnox: my point is there's no subiquity test cases there for arm64 and ppc64le [15:37] patriciadomin: sil2100 is adding some now [15:38] acloke: i'm not your boss =) [15:38] ah good many thanks xnox and sil2100 [15:38] so i can't tell you what should be prioritised [15:38] we are planning to release everything listed in the manifest, and everything must be tested = [15:38] =) [15:39] xnox, :-) Let me rephrase... Is the population of the ISO QA tracker indicative of the likely default installation engine for those archs? [15:39] no [15:39] xnox, thanks. Understood [15:40] it's paper trail of all releasable artefacts, as a complete consistent set. that's all. [15:46] (with serial numbers, links to builds, etc) [15:52] -queuebot:#ubuntu-release- New: accepted uim [amd64] (eoan-proposed) [1:1.8.8-5ubuntu1] [15:53] infinity, I see you did the same hint as me https://code.launchpad.net/~costamagnagianfranco/britney/hints-ubuntu/+merge/373867 [15:53] can you please merge the firewalld change and the alt-ergo one pretty please? [15:55] sighm the hammer didn't work completely it seems... missing build on i386: proteinortho (from 5.16.b+dfsg-1) [15:57] plars: ok, so u-boot for arm64 should be built and published, could you take an arm64 image and try to update u-boot-rpi to version 2019.07+dfsg-1ubuntu3? [15:58] plars: and see if you see your full 2GB of ram [15:58] plars: the armhf one is built but not published yet [16:00] -queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.424 => 1.425] (desktop-core, ubuntu-server) [16:01] bdmurray, ^ [16:01] built package is in ppa:rbalint/scratch [16:07] rbalint: also, checkout me and infinity doing transfersal from partition to block device from this morning =) [16:09] rbalint: i do like that you used it one more way to find things [16:10] rbalint: also just in time =) [16:11] -queuebot:#ubuntu-release- Unapproved: accepted casper [source] (eoan-proposed) [1.425] [16:15] xnox, :-) will check the rollback :-) [16:21] plars: I would assume the armhf version of u-boot should also be available now for testing, if anything [16:25] after installing eoan with zfs, I have no /var/lib/dpkg.. [16:26] did a dist-upgrade before running ubiquity [16:27] plars: so today I need to EOD at point 18 because of dinner arrangements - could you give a sign to infinity once you give those a spin and confirm they're not breaking anything? [16:27] (so in ~20 minutes I will be gone) [16:29] tjaalton: Wat? [16:29] sil2100: sorry, had to step out for a bit but I’ll try it as soon as I get back and let him know [16:29] any AA please? https://bugs.launchpad.net/ubuntu/+source/qr-tools/+bug/1848067 [16:29] Launchpad bug 1848067 in qr-tools (Ubuntu) "qr-tools: kick out from eoan " [Undecided,New] [16:30] infinity: exactly [16:31] maybe I'll try to repro with the pending image [16:31] plars: no worries! [16:31] plars: thank you! [16:31] LocutusOfBorg: No urge to pull in the py3 port instead? [16:41] tjaalton: I appear to have a /var/lib/dpkg on my test install here. [16:41] tjaalton: I'm not really sure how yours would go missing. [16:41] Though it is a separate mountpoint for some reason. [16:41] This ZFS stuff is weird. [16:43] xnox: hm, could you take a look and see what you think about LP: #1848069 ? [16:43] Launchpad bug 1848069 in subiquity "Subiquity device probing failing on Huawei TaiShan 2280 v2" [Undecided,New] https://launchpad.net/bugs/1848069 [16:50] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1023.23~18.04.2] === paride5 is now known as paride [16:54] Updating :) [16:57] infinity: newer image seemed to have the rpool for that, but doesn't seem to boot up [16:57] after install [16:59] can't find the rootfs [16:59] tjaalton: The current image needs the ubiquity from proposed to work. [17:00] okay [17:07] yep, works now [17:09] zbar is 80 days old... and sdaps waits for it... i'm trying to make some stuff migrate [17:09] post eoan will need a kick anyway [17:43] tjaalton: I saw the same with the 20191012 deskto iso + zfs install [17:43] no boot, initramfs prompt only [17:44] infinity: I tried the new u-boot on both armhf and arm64 with my rpi4 and I see the full amount of memory now [17:44] and subiquity is also busted, "Unfortunately probing for devices to intsall to failed." [17:46]