[11:03] <slyon> @pilot in
[13:48] <ahasenack_> tjaalton: hi, could you please kick CI in https://salsa.debian.org/freeipa-team/bind-dyndb-ldap/-/merge_requests/8 ? I don't know why it's not doing it automatically
[13:48] -ubottu:#ubuntu-devel- Merge 8 in freeipa-team/bind-dyndb-ldap "d/t/dyndb-ldap: allow writing to the dns tree" [Opened]
[13:48] <ahasenack_> my branch does have the gitlab-ci.yml file in debian/
[13:48] <ahasenack_> and I branched off salsa/master
[13:49] <ahasenack_> I vaguely remember this happening in another project, but don't remember what I did to fix it
[13:50] <ahasenack_> I think I had to do something in my fork
[13:52] <tjaalton> ahasenack_: maybe try the ci settings, and make it use this path
[13:53] <tjaalton> from your fork
[13:53] <ahasenack_> hm, that might be it
[13:54] <ahasenack_> starting to remember something
[13:54] <andersson123> if there's anyone online with the means to do so, could you please trigger some github autopkgtests for me please and notify me if/when you do? thanks :)
[14:00] <ahasenack_> tjaalton: fixed, it's running now
[14:05] <tjaalton> ahasenack_: nice
[14:45] <Eickmeyer> Dang, missed nteodosio.
[14:46] <Eickmeyer> ahasenack_: I got a drive-by in #ubuntustudio-devel from ntedosio and he has a patch to fix blender in bug 2033618. Thoughts?
[14:46] -ubottu:#ubuntu-devel- Bug 2033618 in blender (Ubuntu) "Please update Blender to 3.6.2" [Undecided, Confirmed] https://launchpad.net/bugs/2033618
[14:47] <ahasenack_> Eickmeyer: the patch is to fix the s390x build?
[14:47] <Eickmeyer> Yes.
[14:47] <Tach> Hi guys, can I ask here questions about package building ?
[14:48] <ahasenack_> Eickmeyer: would want to see upstream's opinion, afaik there is an upstream bug about this, right?
[14:48] <Eickmeyer> ahasenack_: I haven't investigated, tbh.
[14:48] <Eickmeyer> Time hasn't been on my side.
[14:48] <ahasenack_> https://bugs.launchpad.net/ubuntu/+source/blender/+bug/2030291 this is the ftbfs bug
[14:48] -ubottu:#ubuntu-devel- Launchpad bug 2030291 in blender (Ubuntu) "FTBFS on s390x and armhf" [Undecided, New]
[14:49] <ahasenack_> the other one should be marked as a duplicate of this one I think
[14:49] <ahasenack_> although, hm, this ftbfs bug is on 3.4.1
[14:49] <Eickmeyer> Hmm...
[14:49] <ahasenack_> well, 3.6.2 is stuck in proposed due to ftbfs on s390x and armhf, same arches
[14:49] <ahasenack_> oh, and risc
[14:50] <RikMills> Eickmeyer: letes see how the patch does
[14:50] <RikMills> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3997/+sourcepub/15141651/+listing-archive-extra
[14:50] <RikMills> *lets
[14:50] <Eickmeyer> So, more than s390x.
[14:50] <ahasenack_> there was an upstream bug about this, I don't see it in linked in either bug
[14:50] <Eickmeyer> Right.
[14:51] <Eickmeyer> RikMills: So, wait-and-see what it does in bileto.
[14:51] <Tach> does anyone know why there - and how made - there is a seperate package clamav-freshclam instead of all combined in one ?
[14:52] <ahasenack_> Tach: it's one source package (clamav) that produces multiple binary packages
[14:52] <ahasenack_> Tach: see the control file here: https://git.launchpad.net/ubuntu/+source/clamav/tree/debian/control
[14:52] <ahasenack_> look for the "Package:" sections
[14:53] <RikMills> Eickmeyer: yeah, if riscv64 doesn't build there then more fixing would be needed
[14:53] <ahasenack_> Tach: then the various *.install files in https://git.launchpad.net/ubuntu/+source/clamav/tree/debian, one for each package
[14:53] <Tach> ahasenack_ ok so I should be able to produce them as well ?
[14:53] <ahasenack_> there are more details, but this is the start
[14:53] <ahasenack_> Tach: you build the source package. It will produce the individual *.deb binary packages when built
[14:54] <ahasenack_> Tach: if you are new to package building, there is a lot to learn. Maybe start here: https://github.com/canonical/ubuntu-maintainers-handbook
[14:54] <Tach> ahasenack_ ok, nice thanks! Now I need to find the same thing for alpine :)
[14:54] <Tach> ahasenack_ yeah learning is not the issue, I build it from source myself but all was in
[14:56] <Tach> ahasenack_ in my believing freshclam can work on it's own, or not ?
[14:56] <ahasenack_> Tach: I don't recall, it does need to update a db, so on its own it doesn't help, but clamav could be installed without it, hence the packaging split
[14:57] <Tach> ahasenack_ yeah, I want to have seperate workers for updating, that's why
[14:58] <Eickmeyer> ahasenack_: Checking upstream blender, I cannot find the upstream bug nor could I find an upstream bug in Debian, even though they have several missing builds on several archs.
[15:00] <lvoytek> @pilot in
[15:03] <RikMills> Eickmeyer: I see relevant PR upstream in blender that appears to be same fix
[15:04] <RikMills> https://projects.blender.org/blender/blender/pulls/106575
[15:04] -ubottu:#ubuntu-devel- Pull 106575 in blender/blender "CUdeviceptr and hipDeviceptr_t unsigned int loses precision fix for ppc64le" [Merged]
[15:04] <Eickmeyer> No wonder I couldn't find it, it doesn't have a relevant arch.
[15:06] <cpaelzer> oh wow, so many pilot out failing - I hop enot all had outage and then forgot
[15:06] <cpaelzer> @pilot out
[15:06] <Eickmeyer> cpaelzer: XD
[15:06] <slyon> @pilot out
[15:07] <cpaelzer> thanks lvoytek for reminging :-)
[15:07] <RikMills> Eickmeyer: yeah, similar fix, not the same :/
[15:08] <Eickmeyer> ahasenack_: If Nathan's patch works, should we roll with that or should we patch-in the upstream PR? Because, at this point in the cycle, I think the better way to go is what we know is going to work first.
[15:09] <ahasenack_> I would insist a bit with upstream and this patch we got, maybe there is a quick response
[15:09] <RikMills> Eickmeyer: upstream PR looks already included
[15:09] <ahasenack_> personally I'm not good at these types of fixes, so I can't properly evaluate them
[15:09] <Eickmeyer> Oh, so the upstream PR is already in there, but not working.
[15:09] <ahasenack_> I'm wary of "lone-ranger" types of patches, I would at least like to see it submitted upstream
[15:10] <Eickmeyer> Agreed, if Nathan's patch works it should definitely be submitted upstream.
[15:10] <RikMills> and get in debian so we just have to sync
[15:10] <Eickmeyer> He saw it as a compiler error, per what he said in #ubuntustudio-devel.
[15:12] <RikMills> I think Nathan's patch may just be extending the PR fix to s390x
[15:12] <Eickmeyer> Well, it FTBFS on armhf, but that's no surprise as blender doesn't support 32-bit.
[15:15] <Eickmeyer> I can get it into Debian, I'm on the multimedia-team, so I have access to salsa there.
[15:15] <ahasenack_> yeah, don't worry about armhf
[15:15] <Eickmeyer> Upload rights, no. Salsa, yes.
[15:15] <ahasenack_> I think it was even removed
[15:15] <Eickmeyer> ahasenack_: You're right.
[15:16] <RikMills> looks like riscv64 will take about 6hrs
[15:16] <RikMills> or at least that is how long the build in proposed took before it failed
[15:17] <Eickmeyer> No surprise there.
[15:18]  * RikMills wanders off to do other things
[15:19] <ahasenack_> if previous risc build failed, it won't be a problem if it fails again. But s390x was ok before, so it needs to build now
[15:20] <RikMills> ahasenack_: the riscv64 build of the blender version in release pocket succeeded, so this need to as well
[15:20] <ahasenack_> oops
[17:17] <Eickmeyer> juliank: I confirmed GRUB_FLAVOUR_ORDER works in 23.04 as you said. I just uploaded a new version of ubuntustudio-default-settings which sets that as "lowlatency" in a .cfg file in /etc/default/grub.d so it effectively does what we had before.
[17:18] <juliank> +1
[17:18] <juliank> I'll upload the grub tomorrow I think
[17:19] <Eickmeyer> juliank: +1
[17:20] <Eickmeyer> I did make the variable "lowlatency $GRUB_FLAVOUR_ORDER" so that it prepends if someone wanted to do their own order with other kernel flavors for whatever reason.
[17:20] <Eickmeyer> Because idk.
[19:00] <lvoytek> @pilot out
[19:27] <sergiodj> I know apt-key was deprecated some time ago, but I don't remember hearing the same about apt-add-repository.  now a user is asking about it, and what they should use instead.
[19:28] <Eickmeyer> add-apt-repository is the correct one. It adds keys the correct way.
[19:29] <bdmurray> add-apt-repository or apt-add-repository? ;-)
[19:29] <Eickmeyer> One links to the other, iirc.
[19:29] <sergiodj> yeah, one links to the other
[19:30] <Eickmeyer> Probably because nobody could ever remember.
[19:30] <sergiodj> aptly-add-this-apt-repository
[19:30] <Eickmeyer> XD
[19:31] <sergiodj> thanks, Eickmeyer . I'll reply to the user that, to the extent of my knowledge, add-apt-repository will live on
[19:31] <Eickmeyer> If it doesn't there's a lot of PPA owners that are going to get irked real quick. Imagine....?
[19:32] <sergiodj> that was my thought, too.  and why I found it strange to hear about its deprecation
[19:33] <vorlon> I managed to mis-edit my commandline the other day and invented 'add-remove-repository'
[19:33] <vorlon> it didn't work
[19:33] <vorlon> (also it's spelled 'add-apt-repository -r', so)
[19:34] <vorlon> the '-r' stands for 'disable'
[19:34] <cjwatson> Some specific behaviours of add-apt-repository are deprecated
[19:34] <vorlon> sergiodj: this is the second time there's been a wrong rumor about add-apt-repository deprecation.  I think last time it was brought up, we managed to trace it to an ambiguously-written article
[19:35] <cjwatson> Like the mode where it accepts an entire sources.list line as an argument
[19:35] <vorlon> (second time that it's reached me, that is)
[19:35] <sergiodj> vorlon: if it's an article by DigitalOcean, then I found the same one
[19:35] <cjwatson> (without an option to tell it the format, anyway)
[19:35] <vorlon> yes
[19:35] <vorlon> sergiodj: that's the one
[19:36] <Eickmeyer> vorlon: That's not at all surprising. Found an article stating Ubuntu Studio has 5 year support for LTS releases.
[19:36] <sergiodj> this user mentioned "several blog posts", but I believe he might be referring to the same article
[19:41] <vorlon> juliank: do we need a blog post that anti-deprecates add-apt-repository :/
[19:42] <juliank> vorlon: People shouldn't use add-apt-repository for non-LP going forward, because it quite obviously doesn't take long multi-line deb822 sources.
[19:42] <juliank> Well non-shortcuts
[19:42] <Eickmeyer> add-apt-repository: "Rumors of my death have been greatly exaggerated."
[19:42] <vorlon> well, ok
[19:43] <juliank> apt add-sources will take a .sources https url to add but it's not merged yet
[19:43] <juliank> :D
[19:43] <vorlon> there seems to be confusion nevertheless
[19:43] <vorlon> about the current state
[19:44] <juliank> Everything is somewhat confusing right now, I admit
[19:44] <vorlon> we clearly should frame this as deprecating non-Launchpad repositories
[19:44] <vorlon> "what should I use instead?" -> "Launchpad"
[19:44] <juliank> I don't think we have told anyone it's deprecated to be fair
[19:45] <juliank> Probably we should make it take .sources urls to add as well, but I haven't finished thinking about the template variables I want to support and don't want two standards
[19:46] <juliank> Non-deb822 sources are not deprecated yet, and manage just fine, it's just that it's preferable to use deb822 sources with signed-by fields, preferably embedded signed-by for third-party repositories without a keyring file installed in a deb
[19:49] <sergiodj> I recently worked on a documentation page about third party APT repos; you might be interested in reading it: https://discourse.ubuntu.com/t/third-party-repository-usage/37974
[19:49] <sergiodj> (this is where the add-apt-repository question came from)
[19:51] <juliank> sergiodj: Needs a couple adjustments for best practices, e.g. I added /etc/apt/keyrings recently (older systems you have to create it yourselves) to not have admin write files manually in /usr; and probably you want wget -O- ... | sudo tee /etc/apt/keyrings/foo.gpg; also notes about ascii-armored keys needing a .asc extension and unarmored a .gpg
[19:52] <juliank> apt-transport-https has been an empty metapackages for ages now, not sure when it switched
[19:53] <sergiodj> juliank: ack. I can make the adjustments later; feel free to mention whatever is needed here
[19:53] <juliank> Ah yes, and add-apt-repositry doesn't take a name for a sources.list.d file but appends full deb lines (rather than shortcuts) to the main source.list which makes it icky
[19:56] <Eickmeyer> juliank: That hasn't been my experience. I've seen it add whole files to sources.list.d.
[20:02] <juliank> Eickmeyer: it does for PPAs, but not if you pass it "deb http://foo.example.com/ bar somecompnent" lines
[20:03] <juliank> And it does for cloud archives and other kinds of shortcuts it understands
[20:03] <Eickmeyer> juliank: Oh, I see. Yeah, that's no good.
[20:03] <juliank> I don't have the rewriting from legacy to deb822 at that point yet
[20:03] <juliank> Then it could rewrite the given entry in deb822 and write it to a .sources file
[20:03] <juliank> :D
[20:03] <juliank> Scary, huh
[20:04] <Eickmeyer> Very. When I was working at my previous job, I saw them manipulating sources.list and I said, "You're doing WHAT?!?"
[20:05] <Eickmeyer> Fixed that behavior as soon as I could.
[20:05] <juliank> My goal is to represent .list legacy format as deb822 in the service and python APIs eventually
[20:05] <juliank> it will be fun
[20:06] <Eickmeyer> Yeah, I imagine.
[20:06] <juliank> It's the inverse of the current approach I'm stuck with now
[20:06] <juliank> But I'm stuck with the current approach somewhat to actually make software-properties work as is
[20:06] <Eickmeyer> That makes sense, unfortunately.
[20:06] <juliank> It produces some pretty garbled up ubuntu.sources if you edit it, as it pulls entries apart, but it can't always merge them back together
[20:07] <juliank> like if you change the mirror for -updates via API but not for release pocket, it splits one paragraph into two, but then if you change mirror back in a later run, it won't merge back into one paragraph
[20:08] <juliank> Making the API less sophisticated and the rendering less sophisticated so it represents everything as deb822 sources with just hints in the UI should improve that
[20:08] <juliank> But arguably I should learn some flutter and write a mockup of how I'd expect a deb822-only world to be managed
[20:09] <Eickmeyer> So, are we talking machine-readable but not necessarily human-readable?
[20:09] <juliank> I mean everything is both
[20:09] <juliank> But for the GUI experience, I want you to actually see the deb822 format
[20:09] <juliank> But then get hints
[20:09] <Eickmeyer> I see.
[20:10] <juliank> e.g. the UI shows you "Types: deb", but offers a "x" on deb to remove it and a suggested "deb-src" on the right you can add
[20:10] <juliank> likewise for "Components" it shows "x" on existing components, and a + button and maybe some suggested ones if there's space
[20:11] <Eickmeyer> That's much better than the current format where it shows the deb-src underneath the deb.
[20:11] <juliank> And for "URIs" you get a drop-down menu for each URI that's an official mirror
[20:11] <Eickmeyer> My eyes glaze-over sometimes while trying to parse that screen in my head.
[20:11] <juliank> And um an Ubuntu logo attached to it or something?
[20:11] <Eickmeyer> For Ubuntu repositories, absolutely.
[20:11] <juliank> "This is an offical repository"
[20:12] <juliank> A launchpad logo for PPAs maybe
[20:12] <Eickmeyer> Unless, of course, you're evil like me and dpkg-divert the logo. :D
[20:13] <Eickmeyer> Either way, it's official with an official logo.
[20:13] <juliank> I guess most people know that experience from "tags" or "labels" in various apps
[20:13] <juliank> That pattern makes sense for many deb822 lines
[20:13] <Eickmeyer> Yes. Synaptic is very good at that.
[20:17] <juliank> Oh god synaptic also needs a daemon I forgot about this somewhat
[20:17] <Eickmeyer> Glad I could inadvertently remind?
[20:17] <juliank> synaptic was the reference client for the last aptd proposal since it's very powerful
[20:18] <juliank> but the new daemon I want to make was supposed to be a root-only varlink daemon
[20:18] <juliank> Hmm
[20:18] <juliank> I guess I could implement a common services class and provide both varlink and dbus
[20:19] <Eickmeyer> One thing that would be nice is if Synaptic wouldn't ask for a password until "apply" was clicked.
[20:19] <juliank> Right that's what it needs a low-level apt daemon for
[20:19] <Eickmeyer> I kindof thought that's what you meant, but in layman's terms.
[20:20] <juliank> That was the assert-daemon, essentially it opens the cache as user, presents the cache and requested changes to the daemon, the daemon checks that the state it operated on is still valid
[20:20] <juliank> Because the rootless synaptic can't hold a lock obviously
[20:21] <Eickmeyer> And that makes sense. muon was good in that it could open and get the cache, but then wait until you clicked "apply" to ask for password and make changes, so it was rootless and didn't hold a lock until then. But, buhbye muon, it was removed this cycle as it's abandoned upstream.
[20:23] <juliank> there is another mode where the daemon generates the cache file and sends it to the client
[20:23] <juliank> the problem with both models is that the daemon and the client need to use the same libapt-pkg version for that to work
[23:17] <Eickmeyer> RikMills: Burning the midnight oil?