[00:37] <tsimonq2> slangasek: Could you axe kdesudo? bug 1757682
[00:59] -queuebot:#ubuntu-release- New source: grub-legacy-ec2 (bionic-proposed/primary) [1:1]
[01:25] <tsimonq2> slangasek: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1592405/comments/1 Do you happen to remember what version clobbered it?
[01:35] <xnox> tsimonq2, it may have been the merge I have done
[01:36] <xnox> tsimonq2, to get the new upstream release in.
[01:36] <xnox> tsimonq2, should i poke and try to look into this too?
[01:36] <tsimonq2> xnox: You're more than welcome to; I'd certainly like to learn from this but if it's a quick solution, by all means, JFDI. :)
[01:41] <tsimonq2> xnox: Hum, might it be that debian/initramfs-tools/hooks/plymouth is missing?
[01:42] <xnox> tsimonq2, well, i'm trying to dig history, i'm pretty sure I was the one who _introduced_ using UbuntuMono font....
[01:43] <tsimonq2> xnox: Heh, OK.
[01:52] <xnox> tsimonq2, now I am confused. I think, this may only be using ubuntu font, post initramfs, and never in the initramfs.
[01:52] <xnox> tsimonq2, and I do not see any attempts to have UbuntuFont in the initramfs.
[01:53] <xnox> tsimonq2, but I do recall proposing to do that circa 2013/2014, but possibly there were concerns about "too large" file size.
[01:53] <tsimonq2> xnox: I think it could be readdressed.
[01:54] <tsimonq2> xnox: I wonder what the filesize difference might be.
[01:55] <xnox> Ubuntu regular is 357k, we may want the Ubuntu Mono regular which is 209k
[01:56] <tsimonq2> And right now, DejaVu is used?
[01:56] <tsimonq2> I mean, for a 209k difference, I personally think it's a good idea.
[01:56] <xnox> DeajuSerif + Sans are 381k + 758k
[01:56] <tsimonq2> Ok, so if we *just* use Ubuntu Mono, then that's less size?
[01:56] <tsimonq2> Or am I not seeing this right?
[01:57] <xnox> supports less languages, but i'm not sure we support translations in the initramfs
[01:57] <xnox> and we need to customize fonconfig conf file, in the initramfs
[01:57] <xnox> but easy enough to special case that.
[01:57] <xnox> cause, Ubuntu font is not "metric" compatible with Arial, unlike DejaVuSans
[01:57] <tsimonq2> OK
[01:57] <xnox> then again... this is plymouth and plymouth-text, not thesis typesetting
[01:58] <tsimonq2> Hehe, right.
[01:58] <tsimonq2> xnox: So is this something that you could JFDI pretty easily?
[01:58] <xnox> tsimonq2, do you know if derivates plymouth themes also specify and use 'Ubuntu 11'? or just the Ubuntu one?
[01:58] <xnox> aka lubuntu-logo, etc?
[01:58]  * tsimonq2 looks at what Lubuntu does
[01:59] <xnox> just need to write a "better" /etc/fonts/conf.d/60-latin.conf
[01:59] <xnox> to be all ubuntu font family
[02:01] <tsimonq2> xnox: Yeah no, this just specifies a module of "ubuntu-text"
[02:01] <tsimonq2> (in Lubuntu's)
[02:01] <xnox> lubuntu-logo should be the one splashy
[02:01] <xnox> ubuntu-text, is the "serial non-quiet non-splash" version
[02:02] <xnox> plymouth-theme-lubuntu-logo or like plymouth-theme-lubuntu-next-logo
[02:02] <tsimonq2> Right.
[02:02] <tsimonq2> But we also have just text packages.
[02:03] <xnox> yeah, for text-only we don't do anything - no fancy fonts, no pango, no truetype, because we asume the user wants just the kernel font rendering.
[02:03] <xnox> because the user wants it shmall
[02:04] <xnox> tsimonq2, so it looks like at least lubuntu-font got forked, before 'Ubuntu 11' was added in the "ubuntu-logo" theme.
[02:04] <xnox> so does not use that.
[02:04] <xnox> A quick fix, is to stop using 'Ubuntu 11' in the ubuntu-logo theme =)
[02:05] <xnox> or ship the ubuntu font, and force it to be used by default, and then there would be no need for it to be specified.
[02:05] <tsimonq2> If it doesn't use too much resources, I'd argue for the latter.
[02:06] <tsimonq2> I mean, if it introduces little to no size, even in cases where the user wants it small, if it's just 1/5 of a MB, it shouldn't be a big deal.
[02:06] <xnox> when kernel modules are huge.
[02:06] <tsimonq2> Right.
[02:06] <tsimonq2> The kernel is kinda huge. :P
[02:06] <tsimonq2> (In comparison.)
[02:07] <tsimonq2> xnox: Oh, jbicha made a good point on the bug report.
[02:07] <xnox> tsimonq2, this will need testing.
[02:07] <xnox> hm?
[02:07] <xnox> tsimonq2, yes, i did notice the transitional package dep already
[02:07] <tsimonq2> OK, cool.
[02:08] <tsimonq2> xnox: Would you like to take care of this (because I assume you know the codebase better) or should I?
[02:08] <tsimonq2> I'm fine either way.
[02:08] <tsimonq2> And indeed, testing will be needed.
[02:08] <jbicha> the transitional font dep has been annoying me for a while, but I was not annoyed enough to touch plymouth 🙈
[02:09] <tsimonq2> This might be a good occasion. :)
[02:10] <xnox> jbicha, hahahhahaha
[02:10] <xnox> tsimonq2, i'll do it all; but will need to do boot tests; so not right now, but soon.
[02:11] <tsimonq2> xnox: Alright; I'll assign the bug to you. Thanks, and please keep me updated. :)
[02:12] <tsimonq2> Er, you did already. Cool.
[04:38] <slangasek> xnox: ah; I guess I was wrong about the initramfs hook having used the Ubuntu font previously?  I just checked the last version before the Debian merge (0.9.0-0ubuntu9 in vivid) had a dep on both fonts-dejavu-core and ttf-ubuntu-font-family, and only copied fonts-dejavu-core into the initramfs
[04:39] <slangasek> xnox: so, it would be nice to get it using the Ubuntu font consistently (and dropping the need to pull dejavu in in this context), but re-adding the dejavu dep would apparently suffice to fix the regression
[04:58] <tsimonq2> slangasek: Would you happen to know what's going on with armhf autopkgtest builders?
[04:58] <tsimonq2> (I'm asking you because I hope you saw that the build you've triggered is also queued but not running. :P)
[04:59] <slangasek> tsimonq2: nope, haven't looked; looking now
[04:59] <tsimonq2> ack
[05:06] <tsimonq2> lol @ someone uploading zfs-linux to Debian that was likely meant for Ubuntu
[05:06]  * tsimonq2 shrugs, it happens I guess
[05:06] <slangasek> tsimonq2: armhf sorted; looks like the lxd runners aren't entirely happy with the daily maintenance job, they likely would've started right about now on their own if I had done nothing
[05:07] <slangasek> but that means they were down for 2 hours, unhelpfully
[05:07] <tsimonq2> slangasek: ah ok
[05:07] <tsimonq2> cool, thanks
[05:18] <tsimonq2> slangasek: It'd be good to get a second opinion on node-cross-spawn
[05:19] <tsimonq2> Its tests fail with the new nodejs, but the version we ship doesn't have upstream tests for nodejs 8.x.
[05:20] <tsimonq2> We also ship a release that's a major version behind.
[05:21] <tsimonq2> Ultimately the arm{hf,64} test failures are just timeouts.
[05:22] <tsimonq2> I've been trying to set the timeout integers to be larger values in my PPA testing but have ultimately been unsuccessful so far.
[05:24] <tsimonq2> I'll try some more, but if the situation doesn't improve, then I'm not sure what to do from there.
[05:27] <tsimonq2> In fact, that sort of thing seems almost commonplace; we're shipping node modules with out-of-date versions which have failing tests that have been completely revamped upstream.
[05:28] <tsimonq2> (I'm making a generalization, but still.)
[07:22] <slangasek> tsimonq2: there are enough nodejs-triggered autopkgtests that fail only on arm64 and armhf that it makes it suspicious that there may be arch-specific regressions in our nodejs
[07:23] <slangasek> tsimonq2: node-block-stream, node-commander, node-cross-spawn, node-liftoff - are these related?
[07:31] <tsimonq2> slangasek: I haven't taken a close look but it's possible.
[07:35] <tsimonq2> slangasek: node-liftoff seems to need timeout bumps like node-cross-spawn.
[07:36] <tsimonq2> Doing, although it's a bit of a PITA because turnaround time for testing is 20 minutes minimum, and these tests stop as soon as there's one error. Sigh.
[07:38] <tsimonq2> slangasek: I don't quite know what to make of node-block-stream.
[07:38] <tsimonq2> slangasek: node-cross-spawn *should* be fixed now.
[07:39] <tsimonq2> slangasek: And node-commander is kind of weird: AssertionError: expected '' to be 'SIGHUP\n'
[07:39] <tsimonq2> slangasek: So while these are unrelated, it's weird that these only happen on *some* arches.
[08:17] -queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [amd64] (bionic-proposed) [1.175ubuntu1]
[08:17] -queuebot:#ubuntu-release- New: accepted ubuntu-wallpapers [amd64] (bionic-proposed) [18.04.0-0ubuntu1]
[08:17] -queuebot:#ubuntu-release- New: accepted virtualbox-hwe [i386] (bionic-proposed) [5.2.8-dfsg-5ubuntu18.04.1]
[08:17] -queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [i386] (bionic-proposed) [1.175ubuntu1]
[08:17] -queuebot:#ubuntu-release- New: accepted virtualbox-hwe [amd64] (bionic-proposed) [5.2.8-dfsg-5ubuntu18.04.1]
[08:17] -queuebot:#ubuntu-release- New: accepted mir [amd64] (bionic-proposed) [0.31.0.1-0ubuntu1]
[08:17] -queuebot:#ubuntu-release- New: accepted mir [armhf] (bionic-proposed) [0.31.0.1-0ubuntu1]
[08:17] -queuebot:#ubuntu-release- New: accepted mir [ppc64el] (bionic-proposed) [0.31.0.1-0ubuntu1]
[08:17] -queuebot:#ubuntu-release- New: accepted mir [arm64] (bionic-proposed) [0.31.0.1-0ubuntu1]
[08:17] -queuebot:#ubuntu-release- New: accepted mir [s390x] (bionic-proposed) [0.31.0.1-0ubuntu1]
[08:17] -queuebot:#ubuntu-release- New: accepted mir [i386] (bionic-proposed) [0.31.0.1-0ubuntu1]
[09:13] <tsimonq2> slangasek: Actually, note-liftoff can be badtested.
[12:04] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.31.2 => 2.32] (desktop-core, ubuntu-server)
[12:14] <estan> ginggs: ping. bcolz 1.2.0+ds1-1 now ready to be synced from debian/incoming. should fix the autopkgtest failure of c-blosc 1.14.2+ds1-1.
[12:15] <estan> ahem s/of c-blosc/with c-blosc/
[12:15] <ginggs> estan: waiting for it to be picked up by launchpad https://launchpad.net/debian/+source/bcolz
[12:15] <estan> ginggs: aha.
[14:21] -queuebot:#ubuntu-release- New sync: deepin-movie-reborn (bionic-proposed/primary) [3.2.3-2]
[16:43] <estan> ginggs: looks like the eagle landed ^ :)
[18:24] <LocutusOfBorg> hello jbicha, I'm uploading a gtk+2.0 merge, because the current one is FTBFS in release pocket, probably your glib2 upload broke it?
[18:25] <jbicha> LocutusOfBorg: sync meson
[18:25] <jbicha> I mean unless I need yet another FFe for that
[18:26] <jbicha> the Ubuntu diff can be dropped now
[18:27] <ginggs> estan: infinity beat me to it
[18:27] <jbicha> LocutusOfBorg: I mean you could merge glib2.0 if you want too…
[18:29] <jbicha> LocutusOfBorg: I'm all confused. Let's start over. Do you have a build log for the gtk2 build problem?
[18:29] <LocutusOfBorg> ok glib2.0 done
[18:29] <LocutusOfBorg> jbicha, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
[18:30] <jbicha> you synced gtk2, why?
[18:30] <LocutusOfBorg> this is a no change rebuild of the version in release
[18:30] <LocutusOfBorg> jbicha, I didn't :) or better, I did just to avoid uploading the source tarball for the diff
[18:30] <LocutusOfBorg> I have a connection that sucks a bit, I didn't make the sync build at all
[18:33] <LocutusOfBorg> jbicha, do you see the symbols that have been dropped in the merge? http://launchpadlibrarian.net/361892471/gtk+2.0_2.24.32-1_2.24.32-1ubuntu1.diff.gz
[18:33] <LocutusOfBorg> should I readd them in your opinion? g_cclosure_marshal_VOID__BOXED
[18:33] <LocutusOfBorg> they are removed in the last patch that ubuntu applies
[18:33] <LocutusOfBorg> they are coming from glib, and they shouldn't be there...
[18:33] <LocutusOfBorg> not sure if this is a problem or not
[18:42] <LocutusOfBorg> somebody from desktop team today  told me to just remove them
[18:43] <LocutusOfBorg> because such symbols are inside glib2.0, and they shouldn't be in gtk2 (and gtk2 links glib2, so there is no runtime issue)
[18:45] <jbicha> yes, they can be removed as I think that was a glib bug
[18:46] <jbicha> y'all probably shouldn't have changed gtk_print_backend_set_password@Base 2.24.25-0ubuntu2 but since a newer version is in xenial maybe it doesn't matter so much
[18:46] <jbicha> please push your changes to bzr  lp:~ubuntu-desktop/gtk/ubuntu
[18:47] <jbicha> I believe we'll be switching to git for Chaotic Camel ( web link for bzr is https://code.launchpad.net/~ubuntu-desktop/gtk/ubuntu )
[18:48] <jbicha> if y'all are really eager, you can merge gtk3 too :)
[18:51] <LocutusOfBorg> "y'all probably shouldn't have changed gtk_print_backend_set_password@Base 2.24.25-0ubuntu2 but since a newer version is in xenial maybe it doesn't matter so much"
[18:51] <LocutusOfBorg> this is *exactly* what I changed, but after I changed it back, because "better safe than sorry"
[18:51] <LocutusOfBorg> sure, I'll push them
[18:52] <jbicha> that symbol version was changed in the version pushed to bionic
[18:52] <LocutusOfBorg> I know, but maybe reverse-deps complains if we don't rebuild?
[18:52] <jbicha> hmm?
[18:53] <LocutusOfBorg> I mean, ok  the lower bound is already satisfied
[18:55] <jbicha> I'll probably have to do a gtk2 upload in unstable to drop the extra glib symbols
[18:56] <LocutusOfBorg> thanks jbicha :)
[18:56] <LocutusOfBorg> btw, I sync'd meson, just bugfixes, new tests and a bug I was hitting with libinput
[18:57] <jbicha> thanks
[19:04] <estan> ginggs: you guys have been my dream team through this :)
[19:18] <jbicha> LocutusOfBorg: gtk2 builds fine in unstable. I guess I could mark those closure symbols as optional… not really sure why Debian & Ubuntu are different there now
[20:09] <slangasek> tsimonq2: what's the rationale for considering node-liftoff badtest?
[20:38] <jbicha> LocutusOfBorg: gtk2 is one of the last Debian GNOME packages to use cdbs, I wonder if that helps explain the g_cclosure symbols? none of our other libraries have those symbols
[20:43] <jbicha> LocutusOfBorg: https://launchpad.net/ubuntu/+source/meson/0.45.1-1/+build/14489818 (it was a binary upload in Debian :| )
[22:39] -queuebot:#ubuntu-release- New binary: javatools [amd64] (bionic-proposed/universe) [0.63] (no packageset)
[22:50] <LocutusOfBorg> jbicha, gtk2, the latest patch (ubuntu specific) is changing the file "./gtk/gtkmarshalers.list"
[22:50] <LocutusOfBorg> so removing them manually I would say
[22:50] <LocutusOfBorg> Debian has not this patch, so they appears there?
[22:52] <jbicha> ok, the use-secrets-service patch?
[22:56] <LocutusOfBorg> yes, this: +-VOID:POINTER,POINTER,POINTER,POINTER,STRING
[22:56] <LocutusOfBorg> btw, doko any idea if you are building libphobos.a without fPIC?
[22:56] <LocutusOfBorg>  /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/8/libgphobos.a(stdio.o): relocation R_X86_64_TPOFF32 against symbol `_D3std5stdio10readlnImplFPOS4core4stdc5stdio8_IO_FILEKAawE3std5stdio4File11OrientationZ1nm' can not be used when making a shared object; recompile with -fPIC
[22:57] <LocutusOfBorg> this happens with meson
[23:04] <Laney> LocutusOfBorg: we have a packaging branch for glib2.0 if you'd be so kind as to push there please
[23:05] <LocutusOfBorg> link please? I'll be happy to push
[23:06] <LocutusOfBorg> also, gtk3 uploaded
[23:06] <jbicha> LocutusOfBorg: it's in the VCS fields in debian/control :)
[23:08] <LocutusOfBorg> ok, lets do it tomorrow :)
[23:08] <LocutusOfBorg> too late here
[23:18] <LocutusOfBorg> I think I did also glib2.0, please don't shoot at me if I did import it wrong :)
[23:18]  * LocutusOfBorg goes to sleep