I have merged wip-ppc64le-for-master to master

[Chris Marusich]

Hi,

FYI, I have merged wip-ppc64le-for-master to master and closed bug
47182.  I have also deleted the wip-ppc64le-for-master branch.

Later this week, I will update the manual to mention that
powerpc64le-linux is supported, and I will update the "release" target
of the Makefile so that we can make a release!

-- 
Chris


signature.asc
Description: PGP signature

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Leo Famulari]

On Tue, Mar 23, 2021 at 07:05:42PM -0400, Mark H Weaver wrote:
> Also, I'm not sure why you qualify your suggestion with "in this case".
> What is it that distinguishes ImageMagick from, e.g. glib, for purposes
> of this question?  Would it be any less bad for "guix install glib" to
> install a glib with security flaws?

I forgot the reason that end-user applications should have public
replacements, and why it's less important for the replacements of
libraries to be public.

It's about the Guix user interface, that is, `guix show` and `guix
search`.

`guix show gnutls` won't show a meaningful result for a gnutls/fixed
replacement that cherry-picks some patches. Everything is the same about
the replacement package, except some very narrow bug fixing.

But `guix show imagemagick` will show the new version, available as a
replacement, in its results, and users should see it in the UI.

> It would be good to reach agreement on whether replacement packages
> should be made public.  I haven't thought much about it, so I don't know
> what the relevant issues are.

Based on those examples, I'd suggest that replacements that update the
package's version should be public.

It's been suggested before that all the package variables should be
publicly exported, but using the hidden-package procedure. I don't
remember the exact reason.

Sorry for the unreliable communication!

guix import hackage fails with errors, and failed tests

[c4t0]

Hi!

I'm having problems with 'guix import' in my environment:
$guix import hackage -t ghc-events
Syntax error: unexpected token : common (at line 44, column 0)
Syntax error: unexpected end of input
guix import: error: failed to download cabal file for package 'ghc-events'

so I cloned guix, and:

guix environment guix --pure --ad-hoc help2man git strace --container
make check TESTS=tests/hackage.scm

(I need to add --container for a problem that I address in another
email, can be ignored)

I found that two tests are failing with similar error:

Syntax error: unexpected token : (ghc-options (-Wall)) (at line 11, column 2)
Syntax error: unexpected end of input

;;; (fail #f #f)
test-name: hackage->guix-package test mixed layout
location: ./tests/hackage.scm:295
source:
+ (test-assert
+   "hackage->guix-package test mixed layout"
+   (eval-test-with-cabal
+ test-cabal-mixed-layout
+ match-ghc-foo))
actual-value: #f
result: XFAIL

Syntax error: unexpected token : (buildable (False)) (at line 12, column 4)
Syntax error: unexpected end of input

;;; (fail #f #f)
test-name: hackage->guix-package test flag executable
location: ./tests/hackage.scm:322
source:
+ (test-assert
+   "hackage->guix-package test flag executable"
+   (eval-test-with-cabal
+ test-cabal-flag-executable
+ match-ghc-foo))
actual-value: #f
result: XFAIL

I'm using guix 5f9b28b231e17749d14a1b95ae9cad68d7315a1e on top of and
old ubuntu, with all packages upgraded.

How can I start a debugger?

I tried several variations of:

guile -l scripts/guix
and then
(main '("import" "hackage" "ghc-events"))

with out success.

I'm interested in checking the tests and the package that fails.

COD.



hackage.log
Description: Binary data

Julia precompiled twice?

[zimoun]

Hi,

The (guix build julia-build-system) contains this:

--8<---cut here---start->8---
;; Actual precompilation:
(invoke-julia
 ;; When using Julia as a user, Julia writes precompile cache to the first
 ;; entry of the DEPOT_PATH list (by default, the home dir).  We want to
 ;; write it to the store, so let's push the store path as the first
 ;; element of DEPOT_PATH.  Once the cache file exists, this hack is not
 ;; needed anymore (like in the check phase).  If the user install new
 ;; packages, those will be installed and precompiled in the home dir.
 (string-append "pushfirst!(DEPOT_PATH, pop!(DEPOT_PATH)); using " 
package)))
--8<---cut here---end--->8---

i.e., after the ’check’ phase, the Julia files are precompiled…

--8<---cut here---start->8---
$ guix build julia-adapt --no-grafts --check
[…]
phase `check' succeeded after 15.1 seconds
starting phase `precompile'
phase `precompile' succeeded after 1.5 seconds
[…]
--8<---cut here---end--->8---

…but then at the first ’using ’, it is recompiled again:

--8<---cut here---start->8---
$ guix environment --ad-hoc julia julia-adapt -- julia
   _
   _   _ _(_)_ |  Documentation: https://docs.julialang.org
  (_) | (_) (_)|
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.3 (2020-11-09)
 _/ |\__'_|_|_|\__'_|  |  
|__/   |

julia> using Adapt
[ Info: Precompiling Adapt [79e6a3ab-5dfb-504d-930d-738a2a938a0e]

julia> 
--8<---cut here---end--->8---

Note that it is not then recompiled because the precompiled cache is
contained in “$HOME/.julia/compiled”; created by the REPL call.


The question is: is it possible to precompile at build-time?  And
distribute via substitutes these precompiled files?  Especially
regarding the current non-reproducibility status [1,2] of Julia in
general.

Or what is the purpose of this precompilation at build time?


1: 
2: 

Cheers,
simon

Re: guix environment guix -pure can't locate lesspipe

[Julien Lepiller]

Le 23 mars 2021 18:25:38 GMT-04:00, c4t0  a écrit :
>
>Hi,
>
>I'm having trouble importing a package from hackage, so I tried to
>debug
>the import source code. After cloning guix I found that I can't start a
>pure environment:
>
>guix environment guix --pure --ad-hoc help2man git strace
>Command 'lesspipe' is available in the following places
> * /bin/lesspipe
> * /usr/bin/lesspipe
>The command could not be located because '/bin:/usr/bin' is not
>included in the PATH environment variable.
>lesspipe: command not found

This is probably because a start file from bash or your shell uses lesspipe, 
but it's not available in the environment. Something similar happens to me on 
Fedora where it wants to install software that's already there. I simply deny 
the request to install, as it's not a fatal error.

>
>If I use --container it works:
>
>$guix environment guix --pure --ad-hoc help2man git strace lesspipe
>--container
>me@mypc ~/guix/git/guix [env]$
>
>but then I have problems connecting with the daemond:
>./pre-inst-env guix build hello
>guix build: error: failed to connect
>to`/usr/local/var/guix/daemon-socket/socket': No such file or directory

Here, you probably.forgot to pass --localstatedir as documented in the manual. 
If you don't do so, it might result in a broken guix installation!

>
>(also there isn't any file in my user environment with that name)
>
>So I have to run guix environment with --network and start one:
>$guix environment guix --pure --ad-hoc help2man git strace lesspipe
>--container
>me@mypc ~/guix/git/guix [env]$
>
>and then
>./pre-inst-env guix-daemon &
>and
>./pre-inst-env guix build hello
>
>it appears to work, but really I don't know if i'm making a mess at
>this point... I can't pass --build-users-group=guixbuild because it
>doesn't exist inside the container.
>And besides more that one daemon in the same store shurely produces
>nasty race conditions.

You shouldn't run guix-daemon from the checkout. It is not needed. Normally, 
you should be able to share /var/guix inside the container, but the container 
itself should not be needed.

>
>I think that running inside a container should be the way
>to do it but using the store in read-only mode to avoid installing
>stuff
>(or maybe that is not a problem since it can be GC later?) or providing
>a way to connect with the running daemon.
>
>So i'm asking if the last things that I do are safe, and should be
>included in the manual, because it take me a while to figure it out.

No, they're not safe. You might have corrupted guix's database, which might 
result in errors down the road. I'd suggest that you run guix gc 
--verify=contents to make sure your store is alright.

>
>or we have a problem with non containerized environment for guix
>development. Any ideas what might be the problem?
>
>or there isn't any need even to start a guix environment... (do not
>think so)
>
>COD

Re: Make guix commands pipeable

[pkill9]

> Doesnt /dev/stdin work?
> 
> The only reason it could not is that somehow the file descriptor needs
> to be seekable.
> 
> Léo

This doesn't work for me, with `cat  | guix build -f /dev/stdin`
i get "guix build: error: failed to load '/dev/stdin': No such file or
directory"

Re: Make guix commands pipeable

[pkill9]

> Doesnt /dev/stdin work?
> 
> The only reason it could not is that somehow the file descriptor needs
> to be seekable.
> 
> Léo

This doesn't work for me, with `cat  | guix build -f /dev/stdin`
i get "guix build: error: failed to load '/dev/stdin': No such file or
directory"

Re: [opinion] CVE-patching is not sufficient for package security patching

[Mark H Weaver]

Joshua Branson  writes:

> raingloom  writes:
>>
>> What about a Liberapay for Guix? Could also be used to pay developers.
>>
>
> I'd be game for something like this.  We could have a guix membership.
> Drew Devault has a "secret irc" channel for paying patreons.  Perhaps we
> could advertise a guix membership on the guix site.

Then, the Guix leadership would have to decide which Guix developers are
worthy of funding, and how much.  Those who are excluded may feel that
their contributions are insufficiently valued, and therefore feel
alienated.  Sounds to me like it would open up a huge can of worms, so
to speak.

 Regards,
   Mark

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Mark H Weaver]

Hi Andreas,

Andreas Enge  writes:

> these are very good arguments, which I understand and share. But moving
> to another version is problematic even when there is no soname bump, as
> I wrote in my bug report https://issues.guix.gnu.org/47315; grafts with
> different version numbers lead to a command line behaviour that is not
> understandable:
>
> $ guix package -A imagemagick
> imagemagick   6.9.12-2g   out,doc gnu/packages/imagemagick.scm:132:2
> imagemagick   6.9.11-48   out,doc gnu/packages/imagemagick.scm:48:2
>
> $ guix build imagemagick@6.9.11
> guix build: error: imagemagick: package not found for version 6.9.11
>
> $ guix build imagemagick@6.9.11-48
> /gnu/store/c30y49vg735g6b4hh590zrc9fmvcsy0w-imagemagick-6.9.12-2g-doc
> /gnu/store/l3hr0fimip6v7vmkgxbqygsglxaxasy0-imagemagick-6.9.12-2g
>
> From a user's perspective, inkscape@6.9.11 is at the time there and not
> there; it is shown by "guix package", but then not accessible for install-
> ation, but silently "glossed over" in favour of a different version.
[...]
> Otherwise said, grafting to different versions breaks our semantic for
> designating packages, in which version numbers play an important role,
> and replaces it by a mess which even with the examples above I have a
> hard time understanding.

To my mind this suggests a bug, or at least suboptimal behavior, in
"guix package".  I don't think it's appropriate to set grafting policy
to work around it.

How about changing "guix package -A" and "guix package -s" to display
information about the package's replacement, if it has one?

Alternatively, those commands could somehow explicitly indicate that the
package has been grafted, and show the version number of the
replacement, in such a way that is less confusing to users.

What do you think?

 Regards,
   Mark

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès  writes:

> Mark H Weaver  skribis:
>
>> Andreas Enge  writes:
>>> And please let us agree that in the future, we only backport fixes in grafts
>>> and do not update version numbers.
>>
>> I agree that in this particular case, that's what should have been done,
>> and that we should still try to do it.  It will be several days at least
>> before I'm able to look at it, though.  Would someone else like to try?
>>
>> I also agree that in general, we should be more careful to check for ABI
>> compatibility before grafting.
>
> More specifically, for libraries, we should only ever use replacements
> that are ABI-compatible.  (That usually means that the major and minor
> version numbers are the same, which may be what Andreas had in mind.)
> Anything else is most likely broken.
>
> For command-line tools, I think we should only graft with replacements
> that are backward-compatible at the CLI level.  That requires manual
> review of the changes, I guess.

I wholeheartedly agree.

  Thanks,
Mark

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Mark H Weaver]

Hi Leo,

Leo Famulari  writes:

> On Tue, Mar 23, 2021 at 03:38:02PM +0100, Léo Le Bouter wrote:
>> For this, the problem is not grafting but that the replacement package
>> definition has been made public, this is an "issue" (?) that is known
>> and I try to not make replacement package definitions public now.
>
> The replacement should be public in this case. We want people to get the
> updated ImageMagick when they do `guix install imagemagick`.

That should happen anyway, even without making the replacement package
public.  I certainly *hope* that's what happens.  If not, that's a
serious security flaw in Guix.

Also, I'm not sure why you qualify your suggestion with "in this case".
What is it that distinguishes ImageMagick from, e.g. glib, for purposes
of this question?  Would it be any less bad for "guix install glib" to
install a glib with security flaws?

It would be good to reach agreement on whether replacement packages
should be made public.  I haven't thought much about it, so I don't know
what the relevant issues are.

  Regards,
Mark

Re: [opinion] CVE-patching is not sufficient for package security patching

[Ricardo Wurmus]

raingloom  writes:

> On Sat, 20 Mar 2021 12:19:11 +0100
> Ludovic Courtès  wrote:
>
>> Hi,
>> 
>> Mark H Weaver  skribis:
>> 
>> > Ultimately, I gave up.  In my opinion, Guix has never achieved
>> > usability as a desktop system on non-Intel systems.  Therefore, the
>> > Guix community is unable to attract many developers who want a
>> > distro that supports non-Intel systems well.  Our community has
>> > thus become dominated by Intel users, and there's unsufficient
>> > political will to adopt policies that would enable us to provide a
>> > usable system for non-Intel users.  
>> 
>> A practical problem that’s been mentioned repeatedly is lack of
>> ci.guix hardware for non-Intel architectures: please everyone,
>> consider helping the project find either sponsors or companies that
>> sell fitting hardware, along with a plan to host it and maintain it
>> over time!
>> 
>> Ludo’.
>> 
>
> What about a Liberapay for Guix? Could also be used to pay developers.

This seems to be a misunderstanding.  The first step is to use the money
we already have but cannot exchange for hardware, because

- finding appropriate hardware that you can actually buy is not easy
- hosting needs to be considered because we can’t just dump them in the
  MDC data centre where most of the Intel servers are hosted.

We bought a handful of Overdrive 1000 in the past (they are no longer
sold), and hosting was always an obstacle.

While looking for ways to get the project some more money is certainly
worthwhile, it’s really not the pressing issue here.

-- 
Ricardo

guix environment guix -pure can't locate lesspipe

[c4t0]

Hi,

I'm having trouble importing a package from hackage, so I tried to debug
the import source code. After cloning guix I found that I can't start a pure 
environment:

guix environment guix --pure --ad-hoc help2man git strace
Command 'lesspipe' is available in the following places
 * /bin/lesspipe
 * /usr/bin/lesspipe
The command could not be located because '/bin:/usr/bin' is not included in the 
PATH environment variable.
lesspipe: command not found

If I use --container it works:

$guix environment guix --pure --ad-hoc help2man git strace lesspipe --container
me@mypc ~/guix/git/guix [env]$

but then I have problems connecting with the daemond:
./pre-inst-env guix build hello
guix build: error: failed to connect 
to`/usr/local/var/guix/daemon-socket/socket': No such file or directory

(also there isn't any file in my user environment with that name)

So I have to run guix environment with --network and start one:
$guix environment guix --pure --ad-hoc help2man git strace lesspipe --container
me@mypc ~/guix/git/guix [env]$

and then
./pre-inst-env guix-daemon &
and
./pre-inst-env guix build hello

it appears to work, but really I don't know if i'm making a mess at
this point... I can't pass --build-users-group=guixbuild because it
doesn't exist inside the container.
And besides more that one daemon in the same store shurely produces
nasty race conditions.

I think that running inside a container should be the way
to do it but using the store in read-only mode to avoid installing stuff
(or maybe that is not a problem since it can be GC later?) or providing
a way to connect with the running daemon.

So i'm asking if the last things that I do are safe, and should be
included in the manual, because it take me a while to figure it out.

or we have a problem with non containerized environment for guix
development. Any ideas what might be the problem?

or there isn't any need even to start a guix environment... (do not
think so)

COD

Re: A proposal for better quality in maintenance of packages by reducing scope

[Christopher Baines]

Léo Le Bouter  writes:

> There's lots of packages in GNU Guix and maintaining all of them is
> tedious, even if we have tooling, there's only so much we can do.
>
> I want to have a secure and reliable system, I would also like to only
> depend on packages I know are easy to maintain for GNU Guix
> contributors.
>
> I would like to propose that we reduce the scope of the maintenance we
> do in GNU Guix and establish a list of packages that we more or less
> commit to maintaining because this is something that we can do and is
> attainable, for example, we could remove desktop environments that we
> can't maintain to good standards realistically and focus our efforts on
> upstreams that don't go against our way of doing things, that are
> cooperative, that provide good build systems we can rely on for our
> purposes, etc.
>
> I propose we also add some requirements before packages can go into
> such a maintained state, like a working and reliable updater/refresher
> with notifications directed to some mailing list when that one finds a
> new release, a reduced amount of downstream patches and a cooperative
> upstream with who we preferably have some point of contact to solve
> issues or gather more insider knowledge about the software if we need,
> a working and reliable CVE linter with proper cpe-name/vendor and
> notifications going to a mailing list we all subscribe to, etc..
> probably lots of other things are relevant but you see the idea.
>
> It should also be possible to filter out packages that are not declared
> to be in this maintained state, for example, in the GNU Guix System
> configuration.
>
> Some kind of quality rating for packages that users can trust.
>
> What do you think?

This might be beneficial once there are obvious different groups of
packages, probably falling in to a hierarchy (even just a two level
one). But I don't think that point has been reached yet, so this sounds
like more work for not much benefit.


signature.asc
Description: PGP signature

help with go package

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

hi everyone! i've packed golang lib with guix, but cannot use it inside 
guix_env (guix environment --ad-hoc go go-lib-i-packed). why this may happen?

Re: [opinion] CVE-patching is not sufficient for package security patching

[Leo Famulari]

On Mon, Mar 22, 2021 at 02:44:04PM +0100, raingloom wrote:
> What about a Liberapay for Guix? Could also be used to pay developers.

Some of us already have Liberapay accounts.

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Leo Famulari]

On Tue, Mar 23, 2021 at 02:34:52PM +0100, Léo Le Bouter wrote:
> In general my opinion is that backporting fixes is time-consuming and
> that if we have to do it each time I wont be able to keep up with the
> load. I'd rather update things to a version that already includes fixes
> and is supported by upstream even at the cost of world rebuilds. I
> can't deal with upstreams who either do not backport fixes, or don't
> integrate fixes at all.

I agree, backporting is more time-consuming (and energy-consuming) than
upgrading.

But, you don't have to keep up with the load.

We can only do our best, and it's important for each of us to find a
level of commitment that we are able to sustain.

When we compare Guix to other volunteer distros, there have been times
when Guix did more security updates than any other distro, and times
when we were average, and then times when we were below average. At no
time did I perceive that it made a difference to how many people use
Guix.

Ultimately, I think the winning strategy is to work in a way that makes
it easy for other people to help. For example, by filing bug reports
about security updates being available, so that others can write the
patches. The idea is that, over time, we will build a team of people
writing security update patches.


signature.asc
Description: PGP signature

Re: Let's include powerpc64le-linux in the next release, Re: Let's include powerpc64le-linux in the next release

[Chris Marusich]

Tobias Geerinckx-Rice  writes:

> Ludovic Courtès 写道：
>> Like Efraim wrote, the person who makes the release (I’m afraid
>> it’ll be
>> me) needs to be able to offload to a “trustworthy” machine for that
>> platform.
>
> Define trustworthy?  The project has access to an 8-core POWER9 VM
> from OSUOSL, currently running Debian, to which efraim, lle-bout, 
> vincele, and me have root access.

That would probably work.  My understanding is that because we cannot
install Guix from an existing release binary, somebody will need to
manually build Guix on that machine first, for offloading to work.

I can help with this.

Ludovic Courtès  writes:

> If we can do that, we should adjust the ‘release’ target in
> ‘Makefile.am’ to do that.
>
> However, since we won’t be providing substitutes, we should label it as
> “technology preview” in the manual (info "(guix) GNU Distribution").

OK!  I was planning to add some commits to update the docs, anyway.  I
can do those two tasks.

Additionally, I plan to finally merge wip-ppc64le-for-master to master
later today.  I'll send a note when that's done.

-- 
Chris


signature.asc
Description: PGP signature

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Leo Famulari]

On Tue, Mar 23, 2021 at 03:38:02PM +0100, Léo Le Bouter wrote:
> For this, the problem is not grafting but that the replacement package
> definition has been made public, this is an "issue" (?) that is known
> and I try to not make replacement package definitions public now.

The replacement should be public in this case. We want people to get the
updated ImageMagick when they do `guix install imagemagick`.

> > Caeterum censeo:
> > The real fix is probably to do less grafts and more rebuilds...
> 
> Agreed, I would really like a security-updates branch for that, with
> which we can buffer changes waiting for substitutes and then merge with
> master, but I am afraid this enters in conflict with people not having
> lots of bandwidth to download a new world again through substitutes or
> very powerful machines for those who don't use substitutes.

We should definitely try to rebuild more often, but currently we are
only able to do this for x86_64 and i686. We also support ARM, and we
have to balance these different priorities somehow.


signature.asc
Description: PGP signature

Re: Will 2021 be the year of build systems on gexps?

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello!
>
> Ludovic Courtès  skribis:
>
>> Ludovic Courtès  skribis:
>>
>>> Over the last few days I’ve been head-down working on
>>> ‘wip-build-systems-gexp’, the mythical branch that brings gexps to build
>>> systems and packages, so we can say goodbye to
>>> ‘build-expression->derivation’.  And… it’s quite a ride!
>>
>> The current tip of ‘wip-build-systems-gexp’ Just Works; it’s being built,
>> it can build ‘guix’ and cross-build things like ‘sed’:
>>
>>   
>> https://data.guix-patches.cbaines.net/repository/2/branch/wip-build-systems-gexp
>>
>>   https://ci.guix.gnu.org/jobset/wip-build-systems-gexp (though Cuirass
>>   currently has unrelated problems)
>
> It’s building and well!

