| 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:22 |
|---|---|---|
| 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:27 |
| Wimpress | So -proposed should be remove from update.cfg once everything has migrated? | 09:28 |
| Wimpress | Or safe to leave? | 09:28 |
| Wimpress | Thanks for sorting that, I'll let the Ubuntu Budgie guys know what to do. | 09:29 |
| xnox | safe to leave | 09:29 |
| xnox | ie. ubuntu-meta has it always | 09:30 |
| Wimpress | Thanks. | 09:30 |
| xnox | uploaded | 09:30 |
| Wimpress | Wonderful. I'll get the QA guys to test the next daily. | 09:31 |
| xnox | Wimpress: well not gonna migrate yet. | 09:32 |
| Wimpress | OK | 09:32 |
| 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:33 |
| 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. | 09:41 |
| 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:20 |
| 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 | 10:52 |
| 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:02 |
| Laney | but I can't remember what the situation is with mirrors carrying -security | 11:03 |
| sladen | cking: have sent a ubuntu-devel@ reply re: the compression | 11:26 |
| 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:28 |
| 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:29 |
| 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:31 |
| tmhoang | good point. many thanks | 11:32 |
| xnox | github.com/CanonicalLtd/subiquity | 11:32 |
| xnox | etc. | 11:32 |
| === ricab is now known as ricab|lunch | ||
| 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:38 |
| 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:41 |
| 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:42 |
| sladen | xnow: so there is probably a local maxima for Bzip2 using eg 100kB blocks and 30 CPUs in parallel | 11:43 |
| 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:44 |
| 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 | 11:49 |
| === ricab|lunch is now known as ricab | ||
| 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:37 |
| xnox | ditto i386 https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/i386/s/systemd/20190529_215838_00b24@/log.gz | 13:39 |
| Laney | xnox: i dunno, looks like the restart doesn't go very well though | 13:41 |
| 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:42 |
| Laney | does it happen on your system with qemu? if not, you should still have access to the cloud to run things there | 13:44 |
| 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:12 |
| 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:16 |
| tmhoang | xnox: I think I would stick with 2nd option instead of .ddeb. I have not used them before :( | 15:17 |
| 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:18 |
| tmhoang | so, I guess something like : DEB_BUILD_OPTIONS += nostrip should work | 15:19 |
| 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:20 |
| 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:21 | |
| tmhoang | ah I saw it now. Many thanks. Also this is for dev so I'd ignore standards :D | 15:22 |
| 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:51 |
| 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:54 |
| xnox | vorlon: ^ | 16:55 |
| vorlon | "something seems to be booting" - yes, all the cloud images disco and later have this | 16:56 |
| 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 | 16:57 |
| 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 | 17:01 |
| ubottu | Launchpad bug 1829829 in systemd (Ubuntu) "Ubuntu CI has been flaky for a week" [High,Confirmed] https://launchpad.net/bugs/1829829 | 17:01 |
| xnox | ddstreet: no, not expected and not ok | 20:51 |
| xnox | ddstreet: expectation for cloud images is to successfully boot initrdless | 20:51 |
| 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:52 |
| vorlon | unless I'm forgetting something | 20:53 |
| 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:54 |
| vorlon | xnox: AFAIK autopkgtest doesn't depend on nova api to determine whether a system is booted | 20:57 |
| 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 | 20:58 |
| xnox | hmmm | 21:01 |
| xnox | vorlon: i don't understand the point of a cloud image that always boots twice. | 21:04 |
| xnox | and always will...... | 21:04 |
| 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:05 |
| vorlon | xnox: and "always boots twice" is certainly not a feature | 21:06 |
| vorlon | but having initramfs+fallback by default is | 21:06 |
| xnox | right | 21:09 |
| xnox | how do i opt out of that? | 21:09 |
| 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:10 |
| xnox | GRUB_FORCE_PARTUUID= | 21:14 |
| xnox | i think | 21:14 |
| 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:15 |
| xnox | and i do understand that we have more flavour type of kernel. | 21:16 |
| === Wryhder is now known as Lucas_Gray | ||
| Eickmeyer | We (the Ubuntu Studio team) now have two packages that need sponsoring. (bug 1829562 and bug 1831154) | 22:26 |
| ubottu | bug 1829562 in Ubuntu Studio "[Needs Packaging] DPF-Plugins for Eoan" [Medium,In progress] https://launchpad.net/bugs/1829562 | 22:26 |
| ubottu | bug 1831154 in Ubuntu Studio Menu Add "[needs-packaging] ubuntustudio-menu-add" [Medium,In progress] https://launchpad.net/bugs/1831154 | 22:26 |
| Eickmeyer | Somebody PLEASE take a look at these. | 22:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!