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:21 |
---|---|---|
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:23 |
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:24 |
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:25 |
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:26 | |
ahasenack | clone seems to work, it's downloading stuff | 12:27 |
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 | 12:28 |
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:54 |
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>" | 13:55 |
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:07 |
rbasak | I think you might be able to replace the h= value with a commit hash directly as well. | 14:08 |
ahasenack | thanks | 14:11 |
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 | 15:53 |
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] | 18:45 |
=== cpaelzer_ is now known as cpaelzer | ||
cpaelzer | might that be on schopin 's radar already maybe? | 18:45 |
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:47 |
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:48 |
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:49 |
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 | 18:50 |
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 | 21:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!