[12:21] <oSoMoN> I spent some time looking into the node-sha.js autopkgtest failures on ppc64el, which (along with other test failures in various node-* packages) prevent the migration of nodejs
[12:21] <oSoMoN> it turns out it's a nasty bug in V8 that incorrectly optimizes a function on ppc64el only (https://github.com/nodejs/node/issues/34666)
[12:22] <oSoMoN> this requires further investigation upstream, and I'm not sure what the best approach would be to get this moving forward in Ubuntu
[12:22] <oSoMoN> (nodejs in turns is blocking firefox and thunderbird)
[12:22] <oSoMoN> s/turns/turn/
[12:23] <oSoMoN> suggestions welcome
[12:27] <seb128> oSoMoN, would building with a lower -O workaround the optimization problem?
[12:32] <oSoMoN> seb128, I don't know, I'm not familiar with how V8 optimizes code, but I can certainly try
[12:33] <seb128> oSoMoN, I'm just random suggesting, let's see if maybe doko or xnox can help there
[12:36] <icey> oSoMoN: feel free to ignore me but I'm kind of a fan of the minimal `eval('')` patch you mention in the bug report
[12:37] <oSoMoN> icey, that would just hide one symptom of the problem, but V8 would potentially incorrectly optimize other functions in other packages
[12:37] <icey> fair enough
[13:54] <oSoMoN> sil2100, hey, I just commented on bug #1889106, if you're still around and have some time for it, would you mind accepting chromium-browser 84.0.4147.105-0ubuntu0.20.04.1 into focal-proposed?
[13:55] <oSoMoN> that would fix the deb->snap upgrade path for users upgrading from bionic to focal
[13:59] <ahasenack> seb128: I have a merge ready for gnunet, but the my_bool change is still needed
[13:59] <ahasenack> I opened a bug upstream this time
[13:59] <ahasenack> that's our only delta
[14:05] <seb128> ahasenack, right, thank you!
[14:05] <ahasenack> seb128: it doesn't have dep8 tests, and I really don't know much about the pkg
[14:06] <ahasenack> seb128: was it blocking/breaking something else, something I could test with this new version?
[14:06] <ahasenack> otherwise, I'll jut get a quick review and upload
[14:07] <seb128> ahasenack, something was depwaiting on it on the proposed report but I forgot what ... the delta is minimal and that could be an autosynced update, I would trust Debian and not spent too much effort trying to test it
[14:08] <ahasenack> ok
[14:08] <ahasenack> I just got a build failure, taking a quick look
[14:08] <ahasenack> might be gcc10 fun
[14:09] <ahasenack> seb128: ah, gnunet-fuse perhaps
[14:09] <ahasenack> and all the other gnunet-* src packages looks like
[14:09] <ahasenack> which are syncs
[14:10] <seb128> ahasenack, right
[14:10] <ahasenack> ok, I ll handle it
[14:27] <ahasenack> ok, ftbfs resolved
[16:18] <Pinchiukas> Are the pipelines that build images for vagrant, etc public? As I understand, people in ubuntu build them.
[17:08] <ahasenack> vorlon: hi, good morning/afternoon. While reviewing the base-files changes regarding motd-news-config, cpaelzer came across one case which we are wondering if it's worth addressing
[17:08] <ahasenack> vorlon: basically the scenario is you have the current base-files and ubuntu-server installed, and the user removes /etc/default/motd-news (instead of editing it)
[17:09] <ahasenack> in that scenario, when you do the upgrade, /etc/default/motd-news is reinstalled when the new motd-news-config package is installed
[17:09] <ahasenack> you start with base-files/ubuntu-server, upgrade, and end up with base-files, ubuntu-server, and motd-news-config, as expected. But with the config file back, as it's now part of motd-news-config, and before, when the user removed it, it was part of base-files
[17:09] <ahasenack> is this worth addressing? If yes, how?
[17:10] <ahasenack> his comment, for reference: https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/388835/comments/1022645
[20:04] <Pinchiukas> Anyone?
[21:54] <xnox> ahasenack: I think it's impossible to migrate conffile between packages.
[21:54] <ahasenack> I'm doing it for the case of a modified conf file, when there is a backup
[21:54] <ahasenack> but a removed one... that's another story
[21:54] <xnox> ahasenack: at most you can check if the file doesn't exist in preinst and re-remove it.
[21:55] <xnox> ahasenack: backups and modified ones, also hard.