Re: Can we find a better idiom for unversioned packages?

[Sarah Morgensen]

Hi Maxime,

Maxime Devos  writes:

>> > Not losing the revision is useful for things like 
>> > ;, to be able to determine the old
>> > revision.  (That's not about inheriting packages though.)
>
>> Isn't that addressed by addressing the second point, though?  Like, if
>> you know the source location of the revision, you can read it back to
>> get the value itself (or possibly even access it as-is), no?
>
> Indeed!  The patch [0] addresses the second point.  With that patch,
> the proposed  isn't required.  But also: some people
> (at least Sarah?) consider [0] a work-around, and if guix used something
> like , [0] wouldn't be necessary.
>
> It doesn't really matter to me what we'll end up using in guix
> in the long term, though in the short term, I would like something
> like [0] to be merged, as it is used by the (not-yet submitted, needs some
> cleanup, testing & rebasing) minetest updater, and it makes
>  work in more cases.
>
> [0]: 

Despite starting this thread, I do agree that your patch would be
helpful, at least in the short term, since I'd like to get git updating
working sooner rather than later :)

(There are a couple other usages of 'let' forms in packages, and your
patch could either help or hinder getting source locations for those,
depending on what semantics we want.  Very much an edge case, though.)

--
Sarah

Re: [bug#50347] [RFC PATCH] lint: Warn about kernel modules with a suspect license.

[Maxime Devos]

I've discussed this with dstolfa on IRC:
https://logs.guix.gnu.org/guix/2021-09-02.log#234707
https://logs.guix.gnu.org/guix/2021-09-03.log

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

[bug#50347] [RFC PATCH] lint: Warn about kernel modules with a suspect license.

[Maxime Devos]

X-Debbugs-CC: guix-devel@gnu.org

[CC'ing guix-devel@gnu.org because a wider audience seems in order?]

Hi guix,

This patch adds a 'suspect-license' linter detecting some suspicious
values in the license fields of linux modules:

gnu/packages/file-systems.scm:1317:13: zfs@2.1.0: license appears incompatible 
with the Linux kernel
gnu/packages/linux.scm:1185:13: acpi-call-linux-module@1.2.1: license appears 
incompatible with the Linux kernel
gnu/packages/linux.scm:8205:15: ttyebus-linux-module@1.5-0.fe4332a: license 
appears incompatible with the Linux kernel

For zfs, the issue is the CDDL license.  For the others, the issue
is the gpl3+ license.  See the article by the SFLC for why this linter
detets ZFS:

.

I wrote a little about the CDDL-GPL incompatibility issue
(most likely a GPL violation?) at .

Greetings,
Maxime.
From 851cf20b7d5aed45c3331781afef8de3961f4bb4 Mon Sep 17 00:00:00 2001
From: Maxime Devos 
Date: Thu, 2 Sep 2021 23:30:15 +0200
Subject: [PATCH] lint: Warn about kernel modules with a suspect license.

* guix/lint.scm
  (check-suspect-license): New linter.
  (%local-checkers)[suspect-license]: Register it.
---
 guix/lint.scm | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/guix/lint.scm b/guix/lint.scm
index ffd3f7007e..3a7f3be327 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -34,6 +34,7 @@
   #:use-module (guix store)
   #:autoload   (guix base16) (bytevector->base16-string)
   #:use-module (guix base32)
+  #:use-module (guix build-system)
   #:use-module (guix diagnostics)
   #:use-module (guix download)
   #:use-module (guix ftp-client)
@@ -1347,6 +1348,31 @@ of the propagated inputs it pulls in."
   (make-warning package (G_ "invalid license field")
 #:field 'license)
 
+(define (check-suspect-license package)
+  "Warn about suspicious license combinations in PACKAGE."
+  ;; Use 'build-system-name' instead of comparing the build
+  ;; system directly with 'linux-module-build-system' to avoid
+  ;; loading (guix build-system linux-module) when no Linux modules
+  ;; are linted.
+  (define linux-module?
+(eq? 'linux-module
+ (build-system-name (package-build-system package
+  ;; This has plenty of false negatives and should
+  ;; have very few false positives.
+  (define gpl2-only-incompatible?
+;; The Linux kernel is GPL-2-only, so GPL3 and later are out.
+;; The GPL and CDDL appear to be incompatible, see
+;; 
+;; and .
+(memq (package-license package)
+  (list gpl3 gpl3+ cddl1.0)))
+  (if (and linux-module? gpl2-only-incompatible?)
+  (list
+   (make-warning package
+ (G_ "license appears incompatible with the Linux kernel")
+ #:field 'license))
+  '()))
+
 (define (current-vulnerabilities*)
   "Like 'current-vulnerabilities', but return the empty list upon networking
 or HTTP errors.  This allows network-less operation and makes problems with
@@ -1762,6 +1788,10 @@ them for PACKAGE."
  (description "Make sure the 'license' field is a  \
 or a list thereof")
  (check   check-license))
+   (lint-checker
+ (name'suspect-license)
+ (description "Detect some suspect combinations of licenses")
+ (check   check-suspect-license))
(lint-checker
  (name'optional-tests)
  (description "Make sure tests are only run when requested")
-- 
2.33.0



signature.asc
Description: This is a digitally signed message part

Re: branch core-updates-frozen updated: gnu: sddm: Fix build.

[Efraim Flashner]

On Thu, Sep 02, 2021 at 06:47:10PM +0200, Ludovic Courtès wrote:
> Hello!
> 
> guix-comm...@gnu.org skribis:
> 
> > efraim pushed a commit to branch core-updates-frozen
> > in repository guix.
> >
> > The following commit(s) were added to refs/heads/core-updates-frozen by 
> > this push:
> >  new f883677  gnu: sddm: Fix build.
> > f883677 is described below
> >
> > commit f8836774e2c76c1f4d9bee11339839f7d878e32a
> > Author: Efraim Flashner 
> > AuthorDate: Thu Sep 2 17:15:39 2021 +0300
> >
> > gnu: sddm: Fix build.
> > 
> > * gnu/packages/display-managers.scm (sddm)[arguments]: Use gexp for
> > configure-flags.
> 
> Out of curiosity, what was the build issue?  Could it be that
> ‘%build-inputs’ was undefined for this build system?

definitely a possiblity.

> 
> >  (arguments
> >   `(#:configure-flags
> 
> [...]
> 
> > +   ,#~(list
> > +;; This option currently does nothing, but will presumably be 
> > enabled
> > +;; if/when  is merged.
> > +"-DENABLE_WAYLAND=ON"
> > +"-DENABLE_PAM=ON"
> > +;; Both flags are required for elogind support.
> > +"-DNO_SYSTEMD=ON" "-DUSE_ELOGIND=ON"
> > +"-DCONFIG_FILE=/etc/sddm.conf"
> > +;; Set path to /etc/login.defs.
> > +;; An alternative would be to use -DUID_MIN and -DUID_MAX.
> > +(string-append "-DLOGIN_DEFS_PATH="
> > +   #$shadow
> 
> Note that this style makes it impossible for users to override “shadow”
> via something like:
> 
>   (package
> (inherit sddm)
> (inputs `(("shadow" ,my-very-own-shadow
> 
> To avoid that pitfall, the New Recommended Style™ is:
> 
>   #~(list …
>   #$(this-package-input "shadow"))
> 
> Thanks,
> Ludo’.

Sounds good. I'll take another go at it in the morning unless someone
beats me to it.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Can we find a better idiom for unversioned packages?

[Leo Famulari]

On Thu, Sep 02, 2021 at 12:51:58PM -0400, Leo Famulari wrote:
> On Wed, Sep 01, 2021 at 06:50:36PM +0200, Xinglu Chen wrote:
> > > Commit dates don't have a consistent meaning: are they the time of
> > > first revision of a commit? Final revision of a commit? Time of
> > > signing? Pushing? They are often useful to estimate a timeline, but
> > > it's common for a Git "timeline" to jump back and forth by months or a
> > > year due to long-running development branches being merged in, or due
> > > to a "commit and then polish by rebasing" workflow.
> > 
> > I would say the the time of the final commit would be the best option,
> > but I agree that it can be ambiguous.

Reading your message again, I think you misunderstood what I wrote.

I wasn't asking what date we should choose to include in our package
versions. I was asking, "What does the Git commit timestamp describe?"
And the answer is that there is not a clear answer, and it depends on
the workflow of the person who made the Git commit. My point being that
a Git repo does not offer us meaningful information about when anything
happened.

Re: Can we find a better idiom for unversioned packages?

[Leo Famulari]

On Tue, Aug 31, 2021 at 12:57:23PM -0700, Sarah Morgensen wrote:
> I do not have a specific solution in mind, but I think there must be
> one.  I do have a few half-baked ideas, but I'm curious what we can all
> come up with together.  Or maybe you'll just tell me I'm just being
> awfully picky :)

Thanks for starting this discussion. In order to avoid repeating /
rediscovering the reasons why the current idiom was chosen, I recommend
reading the discussion that led to it:

https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00335.html

Re: Can we find a better idiom for unversioned packages?

[Leo Famulari]

On Wed, Sep 01, 2021 at 06:50:36PM +0200, Xinglu Chen wrote:
> With the former, I can quickly see that the version is from 2021-01-31,
> whereas with the latter, I would have to either find the VCS repo online
> or go to my local checkout of it and browse the logs.
> 
> > Commit dates don't have a consistent meaning: are they the time of
> > first revision of a commit? Final revision of a commit? Time of
> > signing? Pushing? They are often useful to estimate a timeline, but
> > it's common for a Git "timeline" to jump back and forth by months or a
> > year due to long-running development branches being merged in, or due
> > to a "commit and then polish by rebasing" workflow.
> 
> I would say the the time of the final commit would be the best option,
> but I agree that it can be ambiguous.

My point was that Git does not provide you a timestamp to use for this.
There are multiple timestamps embedded into Git commits and none of them
reflect anything meaningful.

Re: branch core-updates-frozen updated: gnu: sddm: Fix build.

[Ludovic Courtès]

Hello!

guix-comm...@gnu.org skribis:

> efraim pushed a commit to branch core-updates-frozen
> in repository guix.
>
> The following commit(s) were added to refs/heads/core-updates-frozen by this 
> push:
>  new f883677  gnu: sddm: Fix build.
> f883677 is described below
>
> commit f8836774e2c76c1f4d9bee11339839f7d878e32a
> Author: Efraim Flashner 
> AuthorDate: Thu Sep 2 17:15:39 2021 +0300
>
> gnu: sddm: Fix build.
> 
> * gnu/packages/display-managers.scm (sddm)[arguments]: Use gexp for
> configure-flags.

Out of curiosity, what was the build issue?  Could it be that
‘%build-inputs’ was undefined for this build system?

>  (arguments
>   `(#:configure-flags

[...]

> +   ,#~(list
> +;; This option currently does nothing, but will presumably be 
> enabled
> +;; if/when  is merged.
> +"-DENABLE_WAYLAND=ON"
> +"-DENABLE_PAM=ON"
> +;; Both flags are required for elogind support.
> +"-DNO_SYSTEMD=ON" "-DUSE_ELOGIND=ON"
> +"-DCONFIG_FILE=/etc/sddm.conf"
> +;; Set path to /etc/login.defs.
> +;; An alternative would be to use -DUID_MIN and -DUID_MAX.
> +(string-append "-DLOGIN_DEFS_PATH="
> +   #$shadow

Note that this style makes it impossible for users to override “shadow”
via something like:

  (package
(inherit sddm)
(inputs `(("shadow" ,my-very-own-shadow

To avoid that pitfall, the New Recommended Style™ is:

  #~(list …
  #$(this-package-input "shadow"))

Thanks,
Ludo’.

Re: I just got my pinephone.

[Christine Lemmer-Webber]

Joshua Branson  writes:

> Hey Guix!
>
> I just got my phinephone.

Horray!  Awesome!

> It's currently running postmarketOS (1).  I usually work nights two
> nights a week 10pm-6am (EST) Sunday night and Monday night.  If a guix
> developer would like ssh access to it during those times, then please
> let me know.  If I should use Mobian instead to help port guix to it,
> then I would be willing to switch.

I wonder how much harder it is to port the pine*.scm stuff over as a
"just get it to boot" first step.  It can't be too hard... can it?!

It looks like I'm being "forced" to switch over to my pinephone as my
primary phone anyway.  So maybe now's a good time to see if we can Guix
it up.

Guix on top of Mobian makes sense as a starting point to just make sure
packiages work though I suppose.  I do have Mobian running on mine so
maybe that's a great place to start.

What I'd really like: to use the Guix System Image API so I can do a
"just works" flash-to-sd-card.

> I'd be happy to help out!  Also jmp.chat (2) works really well with
> chatty.

Let's talk in #guix?!

> Thanks,
>
> Joshua
>
> 1) https://postmarketos.org/source-code/
>
> 2) https://jmp.chat

Re: Can we find a better idiom for unversioned packages?

[Maxime Devos]

Liliana Marie Prikler schreef op do 02-09-2021 om 16:20 [+0200]:
> Am Donnerstag, den 02.09.2021, 16:09 +0200 schrieb Maxime Devos:
> > > > > > > 2. We cannot get at the source location for the definition
> > > > > > > of
> > > > > > > 'commit' or 'revision'.  This would be useful for updating
> > > > > > > these
> > > > > > > packages with `guix refresh -u`.  There is a proposed patch
> > > > > > > [0]
> > > > > > > to
> > > > > > > work around this, but it *is* a workaround.
> > > > > Other versioning idioms would also be workarounds, wouldn't
> > > > > they?
> > > > > 
> > > > > > > 3. Packages inheriting from it lose the definitions.  For
> > > > > > > actual fields, we have e.g. `(package-version this-
> > > > > > > package)`, but we have no equivalent for these.
> > > > > What purpose would extracting those serve however? 
> > > > 
> > > > Not losing the revision is useful for things like 
> > > > ;;;, to be able to determine
> > > > the old
> > > > revision.  (That's not about inheriting packages though.)
> > > Isn't that addressed by addressing the second point, though?  Like,
> > > if
> > > you know the source location of the revision, you can read it back
> > > to
> > > get the value itself (or possibly even access it as-is), no?
> > 
> > Indeed!  The patch [0] addresses the second point.  With that patch,
> > the proposed  isn't required.  But also: some
> > people (at least Sarah?) consider [0] a work-around, and if guix used
> > something like , [0] wouldn't be necessary.
> > 
> > It doesn't really matter to me what we'll end up using in guix
> > in the long term, though in the short term, I would like something
> > like [0] to be merged, as it is used by the (not-yet submitted, needs
> > some cleanup, testing & rebasing) minetest updater, and it makes
> >  work in more cases.
> That's not quite my point.  Sarah said that "inheriting definitions"
> loses those values, which is true regardless of the merge of [0].  What
> you said to answer my question w.r.t. why that matters was to repeat
> the second point, which is addressed by [0].

[extra newlines for clarity]

> In other words, what I'm
> asking is why specifically inheriting (as in record inheriting) is made
> to be such a big deal that it deserves its own point when I would
> personally argue that it is not at all that important.

Ok, I understand!  Though I don't have an answer to your question.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Can we find a better idiom for unversioned packages?

[Liliana Marie Prikler]

Am Donnerstag, den 02.09.2021, 16:09 +0200 schrieb Maxime Devos:
> > > > > > 2. We cannot get at the source location for the definition
> > > > > > of
> > > > > > 'commit' or 'revision'.  This would be useful for updating
> > > > > > these
> > > > > > packages with `guix refresh -u`.  There is a proposed patch
> > > > > > [0]
> > > > > > to
> > > > > > work around this, but it *is* a workaround.
> > > > Other versioning idioms would also be workarounds, wouldn't
> > > > they?
> > > > 
> > > > > > 3. Packages inheriting from it lose the definitions.  For
> > > > > > actual fields, we have e.g. `(package-version this-
> > > > > > package)`, but we have no equivalent for these.
> > > > What purpose would extracting those serve however? 
> > > 
> > > Not losing the revision is useful for things like 
> > > ;;, to be able to determine
> > > the old
> > > revision.  (That's not about inheriting packages though.)
> > Isn't that addressed by addressing the second point, though?  Like,
> > if
> > you know the source location of the revision, you can read it back
> > to
> > get the value itself (or possibly even access it as-is), no?
> 
> Indeed!  The patch [0] addresses the second point.  With that patch,
> the proposed  isn't required.  But also: some
> people (at least Sarah?) consider [0] a work-around, and if guix used
> something like , [0] wouldn't be necessary.
> 
> It doesn't really matter to me what we'll end up using in guix
> in the long term, though in the short term, I would like something
> like [0] to be merged, as it is used by the (not-yet submitted, needs
> some cleanup, testing & rebasing) minetest updater, and it makes
>  work in more cases.
That's not quite my point.  Sarah said that "inheriting definitions"
loses those values, which is true regardless of the merge of [0].  What
you said to answer my question w.r.t. why that matters was to repeat
the second point, which is addressed by [0].  In other words, what I'm
asking is why specifically inheriting (as in record inheriting) is made
to be such a big deal that it deserves its own point when I would
personally argue that it is not at all that important.

Greetings

Re: Can we find a better idiom for unversioned packages?

[Maxime Devos]

> > > > > 2. We cannot get at the source location for the definition of
> > > > > 'commit' or 'revision'.  This would be useful for updating
> > > > > these
> > > > > packages with `guix refresh -u`.  There is a proposed patch [0]
> > > > > to
> > > > > work around this, but it *is* a workaround.
> > > Other versioning idioms would also be workarounds, wouldn't they?
> > > 
> > > > > 3. Packages inheriting from it lose the definitions.  For
> > > > > actual
> > > > > fields, we have e.g. `(package-version this-package)`, but we
> > > > > have
> > > > > no equivalent for these.
> > > What purpose would extracting those serve however? 
> > 
> > Not losing the revision is useful for things like 
> > ;, to be able to determine the old
> > revision.  (That's not about inheriting packages though.)

> Isn't that addressed by addressing the second point, though?  Like, if
> you know the source location of the revision, you can read it back to
> get the value itself (or possibly even access it as-is), no?

Indeed!  The patch [0] addresses the second point.  With that patch,
the proposed  isn't required.  But also: some people
(at least Sarah?) consider [0] a work-around, and if guix used something
like , [0] wouldn't be necessary.

It doesn't really matter to me what we'll end up using in guix
in the long term, though in the short term, I would like something
like [0] to be merged, as it is used by the (not-yet submitted, needs some
cleanup, testing & rebasing) minetest updater, and it makes
 work in more cases.

[0]: 

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Can we find a better idiom for unversioned packages?

[Maxime Devos]

Liliana Marie Prikler schreef op wo 01-09-2021 om 23:47 [+0200]:
> > https://guix.gnu.org/manual/en/html_node/Invoking-guix-download.html
> Imo the only thing awkard about guix download is that it only handles
> tarballs when a large chunk of packages use some sort of version
> control.  We might want to look over that at some point and specify
> revisions/commits to download on the command line.

jgart sent a patch to implement this for git:
.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Transform options should error on nonexistant targets

[zimoun]

Hi Ludo,

On Thu, 2 Sept 2021 at 12:06, Ludovic Courtès  wrote:

> Unfortunately we cannot do that: rewriting happens lazily, when the
> various inputs fields (which are thunked) are accessed.  When PROC
> returns P, we still need to recurse into its inputs, until CUT? says we
> can stop.  (I’m surprised this change triggers only one test failure
> actually.)

Yeah.  After sending the email, I tried to fix stuff and I get the point. :-)


However, from my opinion, it is easy to check if the package-target is
a package or not, i.e.

  $ guix build foo --=package-target=new
  guix build: error: package-target: unknown package

For instance by using 'specification->package'; see attached patch.
But then, the test suite fails; I guess because 'dummy-package' and I
have not found the time to investigate.  From my point of view, this
kind of patch will fix one part of the initial issue reported by Ryan.

The other issue is to list if the transformation is applied or not.  I
think it is possible by traversing again the graph and check if a
property appears at least once; well it should be better to warn if
the 'mapping-property' is not found at least once.  I had some
headaches to implement it... and I moved to other "urgent" stuff. :-)


Last, speaking about transformations, the graph is walked too much
when several transformations is applied:

   guix build hello --with-latest=foo --with-input=bar=baz --with-latest=chouib

then the graph is walked 3 times, IIUC.  The options needs a rewrite
to pass a list of specs to 'package-with-latest-upstream' and not
twice a list with only one element.  This would reduce to 2 walks.
Then it could be nice to compose the transformation and then walk only
once (apply 'package-mapping' only once).
Well, maybe I miss something.

Cheers,
simon
From c0fa86d316c91044630b85c9e789f9a455fd29f4 Mon Sep 17 00:00:00 2001
From: zimoun 
Date: Fri, 27 Aug 2021 18:15:16 +0200
Subject: [PATCH] transformations: Error when incorrect specifications.

* guix/transformations.scm (transform-package-with-debug-info,
transform-package-latest, transform-package-tests)[rewrite]: Raise when
incorrect specification.
(options->transformation)[package-name?]: New procedure.
[applicable]: Use it.
---
 guix/transformations.scm | 41 
 1 file changed, 33 insertions(+), 8 deletions(-)

diff --git a/guix/transformations.scm b/guix/transformations.scm
index 5122baa403..2546017d0d 100644
--- a/guix/transformations.scm
+++ b/guix/transformations.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Ludovic Courtès 
+;;; Copyright © 2021 Simon Tournier 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -432,9 +433,15 @@ to the same package but with #:strip-binaries? #f in its 'arguments' field."
(replacement (loop next
 
   (define rewrite
-(package-input-rewriting/spec (map (lambda (spec)
- (cons spec package-with-debug-info))
-   specs)))
+(package-input-rewriting/spec
+ (map (lambda (spec)
+(match (string-tokenize spec %not-equal)
+  ((spec)
+   (cons spec package-with-debug-info))
+  (_
+   (raise
+(formatted-message (G_ "~a: invalid specification") spec)
+  specs)))
 
   (lambda (obj)
 (if (package? obj)
@@ -451,9 +458,15 @@ to the same package but with #:strip-binaries? #f in its 'arguments' field."
  ((#:tests? _ #f) #f)
 
   (define rewrite
-(package-input-rewriting/spec (map (lambda (spec)
- (cons spec package-without-tests))
-   specs)))
+(package-input-rewriting/spec
+ (map (lambda (spec)
+(match (string-tokenize spec %not-equal)
+  ((spec)
+   (cons spec package-without-tests))
+  (_
+   (raise
+(formatted-message (G_ "~a: invalid specification") spec)
+  specs)))
 
   (lambda (obj)
 (if (package? obj)
@@ -569,7 +582,12 @@ are replaced by their latest upstream version."
   (define rewrite
 (package-input-rewriting/spec
  (map (lambda (spec)
-(cons spec package-with-latest-upstream))
+(match (string-tokenize spec %not-equal)
+  ((spec)
+   (cons spec package-with-latest-upstream))
+  (_
+   (raise
+(formatted-message (G_ "~a: invalid specification") spec)
   specs)))
 
   (lambda (obj)
@@ -695,6 +713,12 @@ the resulting objects.  OPTS must be a list of symbol/string pairs such as:
 
 Each symbol names a transformation and the corresponding string is an argument
 to that transformation."
+  (define (package-name? value)
+;; Return an error if value does not correspond to a package.
+(match 

Re: Transform options should error on nonexistant targets

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Wed, 18 Aug 2021 at 03:57, Ryan Prior  wrote:
>> I learned today that Guix will chug happily along applying a transform to a 
>> nonexistent package.
>>
>> For example, I can run:
>> guix environment --with-latest=not-exist --ad-hoc which
>>
>> This shows no warning or errors. I think it would be beneficial to show an 
>> error & bail if the target of a transformation is a package that doesn't 
>> exist, as this is likely indicative of an error.
>
> Indeed. :-)  The issue comes from guix/transformations.scm 
> (options->transformation):
>
>   (let ((new (transform obj)))
> (when (eq? new obj)
>   (warning (G_ "transformation '~a' had no effect on ~a~%")
>name
>(if (package? obj)
>(package-full-name obj)
>obj)))
> new)
>
>
> and the warning is not reach because guix/packages.scm (package-mapping):
>
> (else
>  ;; Return a variant of P with PROC applied to P and its explicit
>  ;; dependencies, recursively.  Memoize the transformations.  
> Failing
>  ;; to do that, we would build a huge object graph with lots of
>  ;; duplicates, which in turns prevents us from benefiting from
>  ;; memoization in 'package-derivation'.
>  (let ((p (proc p)))
>(package
> …
>
>
> In the case of “guix build hello --with-latest=foo”, then ’proc’ has no
> effect, i.e., ’p’ is identical to ’(proc p)’ but a new package is
> allocated which leads that ’new’ and ’obj’ are not ’eq?’.

Indeed.

[...]

> + (let ((new (proc p)))
> +   (if (eq? new p)
> +   p
> +   (package
> + (inherit new)
> + (location (package-location new))
> + (build-system (if deep?
> +   (build-system-with-package-mapping
> +(package-build-system new) rewrite)
> +   (package-build-system new)))
> + (inputs (map rewrite (package-inputs new)))
> + (native-inputs (map rewrite (package-native-inputs 
> new)))
> + (propagated-inputs (map rewrite 
> (package-propagated-inputs new)))
> + (replacement (and=> (package-replacement new) replace))
> + (properties `((,mapping-property . #t)
> +   ,@(package-properties new))

Unfortunately we cannot do that: rewriting happens lazily, when the
various inputs fields (which are thunked) are accessed.  When PROC
returns P, we still need to recurse into its inputs, until CUT? says we
can stop.  (I’m surprised this change triggers only one test failure
actually.)

Does that make sense?

Thanks,
Ludo’.

Re: Can we find a better idiom for unversioned packages?

[Liliana Marie Prikler]

Am Donnerstag, den 02.09.2021, 07:53 + schrieb Jonathan McHugh:
> Hi Liliana,
> 
> Given your examples I expect improving upstream CHANGELOG (or third
> party) files would be too much of a burden in order to solve the
> aforementioned problems.
ChangeLogs are generally not installed as part of packages, though some
packages might include them as documentation.  In other cases, they
might even be part of the source files themselves, Emacs packages
sometimes function like that.  In either case, they only "address" the
problems insofar as reading them might give a clue about what goes into
the resulting binary, but they do not help that much with versioning.

> 
> Jonathan
> 
> September 1, 2021 11:47 PM, "Liliana Marie Prikler" <
> leo.prik...@student.tugraz.at> wrote:
> 
> > Am Mittwoch, den 01.09.2021, 19:48 + schrieb Jonathan McHugh:
> > 
> > > September 1, 2021 8:35 PM, "Liliana Marie Prikler" <
> > > leo.prik...@student.tugraz.at> wrote
> > > 
> > > Making our rando commit git versions look like such other distro
> > > versions does come at a disadvantage though, particularly when we
> > > look
> > > at it through the lense of someone not used to Guix' versioning
> > > scheme.
> > > Instead of telling us "yeah, this is the Nth time we picked a
> > > rando
> > > commit since the last release and this time it's de4db3ef", users
> > > coming from such distros would assume "oh well, this is still
> > > good
> > > ol'
> > > 1.0 with some more patches applied". So while the commit itself
> > > does
> > > not give us any particularly useful information (unless you're
> > > that
> > > person who uses this part of the version string to look the
> > > commit
> > > up
> > > on hubbucket), especially not when thinking in the context of
> > > versioning scheme, it does provide the existential information of
> > > "hold
> > > on, this is not a release commit, it's something else" and might
> > > thus
> > > direct users to be a little more attentive when they'd otherwise
> > > go
> > > "yep, upstream considers this solid and Guix considers it even
> > > more
> > > solid, so it's the solidest". Note, that this can be overcome
> > > both
> > > by
> > > teaching/learning about it and by using a special sigil as
> > > mentioned
> > > above.
> > > 
> > > Perhaps a function revealing metadata based upon the version
> > > string
> > > would allow more people get an overview without visiting
> > > hubbucket^1?
> > 
> > I don't think that information is actually encoded anywhere nor
> > immediately obvious unless you're vaguely familiar with said
> > software,
> > but it's still important e.g. if reading the documentation. Does
> > this
> > feature mentioned in the frobnicatorinator 1.44 docs apply to 1.36
> > or
> > not? Do the examples from some book written in the early 70s work
> > if I
> > compile them with GCC 12? And so on and so forth.

Re: Can we find a better idiom for unversioned packages?

[Jonathan McHugh]

Hi Liliana,

Given your examples I expect improving upstream CHANGELOG (or third party) 
files would be too much of a burden in order to solve the aforementioned 
problems.


Jonathan

September 1, 2021 11:47 PM, "Liliana Marie Prikler" 
 wrote:

> Am Mittwoch, den 01.09.2021, 19:48 + schrieb Jonathan McHugh:
> 
>> September 1, 2021 8:35 PM, "Liliana Marie Prikler" <
>> leo.prik...@student.tugraz.at> wrote
>> 
>> Making our rando commit git versions look like such other distro
>> versions does come at a disadvantage though, particularly when we
>> look
>> at it through the lense of someone not used to Guix' versioning
>> scheme.
>> Instead of telling us "yeah, this is the Nth time we picked a rando
>> commit since the last release and this time it's de4db3ef", users
>> coming from such distros would assume "oh well, this is still good
>> ol'
>> 1.0 with some more patches applied". So while the commit itself
>> does
>> not give us any particularly useful information (unless you're that
>> person who uses this part of the version string to look the commit
>> up
>> on hubbucket), especially not when thinking in the context of
>> versioning scheme, it does provide the existential information of
>> "hold
>> on, this is not a release commit, it's something else" and might
>> thus
>> direct users to be a little more attentive when they'd otherwise go
>> "yep, upstream considers this solid and Guix considers it even more
>> solid, so it's the solidest". Note, that this can be overcome both
>> by
>> teaching/learning about it and by using a special sigil as
>> mentioned
>> above.
>> 
>> Perhaps a function revealing metadata based upon the version string
>> would allow more people get an overview without visiting hubbucket^1?
> 
> I don't think that information is actually encoded anywhere nor
> immediately obvious unless you're vaguely familiar with said software,
> but it's still important e.g. if reading the documentation. Does this
> feature mentioned in the frobnicatorinator 1.44 docs apply to 1.36 or
> not? Do the examples from some book written in the early 70s work if I
> compile them with GCC 12? And so on and so forth.