tobhe changed the topic of #ubuntu-asahi to: Ubuntu-Asahi development | Github: https://github.com/UbuntuAsahi | Logs: https://oftc.irclog.whitequark.org/ubuntu-asahi
<tobhe[m]> am publishing the meta package updates now
<tobhe[m]> I feel like I have tested enough
<tobhe[m]> even did a jammy -> noble upgrade in two steps
kaazoo has joined #ubuntu-asahi
<kaazoo> tobhe: Hi, you mentioned you created a dummy network device to work around the boot delay. Can you post an example please? My ethernet interface is on a USB-C hub, which seems to not be ready when systemd-networkd expects it.
<kaazoo> Found this related bug: https://bugs.launchpad.net/netplan/+bug/2060311
kaazoo has quit [Quit: Leaving.]
kaazoo has joined #ubuntu-asahi
<kaazoo> Meanwhile, I used "sudo systemctl edit systemd-networkd-wait-online.service" to only wait for loopback interface, which seems to get rid of the delay:
<kaazoo> [Service]
<kaazoo> ExecStart=/usr/lib/systemd/systemd-networkd-wait-online -i lo:carrier
<kaazoo> What's strange is that cloud-init seems to have generated /etc/netplan/50-cloud-init.yaml which won't get updated since I disabled cloud-init.
kaazoo has quit [Quit: Leaving.]
kaazoo1 has joined #ubuntu-asahi
kaazoo1 has quit []
<tobhe[m]> unfortunately I didn't really have a solution. I previously had a custom netplan config to add a dummy interface. deleting that fixed my issues
kaazoo has joined #ubuntu-asahi
<tobhe[m]> but I think I deleted all of /etc/netplan/* in the process
kaazoo has quit []
kaazoo has joined #ubuntu-asahi
<tobhe[m]> but that is on my laptop where i don't really use ethernet. on the m1 mini there doesn't seem to be any issue
<kaazoo> I moved /etc/netplan/50-cloud-init.yaml to a new filename and added "renderer: NetworkManager", like in the other wifi-related yaml files in that directory.
kaazoo has quit []
kaazoo has joined #ubuntu-asahi
<kaazoo> OK, I still see "systemd-networkd[1861]: eth0: Could not process link message: No such device or address" in the logs, but there is no boot delay anymore. The interface is brought up and everything seems to work, so good enough for me now.
<tobhe[m]> after the latest package update everyone should have a /etc/apt/sources.list.d/ubuntu-asahi.sources which is pinned at 1001 prio and a /etc/update-manager/release-upgrades.d/ubuntu-asahi.cfg that make sure it survives a release upgrade
<kaazoo> OK, I got those 2 files.
kaazoo has quit [Quit: Leaving.]
<tobhe[m]> perfect. something I didn't want to do automatically at this point is removing the old ~tobhe/asahi ppa
<tobhe[m]> because it would be unfortunate if we locked ourselves out from pushing updates
<tobhe[m]> but at this point I expect everything to go through the ~ubuntu-asahi team on launchpad instead
<tobhe[m]> hm the protection-domain-mapper conflict seems to not work as intended
tobhe_ has quit [reticulum.oftc.net helix.oftc.net]
moon127 has quit [reticulum.oftc.net helix.oftc.net]
tobhe[m]1 has quit [reticulum.oftc.net helix.oftc.net]
popey[m] has quit [reticulum.oftc.net helix.oftc.net]
john-cabaj[m] has quit [reticulum.oftc.net helix.oftc.net]
wildwestrom[m] has quit [reticulum.oftc.net helix.oftc.net]
moon127 has joined #ubuntu-asahi
tobhe[m]1 has joined #ubuntu-asahi
john-cabaj[m] has joined #ubuntu-asahi
wildwestrom[m] has joined #ubuntu-asahi
tobhe_ has joined #ubuntu-asahi
popey[m] has joined #ubuntu-asahi
sespiros[m] has quit [Ping timeout: 485 seconds]
eslerm[m] has quit [Ping timeout: 480 seconds]
jcverdie[m] has quit [Ping timeout: 480 seconds]
Saviq[m] has quit [Ping timeout: 480 seconds]
jmeosbn[m] has quit [Ping timeout: 480 seconds]
throwaway02020[m] has quit [Ping timeout: 480 seconds]
tobhe[m] has quit [Ping timeout: 480 seconds]
GarethWoolridge[m] has quit [Ping timeout: 480 seconds]
popey[m] has quit [Ping timeout: 607 seconds]
tobhe[m]1 has quit [Ping timeout: 607 seconds]
john-cabaj[m] has quit [Ping timeout: 592 seconds]
wildwestrom[m] has quit [Ping timeout: 607 seconds]
tim[m]12 has quit [Ping timeout: 480 seconds]
john-cabaj[m] has joined #ubuntu-asahi
<john-cabaj[m]> do-release-upgrade isn't finding a new Ubuntu release for me
tobhe[m] has joined #ubuntu-asahi
<tobhe[m]> with -d?
<john-cabaj[m]> That found it
<tobhe[m]> aha, thx. will update my github comment
<john-cabaj[m]> tobhe[m]: Yep, this is what I'm following
<john-cabaj[m]> I hardly ever update my main machine, so the do-release-upgrade intricacies are lost on me
<tobhe[m]> I think it will at some point work without -d but is currently blocked to fix some last bugs. 22.04 will only go to 24.04 once 24.04.1 is out
<tobhe[m]> or sth like that
<tobhe[m]> I have raised the libreoffice issue with launchpad and ubuntu-devel
<john-cabaj[m]> Upgrade complete - looking good.
<john-cabaj[m]> Think I'll keep my MacBook as my forward devel machine and work computer on LTS
<tobhe[m]> keeping the mac up-to-date sounds like a good idea 🙂 especially when you're building new kernels
<john-cabaj[m]> I'm definitely forced to keep it up to date. The above was just more rationale for why my Thinkpad stays behind.
<tobhe[m]> I am very bad in sticking to LTSs. Usually the mac stays on the latest release and the desktop goes to development release as soon as it is feasible
<john-cabaj[m]> Now that Asahi is on 6.8, I really hope they work to figure out this idle power issue. My computer died over the weekend on suspend
arcticp[m] has joined #ubuntu-asahi
<tobhe[m]> I had my battery drain way too fast today and wondered if we have a regression
<tobhe[m]> turned out I had vms running in lxd
<tobhe[m]> the downside of fanless. you don't hear when your machine is busier than it should be
popey[m] has joined #ubuntu-asahi
<popey[m]> My MBA isn't heavily used now I have a work M3 MBP. So if there's anything anyone wants me to test, or leave running or whatever on the m1, lemme know
<tobhe[m]> uh nice upgrade 🙂 testing the release upgrade was already a big help. Thanks!
<popey[m]> 🙏
<tobhe[m]> eslerm: added more contect to the protection-domain-mapper bug report https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2062667
eslerm[m] has joined #ubuntu-asahi
<eslerm[m]> nice find, thanks
<eslerm[m]> I'm installing mantic to a raspberry pi to do some more exploring
<eslerm[m]> V wants a specific file that could be disabled, which is likely the service file you mention
<tobhe[m]> vorlon might have resolved the libreoffice issue. looks like launchpad just failed to publish them for some reason
<john-cabaj[m]> That actually makes perfect sense
<tobhe[m]> classic launchpad solution: binary copy to self
GarethWoolridge[m] has joined #ubuntu-asahi
<GarethWoolridge[m]> ah nice - I just purged libreoffice and then installed the snap after d-r-u.
<GarethWoolridge[m]> Im sure I'll regret that given how large that snap seems to be and how long it takes to download, but hey "the future".
<tobhe[m]> GarethWoolridge[m]: > <@moon127:ubuntu.com> ah nice - I just purged libreoffice and then installed the snap after d-r-u.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/eLHWruNxKDusATQeixjXsAMi>)
<tobhe[m]> and libreoffice is indeed fixed
<eslerm[m]> <john-cabaj[m]> "Think I'll keep my MacBook as my..." <- currently, we only support ubuntu releases for 9 months
<eslerm[m]> should we extend that to 9 months and the most recent LTS?
<eslerm[m]> I image that there change less than there had been for jammy (rust, etc)
<john-cabaj[m]> I don't think we can always support the most recent LTS for the same reason we couldn't support Jammy
<john-cabaj[m]> I don't think it's so much a kernel limitation as it is the package dependencies
<eslerm[m]> perhaps we could offer minimal or server support to LTS?
<john-cabaj[m]> The problem with Jammy was continuing to support new versions of rust
<john-cabaj[m]> And I think there was the wireplumber issues or something, too
<eslerm[m]> the one user group I know of is ROS 2, who pin to Ubuntu LTS releases
<eslerm[m]> in their case, mesa and audio are not a priority
<eslerm[m]> they want to use apple devices to have fast arm64 build machines
<eslerm[m]> maybe it is better to keep our current support window, and (after 9 months) keep offering LTS as an unsupported EXPERT=1 install option
<john-cabaj[m]> I can keep copying the kernel binaries to the latest LTS release no problem
<tobhe[m]> imo ROS is still a bit of a non issue. Nothing forces you to run the same release bare metal when there are vms and containers
<tobhe[m]> i'd say we decide that once we approach 24.10
<eslerm[m]> thanks John and Tobias
<tobhe[m]> we are probably in a nicer place now because we can just freeze noble in terms of features at some point
<tobhe[m]> 22.04 to 24.04 was just too much change
<tobhe[m]> the other issue is testing. anything that none of us use is tricky
<tobhe[m]> new 6.8 is actually tagged on github https://github.com/AsahiLinux/linux/tags
<john-cabaj[m]> Yeah, they're outpacing noble right now
<tobhe[m]> 🤯
<john-cabaj[m]> Makes it tricky to figure out the actual patchsets
<tobhe[m]> now what do I do next. Fix a bug I found in 22.04, figure out why update manager segfaults on 23.10 or try to build installer images
<tobhe[m]> create issues to track them sounds like a reasonable next step
<tobhe[m]> <tobhe[m]> "new 6.8 is actually tagged on..." <- aaand one more tagged
<john-cabaj[m]> Haha
<john-cabaj[m]> We need to develop a regular cadence or something
<john-cabaj[m]> Take any updates from the previous week. Prep on Friday and let build over the weekend. Test on weekend (if people can) or Monday. Release Monday/Tuesday
<tobhe[m]> I sure hope it slows down a bit at some point