[04:18] <Skuggen> rafaeldtinoco: Oh lord. We've had test bugs like that before, too :D
[04:18] <rafaeldtinoco> Skuggen: lol
[04:18] <Skuggen> Thanks for looking into it!
[04:18] <rafaeldtinoco> it was written since 2007 =)
[04:19] <rafaeldtinoco> sure! , im investigating other bug and will propose a merge
[04:20] <Skuggen> Thanks. We've fixed bugs like that by setting the event to be something like now()+1day instead of a set date, though I don't remember the exact syntax
[04:20] <rafaeldtinoco> ah, yep its not in github yet
[04:20] <rafaeldtinoco> i made a delta to 2025 until 8.0.20 is released
[04:20] <rafaeldtinoco> i mean, not yet, made it locally to pass the test =)
[04:21] <rafaeldtinoco> just added you to the LP bug
[04:21] <Skuggen> Yeah, that's fine. We can add that as a patch in salsa, since it's just until it's fixed upstream, anyway
[06:11] <cpaelzer> a build taking 13h looks wrong
[06:12] <cpaelzer> even if it would have taken so long timeouts would have kicked in right?
[06:12] <cpaelzer> https://launchpad.net/ubuntu/+source/dpdk/19.11-2ubuntu1/+build/18539704
[06:12] <cpaelzer> I could cancel and start again - but in the current state it might be debuggable ... ?
[06:14] <cpaelzer> the same in a ppa buid multiple times without that https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3881/+build/18538702
[06:34] <cpaelzer> can't find anything useful, restarting to get things moving again :-/
[06:40] <cpaelzer> hmm, cancelling this seems just as stuck as formerly completing it was ...
[06:53] <cpaelzer> still hanging on "cancelling build" after 20 minutes ...
[06:54] <cpaelzer> cjwatson: wgrant: Laney: anything comes to your mind to get this unstuck ^^ ?
[06:54] <cpaelzer> cjwatson: that might also be related to the autopkgtest you mentioned in #ubuntu-release
[08:23] <cpaelzer> fyi dpdk arm64 build still stuck at cancelling
[08:23] <cpaelzer> and as I'd assume withotu all builds it is not yet showing up in the new queue
[08:23] <cpaelzer> jamespage: ^^ FYI why things take a while ... sorry
[09:09] <jamespage> cpaelzer: np - I have a ceph resync/merge I'm working on until that's all cleared
[09:10] <jamespage> doko: once cpaelzer's DPDK uploads have cleared the new queue for focal I have a source project split openvswitch -> openvswitch + ovn to upload - would you have cycles to look at the new source package and binaries for ovn?
[10:07] <cjwatson> cpaelzer: don't cancel builds in that sort of situation please
[10:07] <cjwatson> if anything it makes things worse
[10:11] <cpaelzer> cjwatson: how should I have known that the cancel hangs as much as the build
[10:11] <cpaelzer> cjwatson: and as you see between starting to look at it (discuss here) and the cancel was about an hour
[10:12] <cpaelzer> so I wasn't trigger-happy on cancel, but I found nothing else that could help and was here in the wrong time where everyone else was still asleep :-)
[10:12] <cpaelzer> but I can clearly remember this particular case and not cancel it next time
[10:13] <cpaelzer> I see it was resolved now and became a correctly-cancelled build that I was able to retry
[10:13] <cpaelzer> lets see how it behaves this time
[10:14] <cpaelzer> ok, it was half an hour in IRC log - but also I looked at it before I asked here ... :-)
[10:22] <cjwatson> cpaelzer: if you see a "buildlog" link (not the build log tail, but literally a "buildlog" link), then the build has already completed on the builder side and cancelling it will do nothing useful
[10:22] <cjwatson> if you leave it alone then it will finish eventually (possibly via buildd-manager restarts).  if you cancel it then you might have to run the whole build again
=== seb128_ is now known as seb128
[11:42] <tseliot> xnox, hi, any thoughts on this? https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/1854985
[11:42] <ubottu> Launchpad bug 1854985 in pm-utils (Ubuntu) "pm-utils overrides runtime power management mode for audio devices" [High,Triaged]
[11:46] <doko> jamespage: ok, I'll try
[11:51] <jamespage> doko: thanks
[12:01] <seb128> vorlon, hey, so I'm unsure what to do about network-manager/i386, network-manager-config-connectivity-ubuntu (and -debian) which is arch all depends on network-manager, changing to be architecture any sounds wrong, wdyt?
[12:08] <cpaelzer> cjwatson: that hint with the buildlog is great, that seems like a clear "if A, then B" thanks!
[12:13] <doko> jbicha, seb128: pygtk2 removal ... please could you summarize what should be kept, and what still needs porting?
[12:14] <seb128> doko, I will have a look yes
[12:14] <doko> yes, was first a question for jbicha, he wasn't here yesterday
[12:17] <seb128> doko, I'm unsure he's having much time from Debian/Ubuntu nowadays...
[12:41] <doko> seb128: https://lists.debian.org/debian-gtk-gnome/2019/10/msg00001.html  do you know about that cocinelle status?
[12:42] <doko> any anything on that list in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937452 which you want to keep/port?
[12:42] <ubottu> Debian bug 937452 in src:pygtk "pygtk: Python2 removal in sid/bullseye" [Serious,Open]
[12:45] <seb128> doko, activity-log-manager might still be useful to the unity remix, unsure about the others
[12:48] <doko> that seems to be fixed already. run reverse-depends -l src:pygtk for a current list
[12:49] <doko> ogra: do you know if we still care about edu/sugar?
[12:57] <ogra> doko, no idea, but i gues not particulary ... also, there seems to be a sugarizer snap
[12:58] <doko> ok
[13:17] <cpaelzer> jamespage: dpdk is ready in focal proposed, collectd built against it and ready for proposed as well
[13:18] <cpaelzer> jamespage: I saww ovs and ovn in the new queue and your ping to doko
[13:18] <cpaelzer> I'll come back to this checking proposed migration of all of these on monday then when tests ran
[13:21] <doko> seb128: so coccinelle has one rdep (caml-crush), which can be removed as well. remove?
[13:25] <seb128> doko, +1 from me
[13:28] <xnox> tseliot:  commented
[13:28] <tseliot> xnox, thanks
=== ricab is now known as ricab|lunch
[14:10] <seb128> vorlon, I think your libsdl2 autopkgtest changes have a problem, it fails now with 'CMake Error: The source directory "/tmp/tmp.v3CMlzU4jv/build" does not appear to contain CMakeLists.txt.'
=== ricab|lunch is now known as ricab
[15:46] <vorlon> seb128: network-manager: arch-all packages that are uninstallable on i386 are fine, since we're not actually using it as a host arch and those deps will be satisfied by the amd64 version of the packages.  Only the binaries listed on https://people.canonical.com/~ubuntu-archive/proposed-migration/focal_uninst.txt need excluding
[15:46] <xnox> doko:  heya, i think this will fix python test-suites with stronger openssl in both debian and ubuntu https://paste.ubuntu.com/p/2fNYsDbGJM/ but i'm not sure how to test this best..... shall i just upload it into focal-proposed?
[15:46] <seb128> vorlon, k, it feels wrong but I can close my eyes if that's the decided way :)
[15:46] <xnox> doko:  or do you have a quicker way to re-run just the missing/skipped tests, which i'm now re-enabling?
[15:47] <vorlon> seb128: the reports don't complain, and it doesn't adversely impact users of amd64 hosts + i386 compat, it's fine ;)
[15:47] <seb128> alright!
[15:48] <vorlon> seb128: libsdl2: yeah I guess I should look into that further
[15:48] <xnox> seb128:  i have the same feelings, and my self-help answer is that "uninstallable arch;all packages should not be published into Packages_i386 but such is life, and fixing soyuz to do that is pain"
[15:48] <seb128> vorlon, I fixed the e-d-s build just as fyi
[15:52] <doko> xnox: please do
[15:52] <xnox> doko:  i thought of reruning just the autopkgtests locally with the build from focal-proposed first. As a mini-partial smoke test.
[15:52] <xnox> doko:  if any pass, will upload that into focal-proposed
[17:13] <xnox> doko:  i'm now running just the "failing-tests" autopkgtest, with just the subset of the blacklisted tests, which appear to have "progressed" all by themselves in debian. Even when openssl package is installed with evil openssl.cnf
[17:40] <bdmurray> seb128: is there somebody who can look at bug 1841646? It receives quite a lot of activity.
[17:40] <ubottu> bug 1841646 in evolution (Ubuntu) "White text on white background for HTML e-mail" [Undecided,Confirmed] https://launchpad.net/bugs/1841646
[17:53] <seb128> bdmurray, I will look thx for the ping
[18:01] <santa_> hi everybody
[18:04] <santa_> seb128 vorlon: I've seen above you mentioned something about network-manager, but I sill don't get why it doesn't migrate from -proposed. btw the version in -proposed fixes a bug I've been suffering with VPN passwords (it doesn't remember it with 1.20.4)
[18:05] <santa_> s/sill/still/
[18:06] <vorlon> santa_: because i386 is a partial arch, and some cleanup needs to happen at the source level to not build binaries that are now uninstallable on this arch
[18:06] <vorlon> (even though this is not a regression in -proposed vs the release pocket, proposed-migration doesn't calculate that and considers the uninstallability a blocker)
[18:07] <santa_> ah, I see network-manager is still being built for i386
[18:08] <santa_> vorlon: thanks for the explanation
[18:08] <santa_> and seb128 thanks for the new package
[18:09] <vorlon> yes, because nm builds libraries that are needed somewhere along the line on i386
[18:10] <santa_> aha, I guess building a limited set of packages for i386 leads to complicated situations
[20:04] <xnox> vorlon:  doko: it seems to me that the old gcc-9 in focal-proposed was busted, and like generates binaries that fail with SIGILL illegal instruction; and hence the compiler in focal-proposed/sid cannot build new gcc-9 either. The compiler in focal-release looks fine. Does it make sense to purge gcc-9 from -proposed, to reattempt rebuilding new gcc-9 with compiler from release?
[20:05] <xnox> i cannot tell if binutils or gcc-9 is at fault, cause had to revert both and couldn't revert just one of them.
[20:09] <doko> xnox: build log?
[20:09] <xnox> https://launchpadlibrarian.net/460019735/buildlog_ubuntu-focal-arm64.gnutls28_3.6.11.1-2ubuntu1_BUILDING.txt.gz
[20:10] <xnox> i also have this build on an arm64 box too, which has everything from focal-proposed
[20:10] <xnox> and the fact that it builds fine in focal-release chroot
[20:10] <xnox> (also rebuild the gnutls28 from focal-release with focal-release & focal-proposed toolchains => fails with -proposed, rebuilds fine with -release)
[20:11] <xnox> doko:  and well, also gcc-9 is ftbfs in sid & focal-proposed too => but can't really tell why, xgcc fails?
[20:12]  * xnox tries to quickly rebuild focal-proposed gcc-9 in focal-release chroot
[20:14] <xnox> https://buildd.debian.org/status/fetch.php?pkg=gcc-9&arch=arm64&ver=9.2.1-23&stamp=1578668809&raw=0
[20:15] <doko> xnox: I'll look tomorrow. I see that only arm* is failing
[20:15] <xnox> https://launchpad.net/ubuntu/+source/gcc-9/9.2.1-23ubuntu1/+build/18543838
[20:15] <xnox> doko:  yes, i am experiencing this on arm64
[20:15] <xnox> and i have baremetal arm64 instance up as well, if you want
[22:19] <seb128> pitti, python-dbusmock autopkgtests are unhappy on focal, maybe a glib 2.63 issue?
[22:19] <seb128> pitti, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/g/glib2.0/20200110_064132_d9716@/log.gz
[22:19] <seb128> pitti, AttributeError: 'gi.repository.Gio' object has no attribute 'MemoryMonitor'