On Fri, 23 Apr, 2021, 7:07 am Robbi Nespu, <robbine...@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 the mail 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.
