Hi Ludo,
>> Unfortunately, when there are several packages with identical name and
>> version number in two channels, Guix silently chooses one of them.
>> It would probably be more useful to emit a warning.
>
> I believe that’s already the case.
We already had some discussion, the conclusion bei
Hi,
Konrad Hinsen skribis:
> Unfortunately, when there are several packages with identical name and
> version number in two channels, Guix silently chooses one of them.
> It would probably be more useful to emit a warning.
I believe that’s already the case.
Specifically, if there are several p
Hi Vagrant,
> Rather than picking an arbitrary incremental number, I have in the past
> used something based on the results from git describe... e.g. in my
> current checkout of guix:
>
> $ git describe --match=v1.4'*'
> v1.4.0-142685-gfc059c66cf
>
> e.g. 142685 commits past v1.4.0, with the c
On Monday, September 23rd, 2024 at 11:17 AM, Suhail Singh
wrote:
>
>
> Vagrant Cascadian vagr...@debian.org writes:
>
> > Rather than picking an arbitrary incremental number, I have in the past
> > used something based on the results from git describe... e.g. in my
> > current checkout
Vagrant Cascadian writes:
> Rather than picking an arbitrary incremental number, I have in the past
> used something based on the results from git describe... e.g. in my
> current checkout of guix:
>
> $ git describe --match=v1.4'*'
> v1.4.0-142685-gfc059c66cf
>
> e.g. 142685 commits past v1.
While others have pointed out the workflow fix,
On 2024-09-23 10:22, Konrad Hinsen wrote:
If both packages have the same version, then the
command line tools will warn about the ambiguous package
specification. If the version numbers are different, then the tools
will quietly choose the "newer"
On 2024-09-23, Andreas Enge wrote:
> Am Mon, Sep 23, 2024 at 10:22:28AM +0200 schrieb Konrad Hinsen:
>> $ guix show -L . sbcl-websocket-driver
>> name: sbcl-websocket-driver
>> version: 0.2.0-0.df94496
>> location: gnu/packages/lisp-xyz.scm:30847:4
>> It looks like Guix picked the larger on
Hi Andreas,
>> It looks like Guix picked the larger one by
>> alphanumeric order, which is not a reasonable choice in a development
>> context.
>
> This is exactly the role of the number "-0." in front of the git commit;
> one needs to specify by hand the order of the (non-)releases, as coming
Go
Am Mon, Sep 23, 2024 at 10:22:28AM +0200 schrieb Konrad Hinsen:
> $ guix show -L . sbcl-websocket-driver
> name: sbcl-websocket-driver
> version: 0.2.0-0.df94496
> location: gnu/packages/lisp-xyz.scm:30847:4
> It looks like Guix picked the larger one by
> alphanumeric order, which is not a
Hi Kaelyn,
> Whether it does or doesn't depends on the versions of the duplicate
> packages in question. If both packages have the same version, then the
> command line tools will warn about the ambiguous package
> specification. If the version numbers are different, then the tools
> will quietly
On Sunday, September 22nd, 2024 at 1:34 AM, Konrad Hinsen
wrote:
>
>
> Hi Simon,
>
> > > Unfortunately, when there are several packages with identical name and
> > > version number in two channels, Guix silently chooses one of them.
> >
> > Choose when doing what? :-)
>
>
> Building,
Hi Simon,
>> Unfortunately, when there are several packages with identical name and
>> version number in two channels, Guix silently chooses one of them.
>
> Choose when doing what? :-)
Building, installing, ... whatever you can do with a package.
> When running “guix shell” or “guix package”, i
Hi Konrad,
On mer., 18 sept. 2024 at 10:33, Konrad Hinsen
wrote:
> Unfortunately, when there are several packages with identical name and
> version number in two channels, Guix silently chooses one of them.
Choose when doing what? :-)
When running “guix shell” or “guix package”, it should war
Konrad Hinsen writes:
>> On a related note, when multiple channels are enabled, is there a way to
>> specify a specific package from a particular channel?
>
> Yes, using the -e option followed by the Guile module name. See
>
> https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package
Hi,
On Tue, Sep 17 2024, Tobias Geerinckx-Rice wrote:
> 'That is not possible.'
I believe I experienced it when removing or adding propagated or native
inputs (not sure) to my very own guile-pam [1] while using 'guix shell'.
Unfortunately, I have not had time to investigate.
Kind regards
Felix
Suhail Singh writes:
> On a related note, when multiple channels are enabled, is there a way to
> specify a specific package from a particular channel?
Yes, using the -e option followed by the Guile module name. See
https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-package.html
Yo
Konrad Hinsen writes:
> Unfortunately, when there are several packages with identical name and
> version number in two channels, Guix silently chooses one of them.
Ah, I had wondered what it did. Thank you for reporting.
> It would probably be more useful to emit a warning.
Agreed.
On a rela
Hi Tobias,
Geerinckx-Rice writes:
> 'That is not possible.' You must somehow not have measured what you thought
> you measured.
Thanks for restoring my faith in Guix!
You were in fact right, I was not measuring what I thought you measured,
but for an unusual reason.
> Can you 'reproduce' t
Hi Konrad,
'That is not possible.' You must somehow not have measured what you thought
you measured.
Probably not the answer you were looking for, but reassuring in its own way.
Can you 'reproduce' this? It might still be enlightening to find out where
things went wrong.
Kind regards,
T G-
Hi everyone,
Until today, I thought that all parts of a package definition that could
make a difference to the outputs enter somehow into the package hash,
such that any relevant change to a package definition causes a rebuild.
Today's experience: I built a package, then removed an "add-after" fo
20 matches
Mail list logo
