Re: Blog post about the upcoming FOSDEM + Guix Day

[Pjotr Prins]

We start Monday at 5am UTC (6am AMS/Berlin, 7am Athens) to cater for
some of Asia. The day ends when the last one switches off the lights
:).  Manolis, Efraim and Bonface have promised to be there. The
bluebutton link will be announced a day ahead.

Pj.

On Tue, Feb 02, 2021 at 05:40:04PM -0500, Leo Famulari wrote:
> On Tue, Feb 02, 2021 at 07:07:47PM +0100, Ludovic Courtès wrote:
> > Here we go!
> > 
> >   https://guix.gnu.org/en/blog/2021/meet-guix-at-fosdem-2021/
> 
> People in #guix were asking, "When exactly does it start?" Can we update
> the blog post to say?
> 

Re: Installing a wrapper guile script in /bin

[elaexuotee]

Ludovic Courtès  wrote:
> I wrote about this topic in the past:
> 
>   https://hpc.guix.info/blog/2018/01/pre-built-binaries-vs-performance/

Very nice overview! Thanks for sharing (and writing!) that article. Definitely
feeling the urge to jump down this rabbit hole and patch upstream now. Hehe.

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

I'm downstream, unfortunately. However, the final executable actually provides
a flag to explicitly specify a path to the lib, so that's not really a hurdle
in this case.

Given the small size of the build products, I feel like it would be nice to
fake a fat binary at the filesystem level. Mind if we just entertain this idea
for a second?

Say I have a script that reads /proc/cpuinfo and runs my executable with the
correct flags to load the library with the best CPU features possible. How can
I embed such a script in the package definition (as a gexp?) and install it
under /bin/?

Re: PowerShell core?

[Yasuaki Kudo]

Hi everyone!

Thank you all for replying, and especially because you explored many 
attributes, including my own autography of my sorry existence buried deep 
inside a bank some years ago, where I became a Powershell and Excel "expert"

Ok, so all we need is time (which I don't have much at the moment )

There seems real convergence of Windows and open source now - for one thing, on 
my Windows 10 laptop, I run Microsoft's built-in Linux and Guix and top of it!  
There might come a day when "proprietary software business" is no longer a core 
thing at Microsoft?  I think they are probably aware of being made irrelevant 
by Linux on the server side, Chrome on the web, Android and Iphone on smart 
phones 

Cheers,
Yasu


> On Feb 3, 2021, at 03:24, Ryan Prior  wrote:
> 
> CLR and the .NET Core tools is the first step there.

Re: PowerShell core?

[zimoun]

Hi,

Well, speaking about an

>attempt to pull command 
> interpreters out of the 70s

ads:  :-)

(I previewed the talk and it is worth watching!  Even, I previewed all
the talks of the «room» and they are all inspired and inspiring, see you
on Sunday. :-))

Cheers,
simon

Re: Blog post about the upcoming FOSDEM + Guix Day

[Leo Famulari]

On Tue, Feb 02, 2021 at 07:07:47PM +0100, Ludovic Courtès wrote:
> Here we go!
> 
>   https://guix.gnu.org/en/blog/2021/meet-guix-at-fosdem-2021/

People in #guix were asking, "When exactly does it start?" Can we update
the blog post to say?

Re: PowerShell core?

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

Leo Famulari 写道：
I don't use Windows regularly, but Powershell seems *really* 
cool. It's
a very different paradigm than the Unix shell. It seems like it 
was
designed to solve a lot of the limitations and quirks that 
plague Unix
shell scripting. It may be that Powershell won't catch on 
because shell

scripting isn't popular on Windows, but Unix + Powershell sounds
amazing, and I've been interested in it for years.


I hadn't read Leo's reply when I wrote mine or would have simply 
+1'd it.


One can only pat oneself on the back for inventing pipes for so 
many decades.  Let's welcome improvements, not blindly reject them 
simply because we dislike their sponsors.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: PowerShell core?

[Leo Famulari]

