[03:27] <liushuyu> Hi there, I need some help with retrying the autopkgtests, the links follow:
[03:27] <liushuyu> https://autopkgtest.ubuntu.com/request.cgi?release=kinetic&arch=amd64&package=ycmd&trigger=llvm-toolchain-15/1%3A15.0.7-0ubuntu<IP_ADDRESS>
[03:27] <liushuyu> https://autopkgtest.ubuntu.com/request.cgi?release=kinetic&arch=i386&package=dkms&trigger=llvm-toolchain-15/1%3A15.0.7-0ubuntu<IP_ADDRESS>
[03:28] <liushuyu> -- end of links. Thank you!
[04:38] <holmanb> 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] <holmanb> 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.
[08:01] <daissi[m]> 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]
[09:38] <rbasak> holmanb: that looks good to me!
[12:47] <daissi[m]> jbicha: thanks for libcamera :)
[13:04] <slyon> 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] <seb128> 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] <seb128> I don't have access to the vcs
[13:09] <seb128> jbicha, ^
[13:11] <slyon> 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] <seb128> slyon, I'm unclear what's the right vcs now, let me ask Jeremy
[13:13] <rbasak> 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] <seb128> slyon, so it was slightly confusing but the right repo is launchpad indeed, I've pushed my changes there now
[13:26] <jbicha> 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] <slyon> seb128: jbicha: https://code.launchpad.net/~slyon/network-manager/+git/network-manager/+merge/439829
[13:26] <slyon> oh.. let me rebase on the latest branch that seb just pushed..
[13:28] <seb128> slyon, any idea why that was visible only on ppc64el?
[13:29] <slyon> seb128: it's visible on all architectures, but falling through on the others, probably due to a "migration-reference/0" hint
[13:29] <slyon> "hint", i.e. a failed baseline test
[13:30] <seb128> slyon, ah, right, for some reason ppc64el was the only one not failing migration-reference
[13:31] <slyon> 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] <seb128> right, thanks
[13:38] <seb128> slyon, merged and uploaded
[13:38] <slyon> seb128: sweet, thanks!
[13:40] <seb128> slyon, thank you for the fix!
[13:40] <slyon> Not a problem
[14:04] <adrien> 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] <adrien> I'm also curious about the "Killed" lines in the log<EMAIL_ADDRESS>) and why the could happen (again, probably testbed but I'm curious)
[14:28] <slyon> adrien: done.
[14:33] <adrien> thanks! :)
[14:46] <enr0n_> 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] <adrien> enr0n: thanks for the explanation :)
[14:52] <enr0n> adrien: no problem
[16:03] <holmanb> Thanks rbasak, sounds good will do
[17:15] <bluca> 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] <bluca> is that a known issue?
[17:16] <bluca> eg<EMAIL_ADDRESS>[17:43] <enr0n> 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] <bluca> ballpark figure would be like 90% of s390x jobs in the past week or so
[18:04] <ahasenack> 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] <ahasenack> 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] <rbasak> 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] <rbasak> As I said, I leave it entirely up to you :)
[18:58] <rbasak> (to decide which way)
[18:58] <rbasak> Since neither are particularly bad or wrong IMHO
[18:59] <rbasak> And my philosophy is that in that case the person doing it gets to choose
[19:09] <ahasenack> 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] <ahasenack> but I'm bothered by the empty password cas
[19:09] <ahasenack> case
[19:10] <ahasenack> 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] <ahasenack> where do I "try again"? Not clear at all
[19:11] <ahasenack> 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] <ahasenack> treating an empty password as a signal to "please generate one for me, I don't care" is also a bit unexpected
[19:12] <ahasenack> as is "oh, empty password? Ok, I'll do nothing then" == unconfigured state
[19:12] <ahasenack> or perhaps just accept an empty password
[19:13] <ahasenack> 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] <rbasak> So we don't want an infinite loop for the noninteractive case.
[19:13] <rbasak> But we do want to give an interactive user the opportunity to try again.
[19:13] <ahasenack> yes
[19:13] <rbasak> It strikes me that a way to do that is for the default to be to not try again.
[19:13] <rbasak> "Passwords do not match. Try again? [n]"
[19:13] <rbasak> Or some equivalent.
[19:14] <rbasak> In the case of not trying again, maybe imply the "do nothing" option
[19:14] <rbasak> But yeah, more coding for you.
[19:14] <ahasenack> that's actually what is happening now, with that odd "please try again" dialog box, it's doing nothing
[19:14] <ahasenack> equal to the "unconfigured/do_nothing" case
[19:15] <rbasak> FWIW, I'm not that bothered about it at the moment.
[19:15] <rbasak> As it as at the moment, I don't think it's too bad.
[19:15] <rbasak> I don't think the edge cases have to be perfect. It's pretty obscure as it is.
[19:15] <ahasenack> I did fix the other thing, where you would be told "please try again" twice
[19:15] <ahasenack> the scripts run twice in a package installation
[19:15] <rbasak> And the user can always dpkg-reconfigure to redo it later.
[19:16] <rbasak> They might not know that, but the demographic of people trying out this agent might be different.
[19:16] <ahasenack> in my quick debian code search, I found very complicated and very simple debconf password prompts
[19:16] <ahasenack> nothing in the middle that works
[20:39] <vpa1977> Hi, would it be possible to retry regressions for known flaky tests
[20:39] <vpa1977> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=jsurf-alggeo&trigger=openjdk-lts%2F11.0.18%2B10-0ubuntu4
[20:39] <vpa1977> (race condition)
[20:39] <vpa1977> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=openjdk-lts&trigger=openjdk-lts%2F11.0.18%2B10-0ubuntu4
[20:39] <vpa1977> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=armhf&package=openjdk-lts&trigger=openjdk-lts%2F11.0.18%2B10-0ubuntu4
[20:39] <vpa1977> (timeouts)
[20:40] <vpa1977> Thank you!!!!!
[21:04] <jawn-smith> vpa1977: nobody retried those yet right?
[21:06] <jawn-smith> I didn't see them in the queue so I retried them
[21:07] <vpa1977> Thank you
[22:40] <arraybolt3> 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] <arraybolt3> (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] <sergiodj> arraybolt3: yes!  debuginfod
[22:44] <sergiodj> arraybolt3: since you're using Lunar, it should work out of the box.
[22:45] <arraybolt3> 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] <sergiodj> 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] <sergiodj> check if the DEBUGINFOD_URLS environment variable is set before starting gdb
[22:46] <sergiodj> if it is, then that's all you need
[22:47] <arraybolt3> Oh, I'm seeing the stacktrace in Apport, not gdb.
[22:47] <sergiodj> ah.  apport disables debuginfod
[22:47] <arraybolt3> oh lol
[22:48] <arraybolt3> So do I just poind gdb at the crash dump and then do something to get the stacktrace?
[22:48] <arraybolt3> I can probably figure out how to do that.
[22:49] <sergiodj> yes, point it to the crash dump and to the binary that generated it
[22:59] <arraybolt3> Uh... I don't actually have a normal core dump, I have a .crash file in /var/crash.
[22:59] <arraybolt3> And GDB doesn't recognize that.
[23:00] <arraybolt3> I see that the program that crashed was Xorg though, I guess I can just install debug symbols for it.
[23:02] <sergiodj> there's apport-unpack as well
[23:05] <arraybolt3> Hey, that's working! Thanks!
[23:08] <sergiodj> np!
[23:13] <arraybolt3> 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]


