Re: Uscan no longer works with GitLab tags
Hi Thomas, On 4/23/24 4:09 PM, Thomas Ward wrote: Is there a specific reason you can't follow tags and their corresponding uploads? A long while ago I came up with a mechanism to force uscan to use the gitlab JSON API to get downloads, etc. but it was finnicky and I don't have the exact solutions here since that was long enough ago I lost a computer and its data and lost my solution to scrape the json with uscan. No specific reason. From the discussion it seems that the JSON API is preferable, but is not recommended by default because of the need to mangle the owner/project URL If it turns out to be more brittle I'll probably change it back - this project is finnicky anyway since like the Vala project Fay's example was for, I needed to get one of the manually uploaded tarballs instead of the auto-generated tag... and I also need to override the version (to prepend 0~). Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Uscan no longer works with GitLab tags
On 4/23/24 4:02 PM, Michel Lind wrote: On 4/3/24 5:19 PM, Fay Stegerman wrote: GitLab asset download URLs are a bit of a mess, but the attached watch file seems to give me that exact URL. Thanks for this! I have a similar problem with archlinux-keyring - which uses a different GitLab instance, gitlab.archlinux.org Using your watch file as a template, I managed to capture the exact URL needed (tried using that and also matching on the releases URL), but I still get stuck on the fact that uscan gets given an HTML page prompting to login instead. Ah, turns out matching the upload found the .tar.gz.sig instead since it appeared earlier in the releases JSON, so the upload hash is wrong. Finally ended up matching the release URL instead - luckily uscan (and wget) handles the redirection back to the uploads URL OK. https://salsa.debian.org/michel/archlinux-keyring/-/commit/7c096ea23aad8e0c9f66819cdda2a7d7e094f196 Thanks for figuring out the API access. I'm using it from now on since hopefully it'll be more stable. -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Uscan no longer works with GitLab tags
On 4/3/24 5:19 PM, Fay Stegerman wrote: * Mike Gabriel [2024-04-03 10:00]: On Tuesday, April 2, 2024 8:22:26 AM MST Mike Gabriel wrote: https://salsa.debian.org/debian-ayatana-team/appmenu-gtk-module/-/blob/ master/ debian/watch ``` version=3 https://gitlab.com/vala-panel-project/vala-panel-appmenu/-/tags/?([\d\.]+) .*/uploads/.*/appmenu-gtk-module-?([\d\.]+)\.tar\.xz ``` The above used to successfully download the appmenu-gtk-module tarball from the vala-panel-appmenu releases page: https://gitlab.com/vala-panel-project/vala-panel-appmenu/-/releases Try the attached watch file. This works for vala-panel-appmenu, but not for appmenu-gtk-module. The packaging of vala-panel-appmenu, appmenu-gtk-module and appmenu-registrar is a bit special, because all three packages get built from the same source code tree. [...] The appmenu-gtk-module code is a subfolder in upstream vala-panel-appmenu (subprojects/appmenu-gtk-module) and that subfolder was packaged as a separate src:pkg in Debian at the time when it got introduced. For this the upstream maintainer provides appmenu-gtk-module as a separate tarball for download at [1]. So the watch file should achieve downloading this exact tarball, i.e. https://gitlab.com/vala-panel-project/vala-panel-appmenu/uploads/6c0332e34c41e99de5a1db1fc4239de2/appmenu-gtk-module-24.02.tar.xz Only chew on this if you really want to nut-crack it. I have burnt quite a few brain cells on it yesterday and failed (which does not mean you will also, but be warned, the solution does not seem trivial, however, maybe it is). GitLab asset download URLs are a bit of a mess, but the attached watch file seems to give me that exact URL. Thanks for this! I have a similar problem with archlinux-keyring - which uses a different GitLab instance, gitlab.archlinux.org Using your watch file as a template, I managed to capture the exact URL needed (tried using that and also matching on the releases URL), but I still get stuck on the fact that uscan gets given an HTML page prompting to login instead. wget handled the URL just fine. curl also gets an HTML page... Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 OpenPGP_0x8B229D2F7CCC04F2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065507: RFS: netconsd/0.4-1 [ITP] -- Netconsole Daemon
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "netconsd": * Package name : netconsd Version : 0.4-1 Upstream contact : https://github.com/facebook/netconsd/issues * URL : https://github.com/facebook/netconsd * License : BSD-3-clause * Vcs : https://salsa.debian.org/michel/netconsd Section : admin The source builds the following binary packages: netconsd - Netconsole Daemon To access further information about this package, please visit the following URL: https://mentors.debian.net/package/netconsd/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/n/netconsd/netconsd_0.4-1.dsc Changes for the initial release: netconsd (0.4-1) unstable; urgency=medium . * Initial release. (Closes: #1065462) Regards, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature
