Samba Services

[Simon Streit]

Hello,

While preparing my patch series [1], I've run into issues where I can't
compile my own branch now:

--8<---cut here---start->8---
  MAKEINFO doc/guix.fa.info
./doc/guix.es.texi:30547: warning: node next `Sistema de archivos en red' in 
menu `Integración continua' and in sectioning `Samba Services' differ
./doc/guix.es.texi:16840: node `Servicios' lacks menu item for `Samba Services' 
despite being its Up target
./doc/guix.es.texi:30867: warning: node prev `Integración continua' in menu 
`Sistema de archivos en red' and in sectioning `Samba Services' differ
./doc/guix.texi:29670: warning: node next `Network File System' in menu 
`Continuous Integration' and in sectioning `Samba Services' differ
./doc/guix.texi:16349: node `Services' lacks menu item for `Samba Services' 
despite being its Up target
./doc/guix.texi:29985: warning: node prev `Continuous Integration' in menu 
`Network File System' and in sectioning `Samba Services' differ
make[2]: *** [Makefile:4834: doc/guix.es.info] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [Makefile:4704: doc/guix.info] Error 1
./doc/guix.fa.texi:29097: warning: node next `Network File System' in menu 
`Continuous Integration' and in sectioning `Samba Services' differ
./doc/guix.fa.texi:16005: node `Services' lacks menu item for `Samba Services' 
despite being its Up target
./doc/guix.fa.texi:29407: warning: node prev `Continuous Integration' in menu 
`Network File System' and in sectioning `Samba Services' differ
make[2]: *** [Makefile:4899: doc/guix.fa.info] Error 1
./doc/guix.de.texi:31749: warning: node next `Network File System' in menu 
`Kontinuierliche Integration' and in sectioning `Samba Services' differ
./doc/guix.de.texi:17543: node `Dienste' lacks menu item for `Samba Services' 
despite being its Up target
./doc/guix.de.texi:32070: warning: node prev `Kontinuierliche Integration' in 
menu `Network File System' and in sectioning `Samba Services' differ
make[2]: *** [Makefile:4769: doc/guix.de.info] Error 1
make[2]: Leaving directory '/home/ss2/code/guix'
make[1]: *** [Makefile:6573: all-recursive] Error 1
make[1]: Leaving directory '/home/ss2/code/guix'
make: *** [Makefile:4004: all] Error 2
--8<---cut here---end--->8---

Chances are I missed something while preparing the manual. The problem
arises with this [2] commit.  

Test units in this branch have been prepared too.  Thinking about it
wsdd hasn't got any yet.  

[1] https://git.steel-is-real.com/guix/log/?h=simons-samba-service
[2] 
https://git.steel-is-real.com/guix/commit/?h=simons-samba-service&id=04fd3f8e4eb840b9e2b10337a65035f33bbffce4

Thanks in advance for looking into this! 


Kind regards
Simon 

Re: Unreproducible «When Docker images become fixed-point»?

[Ludovic Courtès]

Hi,

zimoun  skribis:

>> A possible reason why we’re building a different derivation than back
>> then is provenance info: as explained under ‘--save-provenance’ in the
>> manual, provenance info is not “canonical” and we could end up including
>> different provenance info.  I don’t have any clear scenario in mind but
>> that sounds plausible.
>
> I do not understand why provenance is not deterministic.  I mean I
> understand that two provenances can build the same pack, but I miss why
>
> guix time-machine -C channels.scm \
>  -- pack -f docker --save-provenance -m manifest.scm
>
> is not building the same pack for the exact same channels.scm and
> manifest.scm files.  Why the resulting provenance info should be
> different?

I don’t know either, but that’s the only plausible scenario I can think
of.  We would need the original .drv or the original pack to compare.

> Maybe there is bug in how the provenance is managed; but I do not think
> it comes from this part.  Instead, I vaguely think the bug is from
> elsewhere – dependent on filesystem or unsorted list or other creative
> ideas. :-)

No, no: the store file names differ.  That means we’re building
different derivations in the first place.