On Tue, Feb 02, 2021 at 10:41:03PM +0100, Tobias Geerinckx-Rice wrote:
> Still, we don't boycott malicious upstreams (ungoogled-chromium & worse) and
> PowerShell looks like a welcome attempt to pull command interpreters out of
> the 70s.
> 
> Due to its (apparent) verbosity it looks better suited to scripting than
> interactive use, but then unix shs suck at both so it's still a--
> 
> --wait, I just described Scheme.  Hmm.

Heh :) I had the same thought process!

Re: PowerShell core? off topic praise

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

This is why I love guix!  Everyone is super respectful.  I know I've 
asked some questionable (newbie) questions before, and everyone always
treated me with dignity!  We've got some kind people here!

Thanks!

February 2, 2021 2:52 PM, "Leo Famulari"  wrote:

> On Tue, Feb 02, 2021 at 06:35:14PM +0100, Nicolò Balzarotti wrote:
> 
>> Bengt Richter  writes:
>> 
>> Hi Yasu,
>> 
>> "Just curious", what do you hope will be the effect of your post?
>> 
>> Hi Bengt Richter, thanks for asking the same things I had in mind. This
>> post seems just M$ propaganda, more than a "Is anybody working on the
>> inclusion of Powershell?"
>> 
>> From Yasu's mail, when I read:
>> I say Powershell is almost synonymous with IT worker rights
>> 
>> I was really wondering what was happening here. I mean, we are talking
>> about a M$ product, right? I really can't see how this statement can
>> hold true. If it means "when I'm _forced_ to work on windows,
>> powershell is the lest worse thing", then fine. But I don't get how
>> having it available in guix would help then.
> 
> I understand that there may be an atmosphere of suspicion regarding
> Microsoft within a GNU project, but we should really try to give a more
> charitable interpretation to messages on the Guix mailing lists,
> especially if we aren't sure what the sender meant. Remember, Yasu will
> read your replies, too.
> 
> I don't use Windows regularly, but Powershell seems *really* cool. It's
> a very different paradigm than the Unix shell. It seems like it was
> designed to solve a lot of the limitations and quirks that plague Unix
> shell scripting. It may be that Powershell won't catch on because shell
> scripting isn't popular on Windows, but Unix + Powershell sounds
> amazing, and I've been interested in it for years.

Re: PowerShell core?

[Tobias Geerinckx-Rice]

Hi!

Yasuaki Kudo 写道：
Just curious, is there any interest in making PowerShell core 
available for Guix?


If you mean interest as in previous efforts to package it, I'm not 
aware of any.


If you mean interest as in ‘would others accept this package in 
Guix’: I don't see why they wouldn't, as long as it adheres to the 
same standards as other Guix software.  Particularly the GNU 
FSDG[0].


One of the touted (old) features[1] is

 “OneGet cmdlets to support the Chocolatey package manager”

which is almost certainly going to be problematic for us. 
However, as long as it's (entirely) Free and doesn't install or 
recommend non-free software (“sorry, that requires Windows(R)”) or 
send users' command history to Microsoft, go for it!


Most such problems can be patched.  If upstream turns out to 
maliciously evade such patches we simply drop it again.



Windows is always there


Then let's fix that instead of ‘empowering’ its slaves to increase 
productivity.


Still, we don't boycott malicious upstreams (ungoogled-chromium & 
worse) and PowerShell looks like a welcome attempt to pull command 
interpreters out of the 70s.


Due to its (apparent) verbosity it looks better suited to 
scripting than interactive use, but then unix shs suck at both so 
it's still a--


--wait, I just described Scheme.  Hmm.

Get-Help,

T G-R

[0]: 
http://www.gnu.org/distros/free-system-distribution-guidelines.html
[1]: 
https://en.wikipedia.org/wiki/PowerShell#Windows_PowerShell_3.0


signature.asc
Description: PGP signature

Re: PowerShell core?

[Nicolò Balzarotti]

Hi, 

