[07:56] <alkisg> Hi, where would I file a request to change the development iso names from e.g. jammy-desktop-amd64.iso to e.g. ubuntu-mate-jammy-20211020-amd64.iso?
[07:56] <alkisg> The main point is for the flavor to appear in the iso name; now we can't test/zsync many flavors without manually renaming them...
[08:01] <toabctl> could somebody point me to the livefs build in launchpad for https://cdimage.ubuntu.com/ubuntu-server/daily-live/current/  please?
[08:02] <RikMills> alkisg: zsync -o ubuntu-mate-jammy-amd64.iso http://cdimage.ubuntu.com/ubuntu-mate/daily-live/current/jammy-desktop-amd64.iso.zsync
[08:02] <RikMills> that will read from a named seed file and write back to it
[08:03] <seb128> toabctl, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/impish/ubuntu-server ?
[08:03] <seb128> toabctl, sorry, wrong serie, replace 'impish' :)
[08:04] <RikMills> "This live filesystem has not been built yet. "
[08:04] <toabctl> seb128, for jammy, there are no builds but there are files under cdimage.ubuntu.com
[08:05] <seb128> I guess that's the wrong one then, sorry
[08:06] <seb128> there is also an ubuntu-server-live
[08:06] <alkisg> RikMills: indeed, and wget -O file would also work for those that don't use zsync, but wouldn't it be nicer if they already had appropriate names?
[08:06] <RikMills> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/jammy/ubuntu-server-live/
[08:06] <RikMills> seb128: snap
[08:06] <toabctl> thx!
[08:07] <seb128> checking https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server that's the correct one
[08:08] <RikMills> alkisg: guess I am just used to it being the way it is
[08:08] <alkisg> RikMills: I'd like to file the request somewhere for discussion, even if it's just going to be closed; is that OK? And if so, ...where?
[08:10] <RikMills> alkisg: I would guess the people in #ubuntu-release who look after the ISO builds
[08:10] <alkisg> Thank you!
=== cpaelzer_ is now known as cpaelzer
[09:11] <schopin> I'm looking at merging sshfs-fuse, but the MoM field has a comment stating that fuse3 breaks Kubuntu/Studio iso builds. ANyone knows if it's still the case? ( ginggs perhaps? )
[09:13] <ginggs> schopin: best is to speak to the person who TIL (touched it last) = RikMills
[09:14] <ginggs> i'm only tracking main packages for the fuse2 -> fuse3 transition
[09:15] <schopin> Sure, but I figured you'd be aware of fuse3 breaking ISO builds though ;)
[09:15] <ginggs> i was not :)
[09:15] <RikMills> it is still the case AFAIK. if the 2 -> 3 transition completes this cycle, we can pull in the sshfs-fuse that needs fuse3
[09:15] <seb128> schopin, it's because other components try to pull the other version of fuse in and those are not co-installable
[09:16] <seb128> could we start this transition now?
[09:16] <RikMills> there is a bug for it ginggs?
[09:17] <ginggs> RikMills: LP: #1934510
[09:17] <ubottu> Launchpad bug 1934510 in fuse3 (Ubuntu) "[MIR] fuse3 as a dependency of qemu 6.0 and GNOME apps" [Undecided, Incomplete] https://launchpad.net/bugs/1934510
[09:18] <ginggs> I've just marked it new so the MIR approval team can have a look again
[09:19] <RikMills> hmmm. I thought there was a bug tracking the multiple packages needing porting
[09:21] <seb128> RikMills, there is a mailing list discussion which reference the packages and corresponding bug ids
[09:21] <RikMills> aha, I am probably think of that. thanks
[09:21] <schopin> added the MIR bug to the MoM comment so that other wandering contributors have more info :)
[09:21] <RikMills> thinking
[09:22] <cpaelzer> RikMills:  https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041530.html
[09:23] <RikMills> thanks
[09:26] <ginggs> as far as I can see we have patches for everything
[10:42] <seb128> cpaelzer, re fuse3, if we are confident we will transition during the cycle do you see any objection in promoting the new version and start using it? then we have the cycle to demote the previous one
[12:19] <cpaelzer> seb128: my only concern would be not getting rid of the old one
[12:19] <cpaelzer> seb128: usually that pain is the only thing that makes everyone spend the effort to resolve
[12:20] <cpaelzer> seb128: but that is an "assumption / gut-feeling" thing - on the technical side I agree that it could be promoted now
[12:29] <seb128> cpaelzer, at this point we have the patches we need and we had been blocking flavors and having feature regression in the distro by holiding back, but yeah maybe we can simply just move forward and land the transition ... basically MIR team position is +1 to land and promote if the transition is complete, right?
[12:38] <cpaelzer> seb128: how about:
[12:38] <cpaelzer> seb128: "+1 to land and promote early (unblocking a lot) if the transition to demote fuse(2) can and will be completed inside the 22.04 cycle"
[12:38] <cpaelzer> I can also bring this up in the team meeting to ensure to have concsensus on this
[12:38] <seb128> cpaelzer, sound great thanks
[12:39] <seb128> no huirry, it can wait for your next meeting if you prefer to check there
[12:44] <cpaelzer> seb128: I have asked paride to check and summarize all the sub-projects status in regard to the solutions we have sent
[12:44] <cpaelzer> seb128: and have added the topic to next Tuesdays meeting agenda
[12:44] <seb128> cpaelzer, thanks!
[12:45] <cpaelzer> seb128: it is great IMHO that you and the other people here brought it up early, because we will want a security re-evaluation and that needs time
[12:46] <cpaelzer> so agreeing on doing things early in the cycle will help to get this happen anytime soon
=== genii-core is now known as genii
[14:51] <rbasak> vorlon: I see you merged ifupdown. What's its status in Ubuntu now? Is it still being maintained/supported for some use case?
[14:51] <rbasak> I asked because bug 1628591 is in the server team's "bug housekeeping" list, and I want to mark it Won't Fix.
[14:51] <ubottu> Bug 1628591 in ifupdown (Ubuntu) "ifup & ifdown don't work for vlan devices when raw device name is the new 'enp' convention" [Undecided, Confirmed] https://launchpad.net/bugs/1628591
[14:51] <vorlon> rbasak: universe-only, someone can install it but it's not really supported; there are use cases unaddressed by netplan for which it may be useful, e.g. netplan won't do ppp
[14:52] <vorlon> yeah I would definitely wontfix any bugs related to interface types supported by netplan
[14:52] <rbasak> Thanks
[14:56] <sergiodj> rbasak: related: https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1718227
[14:56] <ubottu> Launchpad bug 1718227 in clamav (Ubuntu) "replacement of ifupdown with netplan needs integration for /etc/network/if{up,down}.d scripts" [Medium, Triaged]
[14:57] <rbasak> sergiodj: yeah that's all the networkd-dispatcher stuff?
[14:57] <rbasak> I don't follow how that's related though, apart from being related to the netplan/networkd transition in general.
[15:00] <sergiodj> rbasak: yeah, related to the broader topic of dropping ifupdown and replacing it with netplan
=== mirespace_ is now known as mirespace
[15:44] <jawn-smith> seb128: Feel like looking at an SRU we had previously discussed? LP: #1913656
[15:44] <ubottu> Launchpad bug 1913656 in ghostscript (Ubuntu Focal) "Fix for Ghostscript 9.50 upstream bug needs to be back-ported" [Medium, In Progress] https://launchpad.net/bugs/1913656
[15:44] <seb128> jawn-smith, not today but I will try to nag Till or review it if he still doesn't reply
[15:44] <jawn-smith> thanks!
[20:54] <ahasenack> vorlon: hi, is there some other documentation for the pam-auth-config profile file format, or is this it? https://wiki.ubuntu.com/PAMConfigFrameworkSpec
[20:55] <vorlon> ahasenack: as far as I recall, that's it