> Well, let save some data, replay this scenario 6 months later and
> investigate. :-)  Keep you in touch.

Yeah.

Another approach is to take the derivation returned by

  guix time-machine --commit=fb32a38db1d3a6d9bc970e14df5be95e59a8ab02 -- \
pack -f docker --save-provenance python python-numpy -d

and to look for things that might vary between invocations or call
sites: provenance data, imported modules, (guix config) details,
whatever.

Thinking about it, (guix config) is one possible source of discrepancy:
it captures sysconfdir and localstatedir, so you’ll get a different
result if you have different settings.  The defaults are:

  (define-public %localstatedir "/var")
  (define-public %sysconfdir "/etc")

Could it be that you had something different back then?

Ludo’.

Re: Samba Services

[Julien Lepiller]

This is the relevant part. I think the rest is noise caused by the issue in the 
manual being copied to all translations:

./doc/guix.texi:29670: warning: node next `Network File System' in menu 
`Continuous Integration' and in sectioning `Samba Services' differ
./doc/guix.texi:16349: node `Services' lacks menu item for `Samba Services' 
despite being its Up target
./doc/guix.texi:29985: warning: node prev `Continuous Integration' in menu 
`Network File System' and in sectioning `Samba Services' differ

In particular, it sounds like you didn't add the Samba Services node to the 
menu near line 16349 (that's a different menu from the one at the top of the 
file I believe). The other warnings should disappear after you add it.

On July 5, 2022 9:21:48 AM GMT+02:00, Simon Streit  wrote:
>Hello,
>
>While preparing my patch series [1], I've run into issues where I can't
>compile my own branch now:
>
>--8<---cut here---start->8---
>  MAKEINFO doc/guix.fa.info
>./doc/guix.es.texi:30547: warning: node next `Sistema de archivos en red' in 
>menu `Integración continua' and in sectioning `Samba Services' differ
>./doc/guix.es.texi:16840: node `Servicios' lacks menu item for `Samba 
>Services' despite being its Up target
>./doc/guix.es.texi:30867: warning: node prev `Integración continua' in menu 
>`Sistema de archivos en red' and in sectioning `Samba Services' differ
>./doc/guix.texi:29670: warning: node next `Network File System' in menu 
>`Continuous Integration' and in sectioning `Samba Services' differ
>./doc/guix.texi:16349: node `Services' lacks menu item for `Samba Services' 
>despite being its Up target
>./doc/guix.texi:29985: warning: node prev `Continuous Integration' in menu 
>`Network File System' and in sectioning `Samba Services' differ
>make[2]: *** [Makefile:4834: doc/guix.es.info] Error 1
>make[2]: *** Waiting for unfinished jobs
>make[2]: *** [Makefile:4704: doc/guix.info] Error 1
>./doc/guix.fa.texi:29097: warning: node next `Network File System' in menu 
>`Continuous Integration' and in sectioning `Samba Services' differ
>./doc/guix.fa.texi:16005: node `Services' lacks menu item for `Samba Services' 
>despite being its Up target
>./doc/guix.fa.texi:29407: warning: node prev `Continuous Integration' in menu 
>`Network File System' and in sectioning `Samba Services' differ
>make[2]: *** [Makefile:4899: doc/guix.fa.info] Error 1
>./doc/guix.de.texi:31749: warning: node next `Network File System' in menu 
>`Kontinuierliche Integration' and in sectioning `Samba Services' differ
>./doc/guix.de.texi:17543: node `Dienste' lacks menu item for `Samba Services' 
>despite being its Up target
>./doc/guix.de.texi:32070: warning: node prev `Kontinuierliche Integration' in 
>menu `Network File System' and in sectioning `Samba Services' differ
>make[2]: *** [Makefile:4769: doc/guix.de.info] Error 1
>make[2]: Leaving directory '/home/ss2/code/guix'
>make[1]: *** [Makefile:6573: all-recursive] Error 1
>make[1]: Leaving directory '/home/ss2/code/guix'
>make: *** [Makefile:4004: all] Error 2
>--8<---cut here---end--->8---
>
>Chances are I missed something while preparing the manual. The problem
>arises with this [2] commit.  
>
>Test units in this branch have been prepared too.  Thinking about it
>wsdd hasn't got any yet.  
>
>[1] https://git.steel-is-real.com/guix/log/?h=simons-samba-service
>[2] 
>https://git.steel-is-real.com/guix/commit/?h=simons-samba-service&id=04fd3f8e4eb840b9e2b10337a65035f33bbffce4
>
>Thanks in advance for looking into this! 
>
>
>Kind regards
>Simon 
>

