[03:35] <zhsj> hi, could someone retry these builds https://launchpad.net/ubuntu/+source/golang-1.19/1.19.12-1/+build/26471493 and https://launchpad.net/ubuntu/+source/golang-1.20/1.20.7-1/+build/26471501 they all succeed in debian
[04:59] <mwhudson> zhsj: retried. makes a change to have to retry riscv64! usually it's just armhf
[08:03] <nteodosio> rbasak, did you get any response for bug 2029089, or is there ongoing discussion somewhere?
[08:03] -ubottu:#ubuntu-devel- Bug 2029089 in distro-info (Ubuntu) "Please backport UbuntuDistroInfo().get_all(result='object') to Xenial" [Undecided, Incomplete] https://launchpad.net/bugs/2029089
[09:07] <rbasak> nteodosio: I had one response from an SRU team member who agreed with me, and no objections. I suppose that's enough given that nobody else responded. I'll comment in the bug.
[09:08] <nteodosio> Thank you.
[09:52] <nteodosio> bdrung, do you want me to write the SRU for it?
[09:53] <bdrung> nteodosio, yes. please add the SRU paperwork to that bug
[10:40] <tjaalton> LocutusOfBorg: llvm-16 still doesn't produce the full libclc-16 I'm afraid..
[12:05] <LocutusOfBorg> tjaalton, examples of missing files?
[12:08] <tjaalton> /usr/lib/clc/spirv*-mesa3d-.spv
[12:08] <tjaalton> the rest is there
[12:08] <tjaalton> like before
[12:12] <tjaalton> llvm-spirv: LLVM_SPIRV-NOTFOUND
[12:13] <tjaalton> which is weird, as it's installed
[12:14] <tjaalton> LocutusOfBorg: it's disabled in rules
[12:15] <tjaalton> since august last year
[12:22] <LocutusOfBorg> ok but somebody still have to fix mips*
[12:22] <LocutusOfBorg> for Ubuntu we should be good, on next auto-sync
[12:44] <tjaalton> well, mips* needs to be dropped from the arch list for llvm-spirv-16 build-dep for a start
[13:20] <LocutusOfBorg> tjaalton, exactly what I did :)
[13:20] <LocutusOfBorg> but its not enough to fix the build :p
[13:23] <tjaalton> right
[14:20] <ahasenack> coreycb: hi, anybody up for the lunar verification of https://bugs.launchpad.net/ubuntu/+source/cinder/+bug/2025491 ? It's been in proposed for a long time, maybe it was missed, since there is a verification done for the cloud archive?
[14:20] -ubottu:#ubuntu-devel- Launchpad bug 2025491 in nova (Ubuntu Lunar) "[SRU] antelope stable releases" [High, Fix Committed]
[15:03] <coreycb> ahasenack: hi, it's on my radar but our lunar charms are having issues so we're working on getting those fixed.
[15:03] <ahasenack> cool, thx
[15:10] <jawn-smith> Anyone need anything sponsored? I've got some time to review and upload
[15:10] <dbungert> jawn-smith: :wave: have you peeked at the sponsor queue lately?  it's surprisingly not awful
[15:22] <jawn-smith> Hey dbungert! I haven't, but I'll go check it out
[15:47] <bdrung> juergh, have you seen https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1942260/comments/13?
[15:47] -ubottu:#ubuntu-devel- Launchpad bug 1942260 in linux-firmware-raspi2 (Ubuntu Mantic) "compress firmware in /lib/firmware" [Undecided, Confirmed]
[15:55] <tsimonq2> There we are, finally on a stable bouncer.
[15:55] <tsimonq2> @pilot in
[15:58] <juergh> bdrung: I have now. For some reason LP doesn't like sending me bug update notification emails.
[16:05] <bdrung> juergh, since when? I haven't got an bug update that I am subscribed to. The last email is 10 hours old.
[16:15] <cjwatson> stuck cron job, dealing with it
[16:18] <dbungert> darn, the uploader field is null on the json output on https://merges.ubuntu.com/
[16:20] <cjwatson> Looks like MoM tries to get that from `gpg --verify` rather than from LP ... seems ambitious
[16:20]  * tsimonq2 looks
[16:20] <cjwatson> (also probably not something I'll ever have time to fix, but maybe that's useful direction?)
[16:21] <tsimonq2> cjwatson: ta
[16:21] <tsimonq2> cjwatson: Also, do you know much about the infra it's on?
[16:21] <cjwatson> juergh,bdrung: send-bug-notifications unstuck and it's catching up now
[16:21] <cjwatson> tsimonq2: yes, what do you need to know?
[16:21] <tsimonq2> cjwatson: I reported a bug about the logo being outdated. Honestly, it would be easier if it was all in the same repo, but maybe it's intertwined with something else.
[16:22] <tsimonq2> cjwatson: Also, I'm not sure if my changes from the other day ever updated/if something errored/if I need to fix something.
[16:22] <cjwatson> at the moment it's a bionic VM some bits of which were clumsily lifted-and-shifted from an ancient artisanal installation
[16:23] <cjwatson> in an ideal world it'd be fully charmed (which would probably also involve migrating its state into PostgreSQL and its files into RadosGW), but I've never had the time
[16:23] <tsimonq2> Would that be a prerequisite for moving it/cleaning it up?
[16:23] <cjwatson> depends
[16:24] <cjwatson> anyway I have full access to the current VM, so let me see if I can fix that logo
[16:24] <cjwatson> I'm not sure what you mean by your changes from the other day
[16:24] <tsimonq2> bzr lp:merge-o-matic was pushed to, not sure if that autopulls.
[16:24] <cjwatson> no, that's manual
[16:25] <tsimonq2> Would it be possible to throw that on a cronjob/uncomment the line from cron.daily? :)
[16:25] <cjwatson> not sure I'm comfortable with that at the moment
[16:25] <cjwatson> it's a bit too rickety
[16:26] <cjwatson> anyway, our production services are typically deploy-on-request rather than completely auto-deploy
[16:26] <tsimonq2> The sponsorship queue led me to believe otherwise ;)
[16:26] <tsimonq2> Regardless, thank you
[16:28] <cjwatson> deployed your changes
[16:29] <tsimonq2> ta :)
[16:43] <cjwatson> tsimonq2: icons updated (very very manually)
[16:45] <tsimonq2> Thanks again :)
[17:40] <smoser> o/. I was looking/thinking about checking files integrity on a system (or snapshot/archive of one).
[17:41] <smoser>  /var/lib/dpkg/info/<package>.md5sums contains checksums of files. so i can go through files and verify they match what those files state they should.
[17:43] <ahasenack> like debsums
[17:43] <smoser> i can look at /var/lib/apt/lists/*InRelease and connect the Packages file to a signature
[17:44] <smoser> but is there anything on the system that i can use to verify a <package>.md5sums file ?
[17:45] <juliank> smoser: no
[17:45] <juliank> also I mean it's md5sums, so it's not really all that useful :D
[17:45] <smoser> that is what i thought. is there any work or consideration on doing that ?
[17:45] <smoser> (and yeah... slmething other than md5sum woudl be good)
[17:46] <juliank> There's the mtree feature which allows recording attributes for files like hashes in a dpkg branch upstream
[17:46] <juliank> that's all I can say for now
[17:47] <juliank> Of course the hashes you can't verify either, so you want signed IMA xattrs
[17:47] <juliank> which is very expensive
[17:47] <juliank> Or sign the mtree which is less expensive but hard too
[17:47] <smoser> thank you for your response.  i was looking at an SBOM tool that uses dpkg info to say "these packages were installed at these versions" (producing SPDX info https://spdx.dev/)
[17:48] <smoser> and i'd like to be able to add to it "and those packaegs were signed by ubuntu archive key" or whatever key they were signed by.
[17:48] <juliank> yeah you won't get lucky there
[17:49] <juliank> the best you can do is check if the version you have installed was in the ubuntu archive by querying launchpad for the version in ubuntu
[17:49] <smoser> with the internet it can be done. but just requires me to have a big cache of deb info.
[17:49] <juliank> but no hashes
[17:50] <juliank> so if you want a cryptographic chain you also need to consider old packages and they may not be available anymore in the archive
[17:50] <smoser> i'm glad i came here to ask. i'd have been  happier with an answer of "Yes! here is how", but having someone else validate my assemsment is very useful. thank you.
[17:51] <smoser> juliank: yeah, i'd have to have another source of trust with a database.  but at least for ubuntu, old packages never actually die if you know where to look in launchpad.
[17:51] <juliank> there'll be a snapshot service that you can use to query old archive generations but finding the one containing your package version may be hard
[17:51] <juliank> so you can query launchpad for publish date and then request snapshot for that publish data
[17:52] <juliank> well you will be able to request
[17:52] <juliank> :D
[17:52] <smoser> yeah. i've went down part of the way down this rabbit hole before.
[17:52] <juliank> You might have seen the work in apt to enable the snapshot service integration
[17:53] <juliank> but that service is not fully public yet
[17:53] <smoser> i did not. i only knew of snapshot.debian.org . i assumed you were talking about that.
[17:54] <juliank> heh
[17:55] <juliank> same thing for ubuntu but cooler
[17:56] <juliank> you can try it out in mantic by adding Snapshot: enable to a deb822 sources entry (or [snapshot=enable]) option; or use yes, and then specify --snapshot <timestamp> (same format as Debian)
[17:56] <juliank> or assign a snapshot id to the snapshot sources field directly
[17:56] <juliank> paaaarty
[17:57] <smoser> that is really neat. i have previously gone looking for that service for ubuntu also.
[17:58] <smoser> the solution i have is to run a caching proxy that does not delete old debs and keep package files locally and never run apt-get update.
[18:01] <juliank> if you try it out let me know if it works for you
[18:01] <juliank> I don't think anyone other than me actually did any amount of playing with it yet
[18:02] <juliank> (it being the client side in apt)
[18:12] <smoser> if i play with it, i'll let you know. thank you for your time.
[19:12] <rbasak> smoser: I would write a function that speaks to the Launchpad API and converts a binary package name and version into a list of files and their hashes. Then arrange that function to cache. How you populate the cache would then be up to you. You could do it given a Packages file, for example.
[19:12] <rbasak> (name, version, arch) I think should uniquely identify a deb.
[19:12] <rbasak> (for Ubuntu)
[19:14] <smoser> you're saying the launchpad api has that information ?
[19:26] <tsimonq2> Looks like I did accidentally break the formatting on MoM a little bit.
[19:27] <rbasak> https://launchpad.net/+apidoc/devel.html#archive
[19:27] <rbasak> lp.distributions["ubuntu"].main_archive.getPublishedBinaries. Use exact_match=True
[19:27] <rbasak> Oh you mean the hashes? No - you'd have to download, extract and derive them.
[19:28] <rbasak> But the Launchpad API will give you the download URL for any* binary package I think.
[19:28] <rbasak> From the https://launchpad.net/+apidoc/devel.html#binary_package_publishing_history object, there's the binaryFileUrls() method
[19:29] <smoser> ah. right.
[19:30] <rbasak> In [1]: list(lp.distributions["ubuntu"].main_archive.getPublishedBinaries(binary_nam
[19:30] <rbasak>    ...: e='hello', version='2.10-2ubuntu2', exact_match=True))[0].binaryFileUrls()
[19:30] <rbasak> Out[1]: ['https://launchpad.net/ubuntu/+archive/primary/+files/hello_2.10-2ubuntu2_s390x.deb']
[19:30] <rbasak> (I didn't bother with the arch filter but you can add that)
[19:32] <smoser> i had an experience recently with a "container image scanner" that tried to identify where files came from.  i was moderately surprised that it did not appear to have a giant database of shasums for all linux distro released files.
[19:34] <smoser> and then google didn't seem to show me one either. maybe i just wasn't using the right terms. i just kind of expected that *something* could take a shasum and say: that content is named /bin/bash in (ubuntu/amd64/bash-1.2.3, ..other-packages-here...)
[19:52] <tsimonq2> cjwatson: If you get another chance (I would assume in the morning), I pushed more changes to MoM that should fix things up.
[20:09] <cjwatson> tsimonq2: deployed
[20:17] <bdrung> cjwatson, i still haven't got the launchpad bug mail
[20:19] <cjwatson> hung again, that's weird
[20:19] <cjwatson> but I really need to EOD
[20:21] <cjwatson> hard to see what even could hang there, unless it's like a database connection or something
[21:52] <tsimonq2> cjwatson: ta :)
[21:54] <tsimonq2> PSA: Merge O Matic now has the option to hide long lists of binaries, so you aren't scrolling through half a page of GCC. :)
[22:14] <mwhudson> @pilot in
[22:37] <mwhudson> tsimonq2: are you still actively patch piloting?
[22:38] <mwhudson> tsimonq2: and have you looked at anything that's still showing on the queue :)
[22:38] <Unit193> I removed him yesterday because he'd forgotten.
[22:38] <LocutusOfBorg> tjaalton,
[22:38] <LocutusOfBorg> -rw-r--r-- root/root   2635360 2023-08-03 12:20 ./usr/lib/clc/spirv-mesa3d-.spv
[22:38] <LocutusOfBorg> -rw-r--r-- root/root   2636344 2023-08-03 12:20 ./usr/lib/clc/spirv64-mesa3d-.spv
[22:38] <LocutusOfBorg> 16.0.6-9 should be good now
[22:39] <mwhudson> Unit193: ah hm so when i checked in he got added again?
[22:39] <Unit193> mwhudson: No, I suspect he's forgotten again.
[23:11] <tsimonq2> mwhudson: yes :)
[23:11] <tsimonq2> Unit193: Thanks for that
[23:11] <tsimonq2> mwhudson: Not claiming any particular package, if you're looking to patch pilot too.
[23:28] <mwhudson> well
[23:28] <mwhudson> the docker one -> want server team to look
[23:29] <mwhudson> rsyslog -> seems a commit is missing? might take a look at that
[23:29] <mwhudson> multipath-tools -> yikes
[23:29] <mwhudson> (also server team)
[23:29] <mwhudson> the davmail one has some comments already
[23:30] <mwhudson> so um
[23:31] <Unit193> So I should ping you with all the stuff to fix!? :D
[23:38] <mwhudson> well patches to be sponsored sure
[23:38] <mwhudson> actually trying to understand the multipath situation now
[23:40] <Unit193> While I was joking, that reminds me that I should look into fastforwarding Debian #1040011 to Ubuntu.
[23:40] -ubottu:#ubuntu-devel- Debian bug 1040011 in src:mate-polkit "mate-polkit: Allow mate-polkit to be used in Xfce, Cinnamon, and other desktops" [Wishlist, Open] https://bugs.debian.org/1040011
[23:40] <Unit193> See also: Debian #990271
[23:40] -ubottu:#ubuntu-devel- Debian bug 990271 in policykit-1-gnome "policykit-1-gnome: unmaintained upstream, should not be included in trixie" [Serious, Open] https://bugs.debian.org/990271
[23:41] <mwhudson> maybe lunch will help
[23:59] <sarnold> lunch *always* helps