[07:17] <cpaelzer> paride: as mentioned yesterday https://salsa.debian.org/debian/irqbalance/-/merge_requests/3
[07:37] <paride> hi cpaelzer , I'm looking at what we have...
[07:40] <paride> cpaelzer, all the machines I have access to are haswell
[07:42] <paride> oops, wrong channel :)
[07:46] <cpaelzer> ok, thanks paride
[08:47] <paride> cpaelzer__, commented back on the irqbalance PR, I changes some more things on the package
[08:48] <paride> cpaelzer__, btw I think you can now remove the ugly -guest suffic from your salsa account if you want
[08:52] <paride> cpaelzer_, and I enabled the build-dep on libnuma-dev on armel/armhf, as now the package is available on those archs
[09:29] <cpaelzer> paride: that is ok with me
[09:29] <cpaelzer> thanks paride
[10:03] <ackk> sil2100, hi, do I need to do anthing for this SRU to progress: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1878769 ?
[10:18] <sil2100> ackk: hello! No, everything is in order, now it just needs someone reviewing it from the SRU queue - I am doing my +1 maintenance shift right now so I can't, but I can look at it afterwards (if no one else pick it up first)
[10:18] <sil2100> *picks
[10:28] <ackk> sil2100, thanks. should I ping someone else or will it be picked up automatically?
[10:29] <juliank> ackk: it will be picked up eventually, but there are like 30 other SRUs in the queue in front of it
[10:29] <juliank> :D
[10:29] <ackk> ok :)
[10:29] <sil2100> ackk: it will be picked up eventually!
[10:30] <juliank> ackk: That said, vanguards are listed on https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
[10:30] <ackk> cool, thanks
[10:57] <RAOF> ackk: And the vanguards are generally happy to receive pings, because it means you'll be around for any questions we happen to have :)
[10:58] <ackk> RAOF, :)
[13:06] <sunweaver> Wimpress: popey: hi. I am about to package "url-dispatcher" from the UBports upstream location for Debian as part of getting the Lomiri fork of Unity8 into Debian.
[13:08] <sunweaver> The Unity8 components forked as Lomiri have a clear upstream location, but url-dispatcher does not. Is ulr-dispatcher still used in Ubuntu somewhere? The Ubuntu Indicators link against it afaik. Would it be ok, to use UBports as the (new) upstream for url-dispatcher? Or is a fork with full rename required from Canonical's point of view?
[13:09] <sunweaver> I probably have to modify some parts of the upstream sources (interactive with lomiri-app-launch instead of ubuntu-app-launch, and such...).
[13:10] <sunweaver> Who would be best to address this with?
[13:18] <blaze> better proceed with unity8 rather than do a rename
[13:19] <sunweaver> blaze: fork has already happened.
[13:19] <sunweaver> https://ubports.com/blog/ubports-blog-1/post/lomiri-new-name-same-great-unity8-265
[18:50] <Odd_Bloke> seb128: I have a bug in the desktop installer that's been filed directly against curtin; I'd like you to take a look at it before we dig into it (because you may recognise it as something higher level); should I just add a ubiquity task, or would you prefer a task on something else?
[19:31] <sidfaber> I have an issue trying to do a headless boot of Raspberry Pi 3A/B with Ubuntu 18.04 (ubuntu-18.04.4-preinstalled-server-arm64+raspi3.img.xz). I set a static IP on a wireless network in network-config before booting, but the Pi never connects to the network the first time. If I wait long enough for cloud-init to complete it always connects after a powering cycle.
[19:31] <sidfaber> cloud-init gives a warning "network_state.py: wifi configuration is only available to distros with netplan rendering support"; this seems similar to https://bugs.launchpad.net/cloud-init/+bug/1814297 but I triple-checked the network-config yaml. Any thoughts/suggestions?
[19:33] <waveform> sidfaber, there's a known issue that cloud-init (or possibly netplan) fails to configure wifi on first boot; LP: #1870346
[19:34] <sidfaber> waveform, thanks for the pointer!
[19:36] <sarnold> waveform: oh wow, thanks; I suspect that contributed to the hours I spent trying to get my rpi3b+ working a few months ago. sigh.
[19:36] <waveform> sidfaber, we did dig into this further last week and I need to update that issue with some more info for the cloud-init team; if I recall correctly (need to check my notes) we found it's an issue with cloud-init using netplan generate (instead of netplan apply) when activating interfaces at that stage of boot (in the case of ethernet, this works but not wifi as it involves changing some of systemd's units with then requires a daemon-reload)
[19:36] <waveform> *which then requires
[19:41] <sidfaber> waveform, lmk if you need help troubleshooting. I've been working up tutorials / howto's for installing ROS on a RasPi with 18.04--ROS makes it seem waaaay more difficult than it really is.
[19:43] <sidfaber> Headless wifi boot seems fairly common for roboticists. For now I'll just suggest a reboot after ~5min. I noticed if you reboot to soon the ssh key materials don't get created so you still can't connect.
[19:44] <waveform> sidfaber, will do - thanks; and yes, it's a definite "major bug on my list" - unfortunately it's also one that's taken ages to get to the bottom of (cloud-init, netplan, and systemd have all been blamed at various stages but I *think* we're finally near the bottom of it!)
[19:45] <waveform> oh, incidentally if you want to reboot at a reasonable point - add reboot in the runcmd section of user-data
[19:45] <waveform> sidfaber, ^^
[19:47] <sidfaber> waveform, that sounds like a good idea, let me give it a shot, thanks
[19:47] <waveform> sidfaber, or you can stick "netplan apply" under "runcmd" and that'll bring up wifi without rebooting (though you may want to reboot anyway for whatever reasons). Unfortunately that still won't bring up wifi soon enough to succeed in things like ssh_import_id
[19:49] <sidfaber> 👍
[19:58] <CarlFK> waveform: in trying to track down a pi4 boot problem, vim config.txt ... line  34 # include syscfg.txt
[19:59] <waveform> CarlFK, fire away
[19:59] <CarlFK> that causes kernel paniac  https://matrix.org/_matrix/media/r0/download/matrix.org/mAkgWKDDzCcPirsMJhUTsEGw
[20:00] <CarlFK> a simple fix don't do that.  but I was surprised, and maybe someone cares.
[20:00] <waveform> CarlFK, what's in your syscfg.txt that's causing that?
[20:00] <CarlFK> http://paste.ubuntu.com/p/wgTt4Wjn67/
[20:01] <CarlFK> http://cdimage.ubuntu.com/releases/20.04/release/ubuntu-20.04-preinstalled-server-armhf+raspi.img.xz
[20:01] <CarlFK> flash # that line, boot, crash.
[20:02] <waveform> oh I see what you mean, in *commenting* that line it causes a crash - urgh, I bet I've forgotten something in config.txt
[20:04] <CarlFK> I would think should boot without any config files and have defaults baked in, but meh, im personally not worried about it.
[20:05] <CarlFK> i only brougt it up as I saw pi chatter
[20:05] <waveform> CarlFK, yes ... I have; cmdline= is wrong in base config.txt. Ohhh, that's right - the fix *appears* trivial (fix config.txt), but it's more complex than that because of the upgrade story. Incidentally, it won't boot with a completely blank config as we don't use the default kernel filenames, and there's (currently) an initrd (plus other reasons on arm64)
[20:07] <waveform> CarlFK, still, that does need fixing (thanks for reminding me!) - unfortunately it means messing around in various other places to take account of upgraders, which means a certain amount of care/time is needed
[20:08] <CarlFK> glad I mentioned it.  I had just decided it wasn't worth chasing
[20:09] <CarlFK> is there a daily build? the problem I was poking at involves plugging in a board to the first 20 pins and that causes https://matrix.org/_matrix/media/r0/download/matrix.org/FTyisRDcMbaLibGuptMhoRUC
[20:10] <CarlFK> but it boots fine with debian, so that's my fix for that.