Re: Rust in the kernel

[Akib Azmain Turja]

Ludovic Courtès  writes:

> Hi!
>
> Leo Famulari  skribis:
>
>> The effort to use the Rust programming language within the Linux kernel
>> is progressing and may be realized in the next few months:
>>
>> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e/
>> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel/
>>
>> Within Guix, we'll need to adapt our kernel build processes in order to
>> support this.
>>
>> Although I help with updating and configuring the kernel builds, I won't
>> be able to participate in the "Rust in the kernel" effort for Guix.
>
> Understood…
>
>> So, interested volunteers should begin organizing :)
>
> Yup!
>
> Now, concretely, how long will it take before key parts of the kernel
> are written in Rust?  Hopefully a long time, no?  Per the article above,
> it’s starting small, with Rust usage in well-defined locations.
>
> This is not to say that we shouldn’t start organizing, but rather that
> we still have a bit of time ahead.
>
> (During that time, interested readers can also take a stab at improving
> support for the Hurd, which relies on that revolutionary technology
> called “address spaces” to ensure Memory Safety™ among other things!)
>
> Ludo’.
>

Why "address spaces" is a revolutionary technology?  All kernels (except
the "Hello, World!" ones) use it.

By the way, what basic features are lacking (read available) in the Hurd
port?  Last time when I checked the pre-built disk image, I found that
it completely breaks after a reboot.  I mailed at help-guix list[1],
but got no response.

[1]: https://lists.gnu.org/archive/html/help-guix/2021-09/msg00043.html


-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5


signature.asc
Description: PGP signature

Re: guix refresh to a specific version?

[bokr]

On +2022-07-04 17:53:42 +0200, zimoun wrote:
[ ... ]
> It is indeed a limitation of the Bioconductor importer and the issue is
> discussed here:
> 
> http://issues.guix.gnu.org/issue/39885
> http://issues.guix.gnu.org/issue/54787
>

For me, doing s/http/https/ on above, then
--8<---cut here---start->8---
firefox-esr 'https://issues.guix.gnu.org/issue/39885' &
--8<---cut here---end--->8---
seems to connect ok.

Just wondering if you are posting these as "http" links for some
hidden reason :)
--
Regards,
Bengt Richter

Re: guix refresh to a specific version?

[Tobias Geerinckx-Rice]

They should even redirect from http: to https:, and here they do.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Re: guix refresh to a specific version?

[zimoun]

Hi,

On Tue, 5 Jul 2022 at 11:32,  wrote:

> Just wondering if you are posting these as "http" links for some
> hidden reason :)

Because my Emacs helper [1] still uses 'http'.

1: 



Cheers,
simon

Re: Unreproducible «When Docker images become fixed-point»?

[zimoun]

Hi,

On Tue, 05 Jul 2022 at 09:44, Ludovic Courtès  wrote:

>   (define-public %localstatedir "/var")

This one is for sure the same.

>   (define-public %sysconfdir "/etc")

I do not remember.  However, I am aware of such potential issue since I
sent this patch [1] because I already hit non-reproducible pack. ;-)

So, I guess I did the correct thing using the default.  But I cannot
bet, who knows. :-)



1: 


Cheers,
simon

Re: Rust in the kernel

[jbranso]

July 5, 2022 12:48 AM, "Akib Azmain Turja"  wrote:

