| ottok | teward: replied to your questions here in context at https://bugs.launchpad.net/bionic-backports/+bug/1873597 | 06:47 |
|---|---|---|
| ubottu | Launchpad bug 1873597 in Bionic Backports "Please approve backport of galera-4 26.4.3-4 (universe) from focal" [Undecided,Confirmed] | 06:47 |
| === Wryhder is now known as Lucas_Gray | ||
| cpaelzer | mwhudson: (has seen this on +1 duty) sil2100: (+1 duty atm) xnox: (triggerd the rebuild for ICU): wgrant (for riscv): hi I wanted to ask about "dee" https://launchpad.net/ubuntu/+source/dee/1.2.7+17.10.20170616-6build1/+build/19646792 | 08:20 |
| cpaelzer | it seems it built on all but riscv64 two weeks ago - but ~14h ago someone seems to have restarted the build | 08:20 |
| cpaelzer | it hangs in the after-build stage for several hours by now | 08:21 |
| cpaelzer | mwhudson: said in his mail "dee's tests are timing out on riscv64 :(" but this seems to be after (build time) tests | 08:21 |
| cpaelzer | is someone looking into that actively (after all there must be someone who restarted the build some hours ago) ? | 08:22 |
| cpaelzer | FYI dee (see question ~2h ago) still hangs at that stage https://launchpad.net/ubuntu/+source/dee/1.2.7+17.10.20170616-6build1/+build/19646792 | 10:02 |
| cpaelzer | is there any extended debug we cuold/should do on the job while still running? | 10:02 |
| cjwatson | Let me see if I can get into it | 10:04 |
| seb128 | cpaelzer, right, previous tries did take more than a day to fail the build | 10:06 |
| cjwatson | Zombie schroot process | 10:07 |
| cjwatson | Looks like there's a dbus-daemon process still running in the background of the build that the build didn't clean up properly | 10:08 |
| cjwatson | buildd 481987 0.0 0.0 5244 2780 ? S Aug10 0:00 dbus-daemon --config-file /usr/share/dbus-test-runner/session.conf --print-address | 10:08 |
| cjwatson | # ls -l /proc/481987/cwd | 10:08 |
| cjwatson | lrwxrwxrwx 1 buildd buildd 0 Aug 11 10:08 /proc/481987/cwd -> /home/buildd/build-PACKAGEBUILD-19646792/chroot-autobuild/build/dee-1HAMJl/dee-1.2.7+17.10.20170616/tests | 10:08 |
| cjwatson | cpaelzer: Is that enough for you to debug this or do you need more? | 10:10 |
| cpaelzer | thank you a lto cjwatson, that is enough to give it a start | 10:12 |
| cpaelzer | I can at least try to hard-clearn after the tests (or skip) and try that in PPAs | 10:12 |
| cpaelzer | All I need it a paper-trail and you have provided one - thanks! | 10:12 |
| cjwatson | I would prefer to cancel this build because otherwise we might end up with a build that succeeds in the primary archive but nobody knows why because it took manual intervention | 10:12 |
| cjwatson | Sound reasonable | 10:12 |
| cjwatson | ? | 10:13 |
| cpaelzer | I have only started to look at it this morning and all past builds have failed AFAIK | 10:13 |
| cpaelzer | while I'd expect it to fail again, I see no reason to wait another 10h for it to do so | 10:13 |
| cpaelzer | yes, we should abort it for now unitl we know more | 10:14 |
| cpaelzer | let us hope the hang reproduces in PPA builds | 10:14 |
| cjwatson | OK, cancelling | 10:14 |
| cjwatson | I expect it will | 10:14 |
| cjwatson | That's cancelled now | 10:17 |
| cpaelzer | thank you | 10:17 |
| cpaelzer | cjwatson: could you enable riscv64 on https://launchpad.net/~paelzer/+archive/ubuntu/dee-groovy-hang for me - otherwise I'd need to use a bileto PPA which builds on all architectures (uselss builds are a waste of build resources IMHO) ? | 10:27 |
| cjwatson | I mean negligible | 10:27 |
| cjwatson | But done | 10:28 |
| cpaelzer | thank you | 10:28 |
| cjwatson | cpaelzer: If you could delete that archive when you're finished testing then that would be good | 10:28 |
| cpaelzer | I clean up my PPAs about every 6 months | 10:28 |
| cpaelzer | if in this case it is more urgent I can surely do that | 10:29 |
| LocutusOfBorg | niedbalski, hello, I confirm your patch of LP: #1872118 works on my focal servers as primary and slave dhcpd services... can I upload to unapproved queue? and fix also for groovy? | 10:57 |
| ubottu | Launchpad bug 1872118 in isc-dhcp (Ubuntu Groovy) "DHCP Cluster crashes after a few hours" [Undecided,Confirmed] https://launchpad.net/bugs/1872118 | 10:57 |
| narakrish | Hello all.I've developed an application using Qt5.12.7 on Ubuntu 16.04.06 system. I'm facing flickering issue when the application starts. I was able to fix the flickering by installing the following package from ubuntu repository : sudo apt-get install --install-recommends linux-generic-hwe-16.04 xserver-xorg-hwe-16.04. I would like to understand | 11:16 |
| narakrish | is there any link between Qt 5.12.7 and those packages ? | 11:16 |
| xnox | slyon: seb128: network-manager autopkgtest wpa-dhclient started to fail on ppc64el and i cannot work out what has changed, or even reproduce the failure the same way. For me, even bringing up wlan0/wlan1 fails and I can't even start dnsmasq on the AP which is like part of individual test case setup. | 11:35 |
| xnox | i am slightly concerned, but also not sure if we care abput wifi on ppc64el =( | 11:36 |
| Laney | We have definitely had cases before where ppc64el was just noticing bugs/races that exist everywhere | 11:39 |
| Laney | So IMO to discard it on that basis we should have a determination that it is actually arch specific and not just something we happen to see there for $reasons | 11:39 |
| cpaelzer | and someone started the dee build again https://launchpad.net/ubuntu/+source/dee/1.2.7+17.10.20170616-6build1/+build/19646792 :-/ | 11:53 |
| cpaelzer | The assumption for now is that this is a real issue and not a "retry until it works" case | 11:53 |
| cpaelzer | see https://bugs.launchpad.net/ubuntu/+source/dee/+bug/1891158 and let me know if you look or looked into it already | 11:53 |
| ubottu | Launchpad bug 1891158 in dee (Ubuntu) "riscv64 build issue hang at the end of the build (groovy)" [Medium,Confirmed] | 11:53 |
| juliank | new apt landing, please stay attentive and ping me immediately if you see download errors https://launchpad.net/ubuntu/+source/apt/2.1.10 | 12:40 |
| rbasak | Laney: which series(es) do you need canonical-oem-metapackages defined for? | 12:53 |
| rbasak | Never mind I'll just request $(distro-info --supported) | 12:57 |
| LocutusOfBorg | cpaelzer, my fault, I won't retry it | 12:58 |
| LocutusOfBorg | thanks juliank :) | 12:58 |
| LocutusOfBorg | niedbalski, will you forward upstream the fix? | 13:00 |
| rbasak | Thanks Marc! | 13:14 |
| LocutusOfBorg | @rafaeldtinoco, ^^ I got trapped by the isc-dhcp bug, do you need help/sponsorships? I can upload to groovy and focal if needed | 13:14 |
| udevbot | Error: "rafaeldtinoco," is not a valid command. | 13:14 |
| LocutusOfBorg | rafaeldtinoco, ^^ | 13:15 |
| rafaeldtinoco | LocutusOfBorg: I was waiting niedbalski to give a go | 13:15 |
| rafaeldtinoco | sent an email cc'ing him from yesterday triage | 13:16 |
| rafaeldtinoco | if he is +1 and you're into it, feel free to sponsor it | 13:16 |
| rafaeldtinoco | niedbalski: ^ | 13:17 |
| LocutusOfBorg | btw the problem looks in bind9-libs | 13:18 |
| LocutusOfBorg | no need to no-change rebuild isc-dhcp at all | 13:18 |
| LocutusOfBorg | +- else | 13:19 |
| LocutusOfBorg | ++ else if (!sock->pending_send) | 13:19 |
| LocutusOfBorg | this change is ABI-safe | 13:19 |
| rafaeldtinoco | seems so, haven't looked into details | 13:19 |
| rafaeldtinoco | triage queue was ... interesting yesterday =) | 13:19 |
| rafaeldtinoco | 35 bugs.. many with big updates | 13:20 |
| LocutusOfBorg | well, I suspect niedbalski should open a bug against bind9-libs? | 13:21 |
| rafaeldtinoco | yep, I think he wasn't finished yet with the bug | 13:21 |
| LocutusOfBorg | I can't reproduce the crash with updated bind9-libs and normal isc packages | 13:21 |
| rafaeldtinoco | thats why I didn't take a move | 13:21 |
| niedbalski | LocutusOfBorg: rafaeldtinoco sure, i'll add the bind9-libs and propose the SRU(s) | 13:21 |
| LocutusOfBorg | niedbalski, don't forget to offer a debdiff for groovy, and to open a debian bug with patches | 13:22 |
| LocutusOfBorg | so the package goes in sync again | 13:22 |
| niedbalski | LocutusOfBorg: okay | 13:22 |
| LocutusOfBorg | rbasak, ?? how do you feel about adding the patch directly to the Debian package and wait for the sync? | 13:24 |
| rbasak | Was that for me? | 13:26 |
| ahasenack | hi devel team, I have a failing test on armhf for samba in groovy, and turns out that the host is not running the groovy kernel | 13:28 |
| ahasenack | I know armhf tests are run on lxd/armhf images, but I was expecting the host to have the same kernel as the target ubuntu release at least | 13:28 |
| ahasenack | looks like the host is bionic | 13:28 |
| ahasenack | just checking if this is expected, and that I should guard my test to check for the kernel version | 13:29 |
| rbasak | That was discussed recently as it happens: https://lists.ubuntu.com/archives/ubuntu-devel/2020-August/041109.html | 13:29 |
| ahasenack | fwiw, it's a test using kernel's uring support, which became available in kernel 5.1 and later | 13:29 |
| rbasak | Based on that you can never make that assumption about the build host kernel | 13:29 |
| ahasenack | yeah, for vms it doesn't matter, for armhf is the special guy | 13:30 |
| ahasenack | ok, I'll adapt the test and have it skip if the kernel is too old | 13:31 |
| rbasak | I was under the impression that armhf builds happen on arm64 nowadays? | 13:31 |
| ahasenack | it's an armhf lxd image on an arm64 host | 13:31 |
| rbasak | Right | 13:31 |
| ahasenack | well, at least it shows my test works | 13:31 |
| rafaeldtinoco | and there is yet another problem.. the arm64 kernel with armhf userladn | 13:32 |
| ahasenack | in the sense that it fails if uring support isn't there :) | 13:32 |
| rafaeldtinoco | but thats another story =) | 13:32 |
| rafaeldtinoco | (the syscall execution paths are diff, bugs may rise from there) | 13:32 |
| ahasenack | so uring was really being exercised | 13:32 |
| LocutusOfBorg | rbasak, bind9-libs needs a patch, also in Debian, to fix a crash | 13:39 |
| LocutusOfBorg | the patch is trivial | 13:39 |
| LocutusOfBorg | rbasak, http://debomatic-amd64.debian.net/distribution#unstable/bind9-libs/9.11.19+dfsg-2/buildlog | 13:40 |
| LocutusOfBorg | this is the "fix" | 13:40 |
| rbasak | LocutusOfBorg: wrong URL? | 13:45 |
| rbasak | LocutusOfBorg: I don't follow why you're asking me | 13:45 |
| rbasak | Which of my hats are you talking to? | 13:45 |
| rbalint | ricotz, please open a but then, unless it is LP: #1890913 | 13:45 |
| ubottu | Launchpad bug 1890913 in linux (Ubuntu) "init is using 100% of processor " [Undecided,Invalid] https://launchpad.net/bugs/1890913 | 13:45 |
| rbalint | ricotz, (re: systemd 246) | 13:46 |
| LocutusOfBorg | rbasak, aren't you the maintainer of bind9-libs? | 13:51 |
| ricotz | rbalint, this looks like the symptom I saw, running an i7 2600K, no i915 though | 13:53 |
| rbalint | ricotz, 5.8 kernel? | 13:53 |
| ricotz | rbalint, yes | 13:54 |
| ricotz | 5.8.0-13-generic | 13:54 |
| rbasak | LocutusOfBorg: ah. I wasn't aware. I guess that got copied across from find9 | 13:54 |
| rbasak | bind9 | 13:54 |
| rbasak | LocutusOfBorg: probably best file a BTS patch? | 13:54 |
| ricotz | rbasak, more precise 5.8.0-13.14-generic 5.8.0 | 13:55 |
| rbasak | I've not been active there for a while | 13:55 |
| rbalint | ricotz, i think new systemd would work fine with old kernel | 13:56 |
| ricotz | rbalint, ok, but 5.8.0-12.13 is in groovy-proposed | 13:57 |
| ricotz | you have tested it with 5.4.0-* only? | 13:57 |
| rbalint | ricotz, yes, not breaking release pocket is sufficient for migration | 13:58 |
| cpaelzer | seb128: I see you hav retried sbuild/dpkg in regard to procenv | 13:59 |
| rbalint | i think kernel 5.8 made intel driver's fastboot the default and this breaks old cpus | 13:59 |
| ricotz | rbalint, alright, might be good if you give the proposed kernel a try | 13:59 |
| cpaelzer | seb128: due to the way that gets the procenv source the combined trigger wasn't getting what you wanted | 13:59 |
| cpaelzer | seb128: but now procenv is released to groovy (thanks slyon) | 13:59 |
| cpaelzer | seb128: I have retriggered again and now it should work (or find a different failure) | 14:00 |
| seb128 | cpaelzer, ah, sorry for screwing those triggers set ... what was missing exactly? | 14:00 |
| seb128 | ah | 14:01 |
| seb128 | that wouldn't respect the trigger version, ignore that | 14:01 |
| seb128 | cpaelzer, thanks for the headsup! | 14:01 |
| slyon | cpaelzer: seb128: sbuild should work now, I verified that locally. dpkg needs sbuild to migrate first | 14:01 |
| seb128 | slyon, ack | 14:02 |
| seb128 | doko, could you trigger a refresh of https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200728-groovy-groovy.html ? | 14:04 |
| cpaelzer | slyon: seb128: I have issued the new trigger - and now it should work | 14:04 |
| cpaelzer | slyon: if not I'll let you know and we can debug what new issue it is now | 14:04 |
| seb128 | cpaelzer, thanks! | 14:04 |
| slyon | thanks! | 14:04 |
| rbalint | ricotz, so you have not modified kernel cmd line manually, right? | 14:11 |
| ricotz | rbalint, no | 14:17 |
| rafaeldtinoco | sergiodj: did you open a bug for the rabbitmq-server merge ? | 14:33 |
| rafaeldtinoco | just asking cause I can "sponsor" that sync bug | 14:33 |
| sergiodj | rafaeldtinoco: nope, but I can do that now. I thought the MP was enough :) | 14:38 |
| sergiodj | let me run requestsync here | 14:38 |
| rafaeldtinoco | sergiodj: nah | 14:38 |
| rafaeldtinoco | sergiodj: no need | 14:38 |
| sergiodj | rafaeldtinoco: ah, ok | 14:39 |
| sergiodj | thanks :) | 14:39 |
| rafaeldtinoco | sure! | 14:39 |
| rafaeldtinoco | sergiodj: could u pls check migration for rabbitmq-server upload ? | 14:55 |
| rafaeldtinoco | hopefully it migrates with no issue s=) | 14:55 |
| sergiodj | rafaeldtinoco: absolutely, thanks | 14:55 |
| cpaelzer | slyon: seb128: all sbuild/dpkg turned green | 15:57 |
| cpaelzer | just one systemd test left that has a retry in the queue already | 15:58 |
| slyon | cpaelzer: thanks a lot for your support with this! | 16:07 |
| rbalint | vorlon, vim blocks libguestfs -> systemd , i'd like to disable vim tests on riscv64 to unblock them | 16:40 |
| rbalint | vorlon, or we can unblock tests on riscv64 for all packages which i would not oppose | 16:40 |
| xnox_m | <rbalint "vorlon, vim blocks libguestfs ->"> please go ahead with vim upload to skip riscv64 test. | 16:40 |
| vorlon | rbalint: yes, please do | 16:41 |
| rbalint | vorlon, i guess the former for now :-) | 16:41 |
| vorlon | but also, where did we get to with the discussion about disabling tests at build-time for all riscv64 | 16:41 |
| rbalint | vorlon, it stalled after my last email asking for it | 16:41 |
| xnox | rbalint: vorlon: i tend to agree with wgrant that in general, most of them run, and most of them pass, and are ok. And we should be free to upload disabling them on case by case basis, and like opening a bug report to revisit them. Or like revisit that after next merge from debian. | 16:42 |
| * xnox_m is still not sure if matrix client or weechat are better | 16:43 | |
| vorlon | xnox: no, the problem is the cost on package build time to run tests whose results we don't care about | 16:43 |
| vorlon | it's *not* about test reliability | 16:43 |
| xnox | vorlon: so PPA builds on riscv64 of snapd are the only place where riscv64 tests are executed today..... so it's used as a ci. | 16:43 |
| xnox | vorlon: if we do disable tests by default, it should be possible to re-opt-into them. | 16:44 |
| vorlon | which it would be | 16:44 |
| vorlon | just unset the environment variable that would be set by dpkg-dev | 16:44 |
| vorlon | DEB_BUILD_OPTIONS=notnocheck | 16:44 |
| xnox | i don't see how to make that policy compliant. | 16:44 |
| vorlon | what aspect of policy? | 16:45 |
| xnox | is notnocheck a thing? | 16:45 |
| rbalint | xnox, which policy? | 16:45 |
| xnox | that packages should honor DEB_BUILD_OPTIONS and not modify / ignore it. | 16:45 |
| xnox | debian policy | 16:45 |
| vorlon | xnox: no, I was being facetious re: notnocheck | 16:45 |
| rbalint | well, we are ok with having packages which are not fully policy compliant | 16:46 |
| xnox | there is nocheck profile right? vs DEB_BUILD_OPTIONS? | 16:46 |
| vorlon | profiles are not supported anywhere in launchpad | 16:46 |
| xnox | i'd be more happy with "default profile set to nocheck on riscv64 in dpkg" unless any other profile is specified. | 16:46 |
| xnox | it does not need to be supported by launchpad | 16:46 |
| vorlon | I don't see anything in policy saying that packages are not allowed to change the contents of DEB_BUILD_OPTIONS | 16:46 |
| xnox | also one cannot pass arbitrary DEB_BUILD_OPTIONS via launchpad either. | 16:46 |
| vorlon | hmm | 16:47 |
| vorlon | profiles aren't mentioned in policy at all ;P | 16:47 |
| xnox | ah it's optional | 16:47 |
| xnox | "Supporting the standardized environment variable DEB_BUILD_OPTIONS is recommended." | 16:47 |
| vorlon | yes, and in any case "supporting" doesn't mean "not allowed to override" | 16:47 |
| xnox | vorlon: doko wanted to patch dpkg and/or debhelper, to do "nocheck by default on riscv64" because well, anything else is mad. | 16:48 |
| vorlon | does setting a nocheck profile automatically set DEB_BUILD_OPTIONS? Because most packages honor the latter and not the former | 16:48 |
| rbalint | xnox, i'd go with patching dpkg as well | 16:48 |
| xnox | ie. local sbuild stops matching what launchpad does, if we hide deb_build_options/profiles in launchpad-buildd | 16:48 |
| vorlon | agreed, it should be a dpkg patch | 16:48 |
| xnox | rbalint: but please upload vim first =) | 16:49 |
| vorlon | quite | 16:49 |
| rbalint | vorlon, ok, but i got so enthusiastic i already pulled dpkg, too ... :-) | 16:50 |
| xnox | vorlon: so i'm currntly doing cross-building and something set all the things for me like "nocheck cross" build profiles and like "DEB_BUILD_OPTIONS" too | 16:50 |
| * xnox sensed disturbance in the forse | 16:50 | |
| vorlon | xnox: sure - but the DEB_BUILD_OPTIONS bit is what's actually functional, so I don't see the point in messing with profiles instead of just build options directly | 16:50 |
| xnox | sure | 16:51 |
| xnox | vorlon: it would be neat to eventually wire up profiles/deb-build-options into launchpad archive settings, such that i.e. we could create archive rebuild with|without nocheck, and create cross-building archive, etc. | 16:51 |
| * vorlon nods | 16:52 | |
| vorlon | ahasenack: hi, managing to reply before you drop off IRC for the day; I think the corner case in question is acceptable to not address, but needs to be called out in the SRU | 17:36 |
| vorlon | (as "regression potential") | 17:36 |
| ahasenack | I see | 17:36 |
| ahasenack | I was just implementing cpaelzer's suggestion | 17:36 |
| ahasenack | creating a file in postinst of one package, checking for it in the postinst of another | 17:37 |
| vorlon | ok, I have no well-formed opinion on this at the moment :) | 17:37 |
| ahasenack | it worked in the case of ubuntu-server being installed, but when it's not installed, that touched file used for "inter-maintainerscript-communication" was left around (/etc/default/motd-news.wasremoved) | 17:38 |
| ahasenack | vorlon: this was/is the logic: https://pastebin.ubuntu.com/p/fhg6pHmMMH/ | 17:39 |
| ahasenack | (postinst snippets at the bottom) | 17:40 |
| ahasenack | should I continue with that, or remove this corner case, any opinion? | 17:40 |
| ahasenack | I feel a bit dirty manipulating maintainerscripts like that | 17:44 |
| vorlon | ahasenack: sorry, can't look right now; I'll try to give an opinion in ~1h | 17:57 |
| ahasenack | vorlon: thanks | 18:01 |
| vorlon | ahasenack: yeah, so I'm vaguely inclined to leave this corner case unfixed but called out in the SRU, rather than add additional complicated maintscript handling; but I wouldn't block the SRU if you do add the maintscript stuff | 19:54 |
| ahasenack | yeah, I fear I might introduce bugs of my own with that complicated handling | 19:55 |
| ahasenack | thanks vorlon | 19:56 |
| ahasenack | teward: hi, around? Would you like us to merge nginx from debian again, or would you prefer to work on this one? | 21:19 |
| bdmurray | bryyce: Do you have an example of the nodejs timeout on arm64? | 21:26 |
| bryyce | bdmurray, just the build log, but I can give you a link | 22:49 |
| bryyce | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/n/node-redis/20200811_140200_cbf2b@/log.gz | 22:52 |
| bryyce | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/n/node-immutable-tuple/20200811_110654_f3a78@/log.gz | 22:52 |
| bryyce | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/n/node-address/20200811_110131_4b017@/log.gz | 22:52 |
| bryyce | bdmurray, ^^ | 22:53 |
| bdmurray | bryyce: Have you tried it with a longer timeout? | 22:53 |
| bdmurray | I'm trying it with timeout-test=20000 | 23:02 |
| bryyce | bdmurray, no I hadn't; is that set in the package itself? | 23:31 |
| bdmurray | bryyce: no when you call autopkgtest "--timeout-test" which defaults to 10000 | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!