[02:20] <ChmEarl> noble-proposed: apt-cache search t64 | grep -P '^lib.*t64' | wc -l -> 665
[02:20] <ChmEarl> there are already 464 t64 libs in noble main
[02:21] <ChmEarl> for a total of 1130, while Debian side has 1700+
[02:22] <ChmEarl> it won't be long for time64 transition in Noble
[02:26] <ChmEarl> Wrong, proposed has 200+ more to add
[09:44] <lotuspsychje> app centre cant update itself as its running so it seems, prob known bug already?
[09:47] <lotuspsychje> https://dpaste.org/gjW6s
[10:02] <ogra_> thats not a bug ... snaps can never update themselves while they are running ... but unlike gnome-software app-center doesnt keep a permanently running daemon around that prevents it from updating at all
[10:03] <ogra_> you should have gotten a desktop notification along with the journal message though, telling you to please close the app center ... if you didnt get that, that would be a bug
[10:04] <lotuspsychje> ogra_: did not get a notify no
[10:04] <lotuspsychje> just in inside error inside app centre
[10:08] <ogra_> thats a bug then
[10:08] <lotuspsychje> also closing app centre doesnt update snap store
[10:10] <ogra_> indeed, it would only do that when the next update slot is scheduled ... but you should be able to refresh it manually after closing
[10:11] <lotuspsychje> ogra_: but the average user should not be need to refresh manualy via apt when gui doesnt ?
[10:13] <lotuspsychje> or would a reboot auto refresh?
[10:22] <lotuspsychje> no dice on reboot
[11:04] <ogra_> lotuspsychje, autorefresh only happens on a random schedule snapd sets itself
[11:05] <ogra_> (and definitely not directly after reboot since that would potentially saturate your network immediately)
[11:05] <ogra_> you'd have to wait for the next auto-refresh to kick in
[12:04] <lotuspsychje> ogra_: allrighty