> jbra...@dismail.de writes:
> 
>> July 4, 2022 1:36 PM, "Akib Azmain Turja"  wrote:
>> 
>>> Ludovic Courtès  writes:
>> 
>> Hi!
>> 
>> Leo Famulari  skribis:
>>> The effort to use the Rust programming language within the Linux kernel
>>> is progressing and may be realized in the next few months:
>>> 
>>> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e
>>> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel
>>> 
>>> Within Guix, we'll need to adapt our kernel build processes in order to
>>> support this.
>>> 
>>> Although I help with updating and configuring the kernel builds, I won't
>>> be able to participate in the "Rust in the kernel" effort for Guix.
>> 
>> Understood…
>>> So, interested volunteers should begin organizing :)
>> 
>> Yup!
>> 
>> Now, concretely, how long will it take before key parts of the kernel
>> are written in Rust? Hopefully a long time, no? Per the article above,
>> it’s starting small, with Rust usage in well-defined locations.
>> 
>> This is not to say that we shouldn’t start organizing, but rather that
>> we still have a bit of time ahead.
>> 
>> (During that time, interested readers can also take a stab at improving
>> support for the Hurd, which relies on that revolutionary technology
>> called “address spaces” to ensure Memory Safety™ among other things!)
>> 
>> Ludo’.
>>> "Address spaces"! What's that? Sorry for asking without searching the
>>> internet first, but the Hurd designers are so creative that a few
>>> understand the concepts and join the community, so there is a little
>>> chance (if any) that I'll find any useful information on that.
>> 
>> From the Hurd wiki: https://www.gnu.org/software/hurd/advantages.html
>> 
>> The Hurd is built in a very modular fashion. Other Unix-like kernels
>> (Linux, for example) are also modular in that they allow loading
>> (and unloading) some components as kernel modules, but the Hurd goes
>> one step further in that most of the components that constitute the
>> whole kernel are running as separate user-space processes and are thus
>> using different address spaces that are isolated from each other.
>> This is a multi-server design based on a microkernel. It is not
>> possible that a faulty memory dereference inside the TCP/IP stack
>> can bring down the whole kernel, and thus the whole system, which
>> is a real problem in a monolithic Unix kernel architecture.
>> 
>> Some visual explantions:
>> 
>> https://en.wikipedia.org/wiki/Microkernel#/media/File:OS-structure.svg
>> 
>> The Hurd is on the right in this image.
> 
> Thanks, now I understand Ludo' was saying about virtual address space,
> achieved using paging.
> 
>> Essentially, if your fileserver somehow gets hacked, the attacker
>> cannot magically access your TCP/IP stack, because your TCP/IP is not
>> in the some "software zone" as your fileserver. So microkernels like
>> the Hurd are usually considered more secure and better designed
>> than monolithic kernels like Linux. However, monolithic kernels
>> will usually be faster than microkernels.
> 
> I know microkernels are theorically slow due to the heavy use IPC. But
> is it really impossible for well written microkernel to beat a well
> written monolithic kernel? L4 is super-fast, is it still slower than
> Linux?

Probably a little, but I am not an expert in that area.

GNU Mach, which is what the Hurd runs on.  Is slower that Linux.
There was an attempt to port the Hurd to L4 before.  It is
deemed not possible by the current hurd developers.


> 
>>> --
>>> Akib Azmain Turja
>>> 
>>> This message is signed by me with my GnuPG key. It's fingerprint is:
>>> 
>>> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
> 
> --
> Akib Azmain Turja
> 
> This message is signed by me with my GnuPG key. It's fingerprint is:
> 
> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5

Re: Rust in the kernel

[Akib Azmain Turja]

jbra...@dismail.de writes:

> July 5, 2022 12:48 AM, "Akib Azmain Turja"  wrote:
>
>> jbra...@dismail.de writes:
>> 
>>> July 4, 2022 1:36 PM, "Akib Azmain Turja"  wrote:
>>> 
 Ludovic Courtès  writes:
