[02:33] <cjdesno> if i've checked out package sources with apt-get source, how do i build a specific subpackage? in cases where the repo has multiple subpackages
[02:33] <cjdesno> (specifically looking at u-boot, but seems like something that probably has a general answer)
[02:35] <sarnold> cjdesno: what do you mean by "specific subpackage"?
[02:36] <sarnold> cjdesno: if you mean, the source package builds multiple binary packages, you can't pick and choose, they all build at once in one go..
[02:36] <sarnold> cjdesno: if you meant something else, then it'll probably take more details..
[02:38] <cjdesno> i want to build u-boot-rpi, but it looks like `debuild -i -us -uc -b` just builds u-boot-qemu
[02:43] <sarnold> holy moly that's a complicated package :)
[02:48] <sarnold> cjdesno: okay, so... here's my wild guess: set DEB_BUILD_PROFILES to include something like pkg.uboot.subarch.rpi_3_b_plus_defconfig  --- https://wiki.debian.org/BuildProfileSpec#The_DEB_BUILD_PROFILES_environment_variable  -- check out the debian/rules file, look for DEB_BUILD_PROFILES in there
[02:52] <cjdesno> yeah... i just want to turn off serial prints from u-boot on my rpi4, but when i built from source directly i got stuck in a bootloop, so figured i'd check out building from the package to see if that goes better
[02:52] <cjdesno> thanks! trying that now
[03:09] <cjdesno> no dice, looks like it's something close to that, though. ah well.
[03:15] <sarnold> dang :(
[11:15] <rbasak> We have a thunderbird, tinyjsd and jsunit versioning question. Both the tinyjsd and jsunit packages are gone in Groovy. Does the thunderbird package need a versioned Breaks against them in Groovy? We are doing that in Focal, because we're going to ship empty packages for them in an SRU in Focal, and the thunderbird SRU should push those up. And is a versioned Breaks sufficient? I'm not clear on how
[11:15] <rbasak> package removals interact with do-release-upgrade, autoremove, etc.
[11:27] <seb128> oSoMoN, ^
[11:28] <seb128> rbasak, I don't think anything is going to remove those if they are installed on the system, not that it would create any issue to still have them around on disk
[11:28] <oSoMoN> seb128, yes, that's a question rbasak and I have for ubuntu-devel, hopefully someone knows the answer
[11:28] <seb128> they are just useless
[11:29] <seb128> if you manually install something I don't think we try to clean those up on upgrade
[11:29] <seb128> it could be an old still work package you rely on, the safe choice is to let it
[11:29] <seb128> working*
[11:30] <seb128> but juliank or others probably know better the details
[11:31] <juliank> rbasak: what's the breaks for? breaks foo (<< x) is for upgrading foo to at least x
[11:32] <juliank> don't you want like unversioned conflicts?
[11:33] <juliank> I'm missing a bunch of context - presumably the new thunderbird breaks those old extensions?
[11:33] <juliank> But if there's nothing to upgrade to, Breaks are technically the wrong thing
[11:33] <juliank> not that it matters in practice but certain people get mad
[11:35] <juliank> This will help removing them either way, but i think u-r-u also removes obsolete packages anyway
[11:35] <juliank> on a dist-upgrade
[11:41] <rbasak> juliank: the breaks is for Focal really. In that case we do want to ensure that the package is upgraded as thunderbird is upgraded.
[11:41] <rbasak> So normally we'd keep the versioned breaks until after the next LTS.
[11:41] <juliank> it's fine I guess
[11:41] <rbasak> However in this case we're doing it backwards by adding it in an SRU, so it's a bit odd that we're adding it to Focal only, and Groovy won't have it unless we add it.
[11:41] <rbasak> So...do we need to add it? That's my question really.
[11:42] <rbasak> In enigmail's case I think we do want it, because the enigmail package continues to exist.
[11:42] <rbasak> So we'll be updating groovy anyway for that.
[11:43] <rbasak> The diff then shows the breaks being removed for tinyjsd and jsunit, which made me wonder what the correct answer is for those.
[11:43] <rbasak> I don't understand the mechanism that causes removed packages to be removed on release upgrade
[11:44] <rbasak> It's not autoremove, is it? How does do-release-upgrade do that?
[11:44] <juliank> So assuming the user does not have updates pocket enabled, it's certainly useful to keep the breaks around
[11:44] <juliank> I think u-r-u tarball contains a list of packages that are gone in a new release and offers to uninstall them
[11:44] <juliank> but that might be too late
[11:45] <rbasak> In that scenario, will apt know to resolve by removing jsunit and tinyjsd and upgrading thunderbird, instead of removing thunderbird, to resolve the situation?
[11:45] <juliank> nobody can say for sure
[11:45] <rbasak> Will it pick up on the fact that thunderbird continues to exist but jsunit and tinyjsd are no longer in the archive?
[11:46] <juliank> no idea if it uses such info
[11:46] <rbasak> I can test that I guess
[11:46] <juliank> unless something else depends on jsunit and tinyjsd, I'd expect things to go smooth
[11:47] <juliank> because you'll mark thunderbird for upgrade, and doing so will mark those two for removal
[11:47] <rbasak> OK thanks!
[11:48] <rbasak> oSoMoN: so let's copy the versioned breaks to groovy and hirsute?
[11:48] <rbasak> Then we can test an apt-only upgrade using the PPA
[11:49] <rbasak> (we discussed earlier that we don't think we need to support that, but it'll probably help ensure general correctness if it works
[11:49] <rbasak> )
[11:56] <oSoMoN> rbasak, ok, I'll do that
[12:21] <juliank> ⚠ wiki.ubuntu.com will be offline shortly for brief hardware maintenance
[12:47] <juliank> Wiki is back
[14:20] <rbasak> ItzSwirlz: patch: **** malformed patch at line 51: diff -Nru cinnamon-4.6.7/debian/patches/series cinnamon-4.6.7/debian/patches/series
[14:20] <rbasak> :-/
[14:20] <rbasak> It's not obvious to me what's wrong
[14:26] <oSoMoN> rbasak, I did a quick test: I unpacked the groovy package in ppa:ubuntu-mozilla-security/ppa, added the versioned breaks and repacked it, then made a local apt repository with it, and used it to upgrade a focal chroot (without focal-updates) to groovy, and this resulted in apt removing jsunit and tinyjsd, as we speculated it would
[14:31] <rbasak> oSoMoN: nice. Thanks!
[16:27] <seb128> rbalint, did you check that the systemd upload fixes the network manager issue? not starting udev is probably not going to be enough
[16:32] <rbalint> seb128, yes, i know and left a comment in the bug
[16:32] <rbalint> seb128, that's the most i can do on systemd's side
[16:41] <seb128> rbalint, I was not subscribed to the bug, I saw the comment now, thanks
[16:41] <seb128> stgraber, rbalint, it sucks a bit, I don't know what the right fix for network manager would be
[16:42] <rbalint> seb128, detecting if udevd is really running should do it imo
[16:43] <seb128> upstream is going to argue that the container spec is clear and that /sys should be mounted ro though :/
[16:43] <seb128> rbalint, do you have any code example to check that udev is active?
[16:44] <rbalint> seb128, not at hand
[16:44] <seb128> k, thanks
[16:45] <stgraber> not starting udevd in LXD containers is going to cause other regressions...
[16:45] <stgraber> LXD containers unlike nspawn/docker/whatever does have proper uevents and does send them when external devices are passed
[16:46] <seb128> stgraber, that's what just got uploaded to hirsute though :/
[16:50] <stgraber> making /sys read-only would break k8s, openstack, libvirt, ... pretty much anything that interacts with networking through /sys/class/net, so that's not going to happen. udevd is needed for USB device hotplug, network config, ... so disabling it will cause breakage. As I commented in https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1914062, we can help with specific udevd bugs,
[16:50] <stgraber> disabling things all over the place isn't the right way to handle this. Neither is confronting systemd upstream about their view of what containers are.
[16:51] <rbalint> stgraber, nonprivileged containers should work ok with ro /sys
[16:51] <stgraber> rbalint: no they won't
[16:51] <stgraber> rbalint: /sys/class/net is absolutely writable in unprivileged containers
[16:52] <seb128> stgraber, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1914062/comments/10 is a small testcase showing what broke in hirsute and makes network manager fail, unsure if that's to be fixed on the systemd or lxc side though...
[16:52] <rbalint> stgraber, please discuss it with system upstream
[16:52] <stgraber> rbalint: no we won't, we are very close to systemd upstream, close enough to know when we disagree, bringing it up over and over again just makes things worse.
[16:53] <stgraber> rbalint: however for actual bugs, we have a good track record of getting them fixed
[17:00] <seb128> stgraber, could we get someone from the lxc side looking at the issue? otherwise I fear we are going to be stucked in that situation for a while...
[17:08] <stgraber> rbalint: can you please revert your systemd change to not run udev in containers? I've got a debdiff ready to upload to undo the change, but I've never used git-ubuntu and suspect a direct dput may not be too welcome ;)
[17:10] <stgraber> seb128: hmm, so I created a hirsute container and installed network-manager into it (1.28.0-2ubuntu1) then rebooted the container and `systemctl --failed` is clean, what did I miss?
[17:11] <rbalint> stgraber, please file an MR against https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/+git/systemd/+ref/ubuntu-hirsute
[17:12] <rbalint> and explain why you need udevd
[17:13] <rbalint> stgraber, i guess seb128 will then need a different fix for n-m then
[17:14] <stgraber> rbalint: as I've said, we'll look at getting udevd to behave, that's fine, regressing production use cases isn't
[17:14] <rbalint> stgraber, no tests failed in the archice with udevd disabled in LXC
[17:15] <stgraber> rbalint: presumably because adt tests can't exactly hot plug a usb stick or network device :)
[17:15] <rbalint> stgraber, i think there are ways of testing that
[17:23] <seb128> stgraber,what's the status of NetworkManager-wait-online.service ?
[17:24] <seb128> stgraber, a simpler version is to build the example from https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1914062/+attachment/5459445/+files/bug.c
[17:25] <seb128> stgraber, the enumerate is empty (but works in a focal instance or in hirsute if you comment 	udev_enumerate_add_match_is_initialized(enumerate);)
[17:26] <stgraber> root@u1:~# systemctl -a | grep NetworkManager
[17:26] <stgraber>   NetworkManager-wait-online.service   loaded    inactive dead      Network Manager Wait Online
[17:26] <stgraber>   NetworkManager.service               loaded    active   running   Network Manager
[17:26] <seb128> stgraber, or comment #6 on that bug
[17:28] <seb128> stgraber, ls -al /run/udev/ also, do you get content there?
[17:28] <stgraber> seb128: just the control file
[17:28] <seb128> I think that's showing the issue as well
[17:29] <stgraber> seb128: manually starting the wait unit does hang and eventually fail
[17:29] <seb128> right that's because it waits for udev events which never arrive
[17:29] <seb128> that's basically what the testcase reproduce
[17:29] <seb128> the enumerate is empty
[17:36] <stgraber> seb128: ok, thanks, I'll have brauner sort it out
[17:37] <seb128> stgraber, thanks!
[18:08] <ItzSwirlz> rbasak: I'll look at it. I manually removed stuff from the patch because it contained unneccessary whitespace removals
[18:08] <ItzSwirlz> Is it just cinnamon having the issue?
[18:15] <ItzSwirlz> Oh ok, you already fixed it. I have another debdiff if you need
[18:30] <rbasak> ItzSwirlz: yeah - it was just the cinnamon groovy debdiff
[18:31] <rbasak> ItzSwirlz: you can see what I uploaded at https://launchpad.net/ubuntu/focal/+queue?queue_state=1 and s/focal/groovy/ if you want
[18:42] <ItzSwirlz> ill test it as soon as it gets pushed to -propoesd
[19:32] <kyrofa> So dh-python isn't a dep of python3-all in focal. Is that still the recommended way to package python stuff?
[19:33] <kyrofa> Because I've learned the hard way that adding it as an explicit build dep uses a completely different version of dh-python that behaves very differently
[19:46] <smoser> hey all... figure someone in this channel might know, and google is failing me badly.  I have a cisco cimc that I can get a serial console on over ssh.
[19:46] <smoser> it's "exit SOL" is 'ctrl-x'.
[19:46] <smoser> which is really bad...because i need to change grub cmdline and grub wants ctrl-x to save the edits.
[19:49] <tyhicks> smoser: I thought grub accepted ctrl-x or another key to save and boot. Searching indicates that it is F10.
[19:49] <smoser> i can't seem to get a F10 through either. :-(. i'm not sure if unity or gnome-terminal is grabbing that, but i've even tried sending it with xdotool
[19:51] <tyhicks> Oh, right. You're connecting over ssh. I'm out of ideas.
[19:54] <tyhicks> smoser: maybe this works? https://unix.stackexchange.com/a/53589
[20:04] <ddstreet> smoser does esc-shift-0 work for f10?
[20:04] <ddstreet> that might just be hp bios, though
[20:14] <cjwatson> kyrofa: You want to use the explicit build-dep version, yes
[20:14] <cjwatson> kyrofa: I don't see why it ought to be a dep of python3-all - it isn't part of "all supported Python 3 runtime versions"
[20:15] <kyrofa> cjwatson, fair point. The change made me wonder if there was a better way to be doing it these days, but I should just use the explicit version?
[20:15] <smoser> thanks for suggesting, trying that now.
[20:16] <cjwatson> kyrofa: Yep
[20:16] <kyrofa> cjwatson, thank you :)
[20:16] <cjwatson> I vaguely remember some transition back in (from my POV) the mists of time
[20:16] <kyrofa> cjwatson, yeah that implicit/explicit thing was really rough. My hair was coming out in handfuls
[20:25] <smoser> tyhicks, ddstreet  thanks. ultimately F10 worked. gnome-terminal was eating the f10. "Enable the menu accelerator key (F10 by default)".
[20:25] <smoser> now that is not checked, and F10 works.
[20:25] <smoser> thanks
[22:08] <Eickmeyer> tseliot: You around? Noticing some discrepencies with nvidia-settings and nvidia-modprobe not updated to 460.