[12:21] <ahasenack> rbasak: hi, I imported ffmpeg last friday together with many other packages, and today I checked and switched the default target, but it looks odd: https://code.launchpad.net/ubuntu/+source/ffmpeg
[12:23] <rbasak> https://code.launchpad.net/~git-ubuntu-import/ubuntu/+source/ffmpeg/+git/ffmpeg
[12:23] <rbasak> "Repository scan failed"
[12:23] <rbasak> Do you have the "Rescan" button?
[12:23] <utkarsh2102> ahasenack: oh hey, what's up w frr? Did you get time to investigate the syslog issue?
[12:23] <ahasenack> I clicked, and got an angry permission denied
[12:23] <ahasenack> utkarsh2102: still in my list, that's all
[12:23] <rbasak> "
[12:23] <rbasak> Repository scan scheduled
[12:24] <rbasak> "
[12:24] <utkarsh2102> ahasenack: cool, cool, thank you. 
[12:24] <rbasak> Probably because I'm still in ~git-ubuntu-import
[12:24] <ahasenack> utkarsh2102: is there any particular reason it should be flagged as a high priority bug ahead of others?
[12:24] <rbasak> If it's a regular thing we might need to figure out a way to get the importer or bot to do it.
[12:24] <rbasak> But I think it's self-correcting when the repository is updated.
[12:24] <ahasenack> rbasak: first time I see this
[12:24] <utkarsh2102> ahasenack: none, really. I'm just curious to see what happens. So whenever you get around to doing that, just let me know. :)
[12:24] <rbasak> I think it'll affect the LP web UI only.
[12:25] <rbasak> From our point of view
[12:25] <ahasenack> is the scan still running, or did it fail again? Can you tell?
[12:25] <rbasak> I don't think I can tell.
[12:25] <rbasak> But it's a queued job AIUI, so I'd give it a few minutes.
[12:26] <rbasak> I think a clone should work regardless.
[12:26] <ahasenack> if I go to the page with the button, it still says the scan failed. IIRC it would say scan is in progress if it was still running
[12:26]  * ahasenack tries a clone
[12:27] <ahasenack> clone seems to work, it's downloading stuff
[12:28] <rbasak> Ah yes it does change to "Updating repository..."
[12:28] <rbasak> (I retried again)
[12:28] <rbasak> And it failed again
[12:28] <rbasak> I'll ask in #launchpad
[13:54] <ahasenack> rbasak: do you happen to know how I can get a "stable" reference to this patch in launchpad's git web ui: https://git.launchpad.net/ubuntu/+source/samba/tree/debian/patches/bug_221618_precise-64bit-prototype.patch?h=ubuntu/jammy
[13:54] <ahasenack> although that one might be stable, because I used the "jammy" branch
[13:54] <ahasenack> which won't change anymore
[13:55] <ahasenack> but let's say I wanted a link to the current status in ubuntu/devel. Something like "view this file at commit/revision <hash>"
[14:07] <rbasak> ahasenack: go to the log tab, click on the import tag itself, and then back to the tree tab and select the file?
[14:07] <rbasak> That gives me https://git.launchpad.net/ubuntu/+source/samba/tree/debian/patches/bug_221618_precise-64bit-prototype.patch?h=import/2%254.13.2%2bdfsg-1 and that looks more stable to me.
[14:08] <rbasak> I think you might be able to replace the h= value with a commit hash directly as well.
[14:11] <ahasenack> thanks
[15:53] <paride> The ubuntu-server-minimal seed change https://code.launchpad.net/~xnox/ubuntu-seeds/+git/ubuntu-seeds/+merge/419854 is targeted to the jammy branch as kinetic was not ready when that was filed
[15:53] <paride> I'll retarget it to kinetic
[18:45] <ahasenack> cpaelzer_: that python-ecdsa ftbfs is a bug in python's interaction with openssl3, actually: https://github.com/python/cpython/issues/91257
[18:45] <ubottu> Issue 91257 in python/cpython "hashlib.algorithms_available lists algorithms that are not available in OpenSSL 3.0 default provider" [Open]
=== cpaelzer_ is now known as cpaelzer
[18:45] <cpaelzer> might that be on schopin 's radar already maybe?
[18:47] <ahasenack> https://github.com/python/cpython/pull/32085 is the fix, committed upstream already
[18:47] <ubottu> Pull 32085 in python/cpython "[3.10] bpo-47101: list only activated algorithms in hashlib.algorithms_available (GH-32076) (GH-32085)" [Merged]
[18:47] <cpaelzer> ahasenack: so the fix is for hashlib and the python-ecdsa is only exposing the issue?
[18:47] <ahasenack> I'm weary of uploading a new python :)
[18:47] <ahasenack> cpaelzer: the fix is for python
[18:47] <cpaelzer> I think it is fine to properly put this in a bug and make foundations aware
[18:48] <cpaelzer> they can group it with any kind of other fixes they have enqueued
[18:48] <ahasenack> basically you ask for the list of hash algorithms that can be used, you get the list, then you try to use them, and some of those are not available
[18:48] <ahasenack> try this: python3 -c "import hashlib; a = {(name, hashlib.new(name).digest_size) for name in hashlib.algorithms_available}"
[18:48] <cpaelzer> unless the legacy provider is loaded
[18:48] <ahasenack> it also affects jammy
[18:48] <ahasenack> right
[18:48] <ahasenack> but it's not loaded by default
[18:49] <cpaelzer> yep, really sounds like wrap it in a bug with hint to the test fail, the fix and bug by upstream and ask them to consider adding it to an SRU
[18:49] <ahasenack> so the bug is that the list of algorithms available was not considering that, and returning everything
[18:50] <ahasenack> yeah, I have the bug, will just mark the python-ecdsa as invalid
[18:50] <cpaelzer> and once it exists ping also schopin in case he still tracks openssl3 bugs
[21:00] <yurtesen> ahasenack: You said there are other tickets before the tomcat issue. But can you give an estimate on how long it will take before you can have a look at it? Unless of course you meant that it is so low priority that there will always be tickets to handle before it perhaps?
[21:00] <ahasenack> sometime during june, it will be part of bug work then