Re: Finding the store path of a package

[Konrad Hinsen]

Hi Ludo,

> Yes.  In the presence of grafts, run “guix build PKG”.  That always
> gives you the store file name of PKG, 100% reliable!

At the cost of a few hours of CPU time, in the worst case.

> I regularly do things like:
>
>   ls $(guix build PKG)/bin
>   find $(guix build PKG) -name …

What I am looking for is the equivalent of

   ls $(guix build PKG)

that fails in whatever way for packages that are not in the store, but
guarantees (1) not adding anything to the store and (2) response times
short enough for interactive user interfaces.

> If you want a variant that does that without building/downloading it,
> it’s also possible, though not as easily from the command line.

Guile is fine, no problem. But so far, I haven't found anything even at
the Guile level that respects my two conditions.

Background: I am working on a interactive UI for running reproducible
computations via Guix:

  https://github.com/khinsen/guix-gtoolkit/

I'd like to implement (1) browsing package contents ("what exactly do I
get by adding "core-utils" to my environment?") and (2) searching
packages by the files they contain ("which package do I have to add to
my environment to get the ls command?"). There will be a button for
explicitly building a package, but I don't want it to happen as a side
effect when doing operations that need to be fast.

Cheers,
  Konrad.

Re: Why [bug#47081] Remove mongodb?

[Efraim Flashner]

On Sun, Mar 21, 2021 at 11:15:32PM +0100, Léo Le Bouter wrote:
> Hello!
> 
> > Removing a package and its services is not something to do lightly:
> > it
> > breaks user configs with no recourse.
> > 
> > We must insist on getting more opinions on such matters, and I think
> > there just wasn’t enough feedback here.  I understand it can be
> > frustrating to wait for input, but in such a case, please do.  This
> > project has always strove for consensus.
> > 
> > Remember that the opinion of those who’ve been taking care of
> > security
> > issues in Guix for years, those who’ve been maintaining MongoDB,
> > those
> > who wrote the service and its tests, are invaluable; they must have a
> > say.  I insist: humbly solicit and wait for their feedback.
> > 
> 
> I understand, and I did not think it was a light thing to do, no one
> mentionned anything we should do for the remove, so I actually do not
> know how we handle that but the security/non-free code thing put some
> urge into the situation, apologizes for moving on and pushing without
> waiting for more feedback, few people gave their feedback on IRC and by
> email and that's why I felt more confident doing the actual change.
> 
> > Now, how do we move forward?  IMO we must look for available options
> > before we remove MongoDB.  Are there forks of the original
> > freely-licensed code base maintained around?  That sounds likely.  
> 
> I never heard of any and after some searches even before I pushed the
> remove commit it remained inconclusive on whether we can rely on a
> fork.
> 
> > Are
> > there backports of the security fixes? 
> 
> Ubuntu Focal maintains a package still but to me they still don't have
> all the fixes, see: https://packages.ubuntu.com/focal/mongodb-server
> 
> All in all, I don't think we should keep a package in more-than-
> maintenance mode when the upstream has decided to change the license,
> they are uncooperative and making our work harder so I think we should
> remove the package. It's not like we are an LTS distro like Ubuntu
> Focal that absolutely must keep a package until the end of the support
> cycle. It may break configs yes, but actually this had to happen, at
> the same time they changed to a problematic nonfree license and openssl
> 1.1.1 is not supported on 3.4.x (Ubuntu uses 3.6.8 instead which also
> is under AGPL but more recent than our 3.4.10 we had so supports
> openssl 1.1.1 with some patches they made). I'm not particularily
> sympathetic to MongoDB. Also are there actually people using the
> mongodb service on GNU Guix?
> 
> > What do the previous
> > contributors to this code think—Chris, Efraim, Marius, Arun?
> 
> Chris voiced their opinion saying they didnt mind removing the package,
> I think Efraim said that on IRC also but I am not sure, so let's wait
> for their input here.
> 
> > 
> > Léo, please get involved in reaching consensus on a solution.
> 
> CC'd them, of course, again, sorry.
> 
> > Ludo’.
> 
> Léo
> 

I don't have a strong opinion. I had hoped they'd return to a free
license but that doesn't seem to be the case. I see it a bit more from a
selfish angle, I'd rather drop packages like mongodb which are
unsupported or effectively dead upstream AND I don't use to free up
resources for other packages but I'd rather not take away a package that
someone else is actually using.

Given limited developer time, I would personally rather spend my own
developer time porting gourmet (last release 2014) to python3 than
porting mongodb to openssl-1.1.



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

Re: Finding the store path of a package

[zimoun]

Hi Konrad,

On Mon, 22 Mar 2021 at 08:39, Konrad Hinsen  wrote:

> Background: I am working on a interactive UI for running reproducible
> computations via Guix:
>
>   https://github.com/khinsen/guix-gtoolkit/
>
> I'd like to implement (1) browsing package contents ("what exactly do I
> get by adding "core-utils" to my environment?") and (2) searching
> packages by the files they contain ("which package do I have to add to
> my environment to get the ls command?"). There will be a button for
> explicitly building a package, but I don't want it to happen as a side
> effect when doing operations that need to be fast.

Nice!

On a side note, Ricardo did recently some stuff as UI for packages,

  
  

And on another side note, I would like to have the abilities to join or
intersect graphs; be able to visualize “guix graph foo bar” using D3.js,
or the intersection or the complementary of the intersection, etc.
Something similar for packages as the Ludo’s proof of concept for
services,

   

Sadly, time is not respecting what we are doing without considering
him. ;-)

Cheers,
simon

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

[Andreas Enge]

Am Fri, Mar 19, 2021 at 10:40:45AM +0100 schrieb Léo Le Bouter:
> We had a user reporting that Inkscape stopped working after the graft (
> https://logs.guix.gnu.org/guix/2021-03-18.log#100200), after which we
> decided on IRC with rekado we might cheat by symlinking the shared
> libraries, which I've done in commit
> 2e0ff59f0cd836b156f1ef2e78791d864ce3cfcd, from a glance it didnt seem
> the soname change caused backwards incompatible changes but only
> forward incompatible changes.

It happens I just wanted to use inkscape, started submitting a bug report:
   https://issues.guix.gnu.org/47315
and ended up realising that this is exactly the issue discussed on
guix-devel.

I cannot afford a "guix pull" right now, since with
   https://issues.guix.gnu.org/31719
this might mean a download of a few gigabytes, so I did not check whether
the symlinking fix does work.

But honestly, this feels like piling a cludge (symlinking) onto a cludge
(grafting), and that we are not in the high quality approach for which
I appreciate Guix.

Personally, I would suggest to revert the commits. If the CVE is sufficiently
important (it would be useful if the commit log or the diff itself contained
its number), maybe we can update the imagemagick version on the wip-release
branch, which is supposed to be built soon and merged back to master?

And please let us agree that in the future, we only backport fixes in grafts
and do not update version numbers.

Andreas

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

[zimoun]

Hi,

On Sun, 21 Mar 2021 at 15:04, Ludovic Courtès  wrote:

> To me that means we should revert this patch series (perhaps with the
> exception of bb2427fa28):
>
>   2e0ff59f0c gnu: imagemagick/fixed: Redirect old sonames to new sonames.
>   bb2427fa28 gnu: ImageMagick: Refer to the version number in a more robust 
> way.
>   bb5d84a048 gnu: ImageMagick: Fix version number in build configuration of 
> grafted replacement.
>   852ba914a4 gnu: imagemagick/fixed: Retain version length for successful 
> grafting.
>   82e887ba48 gnu: imagemagick: Update to 6.9.12-2 [security fixes].
>
> After that, what we can do, is introduce 6.9.12-2 as an additional
> public version of imagemagick.  That way, users who run:
>
>   guix install imagemagick
>
> get the newer version, the one that includes security fixes.

I agree.  It sounds reasonable.  In the same time, is it possible to
start to build the branch wip-next-release? then an ungrafted version
could be pushed there and if all the substitutes are availaible on time,
we could cherry-pick for the release.


Cheers,
simon

Re: Finding the store path of a package

[Konrad Hinsen]

Hi Simon,

> On a side note, Ricardo did recently some stuff as UI for packages,
>
>   
>   

Looks good! My project has a lot of overlap, except that it is very
intentionally not based on Web technology, but on a malleable platform
(http://gtoolkit.com/) in which you can also do data analysis and other
computation. It's more like Emacs than like a Web app.

> And on another side note, I would like to have the abilities to join or
> intersect graphs; be able to visualize “guix graph foo bar” using D3.js,
> or the intersection or the complementary of the intersection, etc.
> Something similar for packages as the Ludo’s proof of concept for
> services,
>
>

Nice! That kind of visualization is not my focus for now, but the people
who build the Glamorous Toolkit platform are very much into that and
there's a lot of support code for visually exploring software systems:

   https://gtoolkit.com/usecases/software-assessment/

Cheers,
  Konrad.

Sharing system users for related services

[raingloom]

I'm packaging the Molly Brown Gemini server and I'm trying to play nice
with the already packaged gmnisrv.
Should the two use the same service name and system users? Most users
probably won't want to run both servers at the same time, so the former
seems like a good idea. And the latter would be preferable because if
they use the same certs, %gmnisrv-activation will trample over the
permissions when they do want to run both for some reason.

So should I just reuse %gmnisrv-accounts or should they both use a
shared %gemini-server-accounts?

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

[raingloom]

On Sat, 20 Mar 2021 12:19:11 +0100
Ludovic Courtès  wrote:

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

What about a Liberapay for Guix? Could also be used to pay developers.

Re: A Critique of Shepherd Design

[raingloom]

On Fri, 19 Mar 2021 17:33:57 +
raid5atemyhomework  wrote:

> The Shepherd language for describing actions on Shepherd daemons is a
> Turing-complete Guile language.  Turing completeness runs afoul of
> the Principle of Least Power.

Erlang is turing complete and yet it is famously excellent at managing
services in a robust way.

Re: [art] Tiled Wallpaper Art

[Luis Felipe]

Hi, Sarthak, Leo :)


On Sunday, March 21, 2021 11:42 PM, Leo Famulari  wrote:

> On Mon, Mar 22, 2021 at 04:07:15AM +0530, Sarthak Shah wrote:
>
> > Hello, I put together a tiled svg wallpaper for GuixSD (attached)
> > using the logo resources in the git repository.
> > I'm not sure where to submit it
>
> Cool!
>
> We usually keep this kind of thing in the 'guix-artwork' repository:
>
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/
>
> And, this is the right place to submit it.
>
> I'm CC-ing Luis Felipe, who usually works on our art, and they can help
> guide you in contributing these tiles :)

Well, I try to follow the process below when I want to contribute artwork to 
GNU Guix:

1. I send a proposal to guix-devel
2. Wait for reactions from Guix
3. If there is acceptance, I send a patch to guix-artwork with my work

In the case of your tiled background, Sarthak, step 3 above would go like this:

1. Clone the guix-artwork repository
2. Put your image in guix-artwork/backgrounds
3. Commit your changes
4. Generate a patch
5. Send it by email to guix-patc...@gnu.org

You can see https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/log/ for 
examples of how the commit message should look like.

If you have difficulties with any of these steps, don't hesitate to ask :)

Now, about your wallpaper proposal, I would personally try to make the logos 
smaller, subtle and the background color a dark gray instead of black. That was 
my first thought.

Also, did you tried the tile in a particular desktop environment? I ask because 
I use GNOME 3.34.5 in the Guix System 1ab03fb, and couldn't find a way to tile 
it. But I did try the tile in an HTML document, and it looks seamless.

Looking at the file itself, I see it is clean. That is, Using File → Clean Up 
Document in Inkscape says there are no unused definitions (which are common 
when you import other SVGs into the document and make the file size grow).

I personally add the copyright and license information to the SVG as metadata 
(File → Document Properties... → Metadata).

Finally, if your artwork is not included in the system for any reason, you can 
always create your own repository of artwork, maybe package it for Guix, and 
share it with the world. I personally do that with wallpapers 
(https://gitlab.com/luis-felipe/guix-backgrounds).

Cheers,

Re: Sharing system users for related services

[Leo Prikler]

Hi raingloom,

Am Montag, den 22.03.2021, 13:40 +0100 schrieb raingloom:
> I'm packaging the Molly Brown Gemini server and I'm trying to play
> nice
> with the already packaged gmnisrv.
> Should the two use the same service name and system users? Most users
> probably won't want to run both servers at the same time, so the
> former
> seems like a good idea. And the latter would be preferable because if
> they use the same certs, %gmnisrv-activation will trample over the
> permissions when they do want to run both for some reason.
> 
> So should I just reuse %gmnisrv-accounts or should they both use a
> shared %gemini-server-accounts?
As the one, who wrote the code, that lets you share accounts as list
"pointers" in the first place, I do think something along the lines of 
  (define %molly-brown-accounts %gmnisrv-accounts)
with an appropriate comment should be fine, especially for a proof of
concept implementation.  That being said, patch review is an ideal
opportunity to bikeshed such definitions ;)

Regards,
Leo

Re: Why [bug#47081] Remove mongodb?

[Ludovic Courtès]

Hi Léo,

Léo Le Bouter  skribis:

>> Removing a package and its services is not something to do lightly:
>> it
>> breaks user configs with no recourse.
>> 
>> We must insist on getting more opinions on such matters, and I think
>> there just wasn’t enough feedback here.  I understand it can be
>> frustrating to wait for input, but in such a case, please do.  This
>> project has always strove for consensus.
>> 
>> Remember that the opinion of those who’ve been taking care of
>> security
>> issues in Guix for years, those who’ve been maintaining MongoDB,
>> those
>> who wrote the service and its tests, are invaluable; they must have a
>> say.  I insist: humbly solicit and wait for their feedback.
>> 
>
> I understand, and I did not think it was a light thing to do, no one
> mentionned anything we should do for the remove, so I actually do not
> know how we handle that but the security/non-free code thing put some
> urge into the situation, apologizes for moving on and pushing without
> waiting for more feedback, few people gave their feedback on IRC and by
> email and that's why I felt more confident doing the actual change.

Sure, now you know.  :-) For package removal, we have to wait for
feedback, pinging people if needed, and waiting longer than
usual—security pressure or not.  Removing a package can only happen if
there’s some consensus.

Thanks for your reply!

Ludo’.

Re: [SPITBALL] Jehanne as another kernel option / porting target

[François]

Hello,

On Fri, Mar 19, 2021 at 12:44:47PM -0400, Joshua Branson wrote:
> pinoaffe  writes:
> > raingloom writes:
> >
> >> seL4 would be cool too.


> So essentially most of the active hurd developers considered a port to a
> different microkernel to be impractical.  :(
> 
> However, one of the main hurd developers (he has since stepped away from
> active development), started a hurd clone:  x15.

On the microkernel front there is also [Genode] which seems to have
nice ideas. I don't know if it would suit Guix or not.

[Genode]: https://genode.org/

Re: [art] Tiled Wallpaper Art

[Sarthak Shah]

Thank you!

Self-contained GuixSD Installer

[Gurjeet Singh]

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

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

Is it possible to deliver the /gnu/store on the ISO so that a minimal
system can be installed and started, without having to connect to the
Internet? The user is free to install and upgrade packages from the
internet, but they should be able to run GuixSD without the Internet
being a hard requirement.

Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/

Re: Finding the store path of a package

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen  skribis:

>> Yes.  In the presence of grafts, run “guix build PKG”.  That always
>> gives you the store file name of PKG, 100% reliable!
>
> At the cost of a few hours of CPU time, in the worst case.
>
>> I regularly do things like:
>>
>>   ls $(guix build PKG)/bin
>>   find $(guix build PKG) -name …
>
> What I am looking for is the equivalent of
>
>ls $(guix build PKG)
>
> that fails in whatever way for packages that are not in the store, but
> guarantees (1) not adding anything to the store and (2) response times
> short enough for interactive user interfaces.
>
>> If you want a variant that does that without building/downloading it,
>> it’s also possible, though not as easily from the command line.
>
> Guile is fine, no problem. But so far, I haven't found anything even at
> the Guile level that respects my two conditions.

Here’s an example of how to do that:

--8<---cut here---start->8---
scheme@(guix-user)> ,use(guix)
scheme@(guix-user)> (define s (open-connection ))
scheme@(guix-user)> ,use(gnu packages base)
scheme@(guix-user)> (package-derivation s coreutils #:graft? #f)
$1 = # 
/gnu/store/yvsd53rkbvy9q8ak6681hai62nm6rf31-coreutils-8.32-debug 
/gnu/store/n8awazyldv9hbzb7pjcw76hiifmvrpvd-coreutils-8.32 7fc814f2e1e0>
scheme@(guix-user)> (derivation-outputs $1)
$2 = (("debug" . #< path: 
"/gnu/store/yvsd53rkbvy9q8ak6681hai62nm6rf31-coreutils-8.32-debug" hash-algo: 
#f hash: #f recursive?: #f>) ("out" . #< path: 
"/gnu/store/n8awazyldv9hbzb7pjcw76hiifmvrpvd-coreutils-8.32" hash-algo: #f 
hash: #f recursive?: #f>))
scheme@(guix-user)> (derivation->output-path $1 "out")
$3 = "/gnu/store/n8awazyldv9hbzb7pjcw76hiifmvrpvd-coreutils-8.32"
--8<---cut here---end--->8---

Why #:graft? #f?  Because if you enable graft, you’ll potentially have
to build/download the thing, and that wouldn’t buy you anything because
the set of file names is the same in the grafted package.

Does that make sense?

> Background: I am working on a interactive UI for running reproducible
> computations via Guix:
>
>   https://github.com/khinsen/guix-gtoolkit/

Nice!

> I'd like to implement (1) browsing package contents ("what exactly do I
> get by adding "core-utils" to my environment?") and (2) searching
> packages by the files they contain ("which package do I have to add to
> my environment to get the ls command?"). There will be a button for
> explicitly building a package, but I don't want it to happen as a side
> effect when doing operations that need to be fast.

For #2, there have been discussions about building a service that would
create such a database—a mapping from file names to packages.  It’s not
possible to do with purely local knowledge because, by definition, you’d
have to build/download every package.  I don’t think it has materialized
yet, though.

Thanks,
Ludo’.

Re: Why [bug#47081] Remove mongodb?

[Jack Hill]

I don't have anything to add with respect to the process for package 
removeal, but for the completeness of the thread I'd like the observe that 
one of the packages that was removed (mongo-tools) was broken for over a 
year: https://issues.guix.gnu.org/39637


For the reasons Efraim pointed out, I think that package was unlikely to 
be fixed, so I'm okay with it being removed.


Best,
Jack

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

[Ludovic Courtès]

Hi again!

Ludovic Courtès  skribis:

> It’s also unclear to me that ImageMagick can be meaningfully grafted.
> Are there users of libMagick*.so in external packages?  That seems
> unlikely.
>
> On berlin, I see this:
>
> $ guix graph -t referrers 
> /gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g 
> digraph "Guix referrers" {
>   "/gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g" [label 
> = "imagemagick-6.9.12-2g", shape = box, fontname = sans];
>   "/gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g" -> 
> "/gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g" [color = 
> darkviolet];
>   "/gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g" -> 
> "/gnu/store/wsw9an4lsnqxalwkvycxaa3y0ybp8rxp-ecl-ltk-0.992" [color = 
> darkviolet];
>   "/gnu/store/wsw9an4lsnqxalwkvycxaa3y0ybp8rxp-ecl-ltk-0.992" [label = 
> "ecl-ltk-0.992", shape = box, fontname = sans];
>   "/gnu/store/wsw9an4lsnqxalwkvycxaa3y0ybp8rxp-ecl-ltk-0.992" -> 
> "/gnu/store/wsw9an4lsnqxalwkvycxaa3y0ybp8rxp-ecl-ltk-0.992" [color = 
> peachpuff4];
>
> }
>
> That means ‘ecl-ltk’ is the only package that keeps a reference to
> ImageMagick, and thus, it’s the only one that would benefit from the
> graft.  The graft is useless.

I was plain wrong—apologies for the confusion!

Running:

  guix graph -t referrers 
/gnu/store/cnyiwi6mn53jwmjh7kdvnlmagf3frsa3-imagemagick-6.9.12-2g | xdot -

on my laptop, I see at least emacs-w3m, pstoedit, skribilo, and (of
course) inkscape.

So grafting makes sense.

Consequently, the way forward IMO is to get a 6.9.11 backport of
whatever CVEs it is we are patching and to use such a patched 6.9.11
variant as the replacement.

Does that make sense?

Ludo’.

Re: A Critique of Shepherd Design

[Ludovic Courtès]

Hi,

raid5atemyhomework  skribis:

> I'm not sure you can afford to keep it simple.

It has limitations but it does the job—just like many other init systems
did the job before the advent of systemd.

> Consider: https://issues.guix.gnu.org/47253
>
> In that issue, the `networking` provision comes up potentially *before* the 
> network is, in fact, up.  This means that other daemons that require 
> `networking` could potentially be started before the network connection is up.

The ‘networking’ service is just here to say that some network interface
is up or will be up.  It’s admittedly vague and weak, but it’s enough
for most daemons; they just need to be able to bind and listen to some
port.

> One example of such a daemon is `transmission-daemon`.  This daemon will bind 
> itself to port 9091 so you can control it.  Unfortunately, if it gets started 
> while network is down, it will be unable to bind to 9091 (so you can't 
> control it) but still keep running.  On my system that means that on reboot I 
> have to manually `sudo herd restart trannsmission-daemon`.

Could you report a bug for this one?  I don’t see why it’d fail to bind.

> In another example, I have a custom daemon that I have set up to use
> the Tor proxy over 127.0.0.1:9050.  It requires both `networking` and
> `tor`.  When it starts after `networking` comes up but before the
> actual network does, it dies because it can't access the proxy at
> 127.0.0.1:9050 (apparently NetworkManager handles loopback as well).

Loopback is handled by the ‘loopback’ shepherd service, which is
provided via ‘%base-services’.  Perhaps you just need to have your
service depend on it?

> Switching to a concurrent design for Shepherd --- *any* concurrent design --- 
> is probably best done sooner rather than later, because it risks strongly 
> affecting customized `configuration.scm`s like mine that have almost a half 
> dozen custom Shepherd daemons.

I suspect the main issue here is undeclared dependencies of some of the
Shepherd services you mention.

I like the “sooner rather than later” bit, though: it sounds like you’re
about to send patches or announce some sponsorship program?…  :-)

Thanks,
Ludo’.

Re: Finding the store path of a package

[Konrad Hinsen]

Hi Ludo,

> Here’s an example of how to do that:

Works fine, thanks!

> Why #:graft? #f?  Because if you enable graft, you’ll potentially have
> to build/download the thing, and that wouldn’t buy you anything because
> the set of file names is the same in the grafted package.

OK, so that's the secret, because that's the only difference with what
I tried before.

One day I'll figure out how grafts work, but that day is not today ;-)

> For #2, there have been discussions about building a service that would
> create such a database—a mapping from file names to packages.  It’s not
> possible to do with purely local knowledge because, by definition, you’d
> have to build/download every package.  I don’t think it has materialized
> yet, though.

That would certainly be the best solution, but in the meantime, I'll go
ahead with what is possible today. In practice, I expect most such
queries to succeed because there are only a few packages that contain
popular commands, and those are usually in the store.

Cheers,
  Konrad.

Re: A Critique of Shepherd Design

[Martin]

On Fri, 19 Mar 2021 17:33:57 +
raid5atemyhomework  wrote:


The Shepherd language for describing actions on Shepherd daemons is a
Turing-complete Guile language.  Turing completeness runs afoul of
the Principle of Least Power.

Erlang is turing complete and yet it is famously excellent at managing
services in a robust way.

Ironically nowadays almost everything is Turing complete: 
https://www.gwern.net/Turing-complete


Lack of Turing-completeness by design can be a real feature, i.e. 
bitcoin script is a perfect practical example of it.

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

[Mark H Weaver]

Hi Andreas,

Andreas Enge  writes:
> And please let us agree that in the future, we only backport fixes in grafts
> and do not update version numbers.

I agree that in this particular case, that's what should have been done,
and that we should still try to do it.  It will be several days at least
before I'm able to look at it, though.  Would someone else like to try?

I also agree that in general, we should be more careful to check for ABI
compatibility before grafting.  Moreover, if an update includes
substantial changes other than bug fixes, I agree that backporting the
fixes is highly preferable for grafting purposes.

However, I think it would be going too far to adopt your proposal as a
general rule for all grafts.  In some cases, it can clearly be seen that
an upstream release includes little more than bug fixes.  For example,
if the recent gvfs-1.40.2 security update had required grafting, I would
not have hesitated to do so, and that would have been much simpler and
IMO cleaner than importing the upstream patches into our tree.

I'll also note that fewer imported patches makes for less review work by
those of us who try to keep an eye on changes made to Guix, to help
guard against the possibility of malicious "fixes" being introduced by
our growing list of committers.  Note that this could happen without any
ill intent on the part of the committer, if their development machine is
compromised by a third party.

What do you think?

Regards,
  Mark

Re: Self-contained GuixSD Installer

[raingloom]

On Sun, 21 Mar 2021 18:56:05 -0700
Gurjeet Singh  wrote:

> Does a self-contained GuixSD installer exist? I tried running GuixSD
> in a VM (in VBox, on macOS), and for that I downloaded the ISO image.
> The ISO image, after a few prompts, then tries to install everything
> from the internet.
> 
> If everything is being downloaded and installed from the internet, why
> does the image have to be so huge (~500MB
> guix-system-install-1.2.0.x86_64-linux.iso.xz)?
> 
> Is it possible to deliver the /gnu/store on the ISO so that a minimal
> system can be installed and started, without having to connect to the
> Internet? The user is free to install and upgrade packages from the
> internet, but they should be able to run GuixSD without the Internet
> being a hard requirement.
> 
> Best regards,
> --
> Gurjeet Singh http://gurjeet.singh.im/
> 

I think the installer does a `guix pull` before running `guix system
init`, so it has to download fresh packages.
I haven't used the graphical installer, but at leat that's how the old
school CLI install worked, at least as far as I remember.

You could just not guix pull, or if you did, you could pull the
specific commit that was used to build the system.

At least in theory.