[11:30] <tjaalton> LocutusOfBorg: hi, filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939472 about llvm-9, do you have an idea what's missing?
[11:41] <GunnarHj> vorlon: Wondering if you noticed bug #1800794. In short we have an Ubuntu specific bug in the dispatcher, since we use an own C program instead of upstream's TCL script. I have talked with cyphermox, and it looks like there is no time/interest to maintain that program today. He also let me know that you were involved in the decision many cycles ago to go that route. The direct question I have is in the latest comment in the
[11:41] <GunnarHj> bug report.
[12:21] <doko> coreycb, cpaelzer: postfix ftbfs in eoan
[12:22] <doko> coreycb, cpaelzer: xen ftbfs in eoan
[12:26] <ahasenack> doko: link for the postfix one?
[12:27] <doko> ahasenack: eoan-proposed
[12:28] <ahasenack> the glibc rebuild
[12:35] <ahasenack> sil2100: hi, there is no test case in https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1756595
[12:35] <cpaelzer> doko: lets tell xen to smb ^^
[12:36] <cpaelzer> IIRC that was sort of bad already last time he checked
[12:36] <cpaelzer> All my involvement in it are my efforts to demote it some day :-)
[12:37] <ahasenack> doko: wrt postfix, http://postfix.1071664.n5.nabble.com/build-failure-with-glibc-2-30-td102511.html
[12:38] <cpaelzer> fixed in 3.5 is a bit late foe Eoan
[12:39] <cpaelzer> ahasenack: do you know (or look for) isolated fixes or do you already know that there are massive reworks that are needed?
[12:39] <ahasenack> cpaelzer: I'm looking for them
[12:39] <ahasenack> 3.5 isn't even released upstream yet
[12:40] <cpaelzer> pff, great
[12:41] <cpaelzer> the discussion read like "why are you so outdated to not be on 3.5" but knowing that 3.5 isn't released yet ....
[12:41] <ahasenack> cpaelzer: doko: it's in here: https://github.com/vdukhovni/postfix/commit/3274c3cea9d739f86e84b65664aabb692e37e83f
[12:42] <ahasenack> https://github.com/vdukhovni/postfix/commit/3274c3cea9d739f86e84b65664aabb692e37e83f#diff-777bfb681a1cd539ddc8e1e606959ffa mor specifically, haven't checked if the other hunks are needed
[12:43] <ahasenack> that is not an official postfix git repo, there isn't one publicly available
[12:43] <ahasenack> this is just Viktor pulling in changes from wherever
[12:43] <ahasenack> I think via tarball snapshots even
[12:43] <ahasenack> that wietse releases periodically
[12:45] <LocutusOfBorg> tjaalton, we are discussing on #debian-llvm right now
[12:45] <LocutusOfBorg> I guess the fix is to use llvm-8
[12:45] <LocutusOfBorg> cpaelzer, would you mind trying virtualbox 5.2.12?
[12:46] <cpaelzer> LocutusOfBorg: I can do that later today (that bug is a private effort of mine)
[12:47] <cpaelzer> LocutusOfBorg: is there a benfit we expect in adding 5.2.12 to that list of known good/bad ?
[12:48] <rbasak> cpaelzer, ahasenack, Skuggen, bryyce: I'm preparing a minor version bump of MySQL 8 in Eoan. That won't cause any issues will it?
[12:48] <cpaelzer> LocutusOfBorg: as we know <=18 good and >=20 bad, do you expect 5.2.12 might be special in that regard?
[12:48] <cpaelzer> rbasak: you will actually trigger the right tests this time
[12:48] <rbasak> That was my thinking.
[12:49] <cpaelzer> rbasak: so you might not cause new problems, but might trigger hidden old ones
[12:49] <rbasak> But I thought I'd check so as not to interfere with any other efforts
[12:49] <cpaelzer> I think this is a case where you could use a bileto ticket
[12:49] <cpaelzer> you would be able to trigger all the same tests without dirsturbing anyone
[12:49] <rbasak> cpaelzer: what would be the benefit of doing that over doing it in the archive?
[12:49] <rbasak> We need to make the bump anyway
[12:50] <cpaelzer> ah ok then
[12:50] <cpaelzer> the benefit for me sometimes is to be able to work on my own crap without entangling my upload with anyone elses
[12:51] <doko> RAOF: there are MIRs missing for mir ...
[12:52] <doko> libxml2.6++
[12:53] <ahasenack> doko: cpaelzer: I'm picking postfix then, if there are no objections
[12:53] <ahasenack> unless someone started it already
[12:54] <cpaelzer> ahasenack: ok for me
[12:54] <cpaelzer> ahasenack: but if you are busy with motd or others let me know and I'll try to give it a shot
[12:54] <ahasenack> k
[12:54] <cpaelzer> I can punt some other things to tomorrow if needed
[12:55] <doko> ahasenack, cpaelzer, coreycb: mecab-ipadic wants to promote, there already is an approved MIR, but no package subscriber
[12:55] <doko> ... for mysql-8.0
[12:55] <cpaelzer> doko: that was mysql
[12:55] <cpaelzer> yeah
[12:55] <cpaelzer> we will sort out the subscription as soon as powersj is online
[12:55] <cpaelzer> and ping you then
[12:55] <cpaelzer> thanks for the reminder doko
[12:56] <cjwatson> Is anyone looking at the MIRs needed for the new version of lintian?
[12:56] <cjwatson> (It blocks the latest man-db for autopkgtest reasons)
[12:56] <cpaelzer> I have not seen any MIRs incoming yet cjwatson
[12:57] <doko> yes, promoted one package, and wrote a pseudo MIR for the others, and pinged cyphermox
[12:57] <cpaelzer> wow, was that just the last few hours doko
[12:57]  * cpaelzer needs to recheck his inbox ...
[12:57] <tjaalton> LocutusOfBorg: well, I'm trying to move to llvm-9..
[12:57] <tjaalton> for debian-experimental, then eoan
[12:57] <tjaalton> it's not super urgent
[12:58] <LocutusOfBorg> cpaelzer, sorry I mean 6.0.12
[12:59] <LocutusOfBorg> and yes, it has some audio related fixes
[13:01] <doko> tjaalton: https://launchpad.net/ubuntu/+source/xorg-server/2:1.20.5+git20190820-0ubuntu2/+build/17524450
[13:01] <cpaelzer> LocutusOfBorg: sure I can try that later then ...
[13:04] <tjaalton> doko: needs fe4cd0e7f5c58fa it seems
[13:04] <tjaalton> and some others
[13:05] <tjaalton> nope, just that
[13:05] <tjaalton> compiler.h: Do not include sys/io.h on ARM with glibc
[13:09] <LocutusOfBorg> tjaalton, sorry I don't really know...
[13:09] <LocutusOfBorg> I hope upstream llvm will figure it out
[13:09] <LocutusOfBorg> I just discovered that the llvm-dev package was 250MB
[13:09] <LocutusOfBorg> so I got worried
[13:13] <tjaalton> yeah I noticed the same
[13:19] <jankoprowski> Hello. I have one question. What are advantages of pbuilder over building in docker image?
[13:28] <doko> Laney, desktop: https://launchpad.net/ubuntu/+source/mozjs60/60.2.3-4build1/+build/17523444 ftbfs
[13:28] <Laney> ok, can you file a bug?
[13:28] <Laney> rls-ee-incoming, it'll get assigned that way
[13:30] <rbasak> jankoprowski: if you want a reproducible build, you're best off using the build system that your distribution uses.
[13:30] <rbasak> Otherwise in edge cases you'll get different behaviour.
[13:30] <rbasak> That's always a risk but you can minimise that by building the same as others.
[13:31] <rbasak> For Ubuntu, that's sbuild rather than pbuilder.
[13:31] <jankoprowski> rbasak I'm compiling rust source code and put binary into deb. Anything I should be aware of?
[13:32] <jankoprowski> rbasak also should I commit "debian" directory into source code?
[13:33] <rbasak> jankoprowski: well those are different questions and I don't have good answers, sorry. This channel is for development of Ubuntu itself. If you want help developing your own non-distribution packages, you're not in the right place. Maybe try askubuntu.com.
[13:34] <jankoprowski> rbasak - Thank you :)  I will try there.
[13:49] <ahasenack> cpaelzer: doko: dep8 green, build green, but the non-intel arches haven't even started to build yet: https://code.launchpad.net/~ahasenack/ubuntu/+source/postfix/+git/postfix/+merge/372342
[13:50] <sil2100> ahasenack: yes, I know - it was something I was in contact with Julian about on Monday, we discussed the fix and he said he'll update the test case in the nearest time
[13:50] <sil2100> Reminded him about it right now
[13:50] <ahasenack> sil2100: thanks
[13:51] <sil2100> I should have left a note regarding that
[14:44] <powersj> cpaelzer, doko ubuntu-server is now subscribed to mecab-ipadic
[14:45] <cpaelzer> thanks powersj
[14:50] <doko> powersj, cpaelzer: promoted
[14:51] <powersj> doko, thanks
[15:05] <cpaelzer> ahasenack: I'll look at the postfix MP between calls
[15:05] <ahasenack> cpaelzer: I got a ping from Scott K. to submit it to debian and he can apply it then, and then we can sync
[15:05] <ahasenack> if that's the only change he will add, then it's fine to sync
[15:05] <cpaelzer> sounds even better
[15:08] <rbasak> bryyce: https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/869017
[15:18] <bryyce> rbasak, ah interesting, screen blanking issues are always fun
[15:20] <bryyce> rbasak, but I think this is a regular video driver bug.  I got a nifty cool 6-output radeon card, and I'm sure it's sufficiently obscure to trip misc. X bugs.
[15:22] <rbasak> ack
[15:22] <rbasak> I didn't realise you were doing X.org things
[17:16] <ahasenack> doko: can you wait a couple of days on the postfix ftbfs fix? Debian is willing to take that patch, even though they don't have that glibc yet, and this would avoid adding a delta to the postfix package
[17:17] <ahasenack> if not, then I can upload ours, and sync from debian later
[17:26] <ddstreet> juliank when you get in, i'd like your opinion on lp #1842947, it seems to me like a potentially serious problem with any native package that carries a 'configure' file
[17:29] <cjwatson> really not a problem with any package.  it'll be specific to dpkg's debian/rules
[17:30] <cjwatson> it's relying on a make target for configure to call autoreconf *shrug*
[17:31] <ddstreet> cjwatson removing that doesn't change anything
[17:31] <cjwatson> I would not expect *removing* it to help!
[17:31] <ddstreet> er, so you mean all native packages with configure files need to have special d/rules entry to make sure configure is recreated?
[17:31] <cjwatson> changing "configure:" to "configure: configure.ac" might help, but really it ought to be rewritten to just use dh_autoreconf
[17:32] <cjwatson> nativeness has nothing to do with anything
[17:32] <ddstreet> cjwatson that won't help either if configure.ac is newer than configure
[17:32] <cjwatson> wrong
[17:32] <ddstreet> make doesn't check timestamps?
[17:32] <cjwatson> dpkg is just using an obsolete style of regenerating configure; there's no need to overgeneralise this
[17:32] <cjwatson> you have it backwards
[17:32] <cjwatson> "configure: configure.ac" means consider configure out of date if configure.ac is newer
[17:33] <ddstreet> cjwatson sorry i meant it backwards - if conjfigure is newer than configure.ac
[17:33] <cjwatson> still, the correct approach would be just to use dh_autoreconf
[17:33] <cjwatson> s/correct/modern/
[17:34] <ddstreet> well that's good, at least it's confined to just dpkg
[17:34] <cjwatson> anything using dh(1) and compat level 10 or above does that automatically; dpkg uses compat level 11 but it calls debhelper commands by hand rather than using dh
[17:35] <ddstreet> cjwatson so dh_autoreconf will call autoreconf -v -i ?
[17:36] <cjwatson> by default it runs autoreconf -f -i.  this is configurable by the package - see dh_autoreconf(1)
[17:36] <ddstreet> aha, perfect, that's one suggestion i put in the bug
[17:36] <ddstreet> use -f
[17:36] <ddstreet> ok i'll just fix dpkg then, hopefully nothing else tries to manually run autoreconf
[17:36] <cjwatson> the problem here isn't lack of -f AFAICS, it's just that autoreconf wasn't being run at all
[17:36] <ddstreet> without -f
[17:37] <ddstreet> er, no, autoreconf without -f won't rebuild configure if it's newer than configure.ac
[17:37] <ddstreet> i just checked
[17:37] <ddstreet> -f is definitely needed
[17:37] <cjwatson> I'm not saying it's not needed, I'm saying that just adding -f doesn't help if autoreconf isn't called :)
[17:38] <ddstreet> well, sure :)
[17:38] <ddstreet> thnx!
[17:38] <cjwatson> (in fact configure and configure.ac have equal mtimes in that dpkg source tarball)
[18:04] <doko> ahasenack: no worry, I was just pointing to the ftbfs in main
[18:04] <ahasenack> ok
[20:11] <teward> does anyone know if there's an ETA on Thunderbird 68 being available in the repositories including for Bionic?  Because *some* update to Thunderbird in Bionic broke the ability for Enigmail to function properly, so I have to run a from-source Thunderbird 68 separately, and it's not kind to do that (because different TBird profiles)
[20:41] <rcj> Could I get an Ubuntu Core dev to sponsor livecd-rootfs uploads for bug #1837254 (livecd-rootfs SRU)?