PowerPC: reference to static-bash-for-glibc in binutils-final

[Chris Marusich]

Hi Efraim,

The other day, I asked on IRC why it's OK for binutils-final to refer to
static-bash-for-glibc on powerpc architectures, like in commit
2da8fcfdee7cfde8110a68806f3c4d497f217fe5, but it isn't OK on other
architectures.  You said, "there's an extra file that's a bash script
specific to powerpc machines. I suppose we could just un-patch-shebang
it back to /bin/sh".  Thank you for taking the time to respond!

When I build binutils-final on powerpc64le-linux, I get this message:

output (`/gnu/store/n2ivj40h30wa55qwp9dazzfywqb6s6vz-binutils-2.34') is not 
allowed to refer to path 
`/gnu/store/vnshq5g4ghhbr6c3s69q9p8fp6hr0gpx-bootstrap-bi
naries-0'

Looks like the file in question is embedspu, and it does refer to sh
like you said:

marusich@suzaku:~$ grep -r 
/gnu/store/vnshq5g4ghhbr6c3s69q9p8fp6hr0gpx-bootstrap-binaries-0 
/gnu/store/n2ivj40h30wa55qwp9dazzfywqb6s6vz-binutils-2.34
/gnu/store/n2ivj40h30wa55qwp9dazzfywqb6s6vz-binutils-2.34/bin/embedspu:#!/gnu/store/vnshq5g4ghhbr6c3s69q9p8fp6hr0gpx-bootstrap-binaries-0/bin/sh

Well, what's that script, anyway?  The first lines say:

#!/gnu/store/vnshq5g4ghhbr6c3s69q9p8fp6hr0gpx-bootstrap-binaries-0/bin/sh
# Embed an SPU ELF executable into a PowerPC object file.

OK, so yeah, it's probably necessary on various PowerPC architectures,
that seems clear now.  But would changing this to /bin/sh actually work?
If we changed the reference to /bin/sh, wouldn't it cause problems in
build environments, since /bin/sh isn't available there?

Anyway, I'm fine with making a change like
2da8fcfdee7cfde8110a68806f3c4d497f217fe5 for powerpc64le-linux, since it
clearly seems like a necessary reference on that architecture.  That's
probably what I'll do.

-- 
Chris


signature.asc
Description: PGP signature

Unreproducible “guix pack -f docker” because config.scm-builder

[zimoun]

Hi Ludo,

On Thu, 28 Jan 2021 at 16:54, Ludovic Courtès  wrote:

>> $ guix time-machine -C /tmp/img/channels.scm -- pack -f docker 
>> --save-provenance -m /tmp/img/manifest.scm
>> Updating channel 'guix' from Git repository at 
>> 'https://git.savannah.gnu.org/git/guix.git'...
>> /gnu/store/xzk604g8gysv4azn7sf9nylr6iah97gl-docker-pack.tar.gz
>>
>> To compare with
>> /gnu/store/wxymmnxdvdvf08ifsfy39xjaxilhrigk-docker-pack.tar.gz.
>>
>> On a third machine, I get:
>> /gnu/store/wxymmnxdvdvf08ifsfy39xjaxilhrigk-docker-pack.tar.gz
>>
>> Well, that’s another story and I have not inspected yet the
>> derivations and what could be wrong on the machine B.
>
> You’d have to check the differences.  It may be that provenance data
> differs, for example because the second attempt includes data about
> channels that are actually unused.  (That’s the whole problem of
> provenance data: it’s not a one-to-one mapping and it’s not a bijection
> either.)

After inspecting the derivations, the issue is from the file
’config.scm-builder’ which differs by:

(define-public %sysconfdir "/usr/local/etc")

vs

(define-public %sysconfdir "/etc")


What did I do wrong?  From where does this difference come?  How can I
fix it?



Below, the different commands to spot out the issue.

Cheers,
simon


Machine A

--8<---cut here---start->8---
$ guix describe
Generation 101  Jan 29 2021 16:22:06(current)
  guix b9a54aa
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: b9a54aad0ba282ac78931b67e679bd0132419364
$ guix describe -f channels > /tmp/channels.scm
$ guix pack -f docker hello
/gnu/store/9vhl75vx60l56992hgy5818ndic608p5-docker-pack.tar.gz

$ guix time-machine -C /tmp/channels.scm -- pack -f docker hello
/gnu/store/9vhl75vx60l56992hgy5818ndic608p5-docker-pack.tar.gz
$ guix gc --derivers 
/gnu/store/9vhl75vx60l56992hgy5818ndic608p5-docker-pack.tar.gz  
  
/gnu/store/ih94c9ny68dfalrym9m1vz4wa40rpgvs-docker-pack.tar.gz.drv  

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

07fwgiz56f7dk760qpplnfaxribglqc7-config.scm-builder:

(define-public %sysconfdir "/usr/local/etc")


Machine B (and C)

--8<---cut here---start->8---
$ guix describe
Génération 728 janv. 2021 01:51:17  (actuelle)
   guix 0f20b3f
 URL du dépôt : https://git.savannah.gnu.org/git/guix.git
 branche: master
 commit : 0f20b3fa2050ba6e442e340a204516b9375cd231
$ cat /tmp/channels.scm
(list (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(commit
  "b9a54aad0ba282ac78931b67e679bd0132419364")
(introduction
  (make-channel-introduction
"9edb3f66fd807b096b48283debdcddccfea34bad"
(openpgp-fingerprint
  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")
$ guix time-machine -C /tmp/channels.scm -- pack -f docker hello
Mise à jour du canal « guix » depuis le dépôt Git 
«https://git.savannah.gnu.org/git/guix.git »...
/gnu/store/nkvlqwzvxdlhzlc7vhfcngxc19x2ay2f-docker-pack.tar.gz

$ guix pull --commit=b9a54aad0ba282ac78931b67e679bd0132419364
$ guix describe
Génération 801 févr. 2021 17:00:18  (actuelle)
   guix b9a54aa
 URL du dépôt : https://git.savannah.gnu.org/git/guix.git
 commit : b9a54aad0ba282ac78931b67e679bd0132419364
$ guix pack -f docker hello
/gnu/store/nkvlqwzvxdlhzlc7vhfcngxc19x2ay2f-docker-pack.tar.gz
$ guix gc --derivers 
/gnu/store/nkvlqwzvxdlhzlc7vhfcngxc19x2ay2f-docker-pack.tar.gz   
/gnu/store/323k33sfx869d0nkh69ary8sj6xiy4s4-docker-pack.tar.gz.drv
--8<---cut here---end--->8---

00cy802583sb82kcpzfd1sz1xwff9hln-config.scm-builder:

(define-public %sysconfdir "/etc")   

Re: When substitute download + decompression is CPU-bound

[Ludovic Courtès]

Hi,

Guillaume Le Vaillant  skribis:

> Pierre Neidhardt  skribis:

[...]

>>> It’s not as nice as the ability to choose a download strategy, as we
>>> discussed earlier, but implementing that download strategy sounds
>>> tricky.
>>
>> If the user can choose their favourite substitute compression, I believe
>> it's usually enough since they are the best judge of their bandwidth /
>> hardware requirements.

As should be clear with what Guillaume and Nico posted, it’s pretty hard
to determine whether you need one compression algorithm or the other,
and it changes as you move your laptop around (different networking,
different CPU frequency scaling strategy, etc.).

> Here are a few numbers for the installation time in seconds (download
> time + decompression time) when fetching 580 MB of substitutes for
> download speeds between 0.5 MB/s and 20 MB/s.
>
> | Download speed | gzip -9 | lzip -9 | zstd -19 |
> |+-+-+--|
> |0.5 | 287 | 151 |  181 |
> |1.0 | 144 |  78 |   91 |
> |1.5 |  97 |  54 |   61 |
> |2.0 |  73 |  42 |   46 |
> |2.5 |  59 |  35 |   37 |
> |3.0 |  49 |  30 |   31 |
> |3.5 |  42 |  27 |   26 |
> |4.0 |  37 |  24 |   23 |
> |4.5 |  33 |  22 |   21 |
> |5.0 |  30 |  21 |   19 |
> |5.5 |  28 |  19 |   17 |
> |6.0 |  25 |  18 |   16 |
> |6.5 |  24 |  17 |   14 |
> |7.0 |  22 |  17 |   14 |
> |7.5 |  21 |  16 |   13 |
> |8.0 |  20 |  15 |   12 |
> |8.5 |  18 |  15 |   11 |
> |9.0 |  18 |  14 |   11 |
> |9.5 |  17 |  14 |   10 |
> |   10.0 |  16 |  13 |   10 |
> |   11.0 |  15 |  13 |9 |
> |   12.0 |  14 |  12 |8 |
> |   13.0 |  13 |  12 |8 |
> |   14.0 |  12 |  11 |7 |
> |   15.0 |  11 |  11 |7 |
> |   16.0 |  11 |  11 |6 |
> |   17.0 |  10 |  10 |6 |
> |   18.0 |  10 |  10 |6 |
> |   19.0 |   9 |  10 |5 |
> |   20.0 |   9 |  10 |5 |
>
> When the download speed is lower than 3.5 MB/s, Lzip is better, and
> above that speed Zstd is better.
>
> As Gzip is never the best choice, it would make sense to drop it, even
> if we have to wait a little until everyone has updated their Guix daemon
> to a version with at least Lzip support.

Right.  We can drop it eventually, maybe soon since only 1% of our
downloads pick gzip.

> I think there are many people (like me) with a download speed slower
> than 3 MB/s, so like Pierre I would prefer keeping "lzip -9" and
> "zstd -19".

Understood.  To me, that means we need to implement something smart.

Ludo’.

Re: Staging branch

[Leo Famulari]

The staging branch has been merged to master in commit
75b775e81b5a81a59656eeba8811b42f45d503da

Hooray!

Thanks to everyone that helped out with bug reports, fixes, CI
assistance, etc.

There is some discussion about changes to the branch workflow:

https://lists.gnu.org/archive/html/guix-devel/2021-02/msg4.html

And we should all discuss it "live" next Monday, February 8, during the
Guix Days videoconference. Please follow the Guix blog for more details
on how to join that meeting.


signature.asc
Description: PGP signature

Re: [outreachy] “guix git log --date=”

[zimoun]

Hi Chris,

On Mon, 01 Feb 2021 at 20:41, Christopher Baines  wrote:
> zimoun  writes:
>
>> As discussed today at our weekly meeting, it could be cool to add the
>> option:
>>
>>   guix git log --date=-MM-DD
>>
>> listing the first (resp. last) commit date of the day.  Or maybe all the
>> commits of the days.  Using this information would be really useful to
>> feed “guix time-machine”.  The use case I am interested is to easily
>> find the commit when I only know the date of publication/submission of
>> the paper.
>
> I'd be a little careful about the implementation of this, commits have a
> commit date, and author date, but neither of these things tell you when
> commits were on a given branch.

We are focusing on commit date, which is the one making sense.

> Take the following commit for example:
> f5f642058a3b6bf3eda5eb714ad5fa1f0a2b1b20 [1]
>
> Would it be shown when running the following?
>
>   guix git log --date=2021-01-17
>
> It's commit date is the 17th, so maybe yes? But this commit didn't
> actually turn up on the master branch until the 18th, at least according
> to the Guix Data Service [2].

Yes, for sure.  It is difficult to rebuild aposteriori the exact date
history.  Well, merges increase the number of commit candidates, so the
correct commit will be listed in the middle of other false positive
ones.


> Taking your paper use case, if I produce some results on the 17th, even
> perhaps stating the time down to the second, and then you using the
> commit date of commits try to reproduce the environment, you're going to
> get some commits that I didn't have.

I agree.  The error rate (on average) depends on the number of commits
per day (on average) vs the number of commits per day in other branches
vs the number of merges of such branches.

Well, I did not do the stats, so just guessing that the approximation is
not so bad and the false positive are acceptable in practise.

>From my understanding, you have right that the correct would be to take
care about the merges of the ’staging’ and ’core-updates’ branches.

But even without that, it is already inexact and an rough approximation.
Let consider the last CRAN update for example, it is impossible to have
the exact same environment knowing only the date, say 2021-01-20.

--8<---cut here---start->8---
$ git log --pretty="%cd %s" --before=2021-01-21 --after=2021-01-19 \
| grep 'r-' | grep Update | head -n1
Wed Jan 20 17:19:10 2021 +0100 gnu: r-fdrtool: Update to 1.2.16.
$ git log --pretty="%cd %s" --before=2021-01-21 --after=2021-01-19 \
| grep 'r-' | grep Update | tail -n1
Wed Jan 20 17:18:59 2021 +0100 gnu: r-foreign: Update to 0.8-81.
$ git log --pretty="%cd %s" --before=2021-01-21 --after=2021-01-19 \
| grep 'r-' | grep Update | wc -l
144
--8<---cut here---end--->8---

The same day, the user who pulled before 17:18 got a CRAN environment
and the user who pulled after 17:20 got another CRAN environment.
Without speaking about the one who pulled in the meantime. :-)

> Approaches that work most of the time, or have subtleties that might not
> be immediately obvious make me a little nervous.
>
> 1:
> commit f5f642058a3b6bf3eda5eb714ad5fa1f0a2b1b20
> AuthorDate: Sun Jan 3 16:26:16 2021
> CommitDate: Sun Jan 17 23:07:29 2021
>
> gnu: wxmaxima: Update to 20.12.2.
>
> 2: https://data.guix.gnu.org/revision/f5f642058a3b6bf3eda5eb714ad5fa1f0a2b1b20

Aside, noting that the Data Service is also doing an approximation on
the commit dates.  It considers only batches of pushed commits and not
all the commits individually.  As explained for example here:




Thanks for sharing your experience.  Yeah, dealing with dates and Git is
not as straightforward as it appears at first.  I agree that maybe this
first approximation is too rough and maybe not useful in practise
because knowing the date is too vague.


Cheers,
simon

Re: Blog post about the upcoming FOSDEM + Guix Day

[Leo Famulari]

On Mon, Feb 01, 2021 at 04:57:58PM +0100, Pjotr Prins wrote:
> So far, we'll have a GNU Hurd session and a Rust packaging session. We
> will also discuss ARM, RISC-V and GNU Mes. Otherwise the program is
> open for newbies and unconference topics alike. If you want to propose
> something this may be the time.

I think we should discuss the state of the build farm, the Guix Build
Coordinator, and proposed changes to the "big updates strategy" (i.e.
core-updates).

Re: branch staging updated (5aeee07 -> 104151f)

[Leo Famulari]

On Mon, Feb 01, 2021 at 08:43:19PM +, Christopher Baines wrote:
> > Efraim Flashner  writes:
> >
> >> On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote:
> >>> Hi,
> >>> 
> >>> maybe the process should be the other way round:
> >>> 
> >>> staging -> "staging-frozen" -> master
> >>> no "staging-next"
> >>
> >> I really like this idea
> >
> > It sounds good to me too!
> 
> I've been thinking about this as well [1], although my angle is more
> about making it possible to separate out testing the branch vs building
> substitutes for users.
> 
> 1: https://mail.gnu.org/archive/html/guix-devel/2020-10/msg00401.html

Alright, it sounds like you all have some good ideas. I've deleted the
staging branch, since it has been merged to master. I'll leave it up to
one of you to decide what to do about what is currently "staging-next".


signature.asc
Description: PGP signature

Re: branch staging updated (5aeee07 -> 104151f)

[Christopher Baines]

Mark H Weaver  writes:

> Efraim Flashner  writes:
>
>> On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote:
>>> Hi,
>>> 
>>> maybe the process should be the other way round:
>>> 
>>> staging -> "staging-frozen" -> master
>>> no "staging-next"
>>
>> I really like this idea
>
> It sounds good to me too!

I've been thinking about this as well [1], although my angle is more
about making it possible to separate out testing the branch vs building
substitutes for users.

1: https://mail.gnu.org/archive/html/guix-devel/2020-10/msg00401.html


signature.asc
Description: PGP signature

Re: [outreachy] “guix git log --date=”

[Christopher Baines]

zimoun  writes:

> As discussed today at our weekly meeting, it could be cool to add the
> option:
>
>   guix git log --date=-MM-DD
>
> listing the first (resp. last) commit date of the day.  Or maybe all the
> commits of the days.  Using this information would be really useful to
> feed “guix time-machine”.  The use case I am interested is to easily
> find the commit when I only know the date of publication/submission of
> the paper.

I'd be a little careful about the implementation of this, commits have a
commit date, and author date, but neither of these things tell you when
commits were on a given branch.

Take the following commit for example:
f5f642058a3b6bf3eda5eb714ad5fa1f0a2b1b20 [1]

Would it be shown when running the following?

  guix git log --date=2021-01-17

It's commit date is the 17th, so maybe yes? But this commit didn't
actually turn up on the master branch until the 18th, at least according
to the Guix Data Service [2].

Taking your paper use case, if I produce some results on the 17th, even
perhaps stating the time down to the second, and then you using the
commit date of commits try to reproduce the environment, you're going to
get some commits that I didn't have.

Approaches that work most of the time, or have subtleties that might not
be immediately obvious make me a little nervous.

1:
commit f5f642058a3b6bf3eda5eb714ad5fa1f0a2b1b20
AuthorDate: Sun Jan 3 16:26:16 2021
CommitDate: Sun Jan 17 23:07:29 2021

gnu: wxmaxima: Update to 20.12.2.

2: https://data.guix.gnu.org/revision/f5f642058a3b6bf3eda5eb714ad5fa1f0a2b1b20


signature.asc
Description: PGP signature

[outreachy] “guix git log --date=”

[zimoun]

Hi Magali,

As discussed today at our weekly meeting, it could be cool to add the
option:

  guix git log --date=-MM-DD

listing the first (resp. last) commit date of the day.  Or maybe all the
commits of the days.  Using this information would be really useful to
feed “guix time-machine”.  The use case I am interested is to easily
find the commit when I only know the date of publication/submission of
the paper.

(Format for the date, at first, the one of “git log --date=short”.)


The second thing which could be nice is to profile a bit the function
“get-commits”.  Do not hesitate to ping here if you need help about
Guile profiler. :-)

Feel free to push the last features you implemented and drop an email
here to reach out testers. ;-)


Cheers,
simon

Re: branch staging updated (5aeee07 -> 104151f)

[Mark H Weaver]

Efraim Flashner  writes:

> On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote:
>> Hi,
>> 
>> maybe the process should be the other way round:
>> 
>> staging -> "staging-frozen" -> master
>> no "staging-next"
>
> I really like this idea

It sounds good to me too!

  Mark


>> This would allow committers to use the same workflow all the time. No need
>> for any technical solution preventing to push to staging.

Re: Blog post about the upcoming FOSDEM + Guix Day

[Pjotr Prins]

Sure. Call a time tomorrow and anyone on IRC/mail/matrix can pop in. Are you
a host Manolis? A host can create rooms.

On Mon, Feb 01, 2021 at 06:31:37PM +, Manolis Ragkousis wrote:
>Maybe it would be a good idea to test big blue button tomorrow? How
>about a call?
>Sent from ProtonMail mobile
> Original Message 
>On Feb 1, 2021, 19:49, zimoun < zimon.touto...@gmail.com> wrote:
> 
>  Hi,
> 
>  On Mon, 01 Feb 2021 at 17:30, Ludovic Courtès  wrote:
> 
>  > Attendance to the workshop is free and open to everyone, though
>  you are
>  > -invited to register (there are only a few seats left!). Check out
>  [the
>  > -workshop’s wiki
>  > +invited to register (there are only a few seats left!). Join [our
>  > +BigBlueButton instance]([1]https://guixbbb.fosshost.org) on
>  Monday 8th at
>  > +10AM CET, and check out [the workshop’s wiki
>  > page]([2]https://libreplanet.org/wiki/Group:Guix/FOSDEM2021) for
>  practical
>  > info. Hope to see you on-line!
> 
>  [...]
> 
>  > If we’re not prepared for a broader event, maybe we can make it a
>  > small-case developer gathering and not announce it publicly?
> 
>  Reading the Pjotr’s answer, maybe small-case developer gathering and
>  not
>  announce it publicly seems better; even if we are announcing
>  publicly
>  right now. ;-)
> 
>  The program of the fringe event says:
> 
>  In the European morning the following presentations are planned:
> 
>  1. Guix State of the Union by Ludovic Courtès + Tobias
>  Geerinckx-Rice
>  2. Guix Data Service by Christopher Baines
>  3. Bootstrapping Intro by Jan Nieuwenhuizen
> 
>  …and many more…
> 
>  Is it still something in the pipes? If yes, is it possible to set
>  something more precise than «European morning»?
> 
>  BTW, do we fix hour/check points to organize the day? Or is it an
>  usual
>  day on #guix/#guix-hpc where some video chats is hypothetically
>  added?
> 
>  Cheers,
>  simon
> 
> References
> 
>1. https://guixbbb.fosshost.org/
>2. https://libreplanet.org/wiki/Group:Guix/FOSDEM2021

Re: Blog post about the upcoming FOSDEM + Guix Day

[zimoun]

Hi,

On Mon, 01 Feb 2021 at 17:30, Ludovic Courtès  wrote:

>  Attendance to the workshop is free and open to everyone, though you are
> -invited to register (there are only a few seats left!).  Check out [the
> -workshop’s wiki
> +invited to register (there are only a few seats left!).  Join [our
> +BigBlueButton instance](https://guixbbb.fosshost.org) on Monday 8th at
> +10AM CET, and check out [the workshop’s wiki
>  page](https://libreplanet.org/wiki/Group:Guix/FOSDEM2021) for practical
>  info.  Hope to see you on-line!

[...]

> If we’re not prepared for a broader event, maybe we can make it a
> small-case developer gathering and not announce it publicly?

Reading the Pjotr’s answer, maybe small-case developer gathering and not
announce it publicly seems better; even if we are announcing publicly
right now. ;-)

The program of the fringe event says:

In the European morning the following presentations are planned:

   1. Guix State of the Union by Ludovic Courtès + Tobias Geerinckx-Rice
   2. Guix Data Service by Christopher Baines
   3. Bootstrapping Intro by Jan Nieuwenhuizen

…and many more…

Is it still something in the pipes?  If yes, is it possible to set
something more precise than «European morning»?

BTW, do we fix hour/check points to organize the day?  Or is it an usual
day on #guix/#guix-hpc where some video chats is hypothetically added?


Cheers,
simon

Re: bug#45919: [PATCH 0/8] Exporting a manifest and channels from a profile

[Ludovic Courtès]

Hi!

So I went ahead and pushed this patch series as
15078567c17851ef0f2b017119f305e0d5e8a140.

We can always improve from here, and hopefully getting actual user
feedback will help us see the pros and cons of this option.

Thanks!

Ludo’.

Re: Blog post about the upcoming FOSDEM + Guix Day

[Pjotr Prins]

On Mon, Feb 01, 2021 at 05:30:26PM +0100, Ludovic Courtès wrote:
> Pjotr, Manolis, what are you thoughts?  I’m happy to have this event and
> to make something unconference-style, but IMO we need to have a clearer
> view of when it’ll take place, what we’ll be doing, who’s going to
> moderate, that sort of thing.  :-)

We have the moderators and plan to cross 3 TZs. Bonface and Efraim
start in the Asia slot (6am EU). Manolis and me will take Europe and
after from 9am.

> If we’re not prepared for a broader event, maybe we can make it a
> small-case developer gathering and not announce it publicly?

It is already public as a fringe event :). But, I think, realistically
it will be just us having a discussion/hacking day. But if anyone
walks in the door we should be happy to facilitate. 

  https://fosdem.org/2021/fringe/

I know we don't like lack of structure, but I feel this is just an
open door kinda thing. 

Pj.

Re: Blog post about the upcoming FOSDEM + Guix Day

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Mon, 1 Feb 2021 at 10:35, Ludovic Courtès  wrote:
>
>>   
>> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/meet-guix-at-fosdem-2021.md
>
> LGTM!
>
>> Regarding the Guix Day next Monday, do we have the BBB URL or will it be
>> disclosed later?  What should we say regarding practical connection
>> info?
>
> The Fosshost BBB instance at  is still
> alive.  We are using it every week to run our Outreachy Weekly
> meeting.
> Aside that, I do not know what is planned for the Day.

So what about:

diff --git a/website/drafts/meet-guix-at-fosdem-2021.md b/website/drafts/meet-guix-at-fosdem-2021.md
index 724ba02..773796b 100644
--- a/website/drafts/meet-guix-at-fosdem-2021.md
+++ b/website/drafts/meet-guix-at-fosdem-2021.md
@@ -70,8 +70,9 @@ sessions focused on specific hot topics about Guix, the Shepherd,
 continuous integration, and related tools and workflows.
 
 Attendance to the workshop is free and open to everyone, though you are
-invited to register (there are only a few seats left!).  Check out [the
-workshop’s wiki
+invited to register (there are only a few seats left!).  Join [our
+BigBlueButton instance](https://guixbbb.fosshost.org) on Monday 8th at
+10AM CET, and check out [the workshop’s wiki
 page](https://libreplanet.org/wiki/Group:Guix/FOSDEM2021) for practical
 info.  Hope to see you on-line!
 

Pjotr, Manolis, what are you thoughts?  I’m happy to have this event and
to make something unconference-style, but IMO we need to have a clearer
view of when it’ll take place, what we’ll be doing, who’s going to
moderate, that sort of thing.  :-)

If we’re not prepared for a broader event, maybe we can make it a
small-case developer gathering and not announce it publicly?

Thanks,
Ludo’.

Re: Potential security weakness in Guix services

[Maxime Devos]

> > I’m not sure I understand the threat model.  If Knot has a RCE
> > vulnerability, it can be exploited to run anything on behalf of the
> > ‘knot’ user.
> > 
> > At that point, all the state associated with Knot in /var/lib should be
> > considered tainted; new keys should be generated, and so on.
> > 
> > Why focus on the permissions on /var/lib/knot?
> 
> My understanding is that, in case of an RCE in knot, the attacker can
> replace /var/lib/knot/* with symlinks to arbitrary files in the FS. When
> the activation procedure is run afterwards, the files being linked to
> are chowned to the knot user, and the attacker can access them.

That's exactly what I had in mind!  Though I would like to stress that
‘access’ here is both reading and writing.

Maxime.



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

Re: Installing a wrapper guile script in /bin

[Ludovic Courtès]

Hi!

elaexuo...@wilsonb.com skribis:

> More specifically, the package I have builds separate libraries for CPUs with
> AVX, AVX2, and no AVX support. Since build-type isn't sufficiently specific to
> distinguish such CPU features, I have, so far, opted to just build all three
> libs and stuff them under /lib/.
>
> My idea is to have the linker script check CPU features at runtime (by parsing
> /proc/cpuinfo or something) and executing the binary with the parameters to
> load the correct binary.
>
> Perhaps there is a better overall approach?

I wrote about this topic in the past:

  https://hpc.guix.info/blog/2018/01/pre-built-binaries-vs-performance/

I you’re the upstream author, I recommend using one of the techniques
given above to provide so-called “fat binaries” that contain several
implementations of the performance-sensitive functions; the loader
will pick the right implementation when the program starts.

If you’re downstream… it depends on the specifics.  The loader is also
able to pick a .so from the right lib/ sub-directory depending on the
micro-architecture.  You can try:

  LD_DEBUG=files your program

to see where the loader looks for shared libraries.

HTH!

Ludo’.

Re: Blog post about the upcoming FOSDEM + Guix Day

[Pjotr Prins]

On Mon, Feb 01, 2021 at 10:41:53AM +0100, zimoun wrote:
> Hi Ludo,
> 
> On Mon, 1 Feb 2021 at 10:35, Ludovic Courtès  wrote:
> 
> >   
> > https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/meet-guix-at-fosdem-2021.md
> 
> LGTM!
> 
> > Regarding the Guix Day next Monday, do we have the BBB URL or will it be
> > disclosed later?  What should we say regarding practical connection
> > info?
> 
> The Fosshost BBB instance at  is still
> alive.  We are using it every week to run our Outreachy Weekly
> meeting.
> Aside that, I do not know what is planned for the Day.

So far, we'll have a GNU Hurd session and a Rust packaging session. We
will also discuss ARM, RISC-V and GNU Mes. Otherwise the program is
open for newbies and unconference topics alike. If you want to propose
something this may be the time.

BTW Manolis and I previewed the talks of the FOSDEM devroom and it is
going to be amazing!

  https://fosdem.org/2021/schedule/track/declarative_and_minimalistic_computing/

Attending is free. Just click on the talk when it starts. It'll stream
on Jitsy and we have matrix for chat (join http://chat.fosdem.org).
Thank you to all those who took the trouble of recording a
presentation :)

Pj.

PS the talks will be available after for viewing too.

Re: Potential security weakness in Guix services

[Julien Lepiller]

Le 1 février 2021 10:35:56 GMT-05:00, "Ludovic Courtès"  a écrit :
>Hi,
>
>Leo Famulari  skribis:
>
>> For clarification: the scenario I currently have in mind, is that
>noone
>> has intentionally introduced a security hole in a service, but rather
>> there's an accidental security bug somewhere in service package, that
>> allows an attacker (I'm assuming the service is accessible from the
>> network) arbitrary code execution *within* the service's process.
>>
>> As it is now, the attacker could overtake the service process, then
>chown
>> and chmod arbitrary directories from there. As a particular example,
>I'm
>> considering e.g. a hypothetical ipfs-service-type. A compromised IPFS
>process
>> shouldn't be able to change /etc/passwd entries. The security of the
>IPFS
>> service itself shouldn't be critical to the security of the system as
>a
>> whole.
>> -
>>
>> A more specific exapmle:
>>
>> - Forwarded message from Maxime Devos 
>-
>> I seem to have stumbled upon a potential security issue, it has to
>> do with how some services use mkdir-p/perms. For example, in
>knot-activation:
>>
>>(define (knot-activation config)
>>  #~(begin
>>  (use-modules (guix build utils))
>>  (mkdir-p/perms #$(knot-configuration-run-directory config)
>> (getpwnam "knot") #o755)
>>  (mkdir-p/perms "/var/lib/knot" (getpwnam "knot") #o755)
>>  (mkdir-p/perms "/var/lib/knot/keys" (getpwnam "knot") #o755)
>>  (mkdir-p/perms "/var/lib/knot/keys/keys" (getpwnam "knot")
>#o755)))
>>
>> /var/lib/knot/keys/keys is chmodded and chowned, which seems innocent
>enough.
>> However, what if knot whas compromised at some point, and the
>compromised knot
>> process has replaced /var/lib/knot/keys with, say, a symlink to
>/gnu/store?
>
>I’m not sure I understand the threat model.  If Knot has a RCE
>vulnerability, it can be exploited to run anything on behalf of the
>‘knot’ user.
>
>At that point, all the state associated with Knot in /var/lib should be
>considered tainted; new keys should be generated, and so on.
>
>Why focus on the permissions on /var/lib/knot?

My understanding is that, in case of an RCE in knot, the attacker can replace 
/var/lib/knot/* with symlinks to arbitrary files in the FS. When the activation 
procedure is run afterwards, the files being linked to are chowned to the knot 
user, and the attacker can access them.

>Also, every time it’s possible and not redundant with measures already
>implemented by the daemon itself, we should consider using
>‘make-forkexec-constructor/container’ as a further mitigation.
>
>WDYT?
>
>Ludo’.

Re: 03/163: build/python: Add a new guix-pythonpath procedure.

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> Indeed, I thought about the possibility to filter the GUIX_PYTHONPATH
> entries based on their version at runtime after I wrote my initial
> reply.  It makes life easier.  I've updated the
> cu/farewell-to-pythonpath branch with this new way of doing things.

Awesome, thanks for taking the time to change all this.

Ludo’.

Re: Potential security weakness in Guix services

[Ludovic Courtès]

Hi,

Leo Famulari  skribis:

> For clarification: the scenario I currently have in mind, is that noone
> has intentionally introduced a security hole in a service, but rather
> there's an accidental security bug somewhere in service package, that
> allows an attacker (I'm assuming the service is accessible from the
> network) arbitrary code execution *within* the service's process.
>
> As it is now, the attacker could overtake the service process, then chown
> and chmod arbitrary directories from there. As a particular example, I'm
> considering e.g. a hypothetical ipfs-service-type. A compromised IPFS process
> shouldn't be able to change /etc/passwd entries. The security of the IPFS
> service itself shouldn't be critical to the security of the system as a
> whole.
> -
>
> A more specific exapmle:
>
> - Forwarded message from Maxime Devos  -
> I seem to have stumbled upon a potential security issue, it has to
> do with how some services use mkdir-p/perms. For example, in knot-activation:
>
>(define (knot-activation config)
>  #~(begin
>  (use-modules (guix build utils))
>  (mkdir-p/perms #$(knot-configuration-run-directory config)
> (getpwnam "knot") #o755)
>  (mkdir-p/perms "/var/lib/knot" (getpwnam "knot") #o755)
>  (mkdir-p/perms "/var/lib/knot/keys" (getpwnam "knot") #o755)
>  (mkdir-p/perms "/var/lib/knot/keys/keys" (getpwnam "knot") #o755)))
>
> /var/lib/knot/keys/keys is chmodded and chowned, which seems innocent enough.
> However, what if knot whas compromised at some point, and the compromised knot
> process has replaced /var/lib/knot/keys with, say, a symlink to /gnu/store?

I’m not sure I understand the threat model.  If Knot has a RCE
vulnerability, it can be exploited to run anything on behalf of the
‘knot’ user.

At that point, all the state associated with Knot in /var/lib should be
considered tainted; new keys should be generated, and so on.

Why focus on the permissions on /var/lib/knot?

Also, every time it’s possible and not redundant with measures already
implemented by the daemon itself, we should consider using
‘make-forkexec-constructor/container’ as a further mitigation.

WDYT?

Ludo’.

Re: bug#45919: [PATCH 0/8] Exporting a manifest and channels from a profile

[Pierre Neidhardt]

Ludovic Courtès  writes:

> Hi,
>
> Pierre Neidhardt  skribis:
>
>> Ludovic Courtès  writes:
>
> [...]
>
>>>   • The generated files might use APIs that, in the meantime, got
>>> deprecated or changed somehow.  This is in contrast with
>>> ‘--export-profile’, which interprets ‘manifest’ (a versioned file
>>> format) and produces code that can use the API du jour.
>>
>> /run/current-system/configuration.scm suffers from the same problem.
>
> Not really because it’s precisely the file that you gave to build the
> system.  So you know you can run:
>
>   cd /run/current-system
>   guix time-machine -C channels.scm -- system reconfigure configuration.scm
>
> and it’ll work (modulo the documented caveats).

Ha, actually no, it won't always work! :)
Configuration.scm is only the file passed to `guix system reconfigure`,
but is this file inherits from other user Guile modules, then the
configuration.scm won't be sufficient to regenerate the system.

You could argue that it's a user problem, but still, there is an
"impurity" here! :p

> But again, that’s not really the goal here.  The goal is to help users
> willing to migrate from the “imperative” mode to the declarative mode.

Sure, but my thinking is that we could hit two birds we one stone here.
If we only think one half of the problem, we might end up with too many
commands or an interface that's not flexible enough.

> Once you’re using a manifest, probably you’ll want to put that under
> version control, but that’s already the case.

The channels.scm files are missing though.

My two cents! :)

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: [Outreachy] Feedback on 'guix git log' subcommand

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Thu, 28 Jan 2021 at 00:53, Magali  wrote:
>
>> On a side note, I've been blogging about it at
>> .
>
> Nice readings! :-)

Seconded!

>> Below are a few examples of the options currently available:
>>
>> ./pre-inst-env guix git log --format=medium
>> ./pre-inst-env guix git log --oneline
>> ./pre-inst-env guix git log --channel-cache-path
>> ./pre-inst-env guix git log --channel-cache-path=guix
>
> Cool!
>
> An example, the recent update of setuptools breaks python2-setuptools.
>
> $ ./pre-inst-env guix git log --oneline \
>>   | grep 'python-setuptools:' | grep Update
> b3ca2b4 gnu: python-setuptools: Update to 40.8.0.
> d0205df gnu: python-setuptools: Update to 40.0.0.
> 62a9a23 gnu: python-setuptools: Update to 18.3.1.
> d3d656c gnu: python-setuptools: Update to 12.1.
> d660f7b gnu: python-setuptools: Update to 31.0.0.
> e39d493 gnu: python-setuptools: Update to 41.0.1.
> 3142dac gnu: python-setuptools: Update to 52.0.0.
>
>
> Ah, the order seems weird, “git log” says:
>
> 3142daccbe gnu: python-setuptools: Update to 52.0.0.
> e39d4933d1 gnu: python-setuptools: Update to 41.0.1.
> b3ca2b45d1 gnu: python-setuptools: Update to 40.8.0.
> d0205dfd92 gnu: python-setuptools: Update to 40.0.0.
> d660f7be6d gnu: python-setuptools: Update to 31.0.0.
> 62a9a23bf9 gnu: python-setuptools: Update to 18.3.1.
> d3d656c5fb gnu: python-setuptools: Update to 12.1.

It might be breadth-first vs. depth-first?  I remember having
difficulties finding out which ordering ‘git log’ chooses when I was
working on ‘guix pull --news’.

At any rate, this all looks promising.  Thanks for keeping us posted,
Magali!

Ludo’.

Failure guix build --sources=all $(guix package -A...

[zimoun]

Hi Ludo,

On Thu, 28 Jan 2021 at 08:47, Ludovic Courtès  wrote:

> What failures did you get?

With Guix 0f20b3f.

run #1

  guix build --sources=all $(guix package -A | cut -f1) --fallback

--8<---cut here---start->8---
download-progress
/gnu/store/960b2kch33maxjk7b6g5pp12rj2bagx6-SNPlocs.Hsapiens.dbSNP144.GRCh37_0.99.20.tar.gz
https://ci.guix.gnu.org/nar/960b2kch33maxjk7b6g5pp12rj2bagx6-SNPlocs.Hsapiens.dbSNP144.GRCh37_0.99.20.tar.gz
913353344 152961120
Backtrace:
  18 (primitive-load "/home/sitour/.config/guix/current/bin/…")
In guix/ui.scm:
  2154:12 17 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
  1731:15 15 (with-exception-handler # …)
In guix/status.scm:
780:4 14 (call-with-status-report _ _)
In ice-9/boot-9.scm:
  1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   636:37 12 (thunk)
   1305:8 11 (call-with-build-handler _ _)
   1305:8 10 (call-with-build-handler _ _)
   1305:8  9 (call-with-build-handler # …)
In guix/scripts/build.scm:
   696:26  8 (_)
In guix/store.scm:
  1373:15  7 (_ # _ _)
   745:13  6 (process-stderr _ _)
In unknown file:
   5 (display "://ci.guix.gnu.org/nar/lzip/5v2xxcrh0npbzn2m…" …)
In guix/status.scm:
   703:16  4 (write! _ _ _)
   616:15  3 (_ (download-succeeded "/gnu/store/dm1fc94ais6h5q0:…" …) …)
   273:33  2 (compute-status _ #< building: () downlo…> …)
In ice-9/boot-9.scm:
  1669:16  1 (raise-exception _ #:continuable? _)
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1
(expecting struct): #f
--8<---cut here---end--->8---

re-run #2

--8<---cut here---start->8---
d-data-0.0.23b-alpha.tar.xz
https://ci.guix.gnu.org/nar/6x92chv2cw0wxv9yr5y6x3cvc38sx8q8-0ad-data-0.0.23b-alpha.tar.xz
694549624 298188896
Backtrace:
  17 (primitive-load "/home/sitour/.config/guix/current/bin/…")
In guix/ui.scm:
  2154:12 16 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1736:10 15 (with-exception-handler _ _ #:unwind? _ # _)
  1731:15 14 (with-exception-handler # …)
In guix/status.scm:
780:4 13 (call-with-status-report _ _)
In ice-9/boot-9.scm:
  1736:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   636:37 11 (thunk)
   1305:8 10 (call-with-build-handler _ _)
   1305:8  9 (call-with-build-handler # …)
In guix/scripts/build.scm:
   696:26  8 (_)
In guix/store.scm:
  1373:15  7 (_ # _ _)
   745:13  6 (process-stderr _ _)
In unknown file:
   5 (display "hdjdxjx9wx1mj941b5v8-drascula-audio-2.0.zip …" …)
In guix/status.scm:
   703:16  4 (write! _ _ _)
   616:15  3 (_ (download-succeeded "/gnuhdjdxjx9wx1mj941b5v8-dr…" …) …)
   273:33  2 (compute-status _ #< building: () downlo…> …)
In ice-9/boot-9.scm:
  1669:16  1 (raise-exception _ #:continuable? _)
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1
(expecting struct): #f
--8<---cut here---end--->8---

re-run #3

--8<---cut here---start->8---
h76l2n7v3s5vpzm33w2l80qgg3zv-font-adobe-source-han-sans-1.004-checkout
https://ci.guix.gnu.org/nar/gzip/l0hmh76l2n7v3s5vpzm33w2l80qgg3zv-font-adobe-source-han-sans-1.004-checkout
1665898521 991264768
Backtrace:
  17 (primitive-load "/home/sitour/.config/guix/current/bin/…")
In guix/ui.scm:
  2154:12 16 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1736:10 15 (with-exception-handler _ _ #:unwind? _ # _)
  1731:15 14 (with-exception-handler # …)
In guix/status.scm:
780:4 13 (call-with-status-report _ _)
In ice-9/boot-9.scm:
  1736:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   636:37 11 (thunk)
   1305:8 10 (call-with-build-handler _ _)
   1305:8  9 (call-with-build-handler # …)
In guix/scripts/build.scm:
   696:26  8 (_)
In guix/store.scm:
  1373:15  7 (_ # _ _)
   745:13  6 (process-stderr _ _)
In unknown file:
   5 (display "heme-10.1.3-x86-64.tar.gz 69956440 65929312\…" …)
In guix/status.scm:
   703:16  4 (write! _ _ _)
   616:15  3 (_ (download-succeeded "/gnu/store/rxw5pk8c6hi7nygv…" …) …)
   273:33  2 (compute-status _ #< building: () downlo…> …)
In ice-9/boot-9.scm:
  1669:16  1 (raise-exception _ #:continuable? _)
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
--8<---cut here---end--->8---

re-run #4

--8<---cut here---start->8---
`/gnu/store/pihzkn3zdzksih46nyaynbg4kjrpcrjg-clml-0.0.0-0.95505b5-checkout/time-series/clml.time-series.asd'
-> `clml-0.0.0-0.95505b5-checkout/time-series/clml.time-series.asd'
`File som/src/lvq_pak.lisp is read-only; trying to patch 

Re: bug#45919: [PATCH 0/8] Exporting a manifest and channels from a profile

[Ludovic Courtès]

Hi,

Ryan Prior  skribis:

> I don't think there's much drawback to having both the auto-generated
> files and a command that generates them. That seems more discoverable -
> you might happen across the files when you poke into a profile, or you
> might notice the command while reading the docs or the help output.

Note that the ‘manifest’ file starts with a comment.  This patch set
updates this comment so it mentions ‘--export-channels’.

> Glad to see this capability land any which way, this is something that
> comes up often!

Heh, good.  :-)

> While we're considering putting a manifest in the profile, is this a
> good time to also bring up the idea of renaming the "manifest" file? It
> confuses more people all the time. I'd be inclined to rename it
> "profile-metadata" or "lockfile". 

It’s the kind of thing that can’t really be changed, or at least not
without a looong transition period, because older ‘guix package’
commands wouldn’t recognize profiles that lack a ‘manifest’ file.

Thanks for your feedback,
Ludo’.

Re: bug#45919: [PATCH 0/8] Exporting a manifest and channels from a profile

[Ludovic Courtès]

Hi,

Pierre Neidhardt  skribis:

> Ludovic Courtès  writes:

[...]

>>   • The generated files might use APIs that, in the meantime, got
>> deprecated or changed somehow.  This is in contrast with
>> ‘--export-profile’, which interprets ‘manifest’ (a versioned file
>> format) and produces code that can use the API du jour.
>
> /run/current-system/configuration.scm suffers from the same problem.

Not really because it’s precisely the file that you gave to build the
system.  So you know you can run:

  cd /run/current-system
  guix time-machine -C channels.scm -- system reconfigure configuration.scm

and it’ll work (modulo the documented caveats).

> But with the manifest we could do better, we could include a version
> number one way or another.
> Besides, since it comes together with channels.scm, we know which Guix
> was used, so we always have access to the Guix with the right API to
> install the manifest.

Right.

>>   • One would still have to learn about these two files, and pick the
>> right “manifest” file.
>
> I think it would be easier than a command. See below.
>
>>   • For users of ‘-m my-manifest.scm’, we would need to store
>> ‘my-manifest.scm’ as is instead of generating an approximation
>> thereof.
>
> Which seems easy to do, isn't it?

I take it that you’re volunteering?  :-)

Nothing’s difficult, but in this case we’d need to pass the original
manifest down to ‘profile-generation’.  Requires some redesign.

> Another use-case which I find useful and comes close to this feature is
> that of channel/manifest versioning, in the sense of keeping these files
> under version control for instance in a Git repository.  This can be
> useful to keep the history of everything, even deleted generations, or
> even in case of hardware failure.
>
> To that end, it'd be nice if we could export these files automatically
> to a designated location.
>
> Example: I update ~/my-profile and it automatically produces / overwrite
> ~/repos/guix-profile-metadata.git/my-profile/channels.scm and
> ~/repos/guix-profile-metadata.git/my-profile/manifest.scm.
>
> This way I can commit these 2 files in my guix-profile-metadata.git
> repository.

I guess you could do that either with ‘cp
~/.guix-profile/{channels,manifest.scm …’ or with ‘guix package
--export-manifest … > …’.

But again, that’s not really the goal here.  The goal is to help users
willing to migrate from the “imperative” mode to the declarative mode.
Once you’re using a manifest, probably you’ll want to put that under
version control, but that’s already the case.

Thanks,
Ludo’.

Installing a wrapper guile script in /bin

[Leo Prikler]

Hi elaexuotee,

> More specifically, the package I have builds separate libraries for
> CPUs with
> AVX, AVX2, and no AVX support. Since build-type isn't sufficiently
> specific to
> distinguish such CPU features, I have, so far, opted to just build
> all three
> libs and stuff them under /lib/.
That's certainly one approach to solving the issue of not knowing which
CPU your code runs on.  Another approach is described in [1] under the
section "Dependency graph rewriting".  TL;DR, just offer the base
package with no AVX features, an AVX package and an AVX2 package.  Then
build any dependants against the base package.  Users can afterwards
decide to build against optimized versions on their own.

Regards,
Leo

[1] 
https://hpc.guix.info/blog/2018/01/pre-built-binaries-vs-performance/

Re: branch staging updated (5aeee07 -> 104151f)

[Efraim Flashner]

On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote:
> Hi,
> 
> maybe the process should be the other way round:
> 
> staging -> "staging-frozen" -> master
> no "staging-next"

I really like this idea

> This would allow committers to use the same workflow all the time. No need
> for any technical solution preventing to push to staging.

-- 
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

Installing a wrapper guile script in /bin

[elaexuotee]

Hello Guix,

Writing package definition, I have need of a non-trivial wrapper script that
decides how to execute the installed binary. How do I accomplish this?

With my vague understanding, I am envisioning writing a gexp directly in the
install phase and would like to somehow reify this into a guile script and
install that file under /bin. Is this correct, at the high level?

More specifically, the package I have builds separate libraries for CPUs with
AVX, AVX2, and no AVX support. Since build-type isn't sufficiently specific to
distinguish such CPU features, I have, so far, opted to just build all three
libs and stuff them under /lib/.

My idea is to have the linker script check CPU features at runtime (by parsing
/proc/cpuinfo or something) and executing the binary with the parameters to
load the correct binary.

Perhaps there is a better overall approach?

Appreciate your thoughts!

Re: Bring KDE into Guix easily

[Hartmut Goebel]

Am 31.01.21 um 17:50 schrieb Maxime Devos:

Some things to improve:
* Some scripts have missing copyright and license headers
(00-add.sh, 00-test-gui-app.sh).


These scripts are not meant to be included into guix.


* I don't see any license information on pkgs/*.scm.
   It's sort of implied these are GPLv3, as Guix itself
   is GPLv3+, but it isn't clear if you would allow GPLv3+
   as well.


Will add a License file - but not a license header to each of these 
files, as this would contradict the basic idea of this repo.



* IANAL, but taking synopsises and descriptions
   from external sources (Debian, Mageia) seems
   without mentioning the copyright holder, license
   and author seems suspect for me. Maybe it's legally
   ok here, but best include attribution somewhere,
   and write your reasoning for why inclusion is ok
   somewhere.


No need to put efforts in here IMHO. The person creating a patch might 
choose to write a completely different text.



My proposal on how to go forward is:
* Please address previous three issues.

See above.

* if someone wants a particular KDE package in Guix,
   they can submit an appropriate patch to Guix using
   the repository, after testing whether it works.


This almost is the idea behind this repos - the exact idea is that 
someone will batch-work an these files.



* many KDE packages are not up to date  (guix refresh --type=kde).


Refreshing is part of the half-automated process done by the scripts.


--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: branch staging updated (5aeee07 -> 104151f)

[Hartmut Goebel]

Hi,

maybe the process should be the other way round:

staging -> "staging-frozen" -> master
no "staging-next"

This would allow committers to use the same workflow all the time. No 
need for any technical solution preventing to push to staging.


--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Blog post about the upcoming FOSDEM + Guix Day

[zimoun]

Hi Ludo,

On Mon, 1 Feb 2021 at 10:35, Ludovic Courtès  wrote:

>   
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/meet-guix-at-fosdem-2021.md

LGTM!

> Regarding the Guix Day next Monday, do we have the BBB URL or will it be
> disclosed later?  What should we say regarding practical connection
> info?

The Fosshost BBB instance at  is still
alive.  We are using it every week to run our Outreachy Weekly
meeting.
Aside that, I do not know what is planned for the Day.

Cheers,
simon

Blog post about the upcoming FOSDEM + Guix Day

[Ludovic Courtès]

Hello!

I prepared a blog post that about FOSDEM that I think we should publish
today or tomorrow:

  
https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/meet-guix-at-fosdem-2021.md

Regarding the Guix Day next Monday, do we have the BBB URL or will it be
disclosed later?  What should we say regarding practical connection
info?

Likewise, if you see anything to change, please amend or send patches
and suggestions!

Ludo’.