>>> 
>>> Hi!
>>> 
>>> Leo Famulari  skribis:
 The effort to use the Rust programming language within the Linux kernel
 is progressing and may be realized in the next few months:
 
 https://lwn.net/SubscriberLink/899182/6c831b90eaee015e
 https://www.memorysafety.org/blog/memory-safety-in-linux-kernel
 
 Within Guix, we'll need to adapt our kernel build processes in order to
 support this.
 
 Although I help with updating and configuring the kernel builds, I won't
 be able to participate in the "Rust in the kernel" effort for Guix.
>>> 
>>> Understood…
 So, interested volunteers should begin organizing :)
>>> 
>>> Yup!
>>> 
>>> Now, concretely, how long will it take before key parts of the kernel
>>> are written in Rust? Hopefully a long time, no? Per the article above,
>>> it’s starting small, with Rust usage in well-defined locations.
>>> 
>>> This is not to say that we shouldn’t start organizing, but rather that
>>> we still have a bit of time ahead.
>>> 
>>> (During that time, interested readers can also take a stab at improving
>>> support for the Hurd, which relies on that revolutionary technology
>>> called “address spaces” to ensure Memory Safety™ among other things!)
>>> 
>>> Ludo’.
 "Address spaces"! What's that? Sorry for asking without searching the
 internet first, but the Hurd designers are so creative that a few
 understand the concepts and join the community, so there is a little
 chance (if any) that I'll find any useful information on that.
>>> 
>>> From the Hurd wiki: https://www.gnu.org/software/hurd/advantages.html
>>> 
>>> The Hurd is built in a very modular fashion. Other Unix-like kernels
>>> (Linux, for example) are also modular in that they allow loading
>>> (and unloading) some components as kernel modules, but the Hurd goes
>>> one step further in that most of the components that constitute the
>>> whole kernel are running as separate user-space processes and are thus
>>> using different address spaces that are isolated from each other.
>>> This is a multi-server design based on a microkernel. It is not
>>> possible that a faulty memory dereference inside the TCP/IP stack
>>> can bring down the whole kernel, and thus the whole system, which
>>> is a real problem in a monolithic Unix kernel architecture.
>>> 
>>> Some visual explantions:
>>> 
>>> https://en.wikipedia.org/wiki/Microkernel#/media/File:OS-structure.svg
>>> 
>>> The Hurd is on the right in this image.
>> 
>> Thanks, now I understand Ludo' was saying about virtual address space,
>> achieved using paging.
>> 
>>> Essentially, if your fileserver somehow gets hacked, the attacker
>>> cannot magically access your TCP/IP stack, because your TCP/IP is not
>>> in the some "software zone" as your fileserver. So microkernels like
>>> the Hurd are usually considered more secure and better designed
>>> than monolithic kernels like Linux. However, monolithic kernels
>>> will usually be faster than microkernels.
>> 
>> I know microkernels are theorically slow due to the heavy use IPC. But
>> is it really impossible for well written microkernel to beat a well
>> written monolithic kernel? L4 is super-fast, is it still slower than
>> Linux?
>
> Probably a little, but I am not an expert in that area.
>
> GNU Mach, which is what the Hurd runs on.  Is slower that Linux.
> There was an attempt to port the Hurd to L4 before.  It is
> deemed not possible by the current hurd developers.

Yes, I know that Mach is one of the slowest kernels.  BTW, what's the
status of Viengoos?

>
>
>> 
 --
 Akib Azmain Turja
 
 This message is signed by me with my GnuPG key. It's fingerprint is:
 
 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
>> 
>> --
>> Akib Azmain Turja
>> 
>> This message is signed by me with my GnuPG key. It's fingerprint is:
>> 
>> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5


signature.asc
Description: PGP signature

Re: Rust in the kernel

[Nathan Dehnel]

>GNU Mach, which is what the Hurd runs on.  Is slower that Linux.
There was an attempt to port the Hurd to L4 before.  It is
deemed not possible by the current hurd developers.

