[03:27] Hi there, I need some help with retrying the autopkgtests, the links follow: [03:27] https://autopkgtest.ubuntu.com/request.cgi?release=kinetic&arch=amd64&package=ycmd&trigger=llvm-toolchain-15/1%3A15.0.7-0ubuntu0.22.10.1 [03:27] https://autopkgtest.ubuntu.com/request.cgi?release=kinetic&arch=i386&package=dkms&trigger=llvm-toolchain-15/1%3A15.0.7-0ubuntu0.22.10.1 [03:28] -- end of links. Thank you! [04:38] rbasak: First swing at tring to get the change into debian here -> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033597 [04:38] -ubottu:#ubuntu-devel- Debian bug 1033597 in isc-dhcp-client "isc-dhcp-client: Cannot disable default dhclient script with apparmor" [Normal, Open] [04:39] rbasak: This is my first report/fix for Debian - if you have time for a brief check (Am I following the right process for requesting a fix?) I would be grateful. === Perflosopher9 is now known as Perflosopher === not_phunyguy is now known as phunyguy === rs20094 is now known as rs2009 [08:01] hello, can I have advice on how to get https://bugs.launchpad.net/ubuntu/+source/libcamera/+bug/2012745 fixed for 23.04 knowing that I provided a debdiff and the same fix was already approved by the debian release team, so I guess it should not be an issue for ubuntu as well :) [08:01] -ubottu:#ubuntu-devel- Launchpad bug 2012745 in libcamera (Ubuntu) "IPA modules are not resigned after dh_strip" [Undecided, Confirmed] === sem2peie- is now known as sem2peie [09:38] holmanb: that looks good to me! === arif-ali_ is now known as arif-ali [12:47] jbicha: thanks for libcamera :) [13:04] seb128: would you mind pushing your network-manager 1.42.4-1ubuntu1 tag to the git repo (ubuntu/master branch), I think I have a fix ready for bug #2009543 and would like to create a merge proposal [13:04] -ubottu:#ubuntu-devel- Bug 2009543 in network-manager (Ubuntu) "network-manager nm.py autopkgtest needs to be updated for 1.42" [High, Triaged] https://launchpad.net/bugs/2009543 [13:08] slyon, https://salsa.debian.org/utopia-team/network-manager/-/merge_requests/10 [13:08] -ubottu:#ubuntu-devel- Merge 10 in utopia-team/network-manager "dnsmasq: process both global and per-device configuration" [Opened] [13:09] I don't have access to the vcs === leftyfb_ is now known as leftyfb [13:09] jbicha, ^ [13:11] seb128: oh we're using salsa nowadays? d/control states "Vcs-Git: https://git.launchpad.net/network-manager". Anyway, that should be good enough for me :) [13:12] slyon, I'm unclear what's the right vcs now, let me ask Jeremy [13:13] holmanb: I linked the Debian bug you filed from LP: #2011628. Let me know if you don't hear back soon, and we can add a delta to Ubuntu for it. It'll want to wait until after beta freeze. [13:13] -ubottu:#ubuntu-devel- Launchpad bug 2011628 in isc-dhcp (Ubuntu) "Apparmor Disallows Disabling Dhclient Scripts" [Medium, Triaged] https://launchpad.net/bugs/2011628 [13:26] slyon, so it was slightly confusing but the right repo is launchpad indeed, I've pushed my changes there now [13:26] slyon: technically, LP is the Vcs but I accidentally pushed the ubuntu branch to Salsa. I think next cycle, we'll switch to Salsa because it's a much easier workflow to keep it all in Salsa [13:26] seb128: jbicha: https://code.launchpad.net/~slyon/network-manager/+git/network-manager/+merge/439829 [13:26] oh.. let me rebase on the latest branch that seb just pushed.. [13:28] slyon, any idea why that was visible only on ppc64el? [13:29] seb128: it's visible on all architectures, but falling through on the others, probably due to a "migration-reference/0" hint [13:29] "hint", i.e. a failed baseline test [13:30] slyon, ah, right, for some reason ppc64el was the only one not failing migration-reference [13:31] rebase doesn't seem to be needed.. but the diff is a bit odd on LP, due to me pushing slightly too early :). Anyway the MP should be fine for merging/uploading and the fix is pretty small [13:33] right, thanks [13:38] slyon, merged and uploaded [13:38] seb128: sweet, thanks! [13:40] slyon, thank you for the fix! [13:40] Not a problem [14:04] can someone re-trigger https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=armhf&package=systemd&trigger=strace%2F6.2-0.1ubuntu1 which I assume is a transient testbed error [14:05] I'm also curious about the "Killed" lines in the log ( https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/armhf/s/systemd/20230328_122240_b032b@/log.gz ) and why the could happen (again, probably testbed but I'm curious) [14:28] adrien: done. [14:33] thanks! :) [14:46] adrien: the failure in that log is actually from the boot-and-services test, not a test bed failure. The "Killed" lines are normal because the boot-smoke test reboots the test bed. [14:51] enr0n: thanks for the explanation :) [14:52] adrien: no problem [16:03] Thanks rbasak, sounds good will do [17:15] I've been getting loads of "Creating nova instance adt-jammy-s390x-systemd-upstream..." "ERROR (CommandError): Unable to delete the specified server(s)." (timeout) in the past few weeks [17:16] is that a known issue? [17:16] eg: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-upstream-systemd-ci-systemd-ci/jammy/s390x/s/systemd-upstream/20230328_160403_5e288@/log.gz === Guest8405 is now known as arraybolt3[m] [17:43] bluca: I do see that occasionally. I'm not sure if it's being tracked or if it has been more frequent recently though. bdmurray would know. [17:56] ballpark figure would be like 90% of s390x jobs in the past week or so [18:04] rbasak: hm, so far I have seen the behavior of "if you leave the password empty, a random one will be generated" in two different pacakges [18:05] but it's not that simple. There's a lot of tweaking in the config and postinst scripts, and some don't handle reconfigure at all [18:08] * ahasenack shakes fist at debconf [18:58] ahasenack: I don't have a particularly strong opinion. I think most of the existing behaviour is reasonable. It's just that minor point that I wasn't sure about. [18:58] As I said, I leave it entirely up to you :) [18:58] (to decide which way) [18:58] Since neither are particularly bad or wrong IMHO [18:59] And my philosophy is that in that case the person doing it gets to choose [19:09] I think the password being regenerated when you asked for that is ok, even if there was a password there before. I think I can justify that [19:09] but I'm bothered by the empty password cas [19:09] case [19:10] fresh install, you get the prompt, select supply password, just hit enter at the pw prompt, and I say "sorry, empty password not allowed, please try again", and the installation continues [19:10] where do I "try again"? Not clear at all [19:11] and I can't loop there and ask again until the password is not empty. If I do that in an unattended install, it's an infinite loop [19:11] treating an empty password as a signal to "please generate one for me, I don't care" is also a bit unexpected [19:12] as is "oh, empty password? Ok, I'll do nothing then" == unconfigured state [19:12] or perhaps just accept an empty password [19:13] need to do some magic later on then, do differentiate an empty password, from the (empty) reply to a debconf question that wasn't asked again in an upgrade [19:13] So we don't want an infinite loop for the noninteractive case. [19:13] But we do want to give an interactive user the opportunity to try again. [19:13] yes [19:13] It strikes me that a way to do that is for the default to be to not try again. [19:13] "Passwords do not match. Try again? [n]" [19:13] Or some equivalent. [19:14] In the case of not trying again, maybe imply the "do nothing" option [19:14] But yeah, more coding for you. [19:14] that's actually what is happening now, with that odd "please try again" dialog box, it's doing nothing [19:14] equal to the "unconfigured/do_nothing" case [19:15] FWIW, I'm not that bothered about it at the moment. [19:15] As it as at the moment, I don't think it's too bad. [19:15] I don't think the edge cases have to be perfect. It's pretty obscure as it is. [19:15] I did fix the other thing, where you would be told "please try again" twice [19:15] the scripts run twice in a package installation [19:15] And the user can always dpkg-reconfigure to redo it later. [19:16] They might not know that, but the demographic of people trying out this agent might be different. [19:16] in my quick debian code search, I found very complicated and very simple debconf password prompts [19:16] nothing in the middle that works [20:39] Hi, would it be possible to retry regressions for known flaky tests [20:39] https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=jsurf-alggeo&trigger=openjdk-lts%2F11.0.18%2B10-0ubuntu4 [20:39] (race condition) [20:39] https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=openjdk-lts&trigger=openjdk-lts%2F11.0.18%2B10-0ubuntu4 [20:39] https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=armhf&package=openjdk-lts&trigger=openjdk-lts%2F11.0.18%2B10-0ubuntu4 [20:39] (timeouts) [20:40] Thank you!!!!! [21:04] vpa1977: nobody retried those yet right? [21:06] I didn't see them in the queue so I retried them [21:07] Thank you [22:40] Quick question, is there an easy way to install debug symbols for a package and all of its dependencies? I'm trying to get a good stacktrace for a likely GLib-related crash in Xubuntu Lunar Beta. [22:42] (I can probably figure this out myself if needed, but I figured better to ask people who have done it or similar things before.) [22:44] arraybolt3: yes! debuginfod [22:44] arraybolt3: since you're using Lunar, it should work out of the box. [22:45] Out of the box as in...? I'm seeing lots of missing stuff in the stacktrace I'm getting, so I'm guessing something needs turned on or something. [22:45] however, due to some technical issues the service is a bit behind right now. if you're debugging something that's been published recently (this month), it's likely that the service won't have its debuginfod yet [22:46] check if the DEBUGINFOD_URLS environment variable is set before starting gdb [22:46] if it is, then that's all you need [22:47] Oh, I'm seeing the stacktrace in Apport, not gdb. [22:47] ah. apport disables debuginfod [22:47] oh lol [22:48] So do I just poind gdb at the crash dump and then do something to get the stacktrace? [22:48] I can probably figure out how to do that. [22:49] yes, point it to the crash dump and to the binary that generated it [22:59] Uh... I don't actually have a normal core dump, I have a .crash file in /var/crash. [22:59] And GDB doesn't recognize that. [23:00] I see that the program that crashed was Xorg though, I guess I can just install debug symbols for it. [23:02] there's apport-unpack as well [23:05] Hey, that's working! Thanks! [23:08] np! [23:13] Got a backtrace and posted it on https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/2013071 [23:13] -ubottu:#ubuntu-devel- Launchpad bug 2013071 in xorg (Ubuntu) "Session crash after initial login" [Undecided, Confirmed]