Re: Video narration

[Laura Lazzati]

Hi Paul and Ricardo

> Have you seen this too?
We have been using mpv and VLC, don't know, Ricardo, WDYT? should we
fix this or go on with the narration?

I have just thought, may you see the transcripts of all the videos,
and arrange them if you find a better way of saying things in native
English, and then I record the CLI session videos and create subtitles
for them? Do you find this workflow fine?

Regards :)
Laura

Re: librsvg & Rust

[Marius Bakke]

Ludovic Courtès  writes:

> Hi!
>
> Marius Bakke  skribis:
>
>> Ludovic Courtès  writes:
>
> [...]
>
 I wanted to ask about this: is Rust supported on all the platforms we
 support at the moment?
>>>
>>> According to Efraim and Danny, we have a problem at the moment.
>>> Presumably that can be worked around?
>>
>> Right, Rust currently only works on x86_64.  In order to get this branch
>> started, let us either:
>>
>> * Revert back to 2.40.20, or
>> * Conditionally use the new version on supported platforms
>>
>> For the latter, I imagine something along the lines of...
>>
>> (define-public librsvg
>>   (if (string-prefix? "x86_64" (or (%current-target-system)
>>(%current-system)))
>>   librsvg-2.44
>>   librsvg-2.40))
>
> It would have to be a macro so that the conditional is evaluated in a
> context where (%current-system) and (%current-target-system) have the
> right value, like the ‘glibc’ macro we had until commit
> 2d546858b139e5fcf2cbdf9958a17fd98803ac4c.

Right, thanks!

>> Preferences?
>
> I have a slight preference for having the same librsvg on all platforms.
>
> So we could add 2.44 alongside 2.40, but keep using 2.40 until our Rust
> package works on all the platforms.
>
> That said, if the chances are that Rust won’t work on all 4 platforms in
> the foreseeable future, the other option (upgrading on platforms where
> Rust is supported) may be preferable.
>
> Your call!  :-)

I don't have a strong opinion, so I restored the previous librsvg
variant for now and kept the Rust one as 'librsvg-next' with commit
f67417a1b4d3fbd3a2e1593d32422e0d901ba367.

Let's "freeze" and try to merge this branch soon.  Are there any pending
patches?


signature.asc
Description: PGP signature

Re: Guix on the ASUS C201PA

[Vagrant Cascadian]

On 2019-03-23, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>> There's a FIXME for properly fetching the veyron kernel configuration,
>> but otherwise it's looking almost like something worth formally
>> submitting... ?
>
> It looks like it!  Mark, could you comment on this patch, in particular
> the ‘kernel-config-veyron’ bit (see below)?  Danny is fine with it.  :-)
>
> It’s great that you managed to simplify this.  Then I guess we could add
> the example and other useful bits that Timothy had.

I feel like just getting a working kernel in guix will make it easier to
work on the "bootloader" integration and such, since the kernel is a
relatively large build, having to build that in a local branch only,
rebase, etc. to keep current ... has it's cost.

Although if you want to integrate the depthcharge/bootloader patches
too, they do work, though there's no way I know of to implement system
generation selection in a bootloader menu. Biggest reason I want to get
u-boot working, but no progress on that.

I have a few more changes to the veyron-specific config that were needed
for desktop use (CONFIG_CGROUP_PERF + related), without which, enabling
the desktop caused things like pam calls to fail... The desktop is
unfortunately painfully slow. I might not get a chance to submit the
updated patches for a few days yet...

In theory and ideally, it should be possible to enable the right
features in the "regular" linux-libre package, and document the extra
modules needed in the initrd, but I have not yet managed to figure out a
working combination there. Not sure if it would be better to just wait
for that at this point.

Now if it were just possible to build libreboot in guix... but since
libreboot is essentially it's own system, it would most likely have to
re-implement libreboot's build system in guix.


live well,
  vagrant

Re: Guix on the ASUS C201PA

[Mark H Weaver]

Ludovic Courtès  writes:

