[04:46] <xnox> kanashiro:  so are you actively fixing FTBFS and autopkgtest failures to get ruby2.7 transition to actually migrate?
[04:46] <xnox> kanashiro:  do you have a fix for vim FTBFS on arm64?
[04:46] <xnox> or rafaeldtinoco?
[08:09] <bdmurray> marcustomlinson: I'm still seeing apport bugs being modified
[08:09] <marcustomlinson> bdmurray: I'm just responding to people
[08:09] <marcustomlinson> if you'd like to handle that
[08:10] <bdmurray> bug 1491128 was recently set to Invalid
[08:11] <marcustomlinson> yeah I thought the guy deserved a response
[08:12] <bdmurray> and bug 772336?
[08:12] <marcustomlinson> that was 19 hours ago
[08:12] <marcustomlinson> before we spoke
[08:13] <bdmurray> weird, I just got the mail
[08:13] <bdmurray> well that'll be exciting I wonder how much more mail is coming
[11:17] <rbalint> bryce, if you run login just to show motd in lxc you may find show-motd interesting: https://twitter.com/balintreczey/status/1209270160479133696
[11:17] <rbalint> bryce, it is available from eoan and up
[11:25] <kanashiro> xnox, re ruby2.7 transition: yes, I am actively working on the regressions to make it migrate. And no, I didn't investigate vim FTBFS on arm64 yet
[11:40] <LocutusOfBorg> kanashiro, after the mass retries the situation looks better on update_excuses page
[11:42] <kanashiro> LocutusOfBorg, yes, I just saw that (and thanks for that), I am already working on patches to fix the remaining regressions
[12:07] <LocutusOfBorg> thanks!
[12:38] <xnox> kanashiro:  with either swig3.0 or swig4.0 subversion surby bindings fail to build, it looks like something is using assert() yet subversion compiles with -DNDEBUG somehwere, meaning assert() is not linked in the relevant .so objects
[12:42] <kanashiro> xnox, right, I saw this assert error while I was trying to investigate the FTBFS
[12:47] <xnox> kanashiro:  which might be coming from python3.8!
[12:48] <ahasenack> subtitle for focal fossa: the entangled release
[13:40] <gsedej> hi! Where can one report bugs in 20.04 installer?
[13:42] <rbasak> gsedej: thank you for testing! Which installer? Desktop? Server?
[13:43] <gsedej> desktop. should i ask in #ubuntu+1 or #ubuntu-bugs?
[13:44] <rbasak> gsedej: yes please, if you have further questions. I think the answer to your question though is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+filebug
[13:47] <gsedej> rbasak, thank you
[13:59] <LocutusOfBorg> kanashiro, xnox I retried vim/arm64, lets see what happens, maybe it was an error due to some entangling?
[14:01] <LocutusOfBorg> btw nice to see how new icu fails with #include<libxml> stuff if extern "C" is defined
[14:01] <LocutusOfBorg> doko ^^, http://launchpadlibrarian.net/467947562/scilab_6.1.0+dfsg1-1ubuntu2_6.1.0+dfsg1-1ubuntu3.diff.gz
[14:01] <LocutusOfBorg> not sure if this is intended
[14:01] <LocutusOfBorg> lots of /usr/include/unicode/ucnv.h:585:1: error: conflicting declaration of C function ‘void icu_66::swap(icu_66::LocalUConverterPointer&, icu_66::LocalUConverterPointer&)’
[14:01] <LocutusOfBorg> and similar
[15:32] <LocutusOfBorg> (vim was good on the first retry)
[15:32] <LocutusOfBorg> xnox, kanashiro ^^
[15:36] <kanashiro> LocutusOfBorg, yay \o/
[17:42] <ahasenack> infinity: around? It's about that glibc bug https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1864864
[18:20] <blackboxsw> rbasak: or others with gitfu skillz:    I've landed a commit in tip of master of the cloud-init that got attributed to the wrong author (me). Is there a sane way to ammend that author and/or commit message that doesn't risk breaking consumers of tip or master?
[18:22] <blackboxsw> I know that git ammend will generate a new commitish for that commit... and that could cause problems where consumers may have to rebase (since we know of at least 2 vendors that run CI on our master branch, I'd be a bit concerned that this could impact their automation)
[18:23] <blackboxsw> smoser: it's worth highlighting you too on this ^. Maybe it's not worth the trouble to fix this case?
[18:26] <smoser> i don't think you can. i'd not bother.  I think there is another commit in cloud-init that has my attribution. I just apologized.
[18:26] <smoser> humans suck
[18:30] <blackboxsw> yeah, stinks, strange as it came in via a squash merge button press in github UI. not really sure how that happened in this case.
[18:30] <blackboxsw> ahh well, will be more careful in the future.
[18:45] <doko> LocutusOfBorg: we fixed that for 65 as well, nothing new. there is a surplus extern "C" iirc
[19:39] <mwhudson> blackboxsw: i think github turned that feature off again
[21:58] <xnox> ahasenack:  thank you for doing this!
[22:02] <xnox> ahasenack:  please upload into bionic unapproved queue.
[22:32] <bryce> One of the last php packages I'm trying to troubleshoot is uwsgi-plugin-php
[22:32] <bryce> https://launchpadlibrarian.net/467781450/buildlog_ubuntu-focal-s390x.uwsgi-plugin-php_0.0.4build1_BUILDING.txt.gz
[22:32] <bryce> it's ftbfs running the command `uwsgi --build-plugin /usr/src/uwsgi/plugins/php` which exits 1
[22:33] <bryce> running it with -v, the error it gives is:
[22:33] <bryce>   unable to load configuration from /usr/src/uwsgi/plugins/php
[22:33] <bryce> this appears to work fine in Debian, per kanashiro
[22:33] <bryce> I'm not sure what to do to get this to build
[22:34] <bryce> I'm able to reproduce the error locally (as is kanashiro).
[22:34] <bryce> one of the things that's unusual for uwsgi-plugin-php is that its source code is in a different package, uwsgi-src.
[22:35] <bryce> I plan to look at it more next week, but meanwhile any tips/advice/pointers would be appreciated.
[23:23] <rbasak> blackboxsw: you can leave a note as a correction
[23:24] <rbasak> See git-notes(1)
[23:24] <rbasak> But if you don't want to change the commit hash (you're right in doing that; that's inappropriate in a public master branch) then that's the most you can do I think
[23:26] <blackboxsw> thanks rbasak!