Leo Famulari  writes:

>> 
>> I was really wondering what was happening here.  I mean, we are talking
>> about a M$ product, right?  I really can't see how this statement can
>> hold true.  If it means "when I'm _forced_ to work on windows,
>> powershell is the lest worse thing", then fine.  But I don't get how
>> having it available in guix would help then.
>
> I understand that there may be an atmosphere of suspicion regarding
> Microsoft within a GNU project, but we should really try to give a
> more charitable interpretation to messages on the Guix mailing lists,
> especially if we aren't sure what the sender meant.

Sure, that's why at the end of the message I replied with what, to my
understanding, are inclusion criteria for guix (and why I said that,
except for analytics, it is probably ok for it to be included).

> Remember, Yasu will read your replies, too.
I hope so, that's the base of communication.  If my message seemed
harsh, I'm really sorry about it.  I was not attacking neither Yasu nor
the software (if powershell is cool, freedom respecting and libre, then
let's add it).  But still, a sane level of suspicion against Microsoft
itself is due.

I just felt it was not ok to talk about "IT worker rights", referring to
a product by a company that is and always has been so hostile with us, a
company that does everything to take away our rights (that's why I asked
clarifications on this point).

I'll be more careful with my wordings,
@Yasu: I'm sorry if you felt attacked or something, my fault

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

[zimoun]

Hi,

On Tue, 02 Feb 2021 at 19:12, Ludovic Courtès  wrote:

> It turns out that, as is always the case with GNU Standards compliant
> configure script, the default value for --prefix is /usr/local, and the
> default for --sysconfdir is $prefix/etc.

As discussed on IRC, it is not mentioned in the manual.  What the manual
describes is:

  ./bootstrap
  ./configure --localstatedir=/var/
  make

therefore, if one runs:

  ./pre-inst-env guix pull

then the sysconfdir is set to /usr/local/etc because it is the default.
And so it leads to subtle differences really hard to guess.  I think it
is worth to add one sentence or footnote at the end of the section
«Running Guix Before It Is Installed», right after:

Note that ./pre-inst-env guix pull does not upgrade the local
source tree; it simply updates the ~/.config/guix/current
symlink (see Invoking guix pull). Run git pull instead if you
want to upgrade your local source tree.

Something like: «Note that ’guix pull’ preserves the settings of the host
Guix, for instance ’sysconfdir’, and by default the GNU standards set
’prefix’ to ’/usr/local/’ and ’sysconfdir’ to ’$prefix/etc’, whereas
regular Guix uses ’--sysconfdir=/etc/’.»

WDYT?


> You did find other differences eventually though, right?

The produced tarballs have the same Guix hash, i.e., all the same
inputs, but not the same outputs, compare with commit b9a54aa:


A-machine$ md5sum /gnu/store/nkvlqwzvxdlhzlc7vhfcngxc19x2ay2f-docker-pack.tar.gz
b5fe393d7966cbc3cd0be6e51d3aedc3 
/gnu/store/nkvlqwzvxdlhzlc7vhfcngxc19x2ay2f-docker-pack.tar.gz

B-machine$ md5sum /gnu/store/nkvlqwzvxdlhzlc7vhfcngxc19x2ay2f-docker-pack.tar.gz
e47b9a38b7162f7fb093b97e19dbc1ca 
/gnu/store/nkvlqwzvxdlhzlc7vhfcngxc19x2ay2f-docker-pack.tar.gz

C-machine$ md5sum /gnu/store/nkvlqwzvxdlhzlc7vhfcngxc19x2ay2f-docker-pack.tar.gz
b5fe393d7966cbc3cd0be6e51d3aedc3  
/gnu/store/nkvlqwzvxdlhzlc7vhfcngxc19x2ay2f-docker-pack.tar.gz


And diffoscope returns these differences, something about links, IIUC:

--8<---cut here---start->8---
--- 
/tmp/docker-meary/4ca83868d5e98cb06179a2a7372afe029c10d43bdc9fbfcc5771b89da74889b8/layer.tar
+++ 
/tmp/docker-pfiuh02/4ca83868d5e98cb06179a2a7372afe029c10d43bdc9fbfcc5771b89da74889b8/layer.tar
├── file list
│ @@ -823,17 +823,17 @@

[...]

│ --r-x… 29960 
gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/libexec/getconf/POSIX_V6_LP64_OFF64

[...]

│ +hr-x… 0 
gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/libexec/getconf/POSIX_V6_LP64_OFF64

[...]

├── 
gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/libexec/getconf/POSIX_V6_LP64_OFF64
│ @@ -1,1873 +0,0 @@
│ -: 7f45 4c46 0201 0100      .ELF
│ -0010: 0200 3e00 0100  3015 4000    ..>.0.@.
│ -0020: 4000    486d     @...Hm..
│ -0030:   4000 3800 0b00 4000 1f00 1e00  @.8...@.
│ -0040: 0600  0400  4000     @...
│ -0050: 4000 4000   4000 4000    @.@.@.@.
│ -0060: 6802    6802     h...h...

[...]
--8<---cut here---end--->8---

(Slightly edited to ease the reading, and raw at
.)


On machines A and C, empty file because hard link.  But on machine B,
the files are there.  Tiny files I guess, the size difference is:
23104 vs 23136.

Cheers,
simon

Re: PowerShell core?

[Leo Famulari]

On Tue, Feb 02, 2021 at 06:35:14PM +0100, Nicolò Balzarotti wrote:
> Bengt Richter  writes:
> 
> > Hi Yasu,
> >
> > "Just curious", what do you hope will be the effect of your post?
> >
> Hi Bengt Richter, thanks for asking the same things I had in mind.  This
> post seems just M$ propaganda, more than a "Is anybody working on the
> inclusion of Powershell?"
> 
> From Yasu's mail, when I read:
> > I say Powershell is almost synonymous with IT worker rights
> 
> I was really wondering what was happening here.  I mean, we are talking
> about a M$ product, right?  I really can't see how this statement can
> hold true.  If it means "when I'm _forced_ to work on windows,
> powershell is the lest worse thing", then fine.  But I don't get how
> having it available in guix would help then.

I understand that there may be an atmosphere of suspicion regarding
Microsoft within a GNU project, but we should really try to give a more
charitable interpretation to messages on the Guix mailing lists,
especially if we aren't sure what the sender meant. Remember, Yasu will
read your replies, too.

I don't use Windows regularly, but Powershell seems *really* cool. It's
a very different paradigm than the Unix shell. It seems like it was
designed to solve a lot of the limitations and quirks that plague Unix
shell scripting. It may be that Powershell won't catch on because shell
scripting isn't popular on Windows, but Unix + Powershell sounds
amazing, and I've been interested in it for years.

Re: PowerShell core?

[Ryan Prior]

On February 2, 2021, "Nicolò Balzarotti"  wrote:
> This post seems just M$ propaganda, more than a "Is anybody working on
> the
> inclusion of Powershell?"

For what it's worth I didn't read it that way.

I use PowerShell and have spent some time looking into what it would
take to build .NET Core [1] in Guix. It uses expat license [2] & would
unblock lots of useful software, including PowerShell.

There's a developer guide [3] with build instructions. It seems like it
ought to be doable.

If you want to get PowerShell into Guix I support that goal (with any
patches necessary to remove telemetry & any nonfree bits, of course) and
would be happy to provide assistance and encouragement. I think
packaging Core CLR and the .NET Core tools is the first step there.

Cheers,
Ryan

1: https://github.com/dotnet/core
2: https://github.com/dotnet/core/blob/master/LICENSE.TXT
3:
https://github.com/dotnet/coreclr/blob/master/Documentation/building/linux-
instructions.md

Re: Staging branch

[Ludovic Courtès]

Leo Famulari  skribis:

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

Yay!  And thank *you* for coordinating this effort and working to get
the branch in mergeable stage!

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

That’s a good idea.

Ludo’.

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

[Ludovic Courtès]

Hi,

zimoun  skribis:

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

As discussed on IRC, ‘guix pull’ preserves the settings of the host
Guix.  So if your initial ‘guix’ has %sysconfdir set to /usr/local/etc,
‘guix pull’ will preserve that.

It turns out that, as is always the case with GNU Standards compliant
configure script, the default value for --prefix is /usr/local, and the
default for --sysconfdir is $prefix/etc.

Mostly likely, what happened is that at some point you built Guix from
source using the default prefix and sysconfdir, and then you ran ‘guix
pull’ from that Guix.

You did find other differences eventually though, right?

HTH,
Ludo’.

Re: Blog post about the upcoming FOSDEM + Guix Day

[Ludovic Courtès]

Here we go!

  https://guix.gnu.org/en/blog/2021/meet-guix-at-fosdem-2021/

Ludo’.

Re: PowerShell core?

[Nicolò Balzarotti]

Bengt Richter  writes:

> Hi Yasu,
>
> "Just curious", what do you hope will be the effect of your post?
>
Hi Bengt Richter, thanks for asking the same things I had in mind.  This
post seems just M$ propaganda, more than a "Is anybody working on the
inclusion of Powershell?"

>From Yasu's mail, when I read:
> I say Powershell is almost synonymous with IT worker rights

I was really wondering what was happening here.  I mean, we are talking
about a M$ product, right?  I really can't see how this statement can
hold true.  If it means "when I'm _forced_ to work on windows,
powershell is the lest worse thing", then fine.  But I don't get how
having it available in guix would help then.

Howerver, I think that if it's free software (the main page says it's
expat, but I don't know if any nonfree dependency is required), it
qualifies for guix inclusion.  However, on the github page they say
there are analytics enabled by default, so this is not find and the
package should be patched.

My 2¢.

Nicolò

Re: PowerShell core?

[Bengt Richter]

Hi Yasu,

On +2021-02-02 18:29:25 +0900, Yasuaki Kudo wrote:
> Hi,
> 
> Just curious, is there any interest in making PowerShell core available for 
> Guix?
> 
> I have become quite fond of Powershell over the years (I say Powershell is 
> almost synonymous with IT worker rights - gives poor workers in sorry corners 
> of corporate world [those who are abandoned without adequate tools to get the 
> job done - because Windows is always there and Powershell comes with it!] a 
> huge productivity lift )
> 
> https://devblogs.microsoft.com/powershell/powershell-core-6-0-generally-available-ga-and-supported/
> 
> Cheers,
> Yasu

"Just curious", what do you hope will be the effect of your post?

What functionality in PowerShell provides you with "a huge productivity lift"
that you think is missing in the linux world?

Who do you think is "...abandoned without adequate tools to get the job 
done..." ?

If the "huge productivity lift" exists, are you proposing an independent 
implementation,
or a guix package with microsoft-maintained sources as an upstream dependency ;/
(I didn't go to the powershell URL, sorry :)

"I have become quite fond of Powershell over the years ..."
Um, sounds like years of compromise (I don't mean technical, idk Powershell) :-p
(Ok, sometimes a job you need for subsistence (or luxury/addiction) requires 
compromise, or no job).

"Windows is always there and Powershell comes with it!"

Is that a sales pitch ?? For what?
Caveat emptor!

"I say Powershell is almost synonymous with IT worker rights..."

Sounds political -- something lost in translation?

Sorry if I totally misread your post.

-- 
Regards,
Bengt Richter

Re: Potential security weakness in Guix services

[Maxime Devos]

> I'll look into writing a concrete proposal for *at in guile.
> I'll post a link to the guile mailing list message when it has
> been composed and sent.
Here it is:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=46258

I'm not familiar with guile's code base and conventions
and my TODO list is ever-growing, so it could take quite
some time before I get around writing a patch to Guile.
(Or implementing it in pure Scheme + FFI bindings as
a separate library).

Greetings,
Maxime.


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

Re: PowerShell core?

[Joshua Branson]

Yasuaki Kudo  writes:

> Hi,
>
> Just curious, is there any interest in making PowerShell core available for 
> Guix?

I don't know of any talented developers currently pushing to include it
in guix.  :(  (I'm not one of those developers).

>
> I have become quite fond of Powershell over the years (I say Powershell is 
> almost synonymous with IT worker rights - gives poor workers in sorry corners 
> of
> corporate world [those who are abandoned without adequate tools to get the 
> job done - because Windows is always there and Powershell comes with it!] a
> huge productivity lift )

I will that say since PowerShell is based on .Net, it may be possible to
bring it to guix.  I believe that the mono project for may be a good
start for this, and it is packaged in guix!

https://www.mono-project.com/

>
> https://devblogs.microsoft.com/powershell/powershell-core-6-0-generally-available-ga-and-supported/
>
> Cheers,
> Yasu
>

--
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: Unreproducible “guix pack -f docker” because config.scm-builder

[zimoun]

Hi,

In case someone reads and is interested by the fix.

On Mon, 1 Feb 2021 at 23:42, zimoun  wrote:

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

Ludo explained the issue on IRC [1].  Well, I should have done
"./pre-inst-env guix pull" with a misconfiguration from source.

Therefore, to fix I did:

  ./configure --localstatedir=/var/ --sysconfigdir=/etc
  make
  ./pre-env-inst guix pull

and everything works fine. :-)


The tarballs are not the same:

A$ md5sum /gnu/store/nkvlqwzvxdlhzlc7vhfcngxc19x2ay2f-docker-pack.tar.gz
b5fe393d7966cbc3cd0be6e51d3aedc3
/gnu/store/nkvlqwzvxdlhzlc7vhfcngxc19x2ay2f-docker-pack.tar.gz

B$ md5sum /gnu/store/nkvlqwzvxdlhzlc7vhfcngxc19x2ay2f-docker-pack.tar.gz
e47b9a38b7162f7fb093b97e19dbc1ca
/gnu/store/nkvlqwzvxdlhzlc7vhfcngxc19x2ay2f-docker-pack.tar.gz

but it is another story, I guess.  Investigating...

--8<---cut here---start->8---
$ diff -r --no-dereference /tmp/docker-{pfiuh02,meary}
Les fichiers binaires
/tmp/docker-pfiuh02/4ca83868d5e98cb06179a2a7372afe029c10d43bdc9fbfcc5771b89da74889b8/layer.tar
et 
/tmp/docker-meary/4ca83868d5e98cb06179a2a7372afe029c10d43bdc9fbfcc5771b89da74889b8/layer.tar
sont différents
diff -r --no-dereference /tmp/docker-pfiuh02/config.json
/tmp/docker-meary/config.json
1c1
< {"architecture":"amd64","comment":"Generated by GNU
Guix","created":"1970-01-01T00:00:01Z","config":{"env":["PATH=/gnu/store/251bsvdbnggpjl4iv259sjdn6x4d1ly1-profile/bin"]},"container_config":null,"os":"linux","rootfs":{"type":"layers","diff_ids":["sha256:ac307c1c2da51ff6bbcd2d227843f2526028ef215068b36f16c7d0ecc62af397"]}}
\ Pas de fin de ligne à la fin du fichier
---
> {"architecture":"amd64","comment":"Generated by GNU 
> Guix","created":"1970-01-01T00:00:01Z","config":{"env":["PATH=/gnu/store/251bsvdbnggpjl4iv259sjdn6x4d1ly1-profile/bin"]},"container_config":null,"os":"linux","rootfs":{"type":"layers","diff_ids":["sha256:95f38c548ea3ac95ec62b5ac59ef5099d03cf1dd4d2c9f8851ac21e8a7f0ee92"]}}
\ Pas de fin de ligne à la fin du fichier
--8<---cut here---end--->8---


All the best,
simon

1: 

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

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

[...]

>>   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
>
> That looks like a bug in (guix status).
>
> Do you have max-jobs > 1?
>
> Maxim reported a similar issue, gathered strace output etc., but I think
> it then fell through the cracks and I can’t find it anymore.  Maxim,
> does that ring a bell?

That would be https://issues.guix.gnu.org/43518.  I found it by
searching for "#f" in the list of bugs ;-).

Maxim

Re: Potential security weakness in Guix services

[Maxime Devos]

On Tue, 2021-02-02 at 14:07 +0100, Ludovic Courtès wrote:
> OK, I see.  Roughly, this symlink chown story would be a local exploit
> that the attacker can take advantage of after exploiting the RCE to
> potentially get root access.
> 
> ‘mkdir-p/perms’ could check that the directory is not a symlink, to
> begin with.  Is this what you had in mind, Maxime?

Yes!  Though the parent- and grandparent and etc. should be checked as well.
If e.g. (I don't have a real example at hand) knot's activation has
a (mkdir-p/perms "/var/lib/knot/e/t/c/e/t/e/r/a" uid/gid-stuff) line, then
mkdir-p/perms has to take care that the "e", "t", "c", "e", "t", "e, "r"
and "a" directories aren't symlinks.

I don't know how I should implement this properly in Guile, though.
In C, I would use loop using openat with O_NOFOLLOW, in combination
with stat, but Guile doesn't have openat or O_NOFOLLOW.

I've proposed adding the O_NOFOLLOW to guile [1].  I don't have a
proposal for openat in guile yet.  If I do propose an interface
to openat(2); I should probably make a proposal for fchownat
and other *at variants at the same time.  I don't have a concrete
proposal for how a nice Scheme interface would look like.

In the mean time, I suppose it should be possible to use openat
via the FFI and define O_NOFOLLOW manually in Guix.

I'll look into writing a concrete proposal for *at in guile.
I'll post a link to the guile mailing list message when it has
been composed and sent.

Greetings, Maxime.

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46220


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

Re: Potential security weakness in Guix services

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

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

OK, I see.  Roughly, this symlink chown story would be a local exploit
that the attacker can take advantage of after exploiting the RCE to
potentially get root access.

‘mkdir-p/perms’ could check that the directory is not a symlink, to
begin with.  Is this what you had in mind, Maxime?

Thanks,
Ludo’.

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

[Ludovic Courtès]

Hi,

zimoun  skribis:

> With Guix 0f20b3f.
>
> run #1
>
>   guix build --sources=all $(guix package -A | cut -f1) --fallback
>
> 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

That looks like a bug in (guix status).

Do you have max-jobs > 1?

Maxim reported a similar issue, gathered strace output etc., but I think
it then fell through the cracks and I can’t find it anymore.  Maxim,
does that ring a bell?

Thanks,
Ludo’.

PowerShell core?

[Yasuaki Kudo]

Hi,

Just curious, is there any interest in making PowerShell core available for 
Guix?

I have become quite fond of Powershell over the years (I say Powershell is 
almost synonymous with IT worker rights - gives poor workers in sorry corners 
of corporate world [those who are abandoned without adequate tools to get the 
job done - because Windows is always there and Powershell comes with it!] a 
huge productivity lift )

https://devblogs.microsoft.com/powershell/powershell-core-6-0-generally-available-ga-and-supported/

Cheers,
Yasu

Re: Blog post about the upcoming FOSDEM + Guix Day

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

It seems I can create rooms. I created a `Guix Day` one.

https://guixbbb.fosshost.org/b/man-wtf-odj-91i

Let's try to coordinate tomorrow through email/irc and join for a test.

On 2/1/21 8:51 PM, Pjotr Prins wrote:
> 
> 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

-- 
Manolis Ragkousis   |  Tel: +30 6985855120

Re: Blog post about the upcoming FOSDEM + Guix Day

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

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