[11:30] 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:30] Debian bug 939472 in llvm-9-dev "libclangCodeGen.a: error adding symbols: archive has no index" [Normal,Open] === ricab is now known as ricab|lunch [11:41] 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] bug report. [11:41] bug 1800794 in usb-modeswitch (Ubuntu) "usb-modeswitch can't apply Configuration=0 to Snapdragon X12 LTE" [Medium,In progress] https://launchpad.net/bugs/1800794 [12:21] coreycb, cpaelzer: postfix ftbfs in eoan [12:22] coreycb, cpaelzer: xen ftbfs in eoan [12:26] doko: link for the postfix one? [12:27] ahasenack: eoan-proposed [12:28] the glibc rebuild [12:35] sil2100: hi, there is no test case in https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1756595 [12:35] Launchpad bug 1756595 in apport (Ubuntu Disco) "disk space info inadvertently provides all installed snaps" [Undecided,New] [12:35] doko: lets tell xen to smb ^^ [12:36] IIRC that was sort of bad already last time he checked [12:36] All my involvement in it are my efforts to demote it some day :-) [12:37] doko: wrt postfix, http://postfix.1071664.n5.nabble.com/build-failure-with-glibc-2-30-td102511.html [12:38] fixed in 3.5 is a bit late foe Eoan [12:39] ahasenack: do you know (or look for) isolated fixes or do you already know that there are massive reworks that are needed? [12:39] cpaelzer: I'm looking for them [12:39] 3.5 isn't even released upstream yet [12:40] pff, great [12:41] 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] cpaelzer: doko: it's in here: https://github.com/vdukhovni/postfix/commit/3274c3cea9d739f86e84b65664aabb692e37e83f [12:42] https://github.com/vdukhovni/postfix/commit/3274c3cea9d739f86e84b65664aabb692e37e83f#diff-777bfb681a1cd539ddc8e1e606959ffa mor specifically, haven't checked if the other hunks are needed [12:43] that is not an official postfix git repo, there isn't one publicly available [12:43] this is just Viktor pulling in changes from wherever [12:43] I think via tarball snapshots even [12:43] that wietse releases periodically [12:45] tjaalton, we are discussing on #debian-llvm right now [12:45] I guess the fix is to use llvm-8 [12:45] cpaelzer, would you mind trying virtualbox 5.2.12? [12:46] LocutusOfBorg: I can do that later today (that bug is a private effort of mine) [12:47] LocutusOfBorg: is there a benfit we expect in adding 5.2.12 to that list of known good/bad ? [12:48] 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] LocutusOfBorg: as we know <=18 good and >=20 bad, do you expect 5.2.12 might be special in that regard? [12:48] rbasak: you will actually trigger the right tests this time [12:48] That was my thinking. [12:49] rbasak: so you might not cause new problems, but might trigger hidden old ones [12:49] But I thought I'd check so as not to interfere with any other efforts [12:49] I think this is a case where you could use a bileto ticket [12:49] you would be able to trigger all the same tests without dirsturbing anyone [12:49] cpaelzer: what would be the benefit of doing that over doing it in the archive? [12:49] We need to make the bump anyway [12:50] ah ok then [12:50] the benefit for me sometimes is to be able to work on my own crap without entangling my upload with anyone elses [12:51] RAOF: there are MIRs missing for mir ... [12:52] libxml2.6++ === ricab|lunch is now known as ricab [12:53] doko: cpaelzer: I'm picking postfix then, if there are no objections [12:53] unless someone started it already [12:54] ahasenack: ok for me [12:54] ahasenack: but if you are busy with motd or others let me know and I'll try to give it a shot [12:54] k [12:54] I can punt some other things to tomorrow if needed [12:55] ahasenack, cpaelzer, coreycb: mecab-ipadic wants to promote, there already is an approved MIR, but no package subscriber [12:55] ... for mysql-8.0 [12:55] doko: that was mysql [12:55] yeah [12:55] we will sort out the subscription as soon as powersj is online [12:55] and ping you then [12:55] thanks for the reminder doko [12:56] Is anyone looking at the MIRs needed for the new version of lintian? [12:56] (It blocks the latest man-db for autopkgtest reasons) [12:56] I have not seen any MIRs incoming yet cjwatson [12:57] yes, promoted one package, and wrote a pseudo MIR for the others, and pinged cyphermox [12:57] wow, was that just the last few hours doko [12:57] * cpaelzer needs to recheck his inbox ... [12:57] LocutusOfBorg: well, I'm trying to move to llvm-9.. [12:57] for debian-experimental, then eoan [12:57] it's not super urgent [12:58] cpaelzer, sorry I mean 6.0.12 [12:59] and yes, it has some audio related fixes [13:01] tjaalton: https://launchpad.net/ubuntu/+source/xorg-server/2:1.20.5+git20190820-0ubuntu2/+build/17524450 [13:01] LocutusOfBorg: sure I can try that later then ... [13:04] doko: needs fe4cd0e7f5c58fa it seems [13:04] and some others [13:05] nope, just that [13:05] compiler.h: Do not include sys/io.h on ARM with glibc [13:09] tjaalton, sorry I don't really know... [13:09] I hope upstream llvm will figure it out [13:09] I just discovered that the llvm-dev package was 250MB [13:09] so I got worried [13:13] yeah I noticed the same [13:19] Hello. I have one question. What are advantages of pbuilder over building in docker image? [13:28] Laney, desktop: https://launchpad.net/ubuntu/+source/mozjs60/60.2.3-4build1/+build/17523444 ftbfs [13:28] ok, can you file a bug? [13:28] rls-ee-incoming, it'll get assigned that way [13:30] jankoprowski: if you want a reproducible build, you're best off using the build system that your distribution uses. [13:30] Otherwise in edge cases you'll get different behaviour. [13:30] That's always a risk but you can minimise that by building the same as others. [13:31] For Ubuntu, that's sbuild rather than pbuilder. [13:31] rbasak I'm compiling rust source code and put binary into deb. Anything I should be aware of? [13:32] rbasak also should I commit "debian" directory into source code? [13:33] 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] rbasak - Thank you :) I will try there. [13:49] 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] 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] Reminded him about it right now [13:50] sil2100: thanks [13:51] I should have left a note regarding that === vicamo_ is now known as vicamo [14:44] cpaelzer, doko ubuntu-server is now subscribed to mecab-ipadic [14:45] thanks powersj [14:50] powersj, cpaelzer: promoted [14:51] doko, thanks [15:05] ahasenack: I'll look at the postfix MP between calls [15:05] 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] if that's the only change he will add, then it's fine to sync [15:05] sounds even better [15:08] bryyce: https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/869017 [15:08] Launchpad bug 869017 in linux (Ubuntu Zesty) "Ubuntu server enables screenblanking, concealing crashdumps (DPMS is not used)" [Undecided,Fix released] [15:18] rbasak, ah interesting, screen blanking issues are always fun [15:20] 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] ack [15:22] I didn't realise you were doing X.org things [17:16] 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] if not, then I can upload ours, and sync from debian later [17:26] 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:26] Launchpad bug 1842947 in dpkg (Ubuntu) "dpkg 1.19.0.5ubuntu2.2 build did not recreate 'configure' file, losing changes in 'configure.ac'" [Undecided,New] https://launchpad.net/bugs/1842947 [17:29] really not a problem with any package. it'll be specific to dpkg's debian/rules [17:30] it's relying on a make target for configure to call autoreconf *shrug* [17:31] cjwatson removing that doesn't change anything [17:31] I would not expect *removing* it to help! [17:31] 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] changing "configure:" to "configure: configure.ac" might help, but really it ought to be rewritten to just use dh_autoreconf [17:32] nativeness has nothing to do with anything [17:32] cjwatson that won't help either if configure.ac is newer than configure [17:32] wrong [17:32] make doesn't check timestamps? [17:32] dpkg is just using an obsolete style of regenerating configure; there's no need to overgeneralise this [17:32] you have it backwards [17:32] "configure: configure.ac" means consider configure out of date if configure.ac is newer [17:33] cjwatson sorry i meant it backwards - if conjfigure is newer than configure.ac [17:33] still, the correct approach would be just to use dh_autoreconf [17:33] s/correct/modern/ [17:34] well that's good, at least it's confined to just dpkg [17:34] 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] cjwatson so dh_autoreconf will call autoreconf -v -i ? [17:36] by default it runs autoreconf -f -i. this is configurable by the package - see dh_autoreconf(1) [17:36] aha, perfect, that's one suggestion i put in the bug [17:36] use -f [17:36] ok i'll just fix dpkg then, hopefully nothing else tries to manually run autoreconf [17:36] the problem here isn't lack of -f AFAICS, it's just that autoreconf wasn't being run at all [17:36] without -f [17:37] er, no, autoreconf without -f won't rebuild configure if it's newer than configure.ac [17:37] i just checked [17:37] -f is definitely needed [17:37] 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] well, sure :) [17:38] thnx! [17:38] (in fact configure and configure.ac have equal mtimes in that dpkg source tarball) [18:04] ahasenack: no worry, I was just pointing to the ftbfs in main [18:04] ok [20:11] 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] Could I get an Ubuntu Core dev to sponsor livecd-rootfs uploads for bug #1837254 (livecd-rootfs SRU)? [20:41] bug 1837254 in livecd-rootfs (Ubuntu Disco) "ubuntu-cpc parallel builds produce unused files" [Undecided,New] https://launchpad.net/bugs/1837254