[03:01] where did libburnia upstream go? [03:03] oh the git bits are still around [06:23] is there any way I can re-poke something that's marked ftbfs in proposed (Groovy)? It failed yesterday but I think it's not an issue with my package (Depends: python3 (>= 3.8.3-1~) but 3.8.2-0ubuntu2 is to be installed) [06:39] icey: what package? If you have upload rights, there will be a retry button on the build [06:41] RikMills: I don't have upload rights, https://launchpad.net/ubuntu/+source/python-os-traits/2.4.0-0ubuntu1/ is the package that failed to build [06:42] RikMills: I do suppose I'll be working to get upload rights for the OpenStack packages sometime soon [06:43] icey: ok. that is in main, so I can't do it. so you need a core dev to poke, unless as you say it in another set [06:44] FYI the reason for that dep wait 'should' be fixed [06:45] RikMills: yeah - I can't reproduce the failure locally this morning, and I heard some conversation about it yesterday :) [06:49] jibel: this is still happening with ubiquity 20.10.8 https://i.imgur.com/4LTUds6.png [06:51] icey: looks like it got poked ;) thanks LocutusOfBorg [06:55] thanks LocutusOfBorg [06:55] and RikMills: Where are you seeing who poked it? [06:56] icey: You can't, which is a lack in launchpad. I know because I asked in another chat if someone could poke [06:57] RikMills, yeah, I saw the comment on the bug report. [06:57] looking at Mate now [06:58] jibel: thanks. obviously I confirmed in a VM from that screenshot [06:58] RikMills: well, now I'm wondering where else I should be :-D [06:59] RikMills: any chance you could ask about getting neutron-vpnaas poked as well, seems to be the same failure :) [06:59] * icey goes back to hiding in the corner [07:00] It's a pretty fun place to be, lurking the corner in the shadows. :3 [07:00] :-D [07:00] icey: here is just fine. it was a not public telegram thing. there are plenty of core devs in here, but IRC lacks being able to see who is online (or recently so) [07:01] RikMills: indeed it does lack that :) [07:03] icey, done [07:03] thanks again LocutusOfBorg [07:04] Closest you have is /wii $name, which shows you idle time. [07:04] I'm also mass retrying the last 69 packages in excuses age === Wryhder is now known as Lucas_Gray [11:10] trying to bisect make but shit this is though [11:10] There's all sorts of weird incarnations you have to do to bootstrap the build environment [11:10] e.g. po/ is empty [11:10] and then it complains about missing .po files [11:11] And doing this over SSH in a cloud on a different continent is not exactly fun [11:11] Doesn't ./bootstrap do the job? [11:12] cjwatson: In 4.3, yes, if you have git:// access [11:12] cjwatson: It's not there in 4.2, and I'm bisecting between those two [11:13] Ah [11:13] Now it's trying to rsync from translationproject.org - ugh [11:13] this ain't going to work [11:13] I can only do http* [11:14] If I do make make, it does nice things but ultimately fails with [11:14] /usr/bin/ld: /tmp/make/glob/glob.c:1342: undefined reference to `__alloca' [11:14] why can't people have decent build systems? [11:42] it's done [11:43] xnox: So, I finished bisecting make on s390x for the flatpak-builder/s390x issue. The cause of the issue was a change to make it use posix_spawn() instead of fork()/exec(). [11:44] xnox: I'm not sure if there's an issue with posix_spawn() on s390x, or make's use of it, but I did upload a make 4.3-4ubuntu1 that passes --disable-posix-spawn to configure to make it work again [11:44] I also forwarded that change to Debian [11:45] This is the offending commit: https://paste.ubuntu.com/p/tYhbJFKN76/ [11:47] Maybe there's undefined behavior in there and we compile s390x at -O3, could also be the reason, who knows [11:47] debian doesn't test s390x [11:47] debian bug 964541 [11:47] Debian bug 964541 in make-dfsg "make: Regression on s390x, echo EPERM, caused by posix_spawn change" [Serious,Open] http://bugs.debian.org/964541 [11:56] juliank: we should be compiling s390x at -O2, we only use -O3 for ppc64el by default [11:56] xnox: ah ok [11:57] juliank: is there a launchpad bug about this too? we could try to escalate it to IBM [11:57] xnox: I don't think so [11:57] juliank: ok, i can open a new one. [12:00] * xnox learns word heisenbug === tinwood is now known as tinwood-afk === tinwood-afk is now known as tinwood [14:22] bah, I don't understand the util-linux build failure in groovy :( [14:22] debian/bsdextrautils.install has [14:23] +#!/usr/bin/dh-exec --with=install [14:23] +usr/bin/write => usr/bin/write.ul [14:23] (well, that's the diff, the actual file doesn't have the +) [14:23] and the build fails on [14:23] dh_install: warning: Cannot find (any matches for) "=>" (tried in ., debian/tmp) [14:23] debian/tmp/usr/bin/write does exist [14:24] and the same .install / rules work in Debian (unless I overlooked a diff/change) [14:27] hum, it's just the error being misleading [14:29] Silly question, but I presume that install file has +x? [14:31] I haven't seen --with=install in the sheban line before [14:33] Unit193, not silly at all, thanks a lot for pointing that out [14:33] was that it? [14:34] TELL US WHAT IT WAS!!! [14:34] WE WANT TO KNOW!!! [14:35] lol [14:35] Uh oh, someone appears to have made mdeslaur's coffee too strong. [14:35] build is ongoing, ut it was missing a +x yes [14:35] Happy to have been of help. [14:36] Unit193: perhaps I didn't put enough rum in it [14:36] will teach me to merge by just applying the debdiff :p [14:37] If the diff is generated correctly (eg, git) `patch` can understand to set the correct permissions. [14:38] right, well it wasn't in this case because I wrongly assumed it was a simple diff and doing complicated things wasn't needed :p [14:38] the error is really unhelpful though [14:38] 'dh_install: warning: Cannot find (any matches for) "=>" (tried in ., debian/tmp)' [14:38] it doesn't even tell you the item it tries to match [14:39] It tried to install, literally, '=>' [14:39] not to mention the permission, feels like something could warn about a dh-exec script not being +x [14:46] ahasenack, but yeah, that was the issue :/ [14:46] good to know [14:47] indeed [14:47] Unit193, thank you again! [14:47] Sure thing. [14:47] it's in the same category of weird errors when you try to run a shell script what has windows line endings [14:49] right, 'fun ones" :) [14:50] Or the error when pkg-config is missingg.. === Eighth_Doctor is now known as Conan_Kudo === Conan_Kudo is now known as Eighth_Doctor [17:34] How does one build the various artifacts listed here? https://releases.ubuntu.com/20.04/ [18:58] realtime-neil: I think this is the starting point https://code.launchpad.net/ubuntu-cdimage [18:59] sarnold: much thanks [20:09] it's pretty hard to get going on your own machine unfortunately [20:23] hi +1 maintenance team, I'm looking over the nginx and python-certbot/python-acme migrations [20:23] is there a highlight word for this team, btw? [21:00] I'm noticing a larger than usual delay between a dep8 run disappearing from the /running url, and its result showing up in autopkgtest.u.c, anyone else wondering? [21:00] so much that earlier today I kicked another run, thinking "didn't I trigger this before?", and an hour later both results came back [21:01] specifically, I'm waiting for a result on http://autopkgtest.ubuntu.com/packages/p/python-certbot-apache/groovy/armhf [21:16] vorlon: should we seed shim-signed and grub-pc on all bootable amd64 images? some flavours currently end up with grub-efi-amd64 to satisfy shim-signed's alternate dep and then install fails