This was done with an older L4 (Pistachio, I think) that lacked
capabilities in the kernel. Doing it with SEL4 has not been thoroughly
investigated.

Re: Rust in the kernel

[Nathan Dehnel]

>BTW, what's the
status of Viengoos?

The author put it on indefinite hiatus and no one else has the
expertise (and/or interest) to continue to work on it.

Re: Rust in the kernel

[jbranso]

July 5, 2022 11:36 AM, "Akib Azmain Turja"  wrote:

> jbra...@dismail.de writes:
> 
>> July 5, 2022 12:48 AM, "Akib Azmain Turja"  wrote:
>> 
>>> jbra...@dismail.de writes:
>> 
>> July 4, 2022 1:36 PM, "Akib Azmain Turja"  wrote:
>> 
>> Ludovic Courtès  writes:
>> 
>> Hi!
>> 
>> Leo Famulari  skribis:
>> The effort to use the Rust programming language within the Linux kernel
>> is progressing and may be realized in the next few months:
>> 
>> https://lwn.net/SubscriberLink/899182/6c831b90eaee015e
>> https://www.memorysafety.org/blog/memory-safety-in-linux-kernel
>> 
>> Within Guix, we'll need to adapt our kernel build processes in order to
>> support this.
>> 
>> Although I help with updating and configuring the kernel builds, I won't
>> be able to participate in the "Rust in the kernel" effort for Guix.
>> 
>> Understood…
>> So, interested volunteers should begin organizing :)
>> 
>> Yup!
>> 
>> Now, concretely, how long will it take before key parts of the kernel
>> are written in Rust? Hopefully a long time, no? Per the article above,
>> it’s starting small, with Rust usage in well-defined locations.
>> 
>> This is not to say that we shouldn’t start organizing, but rather that
>> we still have a bit of time ahead.
>> 
>> (During that time, interested readers can also take a stab at improving
>> support for the Hurd, which relies on that revolutionary technology
>> called “address spaces” to ensure Memory Safety™ among other things!)
>> 
>> Ludo’.
>> "Address spaces"! What's that? Sorry for asking without searching the
>> internet first, but the Hurd designers are so creative that a few
>> understand the concepts and join the community, so there is a little
>> chance (if any) that I'll find any useful information on that.
>> 
>> From the Hurd wiki: https://www.gnu.org/software/hurd/advantages.html
>> 
>> The Hurd is built in a very modular fashion. Other Unix-like kernels
>> (Linux, for example) are also modular in that they allow loading
>> (and unloading) some components as kernel modules, but the Hurd goes
>> one step further in that most of the components that constitute the
>> whole kernel are running as separate user-space processes and are thus
>> using different address spaces that are isolated from each other.
>> This is a multi-server design based on a microkernel. It is not
>> possible that a faulty memory dereference inside the TCP/IP stack
>> can bring down the whole kernel, and thus the whole system, which
>> is a real problem in a monolithic Unix kernel architecture.
>> 
>> Some visual explantions:
>> 
>> https://en.wikipedia.org/wiki/Microkernel#/media/File:OS-structure.svg
>> 
>> The Hurd is on the right in this image.
>>> Thanks, now I understand Ludo' was saying about virtual address space,
>>> achieved using paging.
>> 
>> Essentially, if your fileserver somehow gets hacked, the attacker
>> cannot magically access your TCP/IP stack, because your TCP/IP is not
>> in the some "software zone" as your fileserver. So microkernels like
>> the Hurd are usually considered more secure and better designed
>> than monolithic kernels like Linux. However, monolithic kernels
>> will usually be faster than microkernels.
>>> I know microkernels are theorically slow due to the heavy use IPC. But
>>> is it really impossible for well written microkernel to beat a well
>>> written monolithic kernel? L4 is super-fast, is it still slower than
>>> Linux?
>> 
>> Probably a little, but I am not an expert in that area.
>> 
>> GNU Mach, which is what the Hurd runs on. Is slower that Linux.
>> There was an attempt to port the Hurd to L4 before. It is
>> deemed not possible by the current hurd developers.
> 
> Yes, I know that Mach is one of the slowest kernels. BTW, what's the
> status of Viengoos?