> Vagrant Cascadian  skribis:
>
>> There's a FIXME for properly fetching the veyron kernel configuration,
>> but otherwise it's looking almost like something worth formally
>> submitting... ?
>
> It looks like it!  Mark, could you comment on this patch, in particular
> the 'kernel-config-veyron' bit (see below)?  Danny is fine with it.  :-)

Clearly, our handling of kernel configurations and kernel variants
should be redesigned, but this is fine for now.

 Thanks!
   Mark

Re: Cross-compiling guile libraries

[Ludovic Courtès]

Hi Mathieu,

Mathieu Othacehe  skribis:

> Even if guild has a "target" option allowing to cross-compile sources,
> autotools does not seem to have support for guile
> cross-compilation. For instance, passing "--host=aarch64-linux-gnu" to
> configure script doesn't set the "target" argument of guild to the
> specified triplet.

Libraries like Guix itself pass --target to ‘guild’ just fine, so I
guess we’d have to fix Autotools-based Guile packages that don’t do
that.

Thanks,
Ludo’.

Re: boot multiple Gnu/Linux Distributions from one USB key

[Tobias Geerinckx-Rice]

gnuforever,

I missed this question, sorry.  Had any luck?

March 13, 2019 6:24 AM, "gnuforever"  wrote:
>> TL;DR: there is no one reliable way, only distro-specific support.
> 
> Does this mean that ,for the moment, I can not add Guix to my multiple
> boot usb key?

Not out of the box, no, but there's already work being done[1] to change that.  
Until then, you'll have to manually set up the necessary loopiness.

Kind regards,

T G-R

[1]: https://issues.guix.info/issue/34863

Sent from a Web browser.  Excuse or enjoy my brevity.

Re: Include Proot-static with binary releases

[Danny Milosavljevic]

On Tue, 23 Jan 2018 15:49:26 +0100
ludovic.cour...@inria.fr (Ludovic Courtès) wrote:

> > Currently proot only build successfully on x86_64 and i686, so that is
> > something we would need to fix first.  

Are you sure that is not just a limitation of the qemu transparent emulation?

I examined the test failures in proot-static and it's clear that qemu will have
some trouble finding out what one wants to happen:

>#include  /* execve(2), */
>#include  /* exit(3), */
>#include  /* strcmp(3), */
>
>int main(int argc, char *argv[])
>{
>if (argc == 0)
>exit(EXIT_SUCCESS);
>
>execve("/proc/self/exe", NULL, NULL);
>exit(EXIT_FAILURE);
>}

Now, qemu transparent emulation still picks up, but then the missing
argv[0] will be a problem.

And indeed,

$ guix environment -s armhf-linux proot-static
[...]
[env]$ ./test-25069c12
qemu: no user program specified


pgpTTPc31Jxoq.pgp
Description: OpenPGP digital signature

Re: librsvg & Rust

[Ludovic Courtès]

Hi!

Marius Bakke  skribis:

> Ludovic Courtès  writes:

[...]

>>> I wanted to ask about this: is Rust supported on all the platforms we
>>> support at the moment?
>>
>> According to Efraim and Danny, we have a problem at the moment.
>> Presumably that can be worked around?
>
> Right, Rust currently only works on x86_64.  In order to get this branch
> started, let us either:
>
> * Revert back to 2.40.20, or
> * Conditionally use the new version on supported platforms
>
> For the latter, I imagine something along the lines of...
>
> (define-public librsvg
>   (if (string-prefix? "x86_64" (or (%current-target-system)
>(%current-system)))
>   librsvg-2.44
>   librsvg-2.40))

It would have to be a macro so that the conditional is evaluated in a
context where (%current-system) and (%current-target-system) have the
right value, like the ‘glibc’ macro we had until commit
2d546858b139e5fcf2cbdf9958a17fd98803ac4c.

> Preferences?

I have a slight preference for having the same librsvg on all platforms.

So we could add 2.44 alongside 2.40, but keep using 2.40 until our Rust
package works on all the platforms.

That said, if the chances are that Rust won’t work on all 4 platforms in
the foreseeable future, the other option (upgrading on platforms where
Rust is supported) may be preferable.