Excellent!  It’s great to see that you brought this idea across all
the hurdles you encountered in previous attempts.  Inspiring!

>> Here’s what I’d like to do in the coming days, if that doesn’t interfere
>> with what others have in mind for the upcoming release:
>>
>>   • Monitor build failures due to typos/thinkos made while adjusting
>> build systems;
>>
>>   • Merge on ‘core-updates’.
>
> I’ll go ahead with that if there are no objections.

This sounds reasonable to me.  “core-updates” will need some work to
push it into shape for the next merge, but I don’t think merging a
well-monitored branch into “core-updates” would make the job
considerably harder.

Thank you!

-- 
Ricardo

Re: Self-contained GuixSD Installer

[Joshua Branson]

Ludovic Courtès  writes:

> Hi,
>
> Gurjeet Singh  skribis:
>
>> Does a self-contained GuixSD installer exist? I tried running GuixSD
>> in a VM (in VBox, on macOS), and for that I downloaded the ISO image.
>> The ISO image, after a few prompts, then tries to install everything
>> from the internet.
>
> The Guix System (formerly known as “GuixSD”) installer cannot be
> entirely self-contained because there are many different choices users
> can make from there: desktop environments, network services, etc.
>
> However, if you choose a bare-bones, non-graphical kind of system
> installation, most if not all of it is already in the ISO.

That's personally how I install guix system.  I find it's easier to
install the bare-bones.scm...Then after rebooting I switch my config to
my actual config file.

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: [opinion] CVE-patching is not sufficient for package security patching

[Joshua Branson]

raingloom  writes:
>
> What about a Liberapay for Guix? Could also be used to pay developers.
>

I'd be game for something like this.  We could have a guix membership.
Drew Devault has a "secret irc" channel for paying patreons.  Perhaps we
could advertise a guix membership on the guix site.  When someone signs
up, it actually makes them an FSF member. I believe membership with the
FSF includes perks such as: 5 email aliases, a federated XMPP account,
and some other things...

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: A proposal for better quality in maintenance of packages by reducing scope

[david larsson]

On 2021-03-23 16:00, Léo Le Bouter wrote:

Hello!

There's lots of packages in GNU Guix and maintaining all of them is
tedious, even if we have tooling, there's only so much we can do.

I want to have a secure and reliable system, I would also like to only
depend on packages I know are easy to maintain for GNU Guix
contributors.

I would like to propose that we reduce the scope of the maintenance we
do in GNU Guix and establish a list of packages that we more or less
commit to maintaining because this is something that we can do and is
attainable, for example, we could remove desktop environments that we
can't maintain to good standards realistically and focus our efforts on
upstreams that don't go against our way of doing things, that are
cooperative, that provide good build systems we can rely on for our
purposes, etc.

I propose we also add some requirements before packages can go into
such a maintained state, like a working and reliable updater/refresher
with notifications directed to some mailing list when that one finds a
new release, a reduced amount of downstream patches and a cooperative
upstream with who we preferably have some point of contact to solve
issues or gather more insider knowledge about the software if we need,
a working and reliable CVE linter with proper cpe-name/vendor and
notifications going to a mailing list we all subscribe to, etc..
probably lots of other things are relevant but you see the idea.

It should also be possible to filter out packages that are not declared
to be in this maintained state, for example, in the GNU Guix System
configuration.

Some kind of quality rating for packages that users can trust.

What do you think?

Léo


Hi,

Related to your idea on having a relaible updater/refresher; I solved 
some maintenance for myself a while ago by writing a script(1) that I 
used with cuirass which automatically updates packages (both commit and 
hash) to the latest commit for a specified branch, and the same script 
also updates a manifest that is used by a cuirass instance to build 
packages. This way I could install - which 
would be continuously updated and built by cuirass, or 
- when I wanted to stay at a certain upstream 
commit. This is perhaps not the most secure solution, especially not for 
distributing as default, but maybe something similar can be used to help 
maintain the latest version of a subset of packages?


(1) https://gitlab.com/methuselah-0/guix-cigmon/-/tree/master

Best regards,
David

A proposal for better quality in maintenance of packages by reducing scope

[Léo Le Bouter]

Hello!

There's lots of packages in GNU Guix and maintaining all of them is
tedious, even if we have tooling, there's only so much we can do.

I want to have a secure and reliable system, I would also like to only
depend on packages I know are easy to maintain for GNU Guix
contributors.

I would like to propose that we reduce the scope of the maintenance we
do in GNU Guix and establish a list of packages that we more or less
commit to maintaining because this is something that we can do and is
attainable, for example, we could remove desktop environments that we
can't maintain to good standards realistically and focus our efforts on
upstreams that don't go against our way of doing things, that are
cooperative, that provide good build systems we can rely on for our
purposes, etc.

I propose we also add some requirements before packages can go into
such a maintained state, like a working and reliable updater/refresher
with notifications directed to some mailing list when that one finds a
new release, a reduced amount of downstream patches and a cooperative
upstream with who we preferably have some point of contact to solve
issues or gather more insider knowledge about the software if we need,
a working and reliable CVE linter with proper cpe-name/vendor and
notifications going to a mailing list we all subscribe to, etc..
probably lots of other things are relevant but you see the idea.

It should also be possible to filter out packages that are not declared
to be in this maintained state, for example, in the GNU Guix System
configuration.

