[00:24] <tsimonq2> jbicha: I had a backport of spectre-meltdown-checker started but not finished in bug 1743334. If you would like to finish it up (since you synced to Bionic today), you're welcome to, just assign the bug to yourself. Otherwise I'll assign the bug to myself tomorrow.
[02:12] <LargePrime> how can i get this package updated https://launchpad.net/ubuntu/+source/xflr5
[02:12] <LargePrime> please ping if you reply, i sleep now
[02:12] <LargePrime> a link to a how to help ubuntu keep packages up to date would be great
[02:20] <tsimonq2> LargePrime: Ask Debian.
[02:23] <tsimonq2> LargePrime: https://bugs.debian.org/864588
[05:20] <slangasek> nacc: non-standard xz flag> hmph, who do we blame for that?
[06:40] <lathiat> FYI seems there is a bug in bind9-host on bionic that causes it to hang forever sometimes, which causes avahi-daemon-check-dns.sh to hang forever and cause network connections to hang indefinitely.. https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1752411
[07:04] <zyga> re
[07:05] <mvo> sil2100: hey! I was told by zyga that there might be an issue with the ubuntu-image snap (zyga knows the details). are you aware of this?
[07:05] <zyga> mvo, sil2100: the ubuntu-image snap is published to edge and beta and doesn't function (GLIBC things explode)
[07:05] <zyga> if the snap should be used it should be fixed and published to stable
[07:05] <zyga> otherwise I think the channels should be closed
[07:05] <zyga> it's a high-profile item in device maker circles
[07:13] <sil2100> zyga: I think we didn't use stable before, but maybe it's finally time - anyway, I wasn't aware that the current snap is exploding, thanks for letting me know
[07:13] <sil2100> I'll take a look at it
[07:13] <slangasek> sil2100: hum, it's long overdue for it to be on stable IMHO
[07:13] <sil2100> slangasek: yeah
[07:13] <slangasek> sil2100: OTOH we should only push it there if it's actually stable ;)
[07:14] <sil2100> slangasek: well, I think the idea was to publish it to stable once we have 1.0 - and we did, but I guess we forgot ;p
[07:14]  * zyga feels this issue is now in very good and capable hands :)
[07:15] <slangasek> is the glibc issue one that's currently fixable with current snapcraft and classic snaps?
[07:16] <slangasek> I'm not sure if we've gotten the all-clear on that
[08:43] <snikker> hello, i'm compiling kernel usung "make deb-pkg", there is a way to use custom "changelog" and "control" files instead of auto generated?
[10:08] <doko> oSoMoN: re LP: #1034558 why remove, they are synced from Debian. why did you remove the external deps?
[10:10] <oSoMoN> doko, I didn't remove anything, I'm merely suggesting that they could be if we wanted to, there's nothing actually using those
[10:47] <sil2100> mvo, zyga: are the issues with the ubuntu-image snap reported anywhere?
[10:48] <zyga> sil2100: not that I know of
[10:48] <ginggs> tseliot: you have a new PR
[10:49] <sil2100> zyga: I see some issues indeed, e.g. it's busted on artful - but it's been like that since a while, I guess might be good to see if it can get fixed now
[10:49] <sil2100> For xenial it works as expected
[10:49] <sil2100> I was wondering if this was some other issue, or is this it
[10:49]  * sil2100 needs to check on bionic
[10:49] <zyga> sil2100: what was the issue on artful?
[10:49] <zyga> I think you _maybe_ just need a rebuild with new snapcraft
[10:52] <sil2100> zyga: yeah, I guess that's it, it's the glibc issue caused by the old snapcraft IIRC
[10:52] <zyga> sil2100: it looks like the snap was built on bionic
[10:52] <zyga> but I don't understand why it would work on xenial then
[10:54] <sil2100> I'll investigate some more
[11:08] <tseliot> ginggs: yes, I'll have a look at it later, thanks
[11:09] <ginggs> tseliot: thanks - i checked and it wasn't in the 384 packaging, so must have crept in during the switch to the new packaging in 390
[11:21] <doko> please pickup your ftbfs here ... http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20180408-bionic.html
[12:57] <LargePrime> tsimonq2, how hard is it to maintain a package?
[12:57] <LtWorf_> LargePrime: maintaining chromium is slightly harder than maintaining nyancat
[12:58] <LtWorf_> (i mean that it all depends on how hards is the content of the package itself)
[12:58] <LargePrime> LtWorf_, it would be this https://bugs.debian.org/864588
[12:59] <LargePrime> not hard i think.  but no experience in the domain
[12:59] <LargePrime> have you any advice for me?
[13:01] <LtWorf_> LargePrime: i think #debian-mentors on oftc is a better channel to ask this stuff
[15:00] <sil2100> !dmb-ping
[15:21] <tsimonq2> LargePrime: Not *terribly* hard if you RTFM. :P
[15:29] <nacc_> slangasek: not sure, i need to verify it's true, and then see .. i've filed a few bugs in debian re: non-reproducible tarballs before
[15:30] <nacc_> slangasek: none of them have received any response, which makes me feel like pristine-tar is not maintained (i mentioned this to you before, i think)
[15:36] <nacc_> slangasek: and it's also something i struggled to debug effectively, but I believe I should be able to without git-ubuntu ... i'll do that today
[16:25] <seb128> cyphermox, hey, was bug 1754422 good to go after security +1?
[17:25] <nacc> slangasek: i'm still wading into this, but it does appear to be reproducible with just pristine-tar in a Git repo. Also this article https://www.nongnu.org/lzip/xz_inadequate.html
[17:26] <slangasek> heh
[17:26] <nacc> slangasek: i believe (and this might be true for other formats, just no flags are used there), it's not always possible to know what xz was used to compress something
[17:26] <nacc> slangasek: and what flags, maybe, more particularly
[17:26] <slangasek> nacc: sure; it just seems so unlikely that an Ubuntu dev would be using arbitrary xz flags when building this orig.tar.xz?
[17:27] <slangasek> it appears juliank did the cryptsetup upload in question
[17:28] <slangasek> juliank: ^^ how did you acquire the orig.tar.xz for that upload? did it come from upstream or did you create it?
[17:28] <nacc> slangasek: oh no i meant the upstream did
[17:28] <nacc> slangasek: it's what is published upstream (i've verified that now )
[17:28] <slangasek> ah
[17:28] <nacc> slangasek: but i believe pristine-tar has to be able to call xz in the same way upstream does in order to verify it did the right thing
[17:28] <nacc> slangasek: and it's not always going to be able to (again, this is still just my rough understanding)
[17:29]  * slangasek nods
[17:30] <nacc> we obviously could decompress and recompress xz as something else in order to reproduce it, but it's really not a big deal (imo) yet
[17:30] <nacc> pristine-tar support in git-ubuntu is best effort on import
[17:30] <nacc> we can always fallback to Launchpad (and I think I have an algorithm for your merge case now)
[18:01] <nacc> slangasek: i've asked upstream how they generate the tarball, as even the manual try-all-known options path in pristine-xz fails: https://gitlab.com/cryptsetup/cryptsetup/issues/374
[18:04] <coreycb> RAOF: hi, if you have a chance during your Tues SRU rotation, would you be able to take a look at promoting neutron to artful-proposed and possibly reviewing the neutron versions in the xenial and artful queues?
[18:15] <slangasek> coreycb: none of the Monday rotaters available?  (infinity)
[18:18] <coreycb> slangasek: possibly. i like to add a little buffer time to my asks to account for timezones, shock, etc. :)
[18:48] <andyrock> slangasek: hey hey
[18:48] <andyrock> slangasek: I didn't see your ping earlier this morning
[18:50] <andyrock> slangasek: I guess the only problem would be if you've software-properties-dbus installed and not snapd-glib
[18:50] <andyrock> slangasek: maybe we can move that dependency there
[18:50] <andyrock> for the others I'm pretty sure there will be no problem
[19:13] <slangasek> andyrock: ok great, thanks - I'll sponsor the upload now
[19:14] <andyrock> slangasek: I moved snapd back to common
[19:14] <andyrock> how can I check if it is going to create problems in the server image?
[19:15] <slangasek> andyrock: launch a default lxd instance; install updated versions of software-properties-common + python3-software-properties; confirm that add-apt-repository doesn't bail
[19:17] <slangasek> andyrock: so if we have to still depend on gir1.2-snapd-1, that's very specifically the one that is causing the image bloat
[19:17] <slangasek> andyrock: because glib1.2-snapd-1 -> libsnapd-glib1 > libsoup2.4-1 > glib-networking
[19:17] <slangasek> since we don't use it in the "common" case, it would be good to figure out how to avoid that dependency
[19:17] <andyrock> mmm one thing that we can do is to not make it a depedency
[19:18] <andyrock> than we can move the "from gi.repository import snapd" inside a try
[19:18] <andyrock> the rest of the code is not going to be called
[19:18] <slangasek> yes, that would also be fine from my POV
[19:18] <andyrock> so it should not create any problems
[19:19] <nacc> slangasek: ah, pristine-tar 1.42 has added a -r flag
[19:20] <slangasek> nacc: short for --really-pristine?
[19:20] <nacc> slangasek: --recompress
[19:21] <slangasek> ok
[19:21] <nacc> slangasek: which allows for recompressing a reproducible tarball
[19:21] <slangasek> --right-this-time-we-mean-it
[19:21] <nacc> yeah :)
[19:21] <nacc> i think it will guarnatee the .tar is the same, even if hte .tar.xz is not ... which is still not ideal
[19:21] <nacc> i'm not sure we want git-ubuntu to do that, as it will lead to weird issues
[19:28] <andyrock> slangasek: https://code.launchpad.net/~azzar1/software-properties/fix-1762082/+merge/342854
[19:30] <jbicha> slangasek: can you let my DMB email through the u-devel-announce moderation queue? LP: #1762516
[19:47] <slangasek> jbicha: done
[19:50] <slangasek> andyrock: thanks, uploading
[22:01] <joelkraehemann> hi all
[22:01] <joelkraehemann> how is the freeze?
[22:02] <joelkraehemann> Since I just discovered a flaw in GSequencer
[22:02] <joelkraehemann> http://git.savannah.nongnu.org/cgit/gsequencer.git/commit/?h=1.4.x&id=07f18a82b7df829a6969e88f86848e676d888fd4
[22:02] <joelkraehemann> I just build the new tarball
[22:03] <nacc> joelkraehemann: bugfixes are allowed
[22:03] <joelkraehemann> it is a bugfix
[22:03] <nacc> joelkraehemann: ok, file a bug?
[22:03] <joelkraehemann> I am upstream
[22:03] <joelkraehemann> should I do it anyway?
[22:03] <nacc> joelkraehemann: an ubuntu bug, i mean
[22:03] <joelkraehemann> great
[22:04] <nacc> joelkraehemann: file a bug, provide a debdiff, ifyou can
[22:04] <nacc> joelkraehemann: it'll go into the sponsorship queue -- i can probably take a look if you ping me :)
[22:05] <joelkraehemann> thank you
[22:09] <joelkraehemann> https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1762564
[22:10] <joelkraehemann> nacc: the debdiff takes some time because I just run the test-suite
[22:10] <nacc> joelkraehemann: sure
[23:22] <joelkraehemann> nacc: ping
[23:23] <joelkraehemann> FYI, there is a new upstream tarball available
[23:23] <joelkraehemann> it contains 2 other fixes but are less important
[23:24] <sarnold> nacc will probably want all the changes in a new tarball documented in the bug
[23:25] <joelkraehemann> sarnold: Ok, I do so
[23:25] <sarnold> joelkraehemann: thanks :)
[23:25] <joelkraehemann> sarnold, well there was 1 symbol not exported
[23:29] <joelkraehemann> https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1762576
[23:31] <joelkraehemann> https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1762578
[23:43] <joelkraehemann> nacc: all patches provided