[10:28] <rbasak> nacc: I think I can just sync php-defaults now. Please could you check for me that this is sane?
[10:28] <rbasak> I'm basing this on https://git.launchpad.net/ubuntu/+source/php-defaults/log/?h=debian/sid and https://git.launchpad.net/ubuntu/+source/php-defaults/log/
[11:21] <xnox> RAOF[m], mir ftbfs in cosmic now =( something about GMock i think
[11:21] <xnox> -- Cannot enable coverage targets because neither lcov nor gcovr are found.
[11:21] <xnox> CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
[11:21] <xnox> Please set them or make sure they are set and tested correctly in the CMake files:
[11:21] <xnox> GMOCK_INCLUDE_DIR
[11:31] <xnox> RAOF[m], actually, i may have been able to fix it.
[11:56] <xnox> RAOF[m], sigh https://paste.ubuntu.com/p/Q3PFD3rb4J/
[12:15] <RAOF[m]> xnox: there are differences of opinion as to what constitutes a point release on the Mir team 😀
[12:15] <doko> ftbfs is independent of any opinion
[12:16] <doko> tsimonq: are you involved with ffmpeg? http://people.canonical.com/~ubuntu-archive/transitions/html/ffmpeg.html
[12:16] <xnox> RAOF[m], fair enough =) we are talking about cosmic, not bionic. And it needs investigation how come miral gains new symbols, and if they are legit.
[12:17] <xnox> RAOF[m], the google-mock -> libgmock-dev change is straight forward, the symbols are not though =/ please commit the build-dep change, and the symbols changes and make an upload to cosmic sooner; rather than later.
[12:17] <xnox> RAOF[m], probably not as a full point release but just a ubuntuX upload direct to cosmic.
[12:19] <RAOF[m]> xnox: the symbols are almost certainly deliberate; you might want to check against the packaging in github.com/MirServer/Mir
[12:20] <RAOF[m]> (which used to be automatically distro'd, but the bileto workflow is no more)
[12:23] <xnox> RAOF[m], right, i see that you fixed gmock change differently (by using a new googletest path; instead of changing the dep to the new libgmock-dev package) I guess either is fine.
[12:24] <RAOF[m]> I'll get on to that on Monday, when I've returned from holiday 😀
[12:25] <xnox> RAOF[m], yeah \o/
[12:27] <ahasenack> Laney: around?
[12:34] <tsimonq2> ahasenack: He said in -desktop yesterday that he'll be gone until Tuesday.
[12:34] <ahasenack> ah, ok
[12:34] <ahasenack> was looking for someone who could help with stuck tests in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#autofs
[12:37] <tsimonq2> hmm, idk
[12:46] <doko> oSoMoN: any update about libreoffice?
[13:23] <oSoMoN> doko, on it, the various failures are not obvious so I'm working on pushing a 6.0.6~rc1 update, hoping that the failures will go away with it
[14:50] <abeato> sil2100, hey, I was wondering if it would make sense for ubuntu-image to accept a folder with a rootfs as an alternative to creating it with live-build
[14:50] <abeato> sil2100, talking about classic here
[14:51] <abeato> sil2100, as live-build is a rather complex machinary and in many cases you would prefer to run it by yourself and then creating a full volume starting from the rootfs created by lb
[15:02] <sil2100> abeato: might be something worth thinking about
[15:03] <sil2100> abeato: it could be done pretty easily, can't instantly think of any objections (besides the principle of u-i doing most of the job for us)
[15:03] <sil2100> abeato: could you fill in a featue request for it on LP?
[15:04] <abeato> sil2100, sure thing
[15:04] <sil2100> Thanks o/
[15:04] <abeato> yw
[15:13] <abeato> sil2100, https://bugs.launchpad.net/ubuntu-image/+bug/1782795
[16:04] <tsimonq2> Anyone else having problems with debootstrap?
[16:05] <tsimonq2> For the second time in this past week, it's erroring out on a corrupt Packages.gz...
[16:05] <tsimonq2> Only with debootstrap; works when manually downloading and verifying cached copies.
[16:11] <tomreyn> someone else reported problems with debootstrap on bionic on irc the other day. i forgot the details, though.
[16:12] <tomreyn> tsimonq2: what's the system you're running it on running? also 18.04?
[16:13] <tsimonq2> tomreyn: Nope, up-to-date Cosmic.
[16:13] <tomreyn> tsimonq2: oh, using deboostrap from cosmis also then?
[16:14] <tomreyn> *cosmiC
[16:14] <tsimonq2> Yup.
[16:21] <ScottE> For what it's worth, a "debootstrap --arch amd64 bionic /tmp/z" from bionic worked for me
[16:22] <tsimonq2> Perhaps it's only when creating Cosmic chroots.
[16:30] <nacc> rbasak: wil do; give me 5 minutes
[16:31] <nacc> rbasak: yes, sort of. We lose branding (s/Debian/Ubuntu/) but since we no longer diverge that seems fine. NOte that PHP needs some love in 18.10 afaik.
[16:48] <ScottE> tsimonq2 just for the heck of it, I did a debootstrap of cosmic from bionic, then chrooted into that and debootstrapped cosmic - it worked OK. Don't know if that helps, but perhaps it's a useful bit of info.
[16:48] <rbasak> nacc: thanks. I'm aware of pkg-php-tools. What else needs attention? Is there a summary/report I can use?
[16:52] <tsimonq2> ScottE: Hmm.
[17:12] <nacc> rbasak: not sure, but i have a bunch of pakcages that need syncing that can't because they needed phpunit 6 (now 7, maybe?) updates
[17:16] <rbasak> nacc: ah, basically "grep-merges Nish"? That gives me a list to get started, thanks :)
[17:23] <nacc> rbasak: yeah
[17:34] <tomreyn> tsimonq2: fwiw, i also run, on a fully updated bionic amd64 VM, using debootstrap from cosmic, "debootstrap --arch amd64 cosmis /mnt/cosmic" and "debootstrap --arch amd64 cosmic /mnt/cosmic", both of which ran without warnings.
[17:42] <tomreyn> and the same with cosmic's debootstrap from within the bionic cosmis chroot, debootstrapping cosmic.
[17:42] <tsimonq2> O_o
[17:42] <tsimonq2> huh
[17:43] <tomreyn> so in case this was not well explained: bionic -> coscmic debootstrap -> chroot on bootstrapped cosmic -> debootstrap cosmic
[17:43] <tomreyn> this worked without warnings / errors.
[19:37] <hallyn> lvm2 in bionic is missing link from /lib/x86_64-linux-gnu/libdevmapper.so.1.02 to /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1.  That should've been autocreated by the build right?
[22:03] <dannf> GunnarHj: re: console-setup - i wonder if '[ -n "XDG_CURRENT_DESKTOP ]' shouldn't be '[ -n "$XDG_CURRENT_DESKTOP" ]'
[23:11] <infinity> dannf: It should be indeed, but that test also seems bogus.  Why would it matter if I'm upgrading from a console session or X?
[23:12] <infinity> dannf: (ie: I tihnk it's a happy accident that the test is always true, cause I think it shouldn't be testing that at all :P)