Some kind of quality rating for packages that users can trust.

What do you think?

Léo


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

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Léo Le Bouter]

On Tue, 2021-03-23 at 15:22 +0100, Andreas Enge wrote:
> I wrote in my bug report https://issues.guix.gnu.org/47315; grafts
> with
> different version numbers lead to a command line behaviour that is
> not
> understandable:
> 
> $ guix package -A imagemagick
> imagemagick   6.9.12-2g   out,doc gnu/packages/imagemagick.scm:132:2
> imagemagick   6.9.11-48   out,doc gnu/packages/imagemagick.scm:48:2
> 
> $ guix build imagemagick@6.9.11
> guix build: error: imagemagick: package not found for version 6.9.11
> 
> $ guix build imagemagick@6.9.11-48
> /gnu/store/c30y49vg735g6b4hh590zrc9fmvcsy0w-imagemagick-6.9.12-2g-doc
> /gnu/store/l3hr0fimip6v7vmkgxbqygsglxaxasy0-imagemagick-6.9.12-2g
> 
> From a user's perspective, inkscape@6.9.11 is at the time there and
> not
> there; it is shown by "guix package", but then not accessible for
> install-
> ation, but silently "glossed over" in favour of a different version.
> 
> I just noticed that I can do this:
> $ guix build imagemagick@6.9.11-48 --no-grafts
> /gnu/store/wlnciwhn6llwqwywf4hq739v5bbcrq3h-imagemagick-6.9.11-48-doc
> /gnu/store/vlix7fclb7ifjgmxgpwr1pvraff89w7b-imagemagick-6.9.11-48
> But I can also do this:
> $ guix build imagemagick@6.9.12-2g --no-grafts
> /gnu/store/4s20df0zjmmys8zvlvynksrwz5xqk9ls-imagemagick-6.9.12-2g-doc
> /gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g
> where I do not know what I would have expected - the ungrafted
> version
> of 6.9.12 is 6.9.11, no? At the same time, for once it respects my
> wish for a specific version.
> 
> Otherwise said, grafting to different versions breaks our semantic
> for
> designating packages, in which version numbers play an important
> role,
> and replaces it by a mess which even with the examples above I have a
> hard time understanding.

For this, the problem is not grafting but that the replacement package
definition has been made public, this is an "issue" (?) that is known
and I try to not make replacement package definitions public now.

>  
> Caeterum censeo:
> The real fix is probably to do less grafts and more rebuilds...

Agreed, I would really like a security-updates branch for that, with
which we can buffer changes waiting for substitutes and then merge with
master, but I am afraid this enters in conflict with people not having
lots of bandwidth to download a new world again through substitutes or
very powerful machines for those who don't use substitutes.

Léo


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

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Andreas Enge]

Hello Mark and Léo,

Am Mon, Mar 22, 2021 at 05:12:35PM -0400 schrieb Mark H Weaver:
> However, I think it would be going too far to adopt your proposal as a
> general rule for all grafts.  In some cases, it can clearly be seen that
> an upstream release includes little more than bug fixes.  For example,
> if the recent gvfs-1.40.2 security update had required grafting, I would
> not have hesitated to do so, and that would have been much simpler and
> IMO cleaner than importing the upstream patches into our tree.

Am Tue, Mar 23, 2021 at 02:34:52PM +0100 schrieb Léo Le Bouter:
> In general my opinion is that backporting fixes is time-consuming and
> that if we have to do it each time I wont be able to keep up with the
> load. I'd rather update things to a version that already includes fixes
> and is supported by upstream even at the cost of world rebuilds. I
> can't deal with upstreams who either do not backport fixes, or don't
> integrate fixes at all.

these are very good arguments, which I understand and share. But moving
to another version is problematic even when there is no soname bump, as
I wrote in my bug report https://issues.guix.gnu.org/47315; grafts with
different version numbers lead to a command line behaviour that is not
understandable:

$ guix package -A imagemagick
imagemagick 6.9.12-2g   out,doc gnu/packages/imagemagick.scm:132:2
imagemagick 6.9.11-48   out,doc gnu/packages/imagemagick.scm:48:2

$ guix build imagemagick@6.9.11
guix build: error: imagemagick: package not found for version 6.9.11

$ guix build imagemagick@6.9.11-48
/gnu/store/c30y49vg735g6b4hh590zrc9fmvcsy0w-imagemagick-6.9.12-2g-doc
/gnu/store/l3hr0fimip6v7vmkgxbqygsglxaxasy0-imagemagick-6.9.12-2g

>From a user's perspective, inkscape@6.9.11 is at the time there and not
there; it is shown by "guix package", but then not accessible for install-
ation, but silently "glossed over" in favour of a different version.

I just noticed that I can do this:
$ guix build imagemagick@6.9.11-48 --no-grafts
/gnu/store/wlnciwhn6llwqwywf4hq739v5bbcrq3h-imagemagick-6.9.11-48-doc
/gnu/store/vlix7fclb7ifjgmxgpwr1pvraff89w7b-imagemagick-6.9.11-48
But I can also do this:
$ guix build imagemagick@6.9.12-2g --no-grafts
/gnu/store/4s20df0zjmmys8zvlvynksrwz5xqk9ls-imagemagick-6.9.12-2g-doc
/gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g
where I do not know what I would have expected - the ungrafted version
of 6.9.12 is 6.9.11, no? At the same time, for once it respects my
wish for a specific version.

Otherwise said, grafting to different versions breaks our semantic for
designating packages, in which version numbers play an important role,
and replaces it by a mess which even with the examples above I have a
hard time understanding.
 
Caeterum censeo:
The real fix is probably to do less grafts and more rebuilds...

