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-0ubuntu0.22.10.1 | 03:27 |
liushuyu | 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:27 |
liushuyu | -- end of links. Thank you! | 03:28 |
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:38 | |
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. | 04:39 |
=== Perflosopher9 is now known as Perflosopher | ||
=== not_phunyguy is now known as phunyguy | ||
=== rs20094 is now known as rs2009 | ||
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] | 08:01 | |
=== sem2peie- is now known as sem2peie | ||
rbasak | holmanb: that looks good to me! | 09:38 |
=== arif-ali_ is now known as arif-ali | ||
daissi[m] | jbicha: thanks for libcamera :) | 12:47 |
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:04 | |
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:08 | |
seb128 | I don't have access to the vcs | 13:09 |
=== leftyfb_ is now known as leftyfb | ||
seb128 | jbicha, ^ | 13:09 |
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:11 |
seb128 | slyon, I'm unclear what's the right vcs now, let me ask Jeremy | 13:12 |
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:13 | |
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:26 |
seb128 | slyon, any idea why that was visible only on ppc64el? | 13:28 |
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:29 |
seb128 | slyon, ah, right, for some reason ppc64el was the only one not failing migration-reference | 13:30 |
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:31 |
seb128 | right, thanks | 13:33 |
seb128 | slyon, merged and uploaded | 13:38 |
slyon | seb128: sweet, thanks! | 13:38 |
seb128 | slyon, thank you for the fix! | 13:40 |
slyon | Not a problem | 13:40 |
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:04 |
adrien | 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:05 |
slyon | adrien: done. | 14:28 |
adrien | thanks! :) | 14:33 |
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:46 |
adrien | enr0n: thanks for the explanation :) | 14:51 |
enr0n | adrien: no problem | 14:52 |
holmanb | Thanks rbasak, sounds good will do | 16:03 |
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:15 |
bluca | is that a known issue? | 17:16 |
bluca | eg: https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-upstream-systemd-ci-systemd-ci/jammy/s390x/s/systemd-upstream/20230328_160403_5e288@/log.gz | 17:16 |
=== Guest8405 is now known as arraybolt3[m] | ||
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:43 |
bluca | ballpark figure would be like 90% of s390x jobs in the past week or so | 17:56 |
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:04 |
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:05 |
* ahasenack shakes fist at debconf | 18:08 | |
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:58 |
rbasak | And my philosophy is that in that case the person doing it gets to choose | 18:59 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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 | 19:16 |
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:39 |
vpa1977 | Thank you!!!!! | 20:40 |
jawn-smith | vpa1977: nobody retried those yet right? | 21:04 |
jawn-smith | I didn't see them in the queue so I retried them | 21:06 |
vpa1977 | Thank you | 21:07 |
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:40 |
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:42 |
sergiodj | arraybolt3: yes! debuginfod | 22:44 |
sergiodj | arraybolt3: since you're using Lunar, it should work out of the box. | 22:44 |
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:45 |
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:46 |
arraybolt3 | Oh, I'm seeing the stacktrace in Apport, not gdb. | 22:47 |
sergiodj | ah. apport disables debuginfod | 22:47 |
arraybolt3 | oh lol | 22:47 |
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:48 |
sergiodj | yes, point it to the crash dump and to the binary that generated it | 22:49 |
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. | 22:59 |
arraybolt3 | I see that the program that crashed was Xorg though, I guess I can just install debug symbols for it. | 23:00 |
sergiodj | there's apport-unpack as well | 23:02 |
arraybolt3 | Hey, that's working! Thanks! | 23:05 |
sergiodj | np! | 23:08 |
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] | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!