I believe that Viengoos is essentially dead.  I do not believe
that anyone is actively working on it.  

More info is available here:

http://www.gnu.org/software/hurd/history/port_to_another_microkernel.html

> 
>>> 
>> 
>> --
>> Akib Azmain Turja
>> 
>> This message is signed by me with my GnuPG key. It's fingerprint is:
>> 
>> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
>>> --
>>> Akib Azmain Turja
>>> 
>>> This message is signed by me with my GnuPG key. It's fingerprint is:
>>> 
>>> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5
> 
> --
> Akib Azmain Turja
> 
> This message is signed by me with my GnuPG key. It's fingerprint is:
> 
> 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5

Re: repl macro (metacommand?) for guix CLI (sub)commands

[jgart]

On Tue, 05 Jul 2022 00:47:07 +0200 zimoun  wrote:
> All that said, maybe it could be nice to extend the current
> meta-commands of the REPL.  What would be the need between the current
> CLI and the current Scheme API?

Hi,

That's a good question! Maybe we should make a feature table and analyze
what we currently have exposed to decide what we might want in the near
future that we don't currently have.

> Maybe all the ’leave’ and ’exit’ could be wrapped using an hypothetical
> ’maybe-exit’ catching if it is called from REPL or not.

I'll have to read more code. I was just imagining something like that could 
work.

> Is it possible to detect if an interactive call?  I was thinking to add
> a global parameter in ’(guix scripts repl) and then this new
> ’maybe-exit’ could check it; but I guess Guile provides a better
> mechanism for checking interactiveness.

Do you know if guile provides a way of checking that? Should we ask on the 
guile mailing
list or should we read more code first to see what's currently provided?

all best,

jgart

Re: Non-free data in Poppler test suite

[Marius Bakke]

Mark H Weaver  skriver:

> Therefore, I think that in order to comply with the FSDG, we should use
> a snippet to remove any files covered by the CC BY-NC-ND license.

The test suite is shipped separately from the Poppler source code, and
contains many seemingly unauditable PDF files.  I don't think removing
all PDFs without a clear license and adjusting the test suite
accordingly is tenable, so I went ahead and removed the whole origin:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates&id=72cb5a3a648a3853a772b8b1a2cd26206627fb0d

I also raised a ticket with licensing@fsf with ID [gnu.org #1851409].

Thanks for the feedback, everyone.

-- 
Marius


signature.asc
Description: PGP signature

Re: repl macro (metacommand?) for guix CLI (sub)commands

[zimoun]

Hi,

On mar., 05 juil. 2022 at 17:27, jgart  wrote:

> That's a good question! Maybe we should make a feature table and analyze
> what we currently have exposed to decide what we might want in the near
> future that we don't currently have.

What is already exposed:

--8<---cut here---start->8---
$ guix repl
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,help guix
Guix Commands [abbrev]:

 ,run-in-store EXP - Run EXP through the store monad.
 ,enter-store-monad- Enter a REPL for values in the store monad.

scheme@(guix-user)>
--8<---cut here---end--->8---

And patch#56114 [1] introduce in addition:

 ,verbosity LEVEL  - Change build verbosity to LEVEL.
 ,lower OBJECT - Lower OBJECT into a derivation and return 
it.
 ,build OBJECT - Lower OBJECT and build it, returning its 
output file name(s).


1: 


>> Is it possible to detect if an interactive call?  I was thinking to add
>> a global parameter in ’(guix scripts repl) and then this new
>> ’maybe-exit’ could check it; but I guess Guile provides a better
>> mechanism for checking interactiveness.
>
> Do you know if guile provides a way of checking that? Should we ask on
> the guile mailing list or should we read more code first to see what's
> currently provided?

I do not know about a Guile feature allowing to check the
interactiveness.  It seems worth to ask on Guile mailing list because,
if such feature exists then, I have missed from the Guile manual.


Cheers,
simon