[PATCH] download: Add url-fetch/xz-file.

[Hilton Chain]

* guix/download.scm (url-fetch/xz-file): New variable.
---
 guix/download.scm | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/guix/download.scm b/guix/download.scm
index 2e9ecb43fc..cce62c4185 100644
--- a/guix/download.scm
+++ b/guix/download.scm
@@ -41,6 +41,7 @@ (define-module (guix download)
 (url-fetch* . url-fetch)
 url-fetch/executable
 url-fetch/tarbomb
+url-fetch/xz-file
 url-fetch/zipbomb
 download-to-store))
 
@@ -602,6 +603,48 @@ (define tar
   #:graft? #f
   #:local-build? #t)))
 
+(define* (url-fetch/xz-file url hash-algo hash
+#:optional name
+#:key (system (%current-system))
+(guile (default-guile)))
+  "Similar to 'url-fetch' but decompress the xz file at URL as the result.
+This is mainly used for adding xz-compressed patches to a origin definition."
+  (define file-name
+(match url
+  ((head _ ...)
+   (basename head))
+  (_
+   (basename url
+  (define xz
+(module-ref (resolve-interface '(gnu packages compression)) 'xz))
+
+  (mlet %store-monad ((drv (url-fetch* url hash-algo hash
+   (or name (basename file-name ".xz"))
+   #:system system
+   #:guile guile))
+  (guile (package->derivation guile system)))
+;; Take the xz file, and simply decompress it.
+;; Use ungrafted xz so that the resulting file doesn't depend on whether
+;; grafts are enabled.
+(gexp->derivation (or name file-name)
+  (with-imported-modules '((guix build utils))
+#~(begin
+(use-modules (guix build utils))
+(setenv "XZ_OPT"
+(string-join (%xz-parallel-args)))
+
+(copy-file #$drv #$file-name)
+(make-file-writable #$file-name)
+(invoke (string-append #+xz "/bin/unxz")
+#$file-name)
+
+(copy-file (basename #$file-name ".xz")
+   #$output)))
+  #:system system
+  #:guile-for-build guile
+  #:graft? #f
+  #:local-build? #t)))
+
 (define* (url-fetch/zipbomb url hash-algo hash
 #:optional name
 #:key (system (%current-system))

base-commit: 718223c58c20fa066527fb30da2b5dccca82913f
-- 
2.39.1

etc/commiter.scm should not commit

[Ricardo Wurmus]

> There have been countless times when I was using etc/commiter.scm and it
> commited more than it should have and then slapped an incorrect message
> on it.

I wrote the initial version of etc/committer.scm to help me make 200+
commits for R updates.  It performs that task as intended.

If it does not work correctly with arbitrarily complex changes I suggest
clearly specifying the expected behavior in a bug report.

-- 
Ricardo

Re: Struggling to write Dissecting Guix, Part 2

[zimoun]

Hi,

On Wed, 25 Jan 2023 at 07:12, "("  wrote:

> I've been struggling to write Part 2 of Dissecting Guix; I'm just not sure 
> where to start to
> explain monads.

Here my attempt to explain monads using Guile:

1:https://simon.tournier.info/posts/2021-02-03-monad.html

My aim was to provide the “intuition” of the concept.  Therefore, I have
tried to explain the monad concept using as simple as possible other
concepts and in the same time I tried to avoid the “monad fallacy” [2].
(summarized by «Monads are Like Burritos» ;-)))


> It's hard for a variety of reasons, those being that:
>
>   - Guile has no type system, so you can't express monads in terms of types

I do not think the concept of monad is related to the type system but
instead it appears to me related to the composition.


>   - Guix doesn't implement very many monads (only state, identity, and 
> store), so it's
> difficult to explain with a simpler monad, as there are no simpler monads

In [1], I am using the simple monads: list and maybe.

Their implementation is poor but they bring the concept to the table.
Well, I planned to use this introduction of the concepts to then write
another post about the state monad – which is the only we are really
interested in. ;-)


>   - Guix doesn't have functors or monoids either, so it's hard to 
> "progressively" explain
> first functors, then monoids, then monads

I think monad can be introduced using the well-known ’map’ which uses
functor without digging in too much details.


>  - Monads are just difficult in general :P

Well, from my point of view, it is hard because the concept appears
difficult at first then after the oohh moment it becomes hard to explain
without using the concept itself.  IMHO, it is well summarized in this
post:

2: 
https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/

Cheers,
simon

Making sense of webkitgtk and webkitgtk-next

[André A . Gomes]

Hi Guix,

I noticed that webkitgtk-next is defined in such a way that its name is
set to "webkitgtk", not "webkitgtk-next".  This contrasts with how other
*-next packages are defined, such as emacs-next.

With respect to webkitgtk, if I run:

--8<---cut here---start->8---
guix install webkitgtk
--8<---cut here---end--->8---

the version assigned in webkitgtk-next will be installed.  On the other
hand, all packages that depend on webkitgtk will be build with version
according to version assigned to %webkit-version.

I think I'm correct since I've just installed cl-cffi-gtk (which depends
on webkitgtk) and the REPL told me:

--8<---cut here---start->8---
WEBKIT> (format nil "~a.~a" (webkit-get-major-version) 
(webkit-get-minor-version))
"2.36"
--8<---cut here---end--->8---

That is, it picked up the version assigned to webkitgtk, not
webkitgtk-next.

My question is: shouldn't webkitgtk-next be defined with its name set to
"webkitgtk-next" instead of "webkitgtk"?  Thanks.


-- 
André A. Gomes
"You cannot even find the ruins..."

valgrind

[Andreas Enge]

Hello,

I am a bit confused about the valgrind situation. Currently there are three
packages:
(define-public valgrind
  (package
(name "valgrind")
(version "3.17.0")
(properties '((hidden? . #t)

(define-public valgrind/interactive
  (package/inherit
   valgrind
   (version "3.17.0")

(define-public valgrind-3.20
  (package
(inherit valgrind/interactive)
(version "3.20.0")

I have the impression that my past problems with using valgrind have been
solved since the upgrade to 3.20.0, which is the one installed by
"guix package -i valgrind".

On the other hand, the first package is the one used as input to other
packages.

Is version 3.17 really needed? Is the distinction between the hidden package
and the "interactive" package still important?

Andreas

Re: valgrind

[zimoun]

Hi,

On Wed, 25 Jan 2023 at 12:01, Andreas Enge  wrote:

> (define-public valgrind
>   (package
> (name "valgrind")
> (version "3.17.0")
> (properties '((hidden? . #t)
>
> (define-public valgrind/interactive
>   (package/inherit
>valgrind
>(version "3.17.0")
>
> (define-public valgrind-3.20
>   (package
> (inherit valgrind/interactive)
> (version "3.20.0")

> Is version 3.17 really needed? Is the distinction between the hidden package
> and the "interactive" package still important?

--8<---cut here---start->8---
$ guix refresh -l -e '(@ (gnu packages valgrind) valgrind)'
Building the following 544 packages would ensure 1085 dependent packages are 
rebuilt:
--8<---cut here---end--->8---

I guess, the symbol ’valgrind’ refers to a minimal version of Valgrind
used by many packages.  Well, I guess again that ’valgrind-minimal’
could be a better name. :-)

Both ’valgrind/interactive’ and ’valgrind-3.20’ provides what user
expects with Valgrind but at 2 different versions.

Is the package ’valgrind/interactive’ accessible with valgrind@3.17
needed?  Indeed, maybe it could be dropped, especially if it is broken
for some use-case.


Cheers,
simon

Compiler bootstrapping requirements

[Robby Zambito]

Hi,

I remember seeing some details about certain compilers not being allowed
in Guix due to having an inadequate bootstrapping process, but I can't
seem to find it right now. I'm looking to write a package for the
Cyclone Scheme[1] implementation. The compiler requires a copy of itself
to build from the main sources, but there is a secondary repository
which includes some C files that normally require a copy of the compiler
to generate. I'm wondering: is the second repository[2] sufficient for
including in Guix?

Footnotes:
[1]  https://justinethier.github.io/cyclone/
[2]  https://github.com/justinethier/cyclone-bootstrap

Re: valgrind

[Andreas Enge]

Am Wed, Jan 25, 2023 at 01:39:29PM +0100 schrieb zimoun:
> Is the package ’valgrind/interactive’ accessible with valgrind@3.17
> needed?  Indeed, maybe it could be dropped, especially if it is broken
> for some use-case.

I do not know whether it is broken; the question is rather whether it is
needed: We do not normally keep several versions of packages around unless
there is a good reason, and if there is one, it does not seem to be
documented here.

Similarly for valgrind-noninteractive 3.17; maybe if it is to be removed
and replaced by valgrind-noninteractive 3.20, this will have to be done
on a particular branch, or maybe it is indeed needed.

The need for valgrind-noninteractive is also unclear.

Andreas

Uniformly treating native-inputs in native or cross build contexts

[Maxim Cournoyer]

Hello Guix,

In #60857, I've unified the cross/standard builders for the
pyproject-build-system; even their bags representation are now
shared. It enables fixing things such as #25235.

Going forward, I think it'd be beneficial to apply the same strategy to
other build systems, for consistency and to allow filtering purely build
inputs from the inputs captured in the wrap phases.

Thoughts, concerns?

-- 
Thanks,
Maxim

Re: Proposed changes to the commit policy

[Andreas Enge]

Hello,

Am Mon, Jan 23, 2023 at 10:24:56AM +0100 schrieb Simon Tournier:
> > Am Wed, Jan 18, 2023 at 04:54:58PM + schrieb Kaelyn:
> >> On a side note, I'd recently discovered the flag to pass. To have a
> >>subject prefix like "[PATCH core-updates]" (as mentioned in the manual
> >>for staging and core-updates patches) instead of the default "[PATCH]",
> >>one can pass "--subject-prefix="PATCH core-updates" to git
> >>format-patch. 
> > This sounds like it could be a useful addition to the QA process.
> To my knowledge, it is not possible to continuously build core-updates
> because the project does not have enough resource (both human power and
> machine power).

ah right, that is unfortunate.

> Or do you mean mentioning this option of git-format-patch under point #9
> of «Submitting Patches» [4]?  Because this option is already in the
> manual under «Sending a Patch Series» section:
> 
>  Tip: To add a prefix to the subject of your patch, you may use the
>  ‘--subject-prefix’ option.  The Guix project uses this to specify
>  that the patch is intended for a branch or repository other than
>  the ‘master’ branch of
>  .
> 
>   git send-email -1 -a --base=auto \
>   --subject-prefix='PATCH core-updates' \
>   --to=guix-patc...@gnu.org

Okay, I did not notice this; so if this is already implemented, even better!

On the other subject, I just updated mpfr and mpc on core-updates, and hope
that everything will build (with reason, the changes to these projects are
rather conservative in general).

Andreas

Re: Struggling to write Dissecting Guix, Part 2

[Development of GNU Guix and the GNU System distribution.]

Hi, Paren!

>   - Guile has no type system, so you can't express monads in terms of types

While Guile is dynamically typed, functions we define in it generally
do expect their arguments to be of certain types. And they also
generally guarantee their return values to be of certain types. So even
though there's no static type checking, it is still possible (and often
practical) to treat the functions as being typed.

Btw, I really like the explanation of a monad as function taking World
as one of its arguments and producing a modified World. Although you
probably already have your own favorite sources on the topic, here[1] is
the paper (written by someone at Microsoft, lol) where I found this
approach.

Happy dissecting,
Wojtek

[1] https://www.cs.tufts.edu/comp/150PLD/Papers/awkward.pdf


-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)


On Wed, 25 Jan 2023 07:12:45 +
"("  wrote:

> Hello Guix,
> 
> I've been struggling to write Part 2 of Dissecting Guix; I'm just not sure 
> where to start to
> explain monads.
> 
> It's hard for a variety of reasons, those being that:
> 
>   - Guile has no type system, so you can't express monads in terms of types
>   - Guix doesn't implement very many monads (only state, identity, and 
> store), so it's
> difficult to explain with a simpler monad, as there are no simpler monads
>   - Guix doesn't have functors or monoids either, so it's hard to 
> "progressively" explain
> first functors, then monoids, then monads
>   - Monads are just difficult in general :P
> 
> Any suggestions? :/
> 
> -- (




pgpNoBsI62cTT.pgp
Description: OpenPGP digital signature

Re: Compiler bootstrapping requirements

[Katherine Cox-Buday]

Robby Zambito  writes:

> Hi,
>
> I remember seeing some details about certain compilers not being
> allowed in Guix due to having an inadequate bootstrapping process, but
> I can't seem to find it right now. I'm looking to write a package for
> the Cyclone Scheme[1] implementation. The compiler requires a copy of
> itself to build from the main sources, but there is a secondary
> repository which includes some C files that normally require a copy of
> the compiler to generate. I'm wondering: is the second repository[2]
> sufficient for including in Guix?
>
> Footnotes:
> [1]  https://justinethier.github.io/cyclone/
> [2]  https://github.com/justinethier/cyclone-bootstrap

Without having looked at the specifics:

Generally what we do is find an early version of the compiler that was
bootstrapped not using itself, package that, and then use that package
to bootstrap the later versions.

Sometimes that earlier version is never published as the author(s) was
quickly iterating. In that scenario, I don't know what we do.

I hope that helps.

-- 
Katherine

Re: Struggling to write Dissecting Guix, Part 2

[david larsson]

On 2023-01-25 08:12, ( wrote:

Hello Guix,

I've been struggling to write Part 2 of Dissecting Guix; I'm just not
sure where to start to
explain monads.

It's hard for a variety of reasons, those being that:

  - Guile has no type system, so you can't express monads in terms of 
types

  - Guix doesn't implement very many monads (only state, identity, and
store), so it's
difficult to explain with a simpler monad, as there are no simpler 
monads

  - Guix doesn't have functors or monoids either, so it's hard to
"progressively" explain
first functors, then monoids, then monads
  - Monads are just difficult in general :P

Any suggestions? :/

-- (


Hi,
Im not an expert on monads by any means, but...

There's a monad tutorial fallacy to avoid: 
https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/
written by someone Brent: "Associate Professor of Computer Science at 
Hendrix College. Functional programmer, mathematician, teacher, pianist, 
follower of Jesus."


And, personally, I liked this tutorial: 
https://towardsdatascience.com/monads-from-the-lens-of-imperative-programmer-af1ab8c8790c


Maybe it helps, maybe not.

Best regards,
David

no (package definition) patch merged since Jan 2?

[Andy Tai]

Hi, by looking at

https://issues.guix.gnu.org/search?query=is%3Aclosed

no patch issues as listed in the issue tracker processed since Jan 2...
not sure if this is something Guix maintainers should be concerned about.

Re: no (package definition) patch merged since Jan 2?

[kiasoc5]

On 1/25/23 20:37, Andy Tai wrote:

Hi, by looking at

https://issues.guix.gnu.org/search?query=is%3Aclosed

no patch issues as listed in the issue tracker processed since Jan 2...
not sure if this is something Guix maintainers should be concerned about.



Something is wrong with Mumi search.

https://issues.guix.gnu.org/recent shows there are closed patches since Jan 2.

Another example to add to https://issues.guix.gnu.org/54204

purpose of GnuTLS versions

[Jack Hill]

Hi Guix,

We currently have two versions of GnuTLS packaged: 3.7.2 represented by 
the `gnutls` variable and 3.7.7 represented by the `gnutls-latest` 
variable. `guix refresh -l` reports that changes to the 3.7.2 version 
would cause 14770 rebuilds, but only 30 rebuilds for the 3.7.7 version. As 
far as I can tell, neither version currently has a replacement (graft).


What is the purpose of these two versions? 3.7.7 is almost the current 
release [0], but 3.7.2 is an older release in the same series. GnuTLS does 
have two release series [1], stable and next, that correspond to 3.6.x and 
3.7.x numbering schemes.


It seems to me that the `gnutls` variable should refer to the latest 
"stable" release, and the `gnutls-latest` variable to latest "next" 
release. Does that make sense? What am I missing?


It appears that 3.7.2 has some unpatched advisories [2].

[0] https://issues.guix.gnu.org/61064
[1] https://gitlab.com/gnutls/gnutls/-/blob/master/RELEASES.md
[2] https://gnutls.org/security-new.html

Best,
Jack

Re: Struggling to write Dissecting Guix, Part 2

[(]

Hey Simon,

On Wed Jan 25, 2023 at 9:58 AM GMT, zimoun wrote:
> 1:https://simon.tournier.info/posts/2021-02-03-monad.html

Thanks!  This looks helpful.

-- (


signature.asc
Description: PGP signature

Re: Struggling to write Dissecting Guix, Part 2

[(]

On Wed Jan 25, 2023 at 3:54 PM GMT, Wojtek Kosior wrote:
> While Guile is dynamically typed, functions we define in it generally
> do expect their arguments to be of certain types. And they also
> generally guarantee their return values to be of certain types. So even
> though there's no static type checking, it is still possible (and often
> practical) to treat the functions as being typed.

I suppose that's true :)

-- (


signature.asc
Description: PGP signature

Re: Struggling to write Dissecting Guix, Part 2

[(]

On Wed Jan 25, 2023 at 7:39 PM GMT, david larsson wrote:
> https://towardsdatascience.com/monads-from-the-lens-of-imperative-programmer-af1ab8c8790c

I'm not too sure about this one, I'm afraid.

-- (


signature.asc
Description: PGP signature