Re: Should guix track package aliases?

Hi, zimoun skribis: > On Sun, 10 May 2020 at 12:08, Vincent Legoll wrote: > >> Used googl often being used to approximate it, crudely but effectively. > > The big question is how to build such database. > Wikidata? There’s also the Common Platform Enumeration (CPE), the thing used to refer to

Re: Should guix track package aliases?

For gadl, it was that the gal website hosting it went down. With regards to pre-commit hooks, just to make sure each commit message conforms to what is expected and is best practice for PRs and commits for the project. On Mon, May 25, 2020, 19:15 zimoun wrote: > Dear Josh, > > On Tue, 26 May 20

Re: Should guix track package aliases?

Dear Josh, On Tue, 26 May 2020 at 00:31, Josh Marshall wrote: > I could fix up some of the new homepages. We've already seen some Gnu > related package losses like gdal. I think SWH adoption for packages may want > to be moved from as packages are added to as packages are updated -- just to

Re: Should guix track package aliases?

I could fix up some of the new homepages. We've already seen some Gnu related package losses like gdal. I think SWH adoption for packages may want to be moved from as packages are added to as packages are updated -- just to have a regular, low overhead, but still slow move to SWH. On Mon, May 25

Re: Should guix track package aliases?

Hello, On 25/05/2020 16:20, Josh Marshall wrote: Checking out repology.org/repository/gnuguix , it got picked up and guix looks like it is in much better shape. Yay, but we're still far from the front page's top repositories... But, to celebrate our c

Re: Should guix track package aliases?

Checking out repology.org/repository/gnuguix , it got picked up and guix looks like it is in much better shape. On Mon, May 25, 2020, 08:04 Nicolò Balzarotti wrote: > > Hello everybody, > It has been fixed today > https://issues.guix.gnu.org/issue/37207 > > Repology data is now updated > > Nicol

Re: Should guix track package aliases?

Hello everybody, It has been fixed today https://issues.guix.gnu.org/issue/37207 Repology data is now updated Nicolò Josh Marshall writes: > Hi Zimoun, > > The HTTP headers of the page indicate that the file hasn't changed since > 1970. This is a bug. That incorrect date breaks repology.or

Re: Should guix track package aliases?

Hi Zimoun, The HTTP headers of the page indicate that the file hasn't changed since 1970. This is a bug. That incorrect date breaks repology.org trying to track guix packages. On Mon, May 25, 2020, 06:42 zimoun wrote: > Dear Josh, > > On Sun, 24 May 2020 at 21:26, Josh Marshall > wrote: > >

Re: Should guix track package aliases?

Dear Josh, On Sun, 24 May 2020 at 21:26, Josh Marshall wrote: > > Checking http://guix.gnu.org/packages.json again, it seems like the > server changes to not misrepresent dates have not been applied yet. > Can someone get in and do that? I am not sure to understand what you mean and what you are

Re: Should guix track package aliases?

Checking http://guix.gnu.org/packages.json again, it seems like the server changes to not misrepresent dates have not been applied yet. Can someone get in and do that? On Sun, May 10, 2020 at 2:16 PM Josh Marshall wrote: > > This back and forth is what I've been having going on in my head. We mi

Re: Should guix track package aliases?

This back and forth is what I've been having going on in my head. We might be able to leverage repology.org for their work on mapping packages across distros. Yesterday, civodul entered a bug to remove the Etag and last-modified headers in the nginx config to fix a bug on our side so repology wil

Re: Should guix track package aliases?

Hi Julien, On Sun, 10 May 2020 at 14:13, Julien Lepiller wrote: > The proposal was about suggesting anotger nameqwhen no package was found, not > to install something else. Sorry I misinterpreted. > >Well, do you have specific example in mind? > > $ guix install gcc > guix install: error: gc

Re: Should guix track package aliases?

Hi Vincent, On Sun, 10 May 2020 at 12:08, Vincent Legoll wrote: > Used googl often being used to approximate it, crudely but effectively. The big question is how to build such database. Wikidata? All the best, simon

Re: Should guix track package aliases?

Le 10 mai 2020 05:57:22 GMT-04:00, zimoun a écrit : >Dear, > >On Sat, 9 May 2020 at 22:19, Josh Marshall > wrote: > >> [...] naming conventions between the source project, [...] , and guix >itself have some drift. > >Some packages already track upstream name: see the field '(proprieties >(upstream

Re: Should guix track package aliases?

On 09/05/2020 22:18, Josh Marshall wrote: This appears that it could be low effort, not interfere with any commands, not really change the interface, and make life easier. Anybody have any thoughts as to whether this would be a good idea or not? What about the following: >8--

Re: Should guix track package aliases?

Dear, On Sat, 9 May 2020 at 22:19, Josh Marshall wrote: > [...] naming conventions between the source project, [...] , and guix itself > have some drift. Some packages already track upstream name: see the field '(proprieties (upstream-name . "foo"))', e.g., the package "r-flowsom", > The appr

Re: Should guix track package aliases?

Hi, I'm not sure if that's something guix needs to be aware of. If the name differs very much and guix naming conventions differ plus it can not be found through any of the fields, it makes sense. But you probably don't want to track the different conventions used by various package managers as it

Should guix track package aliases?

I'm starting to collect software that needs packaging, and one thing I'm running into is that naming conventions between the source project, various distros, and guix itself have some drift. Something which seems low effort but would ease translating between various nomenclatures would be to track