[03:31] anyone happen to know how grub finds its configuration when booting under uefi? [03:37] there's normally a minimal grub.cfg alongside grubx64.efi in /boot/efi/EFI/ubuntu/ which has enough logic to source the main config from whatever partition has /boot/grub.cfg [04:00] stgraber: thanks, turns out i was not testing the thing i thought i was testing, sigh [05:11] bryyce: rbasak: when the nginx package has been git-ubuntufied can you give me the location to git-ubuntu clone it? [05:11] (thank you!) [05:24] teward, sure. It'll be findable at https://code.launchpad.net/ubuntu/+source/nginx, or just run 'snap install git-ubuntu; git ubuntu clone nginx' [05:27] teward, I finished importing it to git ubuntu today, but need to make sure what remains is accurate, and build/autopkgtest it. [05:32] cool. i have git-ubuntu installed already so i'll just git ubuntu clone it as you indicated. [05:32] and again if there's anything you want me to peek at let me know, there's a few changes also in the works - moving some of the SSL components to a conf.d snippet instead of keeping in nginx.conf (been requested many times) [05:32] s/SSL components/default SSL components/ [05:32] so that's a packaging level change but i'll let the merge happen first :) [05:35] teward, thanks, yeah would be helpful to get your eyes on the result to make sure I haven't messed any important bits up :-) [05:37] teward, btw I noticed debian seems to have some of the php version stuff under /run rather than /var/run, so wondered if that's led to any issues with anyone, or if it's just a theoretical issue [05:45] bryyce: it's more of an issue when we do backports to releases where everything isn't in /run or /var/run or such isn't symlinked to /run or a few other cases - i haven't heard of it causing any issues in Debian so long as the configuration is updated properly to know the different locations. The NGINX PPA has been a direct-from-debian sync since eternity and has not had any issues with /run vs. /var/run so long as the PID config is done [05:45] right. [05:46] but i'll take a look after i wake up [05:46] 01:46 local and last night I didn't sleep well so i need to get to bed heh [05:46] teward, sleep well === pieq__ is now known as pieq [05:49] bryyce: ideally what we're going to do here is match the Ubuntuisms with the configs (php paths, etc.) so if you want to do me a solid and see where php-fpm in Groovy ends up dropping its socket, that'd be great, I *think* it's a /var/run path, but I forget exactly. :P [05:50] i'm also thinking of moving the PHP configs to a snippets/ config snippet for easier inclusion into other configs as well, just as a heads up for future planned ideas/changes that are minor but make things look nicer and easier for end users heh [05:54] teward, that'd be great, thanks [05:55] yeah I can look into what php-fpm does [06:04] bryyce: I don't have upload / push privs it seems, heh. not sure whether that's an issue, but I can just dump merge requests if necessary [06:06] teward, Mp's are fine, that's basically our standard procedure already. afaik push privs are just == core dev [06:06] heh. well i am coredev so xD [06:07] alls good. actually going to sleep now. /off [06:07] night o/ [08:05] do gtk2 apps have the same theme as gtk3 apps in ubuntu 20.04? or is that a known issue? [10:19] rbasak, hey, if you doa SRU shift today could you review the gnome-shell stack in the focal queue? it's waiting for 10 days and including some fixes we would like to see landing [10:20] rbasak, also for an easier one gnutl28/focal would be nice [10:27] rbasak, gnutls28 uploaded to bionic as well, would be nice to also review, it's a simple patch but it should fix connection failing to yahoo/aol/verizon emails servers (following server changes so it used to work and recently stopped working in bionic/focal) [10:55] seb128: sure - if I get to my SRU shift today I'll look at those. [11:13] hi doko, if I'd file a LP bug to get a fix for https://sourceware.org/bugzilla/show_bug.cgi?id=23465 into Bionic is ther any chance this will happen or should I stop right away? [11:13] sourceware.org bug 23465 in gas "wrongly scale non-8-bit x86 displacements" [Normal,Resolved: fixed] [11:13] fnordahl: ^^ FYI [11:14] well I blindly assumed binutils would usually be you doko, let me actually check the changelog ... [11:16] cpaelzer: including the referenced commit in the bug report? [11:19] doko: yeah I guess that is what would need to be backported [11:19] mostly changing the self tests afaics [11:20] I think the effective functional change would just be https://sourceware.org/git/?p=binutils-gdb.git;a=blobdiff;f=gas/config/tc-i386.c;h=b8042ba434207efe9d70c9de9654a2ff110a2c9d;hp=cd69321bdb25f698f7764e5648d10253472724a3;hb=4e518864c879be2e6af4c64415e8775d9a20deaf;hpb=e521dc888158a6cdbdccef0397e663c437450a80 [11:25] cpaelzer: ta for heads up [11:27] sure fnordahl - if doko says it appears to be generally doable I'd file a proper LP bug for it and reply that to the mail [11:27] asking them to chime in on the bug for e.g. testing [11:31] Anyone noticed, that Snap store launcher is untranslated in Applications menu (Activities Overview)? I've registered a bug #1882929 , but no answer from developer in 7 days :( [11:31] bug 1882929 in snap-store "Ubuntu Software (Snap Store) desktop launcher Name isn't translated in Ubuntu 20.04" [Undecided,New] https://launchpad.net/bugs/1882929 [11:33] doko: I'll file a bug as that will be quick - could you state ther eif you consider this doable or not? [11:33] that will also serve as a single place to unite communication on the topic [11:34] doko: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880 it is [11:34] Launchpad bug 1883880 in binutils (Ubuntu Bionic) "fix non-8-bit x86 displacements breaking AVX512 builds on Bionic" [Undecided,New] [11:34] fnordahl: ^^ for you to subscribe to [11:36] rbasak, thanks! [11:55] seb128, doko: hi, I'm starting my day, +1 maintenance for the whole week. I updated the wiki with what I have going on [11:56] ahasenack, ack, thanks, I'm about to start as well, I will check what you put there and update the channel as needed [11:59] ahasenack, seb128: manually cleaned up some NBS binaries in -proposed, now working from the bottom, on ftbfs. lib3mf [11:59] doko: did you happen to see mail-stack-delivery (from dovecot) in those nbs? [11:59] it's not in the report yet, I think because current dovecot (a sync) is an ftbfs [12:00] no [12:00] ok [12:09] one thing I'm noticing with this +1 rotation is that my inbox is getting out of control [12:10] since I'm not focusing on other tasks [12:19] https://github.com/golang/go/issues +5000 issues open [12:19] what chance to I have [12:19] *do [12:20] xnox: about that golang issue from yesterday, should I file a bug upstream with go? I fear a rabbit hole if I keep digging, like starting a matrix of tests with multiple versions of unpatched go (i.e., not from ubuntu, but straight upstream) [12:20] I could file that issue upstream, and upload the yaml.v2 package with that crazy patch of mine with a link to that issue [12:21] that would unblock our migration, and help prometheus to migrate as well I'm told [12:21] doko: do you have an opinion? Do you fancy go? :) [12:21] crazy patch is https://bugs.launchpad.net/ubuntu/+source/golang-yaml.v2/+bug/1883770/comments/4 [12:21] Launchpad bug 1883770 in golang-yaml.v2 (Ubuntu) "Tests fail on s390x and go >= 1.13" [Undecided,New] [12:22] ahasenack: you should ask mwhudson ;p but yes, I think we need a more general solution for all the go packages [12:23] it's the first I see of this, can't say it's affecting others [12:23] mwhudson is many hours away [12:23] I'll file the upstream bug, see how they respond over this week while I'm still on +1 maint [12:23] * ahasenack thinks we need an acronym for "+1 maintenance" [12:25] POM [12:25] When there are two people on rotation, you would therefore have POM POM. [12:25] sounds like PAN PAN [12:25] inside airplane pilots joke === alan_g is now known as alan_g_ [13:39] xnox: I filed https://github.com/golang/go/issues/39651 [14:11] xnox: I also just tried upstream's s390x build and the test fails in the same way, so it doesn't look any of our patches are the culprit [15:06] doko: the upsream people already chimed in on bug 1883880 to help wit ha testcase [15:06] bug 1883880 in binutils (Ubuntu Bionic) "fix non-8-bit x86 displacements breaking AVX512 builds on Bionic" [Undecided,New] https://launchpad.net/bugs/1883880 [15:06] doko: that should make an SRU easier [15:17] LocutusOfBorg: dkms 2.8.2-1ubuntu1 is breaking building dkms builds in our kernel packages, and it looks like the change which breaks us has been reverted upstream - https://github.com/dell/dkms/commit/885f8275aa65fb11be1e17bc28a0b0ea734dc585 [15:17] can we get that reverted in our package too? [15:19] apw: ^ [15:19] utter shit [15:20] oops :) applogies [15:54] ohhhhhhhhhhhhhh [15:54] thansk sforshee [15:54] I was trying hard to find that commit! [15:54] thanks a lot! [15:54] damn, I didn't look at irc :/ [15:56] I have another possibly breaking change, lets see how far we go === ijohnson is now known as ijohnson|afk === ijohnson|afk is now known as ijohnson [19:38] I have a curious go test problem. In a PPA, it fails because it cannot download a certain go module [19:38] but locally in lxd, with network *disabled*, it doesn't try that, and it works [19:38] https://pastebin.ubuntu.com/p/G3FprRXztN/ [19:38] any ideas? [19:38] same package, version, proposed enabled [19:38] ah, wait, I don't have proposed enabled in the lxd container [19:39] sforshee, looks really better now :D [19:40] LocutusOfBorg: great, let me retry these kernel builds and see how it goes [19:47] hm, no change with proposed [19:47] for some reason, locally it doesn't reach out [19:47] I wonder if it's about a controlling terminal during the build, if it behaves differently in each case [19:54] aha! [19:54] it was the terminal [19:54] if I run dpkg-buildpackage -uc -us > ../log 2>&1 [19:54] then it fails locally as well [19:54] sneaky! [19:57] hm, scratch that === nobuto8 is now known as nobuto === xedniv_ is now known as xedniv === CarwynNelson5 is now known as CarwynNelson [20:35] mwhudson: hey, saw you are online [20:35] ahasenack: hi [20:35] mwhudson: if you have an idea, I have this problem: in a ppa, the go test tries to pull in a module from the internet [20:35] but locally (lxd), it doesn't: https://pastebin.ubuntu.com/p/G3FprRXztN/ === balloons7 is now known as balloons [20:35] https://launchpad.net/ubuntu/+source/golang-github-fsouza-go-dockerclient/1.6.5-1/+build/19442767 is the package/build in question [20:36] and locally I tried without a network (used lxc exec to enter the container, and disabled eth0) [20:36] does the package depend on golang-golang-x-crypto-dev? [20:37] but hm yeah that's strange [20:38] mwhudson: no, we don't even have that package [20:38] oh i bet golang-github-docker-docker-dev depends on golang-golang-x-crypto-dev in debian but not ubuntu [20:39] mwhudson: looks like it was added by http://paste.ubuntu.com/p/23vMxTBWCV/ once upon a time, and upstream took it [20:39] mwhudson: oh, so golang-golang-x-crypto-dev provides that ssh/terminal bit? [20:39] yes [20:39] but still wouldn't explain why it works locally [20:40] that's true that is strange [20:40] hm, so I have that installed [20:40] but the builder log doesn't show it being installed [20:40] I'll investigate that [20:41] mwhudson: indeed, the debian build log shows golang-golang-x-crypto-dev being installed [20:41] ours doesn't [20:41] interesting [20:41] mwhudson: I have enough to go on now, many thanks [20:41] ahasenack: it'll be related to the golang-docker-*-dev stuff === smoser1 is now known as smoser [20:43] in any case, if the package imports it directly, it should be in b-d, iow that debian patch should have come with a change to control as well [20:44] mwhudson: check out this fun golang bug I filed today, btw: https://github.com/golang/go/issues/39651 [20:44] ahasenack: mundaym is pretty good at fixing this kind of stuff [20:48] ahasenack: did you try 1.15beta1 fwiw? it's available as a snap now [20:48] mwhudson: I noticed he is from ibm, and he mentioned he fixed a similar bug in the past [20:49] mwhudson: I didn't, I just tried the upstream binary tarball for s390x, I saw they had one [20:49] ahasenack: yeah, he did the s390x port [20:49] ahasenack: https://dl.google.com/go/go1.15beta1.linux-s390x.tar.gz is a thing too, might be worth a try if you have an environment set up [20:49] oh, I do [20:49] let me fetch that [20:55] mwhudson: 1.15b1 failed the same way [20:55] ahasenack: ah well [20:55] worth a try [20:56] leave it to the ibm elves then :) [20:56] hehe [20:56] (unless you want to start staring at disassembly) [20:59] mwhudson: there is a shocking diff between the Depends of golang-github-docker-docker-dev in debian and ubuntu: https://pastebin.ubuntu.com/p/9d8XmsfGqT/ [20:59] we have all that stuff vendorized? [20:59] ahasenack: ah hah um yeah [20:59] i don't know, tbh [21:04] we don't use dh-golang to build [21:05] and debian declares a *lot* of manual Depends packages [21:05] ok, something for later [21:05] let me fix this build [21:46] mwhudson: https://code.launchpad.net/~ahasenack/ubuntu/+source/golang-github-fsouza-go-dockerclient/+git/golang-github-fsouza-go-dockerclient/+merge/385957 [21:47] confirmed fixed in https://launchpad.net/~ahasenack/+archive/ubuntu/fsouza/+packages [21:47] ahasenack: +1 [21:47] mwhudson: can you do a quick +1 in the mp? [21:49] ahasenack: we have outofsync containerd/docker-dev stuff between debian and ubuntu [21:49] ahasenack: i think we are newer, and that's causing divergence in the build-depends. [21:49] mwhudson: awesome, thanks [21:49] because stuff got reorged [21:49] xnox: it's quite the divergence [21:49] I filed a bug to investigate that [21:50] https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1883978 [21:50] Launchpad bug 1883978 in docker.io (Ubuntu) "Possibly missing dependencies in golang-github-docker-docker-dev" [Undecided,New] [21:50] xnox: it was a difference in depends, not just build-depends [21:50] haven't checked b-d [21:50] also the debian maintainer has a king sized pair of jfdi boots [21:53] it's weird to have golang.*-dev packages as depends [22:01] rbalint: doko: osomon: seb128: hello fellow +1maintainers for tomorrow (18th), I kept my wiki entry up-to-date under the "Progress" title [22:02] * ahasenack -> EOD [22:08] ahasenack: nice find