Andreas

Re: Self-contained GuixSD Installer

[Ludovic Courtès]

Hi,

Gurjeet Singh  skribis:

> Does a self-contained GuixSD installer exist? I tried running GuixSD
> in a VM (in VBox, on macOS), and for that I downloaded the ISO image.
> The ISO image, after a few prompts, then tries to install everything
> from the internet.

The Guix System (formerly known as “GuixSD”) installer cannot be
entirely self-contained because there are many different choices users
can make from there: desktop environments, network services, etc.

However, if you choose a bare-bones, non-graphical kind of system
installation, most if not all of it is already in the ISO.

> If everything is being downloaded and installed from the internet, why
> does the image have to be so huge (~500MB
> guix-system-install-1.2.0.x86_64-linux.iso.xz)?

Good question.

> Is it possible to deliver the /gnu/store on the ISO so that a minimal
> system can be installed and started, without having to connect to the
> Internet?

That should be the case.  We have installation tests in VMs that are all
made without network access:

  https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/tests/install.scm

We cheat a little bit to make sure that absolutely nothing is
downloaded, but like I wrote, a regular install for a non-graphical
system should have little to nothing to download.

HTH,
Ludo’.

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Ludovic Courtès]

Hi,

Mark H Weaver  skribis:

> Andreas Enge  writes:
>> And please let us agree that in the future, we only backport fixes in grafts
>> and do not update version numbers.
>
> I agree that in this particular case, that's what should have been done,
> and that we should still try to do it.  It will be several days at least
> before I'm able to look at it, though.  Would someone else like to try?
>
> I also agree that in general, we should be more careful to check for ABI
> compatibility before grafting.

More specifically, for libraries, we should only ever use replacements
that are ABI-compatible.  (That usually means that the major and minor
version numbers are the same, which may be what Andreas had in mind.)
Anything else is most likely broken.

For command-line tools, I think we should only graft with replacements
that are backward-compatible at the CLI level.  That requires manual
review of the changes, I guess.

Thanks,
Ludo’.

Re: Let's include powerpc64le-linux in the next release

[Tobias Geerinckx-Rice]

Ludo',

Ludovic Courtès 写道：
Like Efraim wrote, the person who makes the release (I’m afraid 
it’ll be
me) needs to be able to offload to a “trustworthy” machine for 
that

platform.


Define trustworthy?  The project has access to an 8-core POWER9 VM 
from OSUOSL, currently running Debian, to which efraim, lle-bout, 
vincele, and me have root access.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Let's include powerpc64le-linux in the next release

[Léo Le Bouter]

On Tue, 2021-03-23 at 14:42 +0100, Ludovic Courtès wrote:
> Like Efraim wrote, the person who makes the release (I’m afraid it’ll
> be
> me) needs to be able to offload to a “trustworthy” machine for that
> platform.
> 
> If we can do that, we should adjust the ‘release’ target in
> ‘Makefile.am’ to do that.
> 
> However, since we won’t be providing substitutes, we should label it
> as
> “technology preview” in the manual (info "(guix) GNU Distribution").
> 
> How does that sound?
> 
> Ludo’.

Sounds good!

Ludo, what is your SSH public key so I can give you access to the
powerpc64le-linux machine nckx has gotten from OSUOSL?

Thank you!


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

Secure GNU Guix offloading

[Léo Le Bouter]

Hello!

I have powerful machines at hand and I would like to share them through
the GNU Guix offloading facility so that they are easy to use.

The problem is that setting up offloading requires my machine to trust
each and every client's store public key which means they can spoof
results of derivations with malware.

I am not entirely sure of how it works internally but I was thinking
that instead of copying results of derivations over there could be a
"Secure offloading" mode where instead of copying store items it would
copy the derivation and ask to rebuild them on the offload machine
instead. It will be less efficient but at least it will be safe to
share a single powerful machine with multiple GNU Guix hackers.

I don't want to give more access than what SSH non-root access would
give, and I think it would be possible to do something helpful in GNU
Guix offloading so it can work even without the offload machine
trusting the client's store public signing key.

Another thing is that it would be nice to have greater granularity on
what you trust some store signing keys for, as in, you would want to
use the offload machine for some development work but you wouldnt want
to allow the offload machine to add malware to your own store. I am
thinking the GNU Guix VM machinery can be used to create a copy-on-
write store (through virtio-fs I think?) whose every modification gets
destroyed on VM shutdown or destroy (which looks great security-wise),
and this already works AFAICT, but it's not widely known how it can be
used and why.

What do you think?

Léo


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

Re: Let's include powerpc64le-linux in the next release

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> How shall we build the binary tarball for the release?  Of course,
> anybody with a copy of the (source) release tarball can build their own
> guix binary by invoking "make guix-binary.powerpc64le-linux.tar.xz"
> themselves.  However, for convenience, it would be nice to provide a
> pre-built binary if possible.  Shall I build this myself when the time
> comes, or would people prefer to do it a different way?

Like Efraim wrote, the person who makes the release (I’m afraid it’ll be
me) needs to be able to offload to a “trustworthy” machine for that
platform.

If we can do that, we should adjust the ‘release’ target in
‘Makefile.am’ to do that.

However, since we won’t be providing substitutes, we should label it as
“technology preview” in the manual (info "(guix) GNU Distribution").

How does that sound?

Ludo’.

Re: Will 2021 be the year of build systems on gexps?

[Ludovic Courtès]

Hello!

Ludovic Courtès  skribis:

