=== caribou_ is now known as caribou
[11:47] <bluca> we are hitting a problem that seems due to phased updates
[11:48] <bluca> the case is a jammy img with -updates enabled, that has systemd installed
[11:48] <bluca> with the new update, there's a new version of src:systemd, but it's phased
[11:48] <bluca> if you try to install a package that is not there by default, like systemd-container, it will have a strict dependency on packages that are installed, but held back by the phase
[11:50] <bluca> shouldn't either the phase be ignored in that case, or older versions kept around so that apt can satisfy the dependency by installing the previous version of the non-installed pkg?
[11:50] <bluca> https://github.com/actions/virtual-environments/issues/5806
[11:50] <ubottu> Issue 5806 in actions/virtual-environments "Build stop working on Ubuntu 22.04 since 20220619.1" [Open]
[11:50] <seb128> bluca, check the discussion on https://irclogs.ubuntu.com/2022/06/23/%23ubuntu-devel.html
[11:51] <bluca> thanks, will do
[14:10] <rbasak> lvoytek: mysql-8.0 failed on riscv64 again with no build logs. I'll retry again.
[14:11] <lvoytek> Thanks! I just saw that too
[14:57] <kanashiro> hi, I have an email to ubuntu-release mailing list stuck in moderation, could any admin of that mailing list please accept it?
[15:01] <Skuggen> rbasak: This an infrastructure issue, or an issue with MySQL?
[15:09] <rbasak> Skuggen: o/
[15:09] <rbasak> Skuggen: just infrastructure. But thank you for checking in!
[15:17] <Skuggen> \o
[15:18] <Skuggen> I've been terrible at following up on Ubuntu/Debian building over the last year. Keep thinking "now I'll have some time", but then there's some fire before I can complete anything :|
[15:20] <Skuggen> But I do have a question. Is lvoytek going to work on keeping the debian/ubuntu packages in sync going forward? One thing we do with Fedora packaging which is easier to keep on top of is sending out packaging patches for every new release
[15:24] <rbasak> Skuggen: yes lvoytek is working on that. Maybe we could have a catch up call soon?
[15:45] <juliank> frickler, jbicha So I went back to the drawing board and I believe this solution solves all issues we experience now: https://salsa.debian.org/apt-team/apt/-/merge_requests/245/diffs
[15:45] <ubottu> Merge 245 in apt-team/apt "Draft: (Temporarily) Rewrite phased updates using a keep-back approach" [Opened]
[15:45] <juliank> Essentially this plans a normal upgrade, and then holds back any update that should be ignored by phasing
[15:48] <juliank> I'm consulting with DonKult upstream if there are any solver issues I should be aware of but it sounds reasonable
[15:48] <juliank> Note that this behaves weirdly, like update-manager it will install the still-phasing version 3 from updates rather than version 2 from security
[15:48] <juliank> because it cannot change candidate versions at this stage
[15:49] <juliank> and 3 is hence considered a security update because 2 is and 3 > 2
[15:49] <juliank> (and 2 > 1)
[15:49] <juliank> the full policy driven approach would install 2 which is arguably a whole lot nicer
[15:59] <Skuggen> rbasak: Yeah, that sounds like a good idea!
[16:02] <rbasak> Skuggen: I'll set something up. lvoytek is in UTC-7. When's the latest you're available?
[16:08] <Skuggen> Up to 18UTC is fine as long as I don't have other plans :)
[16:37] <rbasak> Skuggen, lvoytek: OK I scheduled something for Friday 1st July. Is that time OK for both of you? I reused the old recurring invite, but cancelled subsequent recurrences as that meeting is basically dead anyway.
[16:38] <lvoytek> That time works for me!
[16:38] <rbasak> Great! I picked your earliest available time so as not to inconvience Skuggen too much!
[16:47] <Skuggen> Should be good, yeah!
[16:48] <rbasak> Skuggen: just checking: you're confirming the time in the email you got, right? I just realised I was ambiguous above. I moved the time of our previous regular sync back as it'd be too early for l_voytek.
[17:10] <Skuggen> Yeah, got one email that looks most like another invitation to the old meeting. But the new one is 1600 my time, which is fine
[17:10] <Skuggen> Though if we make it a more regular thing again I'd probably want to move it to a different day :)
=== ahasenack__ is now known as ahasenack
[22:06] <jawn-smith> vorlon: you around? I've got an components question
[22:07] <jawn-smith> Or perhaps bdmurray
[22:08] <jawn-smith> The latest upload of vim introduces a new binary package, vim-motif, that creates 3 component mismatches
[22:08] <jawn-smith> Would it be worth looking into the possibility of having vim-motif be in universe rather than main?
[22:09] <jawn-smith> Instead of MIR-ing the 3 mismatches
[22:25] <vorlon> jawn-smith: https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html already shows that this is a candidate for demotion, just needed poking an AA to get it done
[22:26] <jawn-smith> oh neat, thanks!
[22:27] <vorlon> component changed now, shoud migrate soon if that was the only blocker
[22:27] <jawn-smith> that was indeed the only blocker
[22:27] <jawn-smith> Thanks!
[22:45] <arraybolt3[m]> Hey all. I'm attempting to backport libfm-qt11 from Kinetic to Jammy, and have hit a bit of a roadblock with the symbols. I was doing this over on #lubuntu-devel so I have a lot of background for this to make sense, so bear with me.
[22:46] <arraybolt3[m]> Initially, I got my packaging for libfm-qt11 from here: https://github.com/lubuntu-team/libfm-qt-packaging
[22:47] <arraybolt3[m]> I cloned it, prepped for the backport, uscan'd the source code, "debuild -S -d -sa", then uploaded the prepared packaging to a PPA, where I got a bunch of symbol data from the build logs for five different architectures.
[22:48] <arraybolt3[m]> I then extracted the symbol diffs from the build logs, and used "pkgkde-symbolshelper batchpatch" to apply them to the core symbol file in the package, then attempted an sbuild.
[22:48] <arraybolt3[m]> However, I've now run into the following error (given by the sbuild process): https://pastebin.com/cRxLScGk
[22:49] <arraybolt3[m]> It appears that somewhere along the way, some sort of "subst" symbol tag got involved, which appears to not even be an official symbol tag - the best documentation I could find was from here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533916 It appears that, depending on what architecture you build on, the symbol changes, based off of a placeholder within the symbol.
[22:49] <ubottu> Debian bug 533916 in dpkg-dev "dpkg-gensymbols: Implementation of the subst symbol tag" [Wishlist, Open]
[22:49] <arraybolt3[m]> I'm unsure how to proceed. Any thoughts?
[22:50] <arraybolt3[m]> (I'm a newbie packager, so please be patient if it takes me a bit to understand.)
[23:07] <vorlon> arraybolt3[m]: I'm unfamiliar with the pkgkde-symbolshelper package, but it seems rather buggy for it to be emitting things not supported by dpkg.  The way to solve this is, for each of the affected symbols, to edit your symbols file to list two different symbols: one with the correct name for 32-bit archs and tagged (arch=i386 armhf), one with the correct name for 64-bit archs and tagged
[23:07] <vorlon> (arch=!riscv64 !i386 !armhf)
[23:08] <arraybolt3[m]> vorlon: OK, that makes sense. I can get all of the data necessary for putting together the symbols in this way from the individually built .deb packages from the PPA, right?
[23:09] <vorlon> arraybolt3[m]: yes
[23:09] <arraybolt3[m]> Thank you!