[01:48] <tco> ae
=== liushuyu1 is now known as liushuyu
=== liushuyu1 is now known as liushuyu
[09:33] <schopin> Anyone ever encountered "Protected: yes" in a binary package definition in d/control? Specifically, it's in the definition for login in src:shadow.
[09:34] <schopin> It seems there's a dpkg draft about it, but its status isn't clear.
[09:35] <mirespace> schopin: https://codesearch.debian.net/search?q=Protected+path%3Adebian%2Fcontrol&literal=1 but not sure if that can ggive you a clue
[09:35] <schopin> juliank: apparently you wrote the first versions of the wiki page, is it something that's in actual use?
[09:36] <schopin> mirespace: thanks for the link. I guess it sort of confirms my intuition about it?
[09:36] <mirespace> schopin: It seems so :)
[09:39] <mirespace> I'm on +1 this week... I'm checking the clusters, and rust-gix seems to be hold on rust-hashbrown, but all is green for it... a matter of time to be migrated? No more info in the update_excuses page
[09:46] <mirespace> I'm retriggering tests from the top for armhf (ERROR: testbed failure: unexpected eof from the testbed)
[09:50] <juliank> schopin: yes guillem eventually implemented that after apt had Important: yes for ages
[09:50] <juliank> Hence why some have both
[09:55] <schopin> mirespace: have you checked the britney logs for rust-hashbrown?
[09:57] <schopin> It seems to make a whole lot of rust package uninstallable.
[09:57] <schopin> (that'd be https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output.txt )
[09:57] <mirespace> schopin: no, good idea ... that is outdated_oupted, right ? :$
[09:57] <mirespace> yes, it is  :)
[09:58] <mirespace> schopin: wow
[11:01] <waveform> @pilot in
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Noble | Patch Pilots: waveform
[11:35] <ravikant_> just an fyi - https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi is working again.
[11:37] <rbasak> Thanks!
[11:46] <mirespace> Working on mako
[11:51] <jbicha> mirespace: I think the biggest blocker for rust-hashbrown etc is bug 2054491 . Some work was done in rust-reqwest recently to work around similar Ubuntu autopkgtest proxy restrictions
[11:51] -ubottu:#ubuntu-devel- Bug 2054491 in rust-ureq (Ubuntu) "rust-ureq autopkgtest fails" [Undecided, New] https://launchpad.net/bugs/2054491
[12:00] <mirespace> jbicha: thanks! checking... because I was looking into dependencies in update_output, and I was with rust-intrusive-collections because I saw it was depending on itself and blocking rust-memoffset (in amd64), but now is only happening in ppc64el ...
[12:34] <sudip> a newbie question, why does libplacebo transition has ffmpeg in dependency level 1 ?
[13:00] <LocutusOfBorg> sudip, check the build log and you will see as runtime dependency
[13:00] <LocutusOfBorg> e.g. for ffmpeg on libavfilter10
[13:00] <LocutusOfBorg>  Depends: libass9 (>= 1:0.15.0), libavcodec61 (= 7:7.0.1-4ubuntu1), libavformat61 (>= 7:7.0), libavutil59 (= 7:7.0.1-4ubuntu1), libbs2b0 (>= 3.1.0+dfsg), libc6 (>= 2.38), libflite1 (>= 1.4-release-9~), libfontconfig1 (>= 2.12.6), libfreetype6 (>= 2.2.1), libfribidi0 (>= 0.19.2), libharfbuzz0b (>= 0.9.9), liblilv-0-0 (>= 0.14.2~dfsg0), libmysofa1 (>= 0.7~), libplacebo338 (>= 6.338.1), libpocketsphinx3 (>=
[13:00] <LocutusOfBorg> 0.8.0+real5prealpha+1), libpostproc58 (>= 7:7.0), librubberband2 (>= 3.3.0+dfsg), libsphinxbase3t64 (>= 0.8+5prealpha), libstdc++6 (>= 13.1), libswresample5 (>= 7:7.0), libswscale8 (>= 7:7.0), libva2 (>= 1.7.3), libvidstab1.1, libvpl2 (>= 2023.3.0), libzimg2 (>= 0.3.1), libzmq5 (>= 3.2.3+dfsg), ocl-icd-libopencl1 | libopencl1, ocl-icd-libopencl1 (>= 1.0) | libopencl-1.2-1, zlib1g (>= 1:1.1.4)
[13:01] <LocutusOfBorg> but also libavfilter-extras, ffmpeg itself
[13:01] <LocutusOfBorg> but in any case libplacebo is not yet accepted, so no transition can be done
[13:01] <LocutusOfBorg> and also I'm trying to fix ffmpeg on s390x
[13:04] <sudip> ok, I was confused seeing ffmpeg in dependency level 1,  I thought packages depending on libplacebo will be in dependency level 2.
[13:45] <LocutusOfBorg> oh... that "level" thing is a "best effort code"
[13:45] <LocutusOfBorg> don't trust level dependencies
[13:45] <LocutusOfBorg> this is why I usually do them all at once
[13:45] <LocutusOfBorg> and then retry failing builds
[13:46] <LocutusOfBorg> (with some manual check of build logs)
[13:46] <sudip> ahh.. ok.. :)
[15:12] <waveform> @pilot out
=== ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Noble | Patch Pilots: N/A
[15:47] <bdrung> i am currently looking into vowpal-wabbit
[15:58] <bdrung> looking into devicexlib
[17:05] <waveform> is there an issue with the git-ubuntu importer? I'm looking at the u-boot merge and while the ubuntu versions have been imported, the debian ones are way behind (https://code.launchpad.net/ubuntu/+source/u-boot -- debian/sid should be 2024.01+dfsg-5)
[18:14] <ogayot> hello! is there a MOTU/coredev available to trigger a NCR of netgen? It needs to rebuild against mpi-defaults 1.17 (the default changed from openmpi to mpich on 32-bit arches). Thanks!
[18:21] <ogayot> (I can file a LP and attach a debdiff if that helps)
[18:27] <Eickmeyer> ogayot: I can handle it.
[18:27] <vorlon> is that the only package needing a rebuild?
[18:32] <Eickmeyer> ogayot: Before I dput this, ^ ?
[18:32] <ogayot> vorlon: Eickmeyer: looking!
[18:32] <Eickmeyer> :)
[18:48] <ogayot> do we have a `$ reverse-depends src:mpi-defaults` equivalent that supports specifying a version of src:x?
[18:51] <ogayot> (it's not the only package that needs a rebuild)
[19:04] <vorlon> ogayot: I think you would instead do reverse-depends src:$implementation -a i386
[19:06] <vorlon> vpa1977: ah, is it deliberate that https://launchpad.net/ubuntu/+source/bpfcc/0.30.0+ds-1ubuntu2/+build/28685703 only outputs libbpfcc on ppc64el and none of the other binaries?
[19:13] <ogayot> vorlon: that's only a couple packages on i386, but dozens (with false positives) on armhf. I will try to filter the list.
[19:14] <vorlon> ogayot: cheers
[19:15] <vorlon> ogayot: does 'reverse-depends libopenmpi3t64 -a i386' eliminate the false-positives?
[19:15] <vorlon> and would a rebuild of all packages depending on libopenmpi3t64:i386 && ! libmpich12:i386 be correct?
[19:16] <john-cabaj> I have a couple of packages pending publication in -proposed since last Friday (https://launchpad.net/ubuntu/+source/involflt). Is there something gating this or should I discuss with the Launchpad team?
[19:17] <vorlon> john-cabaj: what there indicates pending publication?
[19:17] <john-cabaj> vorlon: Just cling the drop down on the new version and LP says "Note: Some binary packages for this source are not yet published in the repository. "
[19:17] <john-cabaj> clicking*
[19:18] <john-cabaj> rmadison seems to think it's in -propsed, though.
[19:18] <vorlon> john-cabaj: which version is the "new version" you're referring to?
[19:19] <john-cabaj> 0.1.0-0ubuntu7~22.04.1 and 0.1.0-0ubuntu7~20.04.1
[19:19] <vorlon> jammy appears to be in binary NEW
[19:19] <vorlon> same for focal
[19:20] <vorlon> john-cabaj: accepted now
[19:20] <john-cabaj> vorlon: Thanks, I'll keep an eye out
[19:29] <ogayot> vorlon: I guess a rebuild of all packages depending on `mpi-default-bin:i386 && libopenmpi3t64:i386 && ! libmpich12:i386` would be more correct. I don't think it makes a difference for i386 but might for armhf
[19:31] <ogayot> once openmpi 5 lands (it's in experimental currently), support for i386 will be dropped, so all packages will need to switch to libmpich12 on armhf|i386
[19:31] <ogayot> s/support for i386/support for 32-bit arches/
[19:33] <Eickmeyer> ogayot: Catching up on this backlog, I'll go ahead and do this package, but it looks like you've got quite a bit more that need it, correct?
[19:44] <ogayot> Eickmeyer: yes, that's correct. The unfiltered list has quite a few packages listed: https://paste.ubuntu.com/p/8c7RNdSM4m/
[19:44] <ogayot> Eickmeyer: thanks!
[19:46] <Eickmeyer> ogayot: Wow, yes, that's *quite* a lot. Well, I got netgen done, but we're going to need help with the others. Right now, I'm neck-deep in a news post for Ubuntu Studio that I've been putting off.
[19:57] <rbasak> waveform: u-boot and git-ubuntu> I think this is bug 2028288. The commit graph will be correct; it's the branch pointer that's wrong.
[19:57] -ubottu:#ubuntu-devel- Bug 2028288 in git-ubuntu "debian/sid branch incorrect when multiple versions are published" [Medium, Triaged] https://launchpad.net/bugs/2028288
[19:57] <rbasak> waveform: so you should be able to get to the correct commit through the import tag
[20:11] <vpa1977> vorlon: looks like a bug I have introduced. Let me fix it
[20:14] <vpa1977> vorlon: it should also output bpfcc-introspection
[20:20] <waveform> rbasak, hmm -- some of the later imports are indeed present, up to 2024.01-dfsg+4 from experimental, but 2024.01-dfsg+5 (uploaded to Debian back in April) doesn't seem to be there
[20:33] <rbasak> waveform: is that not https://git.launchpad.net/ubuntu/+source/u-boot/tag/?h=import/2024.01%2bdfsg-5 ?
[20:34] <waveform> rbasak, oh dammit ... forgot to fetch --tags on this old clone like a fool
[20:39] <waveform> rbasak, okay ... that tag is now there but origin/debian/sid is still pointing at the ancient import. I'm guessing that's the bug you mentioned from skimming the description. Unfortunately debian/experimental's also in the past so I'll have to do some manual messing around with my merge script :)
=== jfsimon1981_b is now known as jfsimon
[20:42] <rbasak> waveform: right
=== liushuyu1 is now known as liushuyu