Your call!  :-)

Thanks,
Ludo’.

Re: Status update on 1.0

[Ludovic Courtès]

Hello!

Timothy Sample  skribis:

> This didn’t work as well as I had hoped.  I was able to make a “lib”
> output for “colord”, which gets rid of “hplip-minimal” and, in turn,
> “gcc”.  However, it was supposed to also remove “llvm” and “python@3”,
> but those are still in the closure because of other packages.  It looks
> like breaking apart “mesa” (as Debian and Nix do) could cut out “llvm”
> and maybe “python@2”.  The reason “python@3” is there is because of
> “glib:bin”.  The “gnome-session” package brings it in so that it can
> call “gsettings”.  Debian splits the GLib executables into “bin” and
> “dev-bin”, and only the latter needs Python 3.  This is tricky because
> “mesa” and “glib” have thousands of dependants, so changing them could
> cause a lot of problems.  Splitting GLib is not so bad, but Mesa looks
> to be quite complicated.

Yeah, splitting MESA and GLib are longer-term project I guess, but it’s
good that you’ve already analyzed the situation so we know what to do
next.

> Another area that could be improved is NetworkManager.  GDM only needs
> the “libnm” part, but it ends up bringing in everything.  NetworkManager
> doesn’t have many dependants, so this could be done pretty quickly
> (provided that splitting it is easy enough).

Indeed.

> I managed to remove “webgitgtk” from the closure of “gnome-shell”.

Neat!  Do you have that patch around?  :-)

> All told, GDM is down to 1.2GiB, and GNOME Shell is 1.64GiB.  That’s
> better, but not great.  Plenty of GNOME software comes in big bundles
> where you get a daemon, a low-level D-Bus library, a high-level library,
> a GUI, and some utilities.  Being able to break these up would improve
> the situation quite a bit, but it will be a lot of work.  I don’t know
> how much of this we can solve before 1.0.  It all depends on how much of
> a hurry we’re in.  :)

That will be post-1.0, let’s focus on the low-hanging fruits for now.
:-)

> Right now, I have a bit testing to do with my current patches, and then
> maybe I could break up NetworkManager and fix the dependency cycle with
> GDM and GNOME Shell.  If it can go through a core-updates cycle, I could
> split up GLib.  I don’t think I can split up Mesa, though.  I am not
> very familiar with it.
>
> I will be tied up for about a week, so I won’t be able to do any of it
> before next weekend (Mar. 29).

OK, thank you for your work!

Ludo’.

Re: Guix on the ASUS C201PA

[Ludovic Courtès]

Hi Vagrant,

Vagrant Cascadian  skribis:

> There's a FIXME for properly fetching the veyron kernel configuration,
> but otherwise it's looking almost like something worth formally
> submitting... ?

It looks like it!  Mark, could you comment on this patch, in particular
the ‘kernel-config-veyron’ bit (see below)?  Danny is fine with it.  :-)

It’s great that you managed to simplify this.  Then I guess we could add
the example and other useful bits that Timothy had.

Thank you,
Ludo’.

> From d521904a25ea6146a0641c0929cdb5ac5f486cc8 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian 
> Date: Mon, 18 Mar 2019 03:24:05 +
> Subject: [PATCH] gnu: Add linux-libre-arm-veyron.
>
> * gnu/packages/linux.scm (linux-libre-arm-veyron): New variable.
>   FIXME: Merge with "kernel-config"...
>   (kernel-config-veyron): Add function to find veyron kernel config.
> * gnu/packages/aux-files/linux-libre/5.0-arm-veyron.conf
> * Makefile.am (AUX_FILES): Adjust accordingly.

[...]