> Ludovic Courtès  skribis:
>
>> Over the last few days I’ve been head-down working on
>> ‘wip-build-systems-gexp’, the mythical branch that brings gexps to build
>> systems and packages, so we can say goodbye to
>> ‘build-expression->derivation’.  And… it’s quite a ride!
>
> The current tip of ‘wip-build-systems-gexp’ Just Works; it’s being built,
> it can build ‘guix’ and cross-build things like ‘sed’:
>
>   
> https://data.guix-patches.cbaines.net/repository/2/branch/wip-build-systems-gexp
>
>   https://ci.guix.gnu.org/jobset/wip-build-systems-gexp (though Cuirass
>   currently has unrelated problems)

It’s building and well!

> In terms of performance, there’s still a ~10% slowdown when computing
> derivations compared to the ‘core-updates’ revision the branch is based
> on.

I made some improvements yesterday (reducing object cache lookups and
the number of entries therein), but we’re still in the 10% ballpark.
WIP branch:

--8<---cut here---start->8---
$ git log |head -5
commit 082df93be3472e0f38970634260af8c432420b35
Author: Ludovic Courtès 
Date:   Mon Mar 8 13:59:23 2021 +0100

gnu: docbook-xsl: Move 'use-modules' form to the top level.
$ time GUIX_PROFILING=gc ./pre-inst-env guix build libreoffice --no-grafts -d
/gnu/store/fsrbbi8vfrwwdz2dlyzpfvvnky03nczz-libreoffice-6.4.7.2.drv
Garbage collection statistics:
  heap size:87.18 MiB
  allocated:254.25 MiB
  GC times: 16
  time spent in GC: 0.74 seconds (31% of user time)

real0m2.225s
user0m2.415s
sys 0m0.087s
--8<---cut here---end--->8---

Compared to ‘core-updates’:

--8<---cut here---start->8---
$ git log |head -5
commit b35581bd63d929e83d18f42b067f63efc867353c
Author: Efraim Flashner 
Date:   Sun Mar 21 09:42:06 2021 +0200

gnu: openjpeg: Update to 2.4.0.
$ time GUIX_PROFILING=gc ./pre-inst-env guix build libreoffice --no-grafts -d
/gnu/store/irdhm6jx30bgdxvgb0an1mn223rzshkg-libreoffice-6.4.7.2.drv
Garbage collection statistics:
  heap size:79.18 MiB
  allocated:216.51 MiB
  GC times: 16
  time spent in GC: 0.74 seconds (33% of user time)

real0m2.094s
user0m2.277s
sys 0m0.106s
--8<---cut here---end--->8---

> Here’s what I’d like to do in the coming days, if that doesn’t interfere
> with what others have in mind for the upcoming release:
>
>   • Monitor build failures due to typos/thinkos made while adjusting
> build systems;
>
>   • Merge on ‘core-updates’.

I’ll go ahead with that if there are no objections.

> Then there are optimizations to work on, but that can take a bit longer.
> In particular, in ‘gexp->derivation’, allow file-like objects to be
> specified as environment variable values.  In turn, use that so that,
> say, ‘gnu-build-system’ has a single builder for all its packages and
> just calls ‘getenv’ to get the value of its various parameters, similar
> to what (guix git-download) does.

I’m also starting work in this area.

Ludo’.

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Léo Le Bouter]

In general my opinion is that backporting fixes is time-consuming and
that if we have to do it each time I wont be able to keep up with the
load. I'd rather update things to a version that already includes fixes
and is supported by upstream even at the cost of world rebuilds. I
can't deal with upstreams who either do not backport fixes, or don't
integrate fixes at all.

That's how I feel I can keep up with fixing security issues in GNU Guix
considering how overworked we are in general.


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

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

[Xinglu Chen]

On Tue, Mar 23 2021, zimoun wrote:

> Hi,
>
> On Tue, 23 Mar 2021 at 11:32, Xinglu Chen  wrote:
>
>>> And if someone is in the mood to check why ghc-haddock is broken. :-)
>>
>> This was an issue with upstream[1], it has since been fixed but the
>> releases that include the fix are only built for GHC 8.8 or later.
>
> Thanks!  Much appreciated.

You are welcome!

>> Maybe its time to update to a newer Stackage LTS release? :)
>
> Well, I do not know if it possible to do so before the next release.
> IMHO, let focus on what remains for the next release and let upgrade the
> Stackage LTS after.

Ok, sounds good to me.

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

[zimoun]

Hi,

On Tue, 23 Mar 2021 at 11:32, Xinglu Chen  wrote:

>> And if someone is in the mood to check why ghc-haddock is broken. :-)
>
> This was an issue with upstream[1], it has since been fixed but the
> releases that include the fix are only built for GHC 8.8 or later.

Thanks!  Much appreciated.


> Maybe its time to update to a newer Stackage LTS release? :)

Well, I do not know if it possible to do so before the next release.
IMHO, let focus on what remains for the next release and let upgrade the
Stackage LTS after.

Cheers,
simon

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

[Xinglu Chen]

On Wed, Mar 10 2021, zimoun wrote:

> Using the command “guix weather --display-missing” at commit 6bed29b, I
> identify 180 packages ghc-* which are missing.  Then I locally rebuild
> all of them and they build successfully.  The only one broken is:
>
>   ghc-haddock
>
> Therefore, is it possible to “restart” the build on Cuirass of these 179
> ghc-* packages?  It could be nice to have substitutes for the next
> release.
>
> And if someone is in the mood to check why ghc-haddock is broken. :-)

This was an issue with upstream[1], it has since been fixed but the
releases that include the fix are only built for GHC 8.8 or later.

Maybe its time to update to a newer Stackage LTS release? :)

[1]: https://github.com/haskell/haddock/issues/850