[09:22] <xnox> Wimpress:  may I upload refreshed ubuntu-mate-meta? note that it needs update.cfg adjustment to look at -proposed packages too when germinating https://paste.ubuntu.com/p/JBQ3rYDMrX/
[09:27] <Wimpress> xnox: Yeah, I spotted that the ubiquity panel hadn't migrated from proposed.
[09:27] <xnox> and it will not, until we fix metas =) chicken-egg =)
[09:27] <Wimpress> Ah, OK.
[09:27] <xnox> plus it's nice to have all the pockets in update.cfg anyway, for SRUing new deps / updates.
[09:28] <Wimpress> So -proposed should be remove from update.cfg once everything has migrated?
[09:28] <Wimpress> Or safe to leave?
[09:29] <Wimpress> Thanks for sorting that, I'll let the Ubuntu Budgie guys know what to do.
[09:29] <xnox> safe to leave
[09:30] <xnox> ie. ubuntu-meta has it always
[09:30] <Wimpress> Thanks.
[09:30] <xnox> uploaded
[09:31] <Wimpress> Wonderful. I'll get the QA guys to test the next daily.
[09:32] <xnox> Wimpress:  well not gonna migrate yet.
[09:32] <Wimpress> OK
[09:33] <xnox> Wimpress:  for budgie the question is, if they want to show a panel at all during 'maybe-ubiquity' and 'only-ubiquity' modes. cause it looks like they seed indicators just for that.
[09:33] <xnox> the principal need for panel there, historically was to mimick unity7 UI and to provide add-hoc ability to change keyboard layout at any page of the installer.
[09:41] <Wimpress> Yes, Budgie is different in that regard. The indicators are for Ubiquity only.
[09:41] <Wimpress> bashfulrobot: See the discussion above. Can you ask David to join this channel so he can answer xnox questions.
[10:20] <xnox> in essence we are splitting the panel out of ubiquity-frontend-gtk into a separate universe package, and if panel is desired it should be seeded. Or if panel is not part of the desired installer look & feel, one can drop it.
[10:52] <tmhoang> Hello, for Arch, Debian, Fedora, I can find their build "scripts" and patches at : https://src.fedoraproject.org/rpms/gcc, https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gcc, https://salsa.debian.org/toolchain-team/gcc/tree/master/debian/rules.d. Where could I find the same for Ubuntu ? Is it at : https://code.launchpad.net/gcc ? (I pick gcc as an example).
[10:52] <tmhoang> many thanks
[11:02] <Laney> dear hive mind: would it be acceptable for autopkgtest to write ${RELEASE}-security entries here using the configured mirror? https://salsa.debian.org/ci-team/autopkgtest/blob/master/setup-commands/setup-testbed#L141
[11:02] <Laney> I feel a bit uncomfortable about forcefully inserting security.u.c there
[11:03] <Laney> but I can't remember what the situation is with mirrors carrying -security
[11:26] <sladen> cking: have sent a ubuntu-devel@ reply re: the compression
[11:28] <cking> sladen, ok, i'll try and get that done sometime in the next week or so
[11:28] <sladen> cking: it's more than my hunch is that there's likely to be a better solution that adding-more-code
[11:29] <xnox> tmhoang:  that url for gcc is for the "upstream" rather than ubuntu packaging. You probably want something like this: https://code.launchpad.net/ubuntu/+source/gcc-8
[11:31] <tmhoang> xnox: thanks ! Are 'Ubuntu packaging' packages start at prefix https://code.launchpad.net/ubuntu/ ?
[11:31] <xnox> tmhoang:  most but not all.
[11:31] <xnox> tmhoang:  some projects where ubuntu is upstream are at top-level, or even at github. or both!
[11:31] <tmhoang> ah interesting
[11:31] <xnox> tmhoang:  e.g. launchpad.net/ubiquity
[11:32] <tmhoang> good point. many thanks
[11:32] <xnox> github.com/CanonicalLtd/subiquity
[11:32] <xnox> etc.
[11:38] <xnox> sladen:  hmmm.... are you implying that the order of cpio members matters? =)))) as in, initrd will boot faster if busybox is first, init second, and the rest of things are in the exec order?
[11:41] <sladen> xnox: think one needs data ... but if the CPIO can be ordered, and files made available as soon as they are ready (rather than waiting for $everything to be decompressed), there would be the potential for a win there too---but *only* if the code is setup for returns files/object when they are ready
[11:42] <sladen> xnox: the stream decoders do not parallise well;  bzip2 is a block decoder: so when can decode multiple blocks in parallel on separate CPUs
[11:43] <sladen> xnow: so there is probably a local maxima for Bzip2 using eg 100kB blocks and 30 CPUs in parallel
[11:44] <xnox> i wonder if i can experiment with like shuffling init to be the last cpio archive member and like for it to be the very first one.
[11:44] <xnox> to see if there is a significant difference.
[11:44] <xnox> cause it would be behind all the kernel modules, and firmware blobs
[11:49] <sladen> xnox: there are two potential wins: (1) re-ordering similiar file content to be <32kB distant gives compression benefits;  (2) if the code was adjusted to 'stream'/return partial results; then it would unblock lots of downstream processes
[13:37] <xnox> vorlon:  Laney: is new systemd killing virtual machines, or is lcy cloud not nice? i see kernel traceback unable to mount rootfs on reboot.... but then it does show login prompt.... https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/s/systemd/20190530_115729_6065d@/log.gz
[13:39] <xnox> ditto i386 https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/i386/s/systemd/20190529_215838_00b24@/log.gz
[13:41] <Laney> xnox: i dunno, looks like the restart doesn't go very well though
[13:42] <Laney> there's still recent passes on other releases, e.g.: http://autopkgtest.ubuntu.com/packages/systemd/bionic/amd64 http://autopkgtest.ubuntu.com/packages/systemd/bionic/i386 http://autopkgtest.ubuntu.com/packages/systemd/cosmic/i386
[13:44] <Laney> does it happen on your system with qemu? if not, you should still have access to the cloud to run things there
[15:12] <tmhoang> I'm building a package using CMake. Does debian/rules has an option to build with debug info or I have to add something like -DCMAKE_BUILD_TYPE=RelWithDebInfo in debian/rules ?
[15:16] <xnox> tmhoang:  normally, debug symbols are built and stripped into .ddeb
[15:16] <tmhoang> I'm running : dpkg-buildpackage -j4 -uc -us and see that CXXFLAGS=-g -O2 by default. I wonder where that debugging option is set
[15:16] <xnox> tmhoang:  you can keep the debug symbols intact, it's normally done with DEB_BUILD_OPTIONS=nostrip debuild
[15:16] <xnox> to keep all debug stuff attached
[15:17] <tmhoang> xnox: I think I would stick with 2nd option instead of .ddeb. I have not used them before :(
[15:18] <xnox> tmhoang:  we strip debug symbols into .ddebs such that anyone can install all debug symbols for all the packages
[15:18] <tmhoang> understood
[15:18] <xnox> https://wiki.ubuntu.com/Debug%20Symbol%20Packages
[15:18] <xnox> for more details
[15:19] <tmhoang> so, I guess something like : DEB_BUILD_OPTIONS += nostrip should work
[15:20] <xnox> tmhoang:  in debian/rules ?! no, not allowed to do that
[15:20] <xnox> DEB_BUILD_OPTIONS is explicitely build-environment controlled.
[15:20] <xnox> it's for end-users to rebuild things
[15:20] <xnox> tmhoang:  instead one would override dh_strip to not strip them
[15:21] <xnox> but that's non-standards compliant / non-suitable for ubuntu/debian
[15:21] <xnox> i.e.
[15:21] <xnox> override_dh_strip:
[15:21]  * xnox just that ^ will be enough to short circuit dh_strip
[15:22] <tmhoang> ah I saw it now. Many thanks. Also this is for dev so I'd ignore standards :D
[16:51] <ddstreet> xnox your boot-smoke addition of --wait should remove the while loop, and also will make the test hang forever (until adt timeout) if is-system-running never becomes true
[16:54] <ddstreet> xnox Laney re: unable to mount root, it's also booted with panic=-1 so something seems to be booting the kernel without the initrd with the intention for it to panic and reboot, at least that's my best guess, i don't know why else it would be booting with panic=-1
[16:55] <xnox> vorlon:  ^
[16:56] <vorlon> "something seems to be booting" - yes, all the cloud images disco and later have this
[16:57] <vorlon> and as we expect the cloud images to be using linux-generic which is not guaranteed to boot initramfsless in KVM, the normal boot path includes 2 reboots
[17:01] <ddstreet> makes sense, assuming the first initramfsless boot works some of the time, i suppose.  note that upstream systemd (or at least whoever opened the bug from upstream) doesn't appear aware of that, you might want to mention in lp #1829829 that the first panic=-1 boot is expected and ok
[20:51] <xnox> ddstreet:  no, not expected and not ok
[20:51] <xnox> ddstreet:  expectation for cloud images is to successfully boot initrdless
[20:52] <xnox> vorlon:  well
[20:52] <xnox> vorlon:  we build a custom image for autopkgtest..... and we do expect it to boot.....
[20:52] <xnox> vorlon:  so clearly our autopkgtest image building is wrong?!
[20:52] <vorlon> xnox: we expect it to /boot/.  but we also expect it to boot the kernel twice before it gets to userspace, based on the fact that it will fail to boot initramfsless
[20:53] <vorlon> unless I'm forgetting something
[20:54] <xnox> vorlon:  well, but over nova api that trips the state up of autopkgtest, no? cause "yeap booted", "oh no, no network", "meanwhile it booted the second time fine"
[20:57] <vorlon> xnox: AFAIK autopkgtest doesn't depend on nova api to determine whether a system is booted
[20:58] <vorlon> we might issue a reboot command via nova, but then it's polling for the system to come up
[20:58] <vorlon> and a double-reboot should have no impact on networking
[21:01] <xnox> hmmm
[21:04] <xnox> vorlon:  i don't understand the point of a cloud image that always boots twice.
[21:04] <xnox> and always will......
[21:05] <vorlon> xnox: we will have KVM-specific cloud images that use linux-kvm and don't boot twice.  I'm unsure if we would want that in the autopkgtest instances though
[21:06] <vorlon> xnox: and "always boots twice" is certainly not a feature
[21:06] <vorlon> but having initramfs+fallback by default is
[21:09] <xnox> right
[21:09] <xnox> how do i opt out of that?
[21:10] <vorlon> xnox: something something grub.d
[21:10] <xnox> cause we  customize cloud image for autopkgtests, i thought
[21:10] <xnox> let me check the somethings
[21:10] <vorlon> :)
[21:14] <xnox> GRUB_FORCE_PARTUUID=
[21:14] <xnox> i think
[21:15] <xnox> vorlon:  tyring initrdless boot should a properly of a kernel.
[21:15] <xnox> vorlon:  it makes sense for flavours, it doesn't make sence for generic
[21:16] <xnox> and i do understand that we have more flavour type of kernel.
[22:26] <Eickmeyer>  We (the Ubuntu Studio team) now have two packages that need sponsoring.  (bug 1829562 and bug 1831154)
[22:26] <Eickmeyer> Somebody PLEASE take a look at these.