> --- a/gnu/packages/linux.scm
> +++ b/gnu/packages/linux.scm
> @@ -253,6 +253,15 @@ for ARCH and optionally VARIANT, or #f if there is no 
> such configuration."
>   (file (string-append "linux-libre/" name)))
>  (search-auxiliary-file file)))
>  
> +;; FIXME: Merge with "kernel-config"
> +(define* (kernel-config-veyron arch #:key variant)
> +  "Return the absolute file name of the Linux-Libre build configuration file
> +for ARCH and optionally VARIANT, or #f if there is no such configuration."
> +  (let* ((name (string-append (if variant (string-append variant "-") "")
> +  (if (string=? "i386" arch) "i686" arch) 
> "-veyron.conf"))
> + (file (string-append "linux-libre/" name)))
> +(search-auxiliary-file file)))
> +
>  (define %default-extra-linux-options
>`(;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html
>  ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #t)
> @@ -471,6 +480,15 @@ It has been modified to remove all non-free binary 
> blobs.")
>  #:defconfig "multi_v7_defconfig"
>  #:extra-version "arm-generic"))
>  
> +(define-public linux-libre-arm-veyron
> +  (make-linux-libre %linux-libre-version
> +%linux-libre-hash
> +'("armhf-linux")
> +#:patches %linux-libre-5.0-patches
> +;; #:configuration-file (search-auxiliary-file 
> "/linux-libre/5.0-arm-veyron.conf")
> +#:configuration-file kernel-config-veyron
> +#:extra-version "arm-veyron"))
> +
>  (define-public linux-libre-arm-generic-4.19
>(make-linux-libre %linux-libre-4.19-version
>  %linux-libre-4.19-hash

Package file indexing

[Ludovic Courtès]

Hello,

Pierre Neidhardt  skribis:

> I haven't though through the details, but I am under the impression that the
> file listing could be retrieve with the same mechanism as "guix size", i.e. 
> from
> the substitute index.  I think it would work well on the build farm, without
> more complexity than just another entry to the substitute index.

‘guix size’ uses substitute info (“narinfos”) to determine the size of
store items that are unavailable locally.  However, there’s currently no
source of information for file indexes.

My suggestion would be to couple the distribution of file indexes with
the substitute mechanism: if you’ve authorized a given substitute
server, you’d also allow downloads of file lists signed by that server.

An index could look like, say, a list of store item/file pairs.  It
would grow very quickly, which may not be very practical.  ‘guix
publish’ could update that list every time it “bakes” a nar.

The daemon could have a special RPC: you give it a file name and it
returns a store item (or package+version?) or #f.  Internally it’d call
‘guix substitute’ to fetch the file index from the substitute server,
check its signature, cache it locally, and then look up the file.

You should look at how NixOS does it for its ‘command-not-found’ support
(I think it’s part of NixOS, not Nix).  IIRC they distribute an SQLite
database, but it’s a pretty ad-hoc mechanism without authentication.

Ludo’.

Re: Guix system cross-compile

[Ludovic Courtès]

Hi Mathieu,

Sorry for not replying earlier…

Mathieu Othacehe  skribis:

> I'm digging up the --target option topic for guix system. I'd like to be
> able at first to produce a cross-compiled disk-image as discussed here:
>
> https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00242.html
>
> Besides packages for whom cross-compilation is broken, I'm hitting a
> problem that seems to be described here:
>
> https://lists.gnu.org/archive/html/bug-guix/2017-08/msg00140.html
>
> when running:
>
> guix system disk-image --target=arm-linux-gnueabihf config.scm --no-grafts
>
> Something forces the cross-compilation of make-boot0 which isn't
> cross-compilable, even with grafting disabled (log attached).
>
> Any idea on how to investigate this?

[...]

> build of /gnu/store/nc2qbmv0c0mj7nflhpwjsvn3pqm4byab-make-boot0-4.2.1.drv 
> failed
> View build log at 
> '/var/log/guix/drvs/nc/2qbmv0c0mj7nflhpwjsvn3pqm4byab-make-boot0-4.2.1.drv.bz2'.
> cannot build derivation 
> `/gnu/store/27x086jl1pa585gjmbdrcki7szd5qc5s-bzip2-1.0.6.drv': 1 dependencies 
> couldn't be built
> cannot build derivation 
> `/gnu/store/qdcqcc1701j8jk6w80gafpp1mscpkiji-coreutils-8.30.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/791bb2j5yr74ad2h4f020lmnv8l9s0b2-diffutils-3.6.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/knwahdlrmhnig8s77gfmfcqj7zwxap6v-findutils-4.6.0.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/dgc8pkrnsf35zr9bj7j8vwfwvs7jd2xq-gawk-4.2.1.drv': 1 dependencies 
> couldn't be built
> cannot build derivation 
> `/gnu/store/q3yaljifyj5bcl4bbs78h7kj1fw7mv47-glibc-2.28.drv': 1 dependencies 
> couldn't be built
> cannot build derivation 
> `/gnu/store/8jm8bah8cqwpbmcb7g2x9h1whbfk6j0w-grep-3.1.drv': 1 dependencies 
> couldn't be built
> cannot build derivation 
> `/gnu/store/whsrmay3ddj2nifxvj8l7f2jqlil4vvy-gzip-1.9.drv': 1 dependencies 
> couldn't be built
> building /gnu/store/b0j18x8b8jgyq5s581s2qv6bsdb804k4-modprobe.drv...
> cannot build derivation 
> `/gnu/store/fh8xjdi7h8baqwhkhapldhfv62bbmda6-patch-2.7.6.drv': 1 dependencies 
> couldn't be built
> cannot build derivation 
> `/gnu/store/bb1l5zb19nva2kvxxwy2z6zs5z9zvmr4-sed-4.5.drv': 1 dependencies 
> couldn't be built
> cannot build derivation 
> `/gnu/store/qks66p38kj8vm99nr7qgpf26p57kbsb0-tar-1.30.drv': 1 dependencies 
> couldn't be built
> cannot build derivation 
> `/gnu/store/9kp8pl1whm0f6wi7mfmkrmkhrbi4k7il-xz-5.2.4.drv': 1 dependencies 
> couldn't be built
> cannot build derivation 
> `/gnu/store/mq8jaavjxmqfayfdwhvr4mxycw52wl6y-ca-certificate-bundle.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/bray04ln6qvpw7dd40li84i9k0v7mynx-fonts-dir.drv': 1 dependencies 
> couldn't be built
> cannot build derivation 
> `/gnu/store/s167zzl6h92k72xb2f06jg4ai20mcfqp-info-dir.drv': 1 dependencies 
> couldn't be built
> cannot build derivation 
> `/gnu/store/3fkw085xjia3p3gznk0hnw3rwn59992h-manual-database.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/vg73b8j47zgf71fg6547wa5hhz31v1l2-shepherd-nscd.scm.drv': 1 
> dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/pbbd2zbixzla23fijbznnaz09wfx047j-profile.drv': 1 dependencies 
> couldn't be built
> note: keeping build directory `/tmp/guix-build-modprobe.drv-6'
> cannot build derivation 
> `/gnu/store/nr5qprp6n0gggw2ym7cgn9pzwhjry9s1-shepherd.conf.drv': 1 
> dependencies couldn't be built
> building 
> /gnu/store/gnmiac4byjlr875lqy28fvndvkdfrpva-module-import-compiled.drv...
> cannot build derivation 
> `/gnu/store/qbwkrj7v4dgwzfh9cjizv9zgcmkpswnx-system.drv': 1 dependencies 
> couldn't be built
> note: keeping build directory `/tmp/guix-build-module-import-compiled.drv-6'
> cannot build derivation 
> `/gnu/store/l45gylnvs8cv2nd35i86z6nqg598x4kf-disk-image.drv': 1 dependencies 
> couldn't be built
> guix system: error: build of 
> `/gnu/store/l45gylnvs8cv2nd35i86z6nqg598x4kf-disk-image.drv' failed

Could you do it with --max-jobs=1 so we get a clearer view of the chain
of derivations that’s failing?

To test system cross-compilation, I suggest starting from a trimmed list
for the ‘packages’ list, smaller than ‘%base-packages’.

I’m guessing that all the packages added there with ‘canonical-package’
are the cause of the problem (‘make-boot0’ being cross-compiled.)  You
can reproduce this problem like this:

  guix build -e '(@@ (gnu packages commencement) coreutils-final)' \
--target=arm-linux-gnueabihf --no-grafts

(‘coreutils-final’ is the same as (canonical-package coreutils).)

So if you remove these, that should work.

HTH!

Ludo’.

Re: Feature requests

[Julien Lepiller]

Mh… so I'm still not sure if that's an actual issue. You can always install two 
software that rely on different versions of a library. I guess in your example 
it only means that we need two libc packages, right? As long as you're able to 
define a package recipe for everything you want, using different versions of 
the same package is fine, because they are different inputs, so they have a 
different store path.

A package built with glibc 2.10 well reference that old libc and never know 
about the newer ones even if they're installed in the same profile, as long as 
the libc is not a propagated-input.

I still don't see an incompatibility that's not solved by guix. With python 
packages however that's very different because inputs are propagated. If python 
could reference its dependencies directly, it would have been just fine, but 
indeed two incompatible dependencies will end up in your profile. We can wrap 
python software already though, so it ignores the environment and picks only 
the dependencies it was built with. That's not always the best solution though. 
Maybe you can give as a concrete example for the python case? Then we will be 
able to help you better and come up with the right solution for your problems :)

From what you describe I still think that guix environments are what you want: 
if you have python-foo and python-bar that both depend on incompatible versions 
of python-baz, you can create an environment for python-foo:

guix environment --ad-hoc python python-foo --pure

In which you can use python-foo but not python-bar, and a similar command will 
give you a similar environment where you can run python-bar but not python-foo.

If you suppose these python packages provide a foo and a bar command, you could 
also do:

alias bar=guix environment --ad-hoc python python-bar --pure -- bar

And the same for foo, and you would have isolated environments. You can also 
use that to control what python-foo has access to at runtime. For instance if 
it can use python-foobar at runtime, you would do:

alias foo=guix environment --ad-hoc python python-foo python-foobar --pure -- 
foo

And the foo command now has access to its runtime dependency (if it wasn't 
already declared at build time).

HTH

Le 23 mars 2019 15:01:24 GMT+01:00, Joshua Marshall  a 
écrit :
>I'm still getting my feet wet as it were.  As a more relatable example,
>lets use glibc.  Say an application developed in 2000 had bug
>compatibility
>with glibc at that time.  Then say that bug is fixed circa 2005 and
>another
>introduced.  Then have in 2010 an application made with bug
>compatibility
>for the 2005 version.  Now, if both of these applications were
>co-installed
>at most one could work due to bug compatibility.  Now I'm not saying
>this
>is good practice or even common, but this type of thing happens at my
>work
>frequently enough that we have a whole toolset dedicated to managing
>just
>this problem.  It gets far more severe in the python world.  To cope
>with
>such poorly behaved programs, greater levels of isolation are needed,
>like
>each individual thing running in its own Docker container.  But
>sometimes
>even this isn't enough as the dependencies will have a similar problem
>and
>so such isolation measures need to be recursively applied.  It gets
>messy.
>
>On Fri, Mar 22, 2019 at 6:30 PM Julien Lepiller 
>wrote:
>
>> Hi!
>>
>> I'm not sure what you mean when you talk about incompatible packages,
>> maybe you could give a concrete example? I don't think there's
>anyching
>> that couldn't go to the store at least… So you can always create
>separate
>> profiles.
>>
>> That said, I think people are working on improving the network
>support in
>> guix environment containers, and I think it's a good thing :). I'm
>not sure
>> about cgroups, but our environments already provide quite a bit of
>> isolation. Have you tried "guix environment --ad-hoc python
>--container"
>> for instance? There are more options to control what parts of the
>file
>> system is available inside the container.
>>
>> Le 22 mars 2019 18:47:19 GMT+01:00, Joshua Marshall
>
>> a écrit :
>>>
>>> Hello all,
>>>
>>> I was told in IRC to post my possibly unreasonable feature requests
>here.
>>>
>>> I've been thinking more on what Guix might be able to do, and what
>would
>>> make it more useful for a few of my past jobs.  I'd like to see it
>take on
>>> the ability to have a per-installation target cgroup, network
>namespace,
>>> and filesystem chroot settings set with defaults which are
>overridable at
>>> invocation.  In this way, a user could install and use packages with
>>> mutually incompatible dependencies (I talked about this with a few
>people
>>> on IRC) like what happens with python.  If this kind of
>functionality were
>>> added, it would largely supplant Docker, virtualenv, pip, poetry,
>apk,
>>> pacman, and probably a few other tools at my company which are there
>just
>>> to handle this kind of frailness.  From this, I could also see 

Re: Feature requests

[Joshua Marshall]

I'm still getting my feet wet as it were.  As a more relatable example,
lets use glibc.  Say an application developed in 2000 had bug compatibility
with glibc at that time.  Then say that bug is fixed circa 2005 and another
introduced.  Then have in 2010 an application made with bug compatibility
for the 2005 version.  Now, if both of these applications were co-installed
at most one could work due to bug compatibility.  Now I'm not saying this
is good practice or even common, but this type of thing happens at my work
frequently enough that we have a whole toolset dedicated to managing just
this problem.  It gets far more severe in the python world.  To cope with
such poorly behaved programs, greater levels of isolation are needed, like
each individual thing running in its own Docker container.  But sometimes
even this isn't enough as the dependencies will have a similar problem and
so such isolation measures need to be recursively applied.  It gets messy.

On Fri, Mar 22, 2019 at 6:30 PM Julien Lepiller  wrote:

> Hi!
>
> I'm not sure what you mean when you talk about incompatible packages,
> maybe you could give a concrete example? I don't think there's anyching
> that couldn't go to the store at least… So you can always create separate
> profiles.
>
> That said, I think people are working on improving the network support in
> guix environment containers, and I think it's a good thing :). I'm not sure
> about cgroups, but our environments already provide quite a bit of
> isolation. Have you tried "guix environment --ad-hoc python --container"
> for instance? There are more options to control what parts of the file
> system is available inside the container.
>
> Le 22 mars 2019 18:47:19 GMT+01:00, Joshua Marshall 
> a écrit :
>>
>> Hello all,
>>
>> I was told in IRC to post my possibly unreasonable feature requests here.
>>
>> I've been thinking more on what Guix might be able to do, and what would
>> make it more useful for a few of my past jobs.  I'd like to see it take on
>> the ability to have a per-installation target cgroup, network namespace,
>> and filesystem chroot settings set with defaults which are overridable at
>> invocation.  In this way, a user could install and use packages with
>> mutually incompatible dependencies (I talked about this with a few people
>> on IRC) like what happens with python.  If this kind of functionality were
>> added, it would largely supplant Docker, virtualenv, pip, poetry, apk,
>> pacman, and probably a few other tools at my company which are there just
>> to handle this kind of frailness.  From this, I could also see an entry
>> point to adding build module support to start to replace tools like Make,
>> CMake, Meson, Bazel, and so on.
>>
>> These expand the scope of Guix quite a bit, but I think these are needed
>> for it to really feel logically complete.  Does all this make sense?
>>
>>
>> Please be advised that this email may contain confidential information.
>> If you are not the intended recipient, please notify us by email by
>> replying to the sender and delete this message. The sender disclaims that
>> the content of this email constitutes an offer to enter into, or the
>> acceptance of, any agreement; provided that the foregoing does not
>> invalidate the binding effect of any digital or other electronic
>> reproduction of a manual signature that is included in any attachment.
>>
>> 
>> 
>> 
>>
>
> --
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma
> brièveté.
>

-- 



Please be advised that this email may contain confidential information. 
If you are not the intended recipient, please notify us by email by 
replying to the sender and delete this message. The sender disclaims that 
the content of this email constitutes an offer to enter into, or the 
acceptance of, any agreement; provided that the foregoing does not 
invalidate the binding effect of any digital or other electronic 
reproduction of a manual signature that is included in any attachment.