[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fixing d/watch Teamwide





On Fri, 23 Apr, 2021, 7:07 am Robbi Nespu, <robbinespu@gmail.com> wrote:

On 4/23/21 5:02 AM, Nilesh Patra wrote:
> Hi,
>
> GitHub lately decided to change it's tarball locations from
> archive/version to archive/ref/tag/version - or something similar.
> This ended up breaking a lot of d/watch files which fetch stuff from
> github.
> There was a discussion on -devel[1] regarding fixing d/watch for github
> URLs, a few nice suggestions but nothing concrete - and looks like in
> any case, we need to editing huge amounts of watch files.
>
> If someone has a script/way to do that teamwide, it'd be nice - please
> consider doing so.
> If not, I'll try asking around. Perhaps JS team fixed that already.
>
> Or would you know if there's another way than manually(or via script) changing watch
> files?
>
> [1]: https://lists.debian.org/debian-devel/2021/03/msg00179.html
>
> Nilesh
>

Hi Nilesh,
I thinking some concept, I hope it okay to type so maybe one of the
logic will work... as I also new with debian packaging to I not use it
possible or not.

1 Using github API
1.1 access limit
        - Unauthenticated clients can make 60 requests per hour
        - Authenticated clients via personal OAuth tokens can make 5,000
requests per hour
        - Enterprise client, not sure..
1.2 Who use it
        - if personal person, it don't think that will be problem as the limit
is good enough
        - but for bigger system like tracker.d.o, this will be issue
1.3 Possibility of endpoint changes
        - It rarely IMO but the best workaround (so we don't need to alter
watch file on all debian package) is to have 1 system hosted by debian
so the watch file will just get package version and package URL (tar.gz
file) which return by Github API.
1.4 comment
        - need API subscription (maybe need to pay? or github willing to give
free access?). For example, I may use
https://api.github.com/repos/<username>/<projectname>/releases and read
tag_name, prerelease and tarball_url for next further action
        - need a new system (lets call it as "watch.debian.net" to use github
API) so watch file will fetch from it
        (github API) <--> (watch.debian.net) <--> (uscan watch file)

Not practical. Who is going to pay for it?
You cannot ask everyone to do that. Problematic for UDD since it makes a huge number of such requests.


2. mass changes
2.1 tool
        - need to write a tool to fetch any debian package that use "not
working" watch URL (github)
        - alter the d/watch file with "working" watch URL (github)
        - commit
2.2 comment
        - if the URL break/change in future, this tool need to execute again
and commit the change.

Please read through the thread on -devel I linked to, Yadd who maintains uscan suggested similar and more concrete.

https://lists.debian.org/debian-devel/2021/03/msg00182.html


3. manual changes
3.1 comment
        - The maintainer need to spent time each time URL changes happen..it
repetitive


 From this 3 concept in my head, the best solution and less time
consuming in future and now are using github API. But as I mention that
part split into 2; either use call the github API directly or call the
API from a centralize system (watch.debian.net)

See:
https://lists.debian.org/debian-devel/2021/03/msg00186.html

The point of my mail was *not* "what could we do better?"  We already had that discussion on -devel, and I absolutely do not want to discuss it again.
Rather the point of this mail was, "what's the plan of action now? And just please do it"

For now, we need to change watch files manually as it seems. Even if it's using a redirector, a GitHub regex from uscan, manually changing or whatever the watch file needs to be changed, and it'd be nice if someone can do that teamwide.

And probably Andreas has a way to do this.

In any case, thanks for replying.

Nilesh

Reply to: