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:18 |
rafaeldtinoco | sure! , im investigating other bug and will propose a merge | 04:19 |
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:20 |
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 | 04:21 |
cpaelzer | a build taking 13h looks wrong | 06:11 |
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:12 |
cpaelzer | the same in a ppa buid multiple times without that https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3881/+build/18538702 | 06:14 |
cpaelzer | can't find anything useful, restarting to get things moving again :-/ | 06:34 |
cpaelzer | hmm, cancelling this seems just as stuck as formerly completing it was ... | 06:40 |
cpaelzer | still hanging on "cancelling build" after 20 minutes ... | 06:53 |
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 | 06:54 |
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 | 08:23 |
jamespage | cpaelzer: np - I have a ceph resync/merge I'm working on until that's all cleared | 09:09 |
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? | 09:10 |
cjwatson | cpaelzer: don't cancel builds in that sort of situation please | 10:07 |
cjwatson | if anything it makes things worse | 10:07 |
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:11 |
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:12 |
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:13 |
cpaelzer | ok, it was half an hour in IRC log - but also I looked at it before I asked here ... :-) | 10:14 |
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 | 10:22 |
=== seb128_ is now known as seb128 | ||
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:42 |
doko | jamespage: ok, I'll try | 11:46 |
jamespage | doko: thanks | 11:51 |
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:01 |
cpaelzer | cjwatson: that hint with the buildlog is great, that seems like a clear "if A, then B" thanks! | 12:08 |
doko | jbicha, seb128: pygtk2 removal ... please could you summarize what should be kept, and what still needs porting? | 12:13 |
seb128 | doko, I will have a look yes | 12:14 |
doko | yes, was first a question for jbicha, he wasn't here yesterday | 12:14 |
seb128 | doko, I'm unsure he's having much time from Debian/Ubuntu nowadays... | 12:17 |
doko | seb128: https://lists.debian.org/debian-gtk-gnome/2019/10/msg00001.html do you know about that cocinelle status? | 12:41 |
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:42 |
seb128 | doko, activity-log-manager might still be useful to the unity remix, unsure about the others | 12:45 |
doko | that seems to be fixed already. run reverse-depends -l src:pygtk for a current list | 12:48 |
doko | ogra: do you know if we still care about edu/sugar? | 12:49 |
ogra | doko, no idea, but i gues not particulary ... also, there seems to be a sugarizer snap | 12:57 |
doko | ok | 12:58 |
cpaelzer | jamespage: dpdk is ready in focal proposed, collectd built against it and ready for proposed as well | 13:17 |
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:18 |
doko | seb128: so coccinelle has one rdep (caml-crush), which can be removed as well. remove? | 13:21 |
seb128 | doko, +1 from me | 13:25 |
xnox | tseliot: commented | 13:28 |
tseliot | xnox, thanks | 13:28 |
=== ricab is now known as ricab|lunch | ||
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.' | 14:10 |
=== ricab|lunch is now known as ricab | ||
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:46 |
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:47 |
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:48 |
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 | 15:52 |
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:13 |
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:40 |
seb128 | bdmurray, I will look thx for the ping | 17:53 |
santa_ | hi everybody | 18:01 |
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:04 |
santa_ | s/sill/still/ | 18:05 |
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:06 |
santa_ | ah, I see network-manager is still being built for i386 | 18:07 |
santa_ | vorlon: thanks for the explanation | 18:08 |
santa_ | and seb128 thanks for the new package | 18:08 |
vorlon | yes, because nm builds libraries that are needed somewhere along the line on i386 | 18:09 |
santa_ | aha, I guess building a limited set of packages for i386 leads to complicated situations | 18:10 |
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:04 |
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:05 |
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:09 |
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:10 |
xnox | doko: and well, also gcc-9 is ftbfs in sid & focal-proposed too => but can't really tell why, xgcc fails? | 20:11 |
* xnox tries to quickly rebuild focal-proposed gcc-9 in focal-release chroot | 20:12 | |
xnox | https://buildd.debian.org/status/fetch.php?pkg=gcc-9&arch=arm64&ver=9.2.1-23&stamp=1578668809&raw=0 | 20:14 |
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 | 20:15 |
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' | 22:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!