Re: fftwf tests running for 25+ hours - is this normal?

[Bengt Richter]

On +2019-10-14 20:46:01 -0700, Chris Marusich wrote:
> Hi,
> 
> I've been trying to reconfigure my system on my x200 laptop.  It's been
> a day or two, and I've found that my computer has spent the last 25
> hours running fftwf tests.  I know my laptop is rather weak (2 cores, 8
> GB of memory, an SSD) compared to most desktops today, but still, 25
> hours seems pretty long.
> 
> Guix is running
> 
>   make check -j 2
> 
> which ultimately calls
> 
>   perl -w ./check.pl -r -c=30 -v --nthreads=2 
> /tmp/guix-build-fftwf-3.3.8.drv-0/fftw-3.3.8/tests/bench
> 
> which calls
> 
>   /tmp/guix-build-fftwf-3.3.8.drv-0/fftw-3.3.8/tests/.libs/bench -o 
> nthreads=2 --verbose=1 --verify //obcd34320 [... a lot of arguments ...]
> 
> Despite the fact that "-j 2" was provided to make, only 1 CPU is pegged
> at 100% utilization.  I suppose I'll just wait and see what happens, but
> 25 hours feels very long.  It seems on ci.guix.gnu.org, the build times
> are generally less than 1 hour:
> 
>   https://ci.guix.gnu.org/search?query=fftwf
> 
> Is this normal, or should I kill the build and try again?  What kind of
> system is ci.guix.gnu.org building on (how many cores, how much memory)?
> 
> -- 
> Chris

Hi Chris,

Have you checked sensors for overheating that might induce CPU clock throttling?

That happened to me when I did guix pull; guix upgrade; and it got to doing 
racket,
which started out fast, but got really slow -- though it did finally crawl 
across
the finish line, and cooled off.

I guess it would show up in dmesg or journalctl -xe but I didn't look, sorry.

HTH
--
Regards,
Bengt Richter

fftwf tests running for 25+ hours - is this normal?

[Chris Marusich]

Hi,

I've been trying to reconfigure my system on my x200 laptop.  It's been
a day or two, and I've found that my computer has spent the last 25
hours running fftwf tests.  I know my laptop is rather weak (2 cores, 8
GB of memory, an SSD) compared to most desktops today, but still, 25
hours seems pretty long.

Guix is running

  make check -j 2

which ultimately calls

  perl -w ./check.pl -r -c=30 -v --nthreads=2 
/tmp/guix-build-fftwf-3.3.8.drv-0/fftw-3.3.8/tests/bench

which calls

  /tmp/guix-build-fftwf-3.3.8.drv-0/fftw-3.3.8/tests/.libs/bench -o nthreads=2 
--verbose=1 --verify //obcd34320 [... a lot of arguments ...]

Despite the fact that "-j 2" was provided to make, only 1 CPU is pegged
at 100% utilization.  I suppose I'll just wait and see what happens, but
25 hours feels very long.  It seems on ci.guix.gnu.org, the build times
are generally less than 1 hour:

  https://ci.guix.gnu.org/search?query=fftwf

Is this normal, or should I kill the build and try again?  What kind of
system is ci.guix.gnu.org building on (how many cores, how much memory)?

-- 
Chris


signature.asc
Description: PGP signature

Re: (Really) Free Software future

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

If systemD is be hard to replace, that is a kind of lock-in.  But it
isn't _vendor_ lock-in.  systemD, like most free software packages, is
not tied to any particular vendor.  Indeed, the usual concept of
"vendor" for free software is not applicable to free software at all.


-- 
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [completion] Completion scripts not loaded from ~/.guix-profile/etc/profile

[Maxim Cournoyer]

Hello,

YOANN P  writes:

> Hi guix,
>
> Not sure if it needs to be add to the guix documentation or directly included 
> in "~/.guix-profile/etc/profile" generation process, 
> but the completion scripts provided by packages seem not to be loaded.
> For example, if i only install the package "git", the completion scripts for 
> "git" reside in "~/.guix-profile/etc/bash_completion.d/git".
> But there is no loading instructions for those files in 
> "~/.guix-profile/etc/profile".
> So after sourcing "~/.guix-profile/etc/profile", a user need to loop over 
> files in "~/.guix-profile/etc/bash_completion.d/" 
> and "~/.guix-profile/share/bash-completion" to source them manually because 
> native bash/bash-completion from the user distribution 
> are not aware of the new completion scripts available in 
> "~/.guix-profile/etc/bash_completion.d/" and  
> "~/.guix-profile/share/bash-completion".
>
> I think a "bash loop" need to be added for this purpose in the generation of 
> "~/.guix-profile/etc/profile" and in the meantime add a section for this
> inside "2.6 Application Setup" section be cause i didn't find any 
> instructions about this on the documentation.
>
> Regards,
> Yoann

I think was is needed is to install the 'bash-completion' package.  On
the Guix System, this is was gets run at login (/etc/profile, which
sources /etc/bashrc):

--8<---cut here---start->8---
# The 'bash-completion' package.
if [ -f /run/current-system/profile/etc/profile.d/bash_completion.sh ]
then
  # Bash-completion sources ~/.bash_completion.  It installs a dynamic
  # completion loader that searches its own completion files as well
  # as those in ~/.guix-profile and /run/current-system/profile.
  source /run/current-system/profile/etc/profile.d/bash_completion.sh
fi
--8<---cut here---end--->8---

I also have this line in my ~/.bashrc, and IIRC it was useful in getting
the completion to work (not sure if it's required anymore):

--8<---cut here---start->8---
# Source the system-wide file.
source /etc/bashrc
--8<---cut here---end--->8---

HTH,

Maxim

Re: 'core-updates' Q4 2019

[Kei Kebreau]

Ludovic Courtès  writes:

> Hello Kei,
>
> Kei Kebreau  skribis:
>
>> I have the GNOME 3.32 branch! I'm building it on top of the new
>> core-updates as you read this message. If everything still builds, I'll
>> immediately send my changes to the guix-patches mailing list for review
>> and testing.
>
> Shouldn’t you instead base it on ‘master’ or ‘staging’?
>
> That may allow us to merge it more quickly, especially if these are only
> GNOME-related changes.
>
> Thanks for working on it!
>
> Ludo’.

Hi Ludovic,

Taken individually, most changes on the GNOME 3.32 branch could be
pushed to master without too much trouble. The only issues are big changes like
upgrading Vala. The following changes would cause a large number of
rebuilds:

At least 300 rebuilds: python-pygobject, gtk+

At least 1200 rebuilds: gtk-doc, vala, yelp-tools, python-parameterized,
python-check-manifest, python-anytree

I'll minimize the changes, isolate what I can, and submit the results
for review as time allows!

Thanks,
Kei


signature.asc
Description: PGP signature

Re: Joint statement on the GNU Project

[Wilson Bustos]

> You miss how any GNU project works. The key point is the do-ocracy:
> the people who are currently doing decide how they want to do.

I'm completely agree with you, that is why I didn't say to anyone what
should they do or not,
That is also why I accept the female-grammar in that moment. (When I
thought that grammar is about
an attempt to include people, a bad attempt, but an attempt after all).

So what I said in this discussion?
well, I said that in my opinion change a language's rules to fit your
politics because you feel the normal language is offensive,is actually
extreme.

Why I said that?
because now with all that you do, including cancel stallman for his
opinions seems a strongly feminist movement and the translation is one of
the
form in how the feminist movement get expression in this project.

Should I be a contributor to give my opinion?
I think no, that is just my opinion.

> I will be happy to share with you some tips about translation.
I would be happy to, but I will look for a non-feminist project to help,
that is also the reason because I didn't text anything in the guix list the
last 2 days,
and I didn't want to text anything in this list again, because do it would
be not productive for anyone and now I text only because you start to talk
about me.


All the best,
Wilson


El lun., 14 oct. 2019 a las 14:13, zimoun ()
escribió:

> On Mon, 14 Oct 2019 at 18:14, Wilson Bustos  wrote:
>
> > That makes me feel uncomfortable with this project and I'm also sure
> that the same is what happen with a lot of more persons.
> > I'm an example about how a persons who wanted to help to this project
> feels disagree with your path and get regret to do it.
>
> You miss how any GNU project works. The key point is the do-ocracy:
> the people who are currently doing decide how they want to do.
>
> Therefore, please discuss, correct and commit change to the
> Translation Project (TP). As you can see, the TP is not only about GNU
> Guix and the Spanish team translates a lot of packages.
>
> https://translationproject.org/team/es.html
>
> Instead of being so angry (state), please propose concrete changes
> (action).
>
> Any GNU project does not exist by itself but because people are doing.
>
>
> > Anyway you seems happy to see how someone that wanted to collaborate at
> the end didn't do it,
>
> Talk is cheap. Show me the code -- Linus Torvalds
>
>
> > Thank you so much for your support ;)
>
> I will be happy to share with you some tips about translation.
>
>
> All the best,
> simon
>

Performance improvements

[Ludovic Courtès]

Hello Guix!

I just wanted to share that recent commits have improved the performance
of ‘package-derivation’ and related operations quite a bit:

  8f417ed280 gnu: commencement: Further optimize the package object graph.
  f618134e4c build-system/gnu: 'package-with-explicit-inputs' uses 
'package-mapping'.
  dab669e075 gnu: ld-wrapper: Memoize.
  099dbc4fd3 gnu: Improve memoization of 'package-with-bootstrap-guile'.
  99b73d0f0c gnu: commencement: Reduce the graph of package objects.
  9a45a24f7f gnu: Remove unnecessary uses of 'package-with-bootstrap-guile'.

What these commits do is that they greatly reduce the graph of 
objects built in ‘commencement.scm’.  As a result, there’s much less
work to do, less code to run, less stuff to memoize, all that.  :-)

Before these changes, if you’d run, say:

  guix graph -e '(@@ (gnu packages commencement) gnu-make-final)'

you’d see the  graph was huge and had a weird shape.  Indeed,
many parts were duplicated as a consequence of graph rewriting.  That’s
not news, but it became more visible with the reduced binary seed
boostrap, which adds quite a few nodes and edges.

The commit logs have more details, but the take-away is:

--8<---cut here---start->8---
$ time /var/guix/profiles/per-user/ludo/current-guix-109-link/bin/guix build 
libreoffice -nd
/gnu/store/7whsss0gn7h4dqvz627sq3i4cb1qlc1v-libreoffice-6.1.5.2.drv

real0m3.238s
user0m3.693s
sys 0m0.047s
$ time guix build libreoffice -nd
/gnu/store/8drmbhsrayr2j5lkvrwq37rg8g06hgsw-libreoffice-6.1.5.2.drv

real0m2.142s
user0m2.323s
sys 0m0.082s
$ guix describe
Generacio 110   Oct 14 2019 08:43:33(nuna)
  guix bd04fe8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: bd04fe878627a14533d908ccdf5b906050d6e0a4
--8<---cut here---end--->8---

I think we need to aim for 1s, but that’s already a good step.

Ludo’.

Re: Unikernel build and deploy systems?

[Ludovic Courtès]

Hi John,

John Soo  skribis:

> I have a more conceptual question than technical. I am really curious
> about unikernels and I know there is work to support the Hurd. So my
> thinking is: would it be possible to make a build and deployment
> system for unikernels? Advantages I see coming from guix are
> provenance tracking built in, a growing support for deployment systems
> and standardized build environments and steps. Major caveats are that
> I’m quite unfamiliar with virtualization technology and
> unikernels. They just are so tempting to me.

I agree that conceptually the two ideas work well together: if you could
declare what your unikernel contains and have it built and deployed in a
reproducible fashion, that’d be neat.

Now, there’s quite some distance between theory and practice, so…  :-)

Ludo’.

Re: (Really) Free Software future

[Stefan Huchler]

Hi,

isn't that what basically every Developer does? If I write a program and
it's elisp there is only as far as I know one interpreter and all libs I
use are also not replacable without rewriting code.

So is all my programmes I ever wrote also not Free software because it's
not based on some very primitive Kernel Systemcalls (that have to be
then not even linux specific right? Then 99% of GPL software out there
would not really be free software.

So that A only runs with B seems no good Definition you would have to
provide some other definition that makes Gnome here a special case.

I assume you would bring up that a DE is some sort of base level
software that is no application layer software in itself but part of a
Operation System, like the UI in Windows is also considered part of the
OS?

I could see that argument if Gnome would be the only grafical
environment for Linux in existence, and even then I wonder what's the
problem with rewriting it to run without systemd?

It's like saying a software that has not my wished Feature A / B / C is
not free software. But we don't meassure freedom in how much and which
features a software has.

Sorry to interject that discussion but maybe that is helpful?

 writes:

> But that is achieved with forks of systemd tools and messing with the source 
> code.
> How does that make GNOME independent from Systemd?
>
> Fannys
>
> Oct 14, 2019, 20:59 by jgibbons2...@gmail.com:
>
>  On Mon, 2019-10-14 at 21:32 +0300, Alexander Vdolainen wrote:
>
>  Hi,
>
>  On 10/14/19 9:16 PM, Paul Smith wrote:
>  > On Mon, 2019-10-14 at 18:52 +0200, Svante Signell wrote:
>  > > On Mon, 2019-10-14 at 12:13 -0400, Paul Smith wrote:
>  > > > On Mon, 2019-10-14 at 12:07 +0200, Svante Signell wrote:
>
>  (skipped)
>
>  > For example, no aspect of either GNOME or systemd are proprietary,
>  > using the common meaning of the term. Also, "lock-in" usually refers
>  > to software that prevents users from switching to an alternative; GNOME
>  > and systemd are certainly not lock-in.
>
>  I'm afraid but I cannot agree with that. Actually with systemd design
>  you have 'lock-in', because in some cases you need to modify a source
>  code to support systemd (or you will face something like this -
>  
> https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions).
>  Also, a lot of system daemons has eaten by systemd (and to make it works
>  some forks were created like eudev).
>  Finally, correct me if I wrong, but GNOME 3.8 and newer requires systemd
>  to run, it's a lock-in isn't it ?
>
>  I'm assuming by GNOME you mean gnome-shell. Please let me know if I'm
>  incorrect.
>
>  Guix has packaged gnome-shell 3.30.2 but has not packaged systemd.
>  If systemd was a requirement for gnome-shell guix would have had to package
>  systemd in order for gnome-shell to compile and/or work, by definition of
>  requirement.
>  gnome-shell builds and works just fine in guix.
>  It follows that systemd is not a prerequisite for gnome-shell 3.30.2.
>
>  Please consider this a friendly correction :)

Re: (Really) Free Software future

[Paul Smith]

On Mon, 2019-10-14 at 18:52 +0200, Svante Signell wrote:
> On Mon, 2019-10-14 at 12:13 -0400, Paul Smith wrote:
> > On Mon, 2019-10-14 at 12:07 +0200, Svante Signell wrote:
> > > Perhaps we should divide free software into two groups: 1) Really
> > > free software where Freedom 1 applies and 2) not-so-free software
> > > where Freedom 1 does no longer applies.
> > > 
> > > Here gnome and systemd are in the second kind.
> > 
> > Both GNOME and systemd are fully free software that support all four
> > freedoms, including freedom 1.
> 
> Still, I think we need to differentiate between Really Free Software
> and Not-So-Free Software. Maybe even to add one more freedom: For
> example adding a, non-commercial, non-lock-in, non-proprietary, *NIX
> and KISS-friendly, clause. Software development is nowadays too vendor
> driven (and purposely made complicated), ruling out contributions from
> people not employed by companies working full-time. 

It's not clear (to me at least) what distinction you're hoping to make
between "Really Free" and "Not-So-Free".  Perhaps you could provide an
initial attempt at a set of criteria by which software would become
"Really Free", and discuss why GNOME and systemd don't meet those
criteria.  Until that happens I don't see what sort of reply RMS could
give.

Most likely such a discussion should be moved to gnu-misc-discuss: I
don't think it belongs on either of the current two mailing lists
until/unless there's an actionable outcome.

For example, no aspect of either GNOME or systemd are proprietary,
using the common meaning of the term.  Also, "lock-in" usually refers
to software that prevents users from switching to an alternative; GNOME
and systemd are certainly not lock-in.

A non-commercial clause is directly opposed to the four freedoms (in
particular freedom 0).  In fact a number of otherwise-could-be-free
software licenses have been deemed non-free solely for this type of
thing.  Unless I misunderstand what you mean by "non-commercial
clause".

I don't think it's appropriate to state that software that doesn't
follow KISS can be considered non-free... how does one even measure
that?  By whose definition is software not "simple"?  Many people would
suggest that GCC, glibc, Emacs, or other flagship GNU packages are not
"KISS".  Similarly, there's no concrete definition of "*NIX principles"
that one can use.  Who will decide?  Again many people would suggest
Emacs, with its "editor as an OS interface" construction, doesn't
follow *NIX principles.  I don't see how these criteria can be used to
measure software freedoms, other than by each person individually
according to their own tastes.

As with all free software, if someone feels that some software is not
KISS (enough) or not *NIX (enough), they can avail themselves of their
four freedoms and modify that software as they like, and distribute it
to anyone else they like.

Re: (Really) Free Software future

[Paul Smith]

On Mon, 2019-10-14 at 21:32 +0300, Alexander Vdolainen wrote:
> > For example, no aspect of either GNOME or systemd are proprietary,
> > using the common meaning of the term.  Also, "lock-in" usually refers
> > to software that prevents users from switching to an alternative; GNOME
> > and systemd are certainly not lock-in.
> 
> I'm afraid but I cannot agree with that. Actually with systemd design
> you have 'lock-in', because in some cases you need to modify a source
> code to support systemd (or you will face something like this -
> https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions).

It's not lock-in because you don't have to use systemd.  You can take a
system that currently uses systemd and you can remove it and replace it
with something else.  It may be more or less effort, depending, but you
_can_ do it, without violating licenses or losing access to any of your
personal data.

If you consider systemd "lock-in" then you *must* consider something
like GNU libc "lock-in"; it's far more difficult to replace your libc
than it is to switch away from systemd!

> Finally, correct me if I wrong, but GNOME 3.8 and newer requires
> systemd to run, it's a lock-in isn't it ?

No, because you don't need to run GNOME.  You can't consider software
"lock-in" just because it requires some other software, as long as you
don't have to use either one.  And you can't consider some software
non-free just because it requires other free software: a large majority
of free programs out there rely on some other free libraries for
example.

Anyway, as I said this thread should be moved to gnu-misc-discuss.

Re: (Really) Free Software future

[marinus.savoritias]

But that is achieved with forks of systemd tools and messing with the source 
code.
How does that make GNOME independent from Systemd?

Fannys

Oct 14, 2019, 20:59 by jgibbons2...@gmail.com:

> On Mon, 2019-10-14 at 21:32 +0300, Alexander Vdolainen wrote:
>
>> Hi,
>>
>> On 10/14/19 9:16 PM, Paul Smith wrote:
>> > On Mon, 2019-10-14 at 18:52 +0200, Svante Signell wrote:
>> > > On Mon, 2019-10-14 at 12:13 -0400, Paul Smith wrote:
>> > > > On Mon, 2019-10-14 at 12:07 +0200, Svante Signell wrote:
>>
>> (skipped)
>>
>> > For example, no aspect of either GNOME or systemd are proprietary,
>> > using the common meaning of the term.  Also, "lock-in" usually refers
>> > to software that prevents users from switching to an alternative; GNOME
>> > and systemd are certainly not lock-in.
>>
>> I'm afraid but I cannot agree with that. Actually with systemd design
>> you have 'lock-in', because in some cases you need to modify a source
>> code to support systemd (or you will face something like this -
>> https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions).
>> Also, a lot of system daemons has eaten by systemd (and to make it works
>> some forks were created like eudev).
>> Finally, correct me if I wrong, but GNOME 3.8 and newer requires systemd
>> to run, it's a lock-in isn't it ?
>>
> I'm assuming by GNOME you mean gnome-shell. Please let me know if I'm
> incorrect.
>
> Guix has packaged gnome-shell 3.30.2 but has not packaged systemd.
> If systemd was a requirement for gnome-shell guix would have had to package
> systemd in order for gnome-shell to compile and/or work, by definition of
> requirement.
> gnome-shell builds and works just fine in guix.
> It follows that systemd is not a prerequisite for gnome-shell 3.30.2.
>
> Please consider this a friendly correction :)
>

Re: (Really) Free Software future

[Alexander Vdolainen]

On 10/14/19 10:11 PM, Paul Smith wrote:
> On Mon, 2019-10-14 at 21:32 +0300, Alexander Vdolainen wrote:
>>> For example, no aspect of either GNOME or systemd are proprietary,
>>> using the common meaning of the term.  Also, "lock-in" usually refers
>>> to software that prevents users from switching to an alternative; GNOME
>>> and systemd are certainly not lock-in.
>>
>> I'm afraid but I cannot agree with that. Actually with systemd design
>> you have 'lock-in', because in some cases you need to modify a source
>> code to support systemd (or you will face something like this -
>> https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions).
> 
> It's not lock-in because you don't have to use systemd.  You can take a
> system that currently uses systemd and you can remove it and replace it
> with something else.  It may be more or less effort, depending, but you
> _can_ do it, without violating licenses or losing access to any of your
> personal data.

Also I _can_ write a new kernel using existing code base...

> 
> If you consider systemd "lock-in" then you *must* consider something
> like GNU libc "lock-in"; it's far more difficult to replace your libc
> than it is to switch away from systemd!

uclibc, musl ... but GNU libc doesn't require software to make some
modifications - that's the point.

> 
>> Finally, correct me if I wrong, but GNOME 3.8 and newer requires
>> systemd to run, it's a lock-in isn't it ?
> 
> No, because you don't need to run GNOME.  You can't consider software
> "lock-in" just because it requires some other software, as long as you
> don't have to use either one.  And you can't consider some software
> non-free just because it requires other free software: a large majority
> of free programs out there rely on some other free libraries for
> example.

yep

> 
> Anyway, as I said this thread should be moved to gnu-misc-discuss.

ok, let's move it on.

> 

-- 
Alexander Vdolainen,
Evil contractor.



signature.asc
Description: OpenPGP digital signature

Re: (Really) Free Software future

[Alexander Vdolainen]

Hi again,

On 10/14/19 9:59 PM, Jesse Gibbons wrote:
> On Mon, 2019-10-14 at 21:32 +0300, Alexander Vdolainen wrote:
>> Hi,
>>
>> On 10/14/19 9:16 PM, Paul Smith wrote:
>>> On Mon, 2019-10-14 at 18:52 +0200, Svante Signell wrote:
 On Mon, 2019-10-14 at 12:13 -0400, Paul Smith wrote:
> On Mon, 2019-10-14 at 12:07 +0200, Svante Signell wrote:
>>
>> (skipped)
>>
>>> For example, no aspect of either GNOME or systemd are proprietary,
>>> using the common meaning of the term.  Also, "lock-in" usually refers
>>> to software that prevents users from switching to an alternative; GNOME
>>> and systemd are certainly not lock-in.
>>
>> I'm afraid but I cannot agree with that. Actually with systemd design
>> you have 'lock-in', because in some cases you need to modify a source
>> code to support systemd (or you will face something like this -
>> https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions).
>> Also, a lot of system daemons has eaten by systemd (and to make it works
>> some forks were created like eudev).
>> Finally, correct me if I wrong, but GNOME 3.8 and newer requires systemd
>> to run, it's a lock-in isn't it ?
> I'm assuming by GNOME you mean gnome-shell. Please let me know if I'm
> incorrect.

yep.

> 
> Guix has packaged gnome-shell 3.30.2 but has not packaged systemd.
> If systemd was a requirement for gnome-shell guix would have had to package
> systemd in order for gnome-shell to compile and/or work, by definition of
> requirement.
> gnome-shell builds and works just fine in guix.

it's a good point. But as I understood a special fork of logind (elogind
or something similar required).

> It follows that systemd is not a prerequisite for gnome-shell 3.30.2.

yep, you can emulate it somehow :) but, I'm just happy without gnome,
let's assume 'gnome case' isn't a lock-in.

> 
> Please consider this a friendly correction :)

ok, got it :)

> 

-- 
Alexander Vdolainen,
Evil contractor.



signature.asc
Description: OpenPGP digital signature

Re: (Really) Free Software future

[marinus.savoritias]

Systemd is Free Software no doubt but, it is vendor lockin. GNOME too. 
They are because:
1) systemd has absorbed many things like udev which are important for all 
distros into their own project. Thus you have to "extract" it. 
2) I would argue that you can't replace systemd on the fly. On gentoo you had 
specific use-flags for systemd to make things work. 
3) The Elogind situation. GNOME depends on systemd features for anything they 
want. Because of that GNOME makes it hell for other distros to use the 
environment without Systemd. 

Now I understand that you have the choice not to use systemd or GNOME. In the 
case of the first though you have to use obscure distros with specific flags 
and packages and hacks. Often behind on other packages which depend on it. The 
second one is kind of ironic that it is GNU in my opinion. Since they don't use 
many GNU tools anymore or even the acronym for that matter. The lock-in for 
GNOME is that they have a predetermined set of tools they want you to use. You 
can't pick and choose easily without advanced configurations.

Fannys.

Oct 14, 2019, 20:16 by psm...@gnu.org:

> On Mon, 2019-10-14 at 18:52 +0200, Svante Signell wrote:
>
>> On Mon, 2019-10-14 at 12:13 -0400, Paul Smith wrote:
>> > On Mon, 2019-10-14 at 12:07 +0200, Svante Signell wrote:
>> > > Perhaps we should divide free software into two groups: 1) Really
>> > > free software where Freedom 1 applies and 2) not-so-free software
>> > > where Freedom 1 does no longer applies.
>> > > 
>> > > Here gnome and systemd are in the second kind.
>> > 
>> > Both GNOME and systemd are fully free software that support all four
>> > freedoms, including freedom 1.
>>
>> Still, I think we need to differentiate between Really Free Software
>> and Not-So-Free Software. Maybe even to add one more freedom: For
>> example adding a, non-commercial, non-lock-in, non-proprietary, *NIX
>> and KISS-friendly, clause. Software development is nowadays too vendor
>> driven (and purposely made complicated), ruling out contributions from
>> people not employed by companies working full-time.
>>
>
> It's not clear (to me at least) what distinction you're hoping to make
> between "Really Free" and "Not-So-Free".  Perhaps you could provide an
> initial attempt at a set of criteria by which software would become
> "Really Free", and discuss why GNOME and systemd don't meet those
> criteria.  Until that happens I don't see what sort of reply RMS could
> give.
>
> Most likely such a discussion should be moved to gnu-misc-discuss: I
> don't think it belongs on either of the current two mailing lists
> until/unless there's an actionable outcome.
>
> For example, no aspect of either GNOME or systemd are proprietary,
> using the common meaning of the term.  Also, "lock-in" usually refers
> to software that prevents users from switching to an alternative; GNOME
> and systemd are certainly not lock-in.
> A non-commercial clause is directly opposed to the four freedoms (in
> particular freedom 0).  In fact a number of otherwise-could-be-free
> software licenses have been deemed non-free solely for this type of
> thing.  Unless I misunderstand what you mean by "non-commercial
> clause".
>
> I don't think it's appropriate to state that software that doesn't
> follow KISS can be considered non-free... how does one even measure
> that?  By whose definition is software not "simple"?  Many people would
> suggest that GCC, glibc, Emacs, or other flagship GNU packages are not
> "KISS".  Similarly, there's no concrete definition of "*NIX principles"
> that one can use.  Who will decide?  Again many people would suggest
> Emacs, with its "editor as an OS interface" construction, doesn't
> follow *NIX principles.  I don't see how these criteria can be used to
> measure software freedoms, other than by each person individually
> according to their own tastes.
>
> As with all free software, if someone feels that some software is not
> KISS (enough) or not *NIX (enough), they can avail themselves of their
> four freedoms and modify that software as they like, and distribute it
> to anyone else they like.
>

Re: (Really) Free Software future

[Jesse Gibbons]

On Mon, 2019-10-14 at 21:32 +0300, Alexander Vdolainen wrote:
> Hi,
> 
> On 10/14/19 9:16 PM, Paul Smith wrote:
> > On Mon, 2019-10-14 at 18:52 +0200, Svante Signell wrote:
> > > On Mon, 2019-10-14 at 12:13 -0400, Paul Smith wrote:
> > > > On Mon, 2019-10-14 at 12:07 +0200, Svante Signell wrote:
> 
> (skipped)
> 
> > For example, no aspect of either GNOME or systemd are proprietary,
> > using the common meaning of the term.  Also, "lock-in" usually refers
> > to software that prevents users from switching to an alternative; GNOME
> > and systemd are certainly not lock-in.
> 
> I'm afraid but I cannot agree with that. Actually with systemd design
> you have 'lock-in', because in some cases you need to modify a source
> code to support systemd (or you will face something like this -
> https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions).
> Also, a lot of system daemons has eaten by systemd (and to make it works
> some forks were created like eudev).
> Finally, correct me if I wrong, but GNOME 3.8 and newer requires systemd
> to run, it's a lock-in isn't it ?
I'm assuming by GNOME you mean gnome-shell. Please let me know if I'm
incorrect.

Guix has packaged gnome-shell 3.30.2 but has not packaged systemd.
If systemd was a requirement for gnome-shell guix would have had to package
systemd in order for gnome-shell to compile and/or work, by definition of
requirement.
gnome-shell builds and works just fine in guix.
It follows that systemd is not a prerequisite for gnome-shell 3.30.2.

Please consider this a friendly correction :)

Re: (Really) Free Software future

[Jesse Gibbons]

On Mon, 2019-10-14 at 18:52 +0200, Svante Signell wrote:
> On Mon, 2019-10-14 at 12:13 -0400, Paul Smith wrote:
> > On Mon, 2019-10-14 at 12:07 +0200, Svante Signell wrote:
> > > Perhaps we should divide free software into two groups: 1) Really
> > > free software where Freedom 1 applies and 2) not-so-free software
> > > where Freedom 1 does no longer applies.
> > > 
> > > Here gnome and systemd are in the second kind.
> > 
> > Both GNOME and systemd are fully free software that support all four
> > freedoms, including freedom 1.
> 
> Still, I think we need to differentiate between Really Free Software
> and Not-So-Free Software. Maybe even to add one more freedom: For
> example adding a, non-commercial, non-lock-in, non-proprietary, *NIX
> and KISS-friendly, clause. Software development is nowadays too vendor
> driven (and purposely made complicated), ruling out contributions from
> people not employed by companies working full-time. 
> 
> > > Especially systemd, even if GPLed, is currently swallowing most of
> > > free software excluding large groups of people to make
> > > contributions.
> > 
> > Neither excluding upstream contributions nor "swallowing" other free
> > software projects violate any of the four freedoms.
> > 
> > As long as you are able to run the program, access the source code,
> > modify the source code as you like, and distribute both the original
> > and your modifications to others, then your freedoms are preserved.
> 
> See above. A redefinition of free software is really needed,
> independent of RMS being leader of GNU or not. And funding for Really
> Free Software can be steered by FSF towards the goal of Really Free
> Software, leaving non-complying companies out of funding. (whoever will
> take the lead of FSF after RMS).
> 
> I'd really like RMS to reply on these issues, adding him to this email
> recipients too.
> 
> Thanks!
> 

Free software is about end-user freedom, and has nothing to do with the
ability to push upstream. The distinction "really free" vs "not so free"
looks to me like an appeal to purity[0].

[0] https://en.wikipedia.org/wiki/No_true_Scotsman


I no longer see how this is relevant to guix-devel.

Re: (Really) Free Software future

[Alexander Vdolainen]

Hi,

On 10/14/19 9:16 PM, Paul Smith wrote:
> On Mon, 2019-10-14 at 18:52 +0200, Svante Signell wrote:
>> On Mon, 2019-10-14 at 12:13 -0400, Paul Smith wrote:
>>> On Mon, 2019-10-14 at 12:07 +0200, Svante Signell wrote:

(skipped)

> For example, no aspect of either GNOME or systemd are proprietary,
> using the common meaning of the term.  Also, "lock-in" usually refers
> to software that prevents users from switching to an alternative; GNOME
> and systemd are certainly not lock-in.

I'm afraid but I cannot agree with that. Actually with systemd design
you have 'lock-in', because in some cases you need to modify a source
code to support systemd (or you will face something like this -
https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions).
Also, a lot of system daemons has eaten by systemd (and to make it works
some forks were created like eudev).
Finally, correct me if I wrong, but GNOME 3.8 and newer requires systemd
to run, it's a lock-in isn't it ?

> 
> A non-commercial clause is directly opposed to the four freedoms (in
> particular freedom 0).  In fact a number of otherwise-could-be-free
> software licenses have been deemed non-free solely for this type of
> thing.  Unless I misunderstand what you mean by "non-commercial
> clause".
> 
> I don't think it's appropriate to state that software that doesn't
> follow KISS can be considered non-free... how does one even measure
> that?  By whose definition is software not "simple"?  Many people would
> suggest that GCC, glibc, Emacs, or other flagship GNU packages are not
> "KISS".  Similarly, there's no concrete definition of "*NIX principles"
> that one can use.  Who will decide?  Again many people would suggest
> Emacs, with its "editor as an OS interface" construction, doesn't
> follow *NIX principles.  I don't see how these criteria can be used to
> measure software freedoms, other than by each person individually
> according to their own tastes.
> 
> As with all free software, if someone feels that some software is not
> KISS (enough) or not *NIX (enough), they can avail themselves of their
> four freedoms and modify that software as they like, and distribute it
> to anyone else they like.
> 
> 
> 

-- 
Alexander Vdolainen,
Evil contractor.



signature.asc
Description: OpenPGP digital signature

Unikernel build and deploy systems?

[John Soo]

Hi guix!

I have a more conceptual question than technical. I am really curious about 
unikernels and I know there is work to support the Hurd. So my thinking is: 
would it be possible to make a build and deployment system for unikernels? 
Advantages I see coming from guix are provenance tracking built in, a growing 
support for deployment systems and standardized build environments and steps. 
Major caveats are that I’m quite unfamiliar with virtualization technology and 
unikernels. They just are so tempting to me. 

Thanks!

John

Re: (Really) Free Software future

[Svante Signell]

On Mon, 2019-10-14 at 12:13 -0400, Paul Smith wrote:
> On Mon, 2019-10-14 at 12:07 +0200, Svante Signell wrote:
> > Perhaps we should divide free software into two groups: 1) Really
> > free software where Freedom 1 applies and 2) not-so-free software
> > where Freedom 1 does no longer applies.
> > 
> > Here gnome and systemd are in the second kind.
> 
> Both GNOME and systemd are fully free software that support all four
> freedoms, including freedom 1.

Still, I think we need to differentiate between Really Free Software
and Not-So-Free Software. Maybe even to add one more freedom: For
example adding a, non-commercial, non-lock-in, non-proprietary, *NIX
and KISS-friendly, clause. Software development is nowadays too vendor
driven (and purposely made complicated), ruling out contributions from
people not employed by companies working full-time. 

> > Especially systemd, even if GPLed, is currently swallowing most of
> > free software excluding large groups of people to make
> > contributions.
> 
> Neither excluding upstream contributions nor "swallowing" other free
> software projects violate any of the four freedoms.
> 
> As long as you are able to run the program, access the source code,
> modify the source code as you like, and distribute both the original
> and your modifications to others, then your freedoms are preserved.

See above. A redefinition of free software is really needed,
independent of RMS being leader of GNU or not. And funding for Really
Free Software can be steered by FSF towards the goal of Really Free
Software, leaving non-complying companies out of funding. (whoever will
take the lead of FSF after RMS).

I'd really like RMS to reply on these issues, adding him to this email
recipients too.

Thanks!

Re: Joint statement on the GNU Project

[zimoun]

On Mon, 14 Oct 2019 at 18:14, Wilson Bustos  wrote:

> That makes me feel uncomfortable with this project and I'm also sure that the 
> same is what happen with a lot of more persons.
> I'm an example about how a persons who wanted to help to this project feels 
> disagree with your path and get regret to do it.

You miss how any GNU project works. The key point is the do-ocracy:
the people who are currently doing decide how they want to do.

Therefore, please discuss, correct and commit change to the
Translation Project (TP). As you can see, the TP is not only about GNU
Guix and the Spanish team translates a lot of packages.

https://translationproject.org/team/es.html

Instead of being so angry (state), please propose concrete changes (action).

Any GNU project does not exist by itself but because people are doing.


> Anyway you seems happy to see how someone that wanted to collaborate at the 
> end didn't do it,

Talk is cheap. Show me the code -- Linus Torvalds


> Thank you so much for your support ;)

I will be happy to share with you some tips about translation.


All the best,
simon

Re: Reminder to keep posts on topic

[Ricardo Wurmus]

Hi Mikhail,

> Then, please, apply the same standards to yourself as you demand of
> others and remove the off-topic statement from the Guix website.  Doing
> so would not, of course, automatically invalidate the message of the
> statement, which is a separate issue that, I agree, should be discussed
> elsewhere.

I’m not playing this game.  Please refrain from using guix-devel for
discussions that do not pertain to the development of Guix.

People who repeatedly ignore these requests will be put on moderation.

--
Ricardo

Re: (Really) Free Software future Was: Re: Proposal to remove the off-topic, ...

[Paul Smith]

On Mon, 2019-10-14 at 12:07 +0200, Svante Signell wrote:
> Perhaps we should divide free software into two groups: 1) Really
> free software where Freedom 1 applies and 2) not-so-free software
> where Freedom 1 does no longer applies.
> 
> Here gnome and systemd are in the second kind.

Both GNOME and systemd are fully free software that support all four
freedoms, including freedom 1.

> Especially systemd, even if GPLed, is currently swallowing most of
> free software excluding large groups of people to make contributions.

Neither excluding upstream contributions nor "swallowing" other free
software projects violate any of the four freedoms.

As long as you are able to run the program, access the source code,
modify the source code as you like, and distribute both the original
and your modifications to others, then your freedoms are preserved.

Re: Joint statement on the GNU Project

[Wilson Bustos]

I explain in my answer my reasons,
For me if is about collaboration, I'll do it anyway even if I'm totally
disagree with the gender politics and I was completely clear in my message,
In the same message I said that Is more important is have an Spanish
version that have nothing at all, even if that Spanish version is a
feminist version,
because once it is finish in the future is possible fix it for a normal
spanish.

And in my free time I was learning about how to translate those text, and I
started fixing the un-correct spanish for myself,
(I understand also I cannot send that fixed-spanish to the project because
you will reject it).

And I still was on the way to translate the other part of english to
political-correct-spanish to collaborate with you.
So as you can see even if I was completely disagree with your ideas I
wanted to help (as I shows you in my message),
But all that you did lastly shows how much your politics are inside the
project even before what you do to Stallman.

That makes me feel uncomfortable with this project and I'm also sure that
the same is what happen with a lot of more persons.
I'm an example about how a persons who wanted to help to this project feels
disagree with your path and get regret to do it.

Anyway you seems happy to see how someone that wanted to collaborate at the
end didn't do it,
Should be all the opposite, right?

Thank you so much for your support ;)

Regards.


El lun., 14 oct. 2019 a las 10:30, zimoun ()
escribió:

> Dear Wilson,
>
>
> On Sat, 12 Oct 2019 at 19:47, Wilson Bustos  wrote:
>
> > For example at the point to change the rules of a human language just
> for politics reason.
>
> I do not understand your point because you gently asked about this
> rule in this message on the 31rst of July.
>
> https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00457.html
>
> Then Miguel (the only translator referenced in
> po/doc/guix-manual.es.po) provided you a detailed answer:
>
> https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00458.html
>
> And you agreed on the answer, I quote you using your reply:
>
> <>
>
> And now, you seem so angry... maybe you should take a breath.
>
>
> > Don't you think that is extreme?
>
> Ah, I am still confused by your current words and the previous ones on
> July.
>
> <<
> >> Right now, yes. If you want to help, that'd make it two. :-)
> Ahh ok! I will
>
> >> Well, actually https://translationproject.org is the real platform for
> the translation process, but we could define any workflow as needed, I
> think. We can agree about that privately or on the tp list (address@hidden),
> if needed.
>
> Nice! I'm will check that
> >>
>
> https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00462.html
>
> Hum? I have not seen any of your patches. Therefore, if you think the
> translation is not accurate enough, please submit improvements instead
> of spending so much time on pointless emails.
> "Speak does not cook the rice."
>
>
> All the best,
> simon
>

Re: (Really) Free Software future Was: Re: Proposal to remove the off-topic, ...

[Jesse Gibbons]

On Mon, 2019-10-14 at 12:07 +0200, Svante Signell wrote:
> On Sun, 2019-10-13 at 21:44 -0400, Richard Stallman wrote:
> > [[[ To any NSA and FBI agents reading my email: please consider]]]
> > [[[ whether defending the US Constitution against all enemies,]]]
> > [[[ foreign or domestic, requires you to follow Snowden's example.]]]
> > 
> > Indeed, gnu-system-discuss is for system-level technical issues.
> > We set up gnu-community-private for nontechnical issues.
> > Please, everyone, move this discussion there.
> > 
> 
> The following is definitely on-topic for the gnu-system-discuss mailing
> list, as it is technical. 
> 
> I'm also Cc:ing this to guix-devel, who made the big mistake of
> publishing the joint statement to that list: (however, I'm a big fan of
> Guix, it is a major contribution to really free software, see below)

The only way I see this as on topic is guixsd would need to stop supporting
gnome if gnome is not actually free software and guixsd is to remain a
purely free distro. The guix developers would have a major interest in that.
> 
> I'd like to bring up two things you Richard was too weak to make a
> statement on historically: gnome and systemd.
> 
> Gnome: https://en.wikipedia.org/wiki/GNOME When Miguel de Icaza
> destroyed the gnome project with his contributions to that project.
> 
> From August 2015:
> Me:
> > > OK; I understand that you cannot take action for software using the
> > GPL that you created (here systemd), even if Freedom 1 is violated.
> > > Nevertheless, can you please take your (GNU/FSF) hand off Gnome, it
> > is no longer (in my and many others opinion) a GNU project (and
> > hasn't been for a long  time, since Miguel took over).
> > Hi again. Sorry to bother you. In the world of free and open
> > software, systemd is one of the most mean creatures. And you from
> > FSF/GNU still don't have an opinion? Additionally, why are you still
> > supporting gnome; they don't adhere to the free software philosophy
> > any longer, it died with icaza :(
> 
> Me:
> >   > Additionally, why are you still supporting gnome;
> >   > they don't adhere to the free software philosophy any longer,
> > 
> RMS:
> > How so?
> > 
> >   >  it died with icaza :(
> > 
> RMS:
> > On the contrary, he betrayed us totally; GNOME has more or less
> > got back on track since his departure.
> 
> I don't agree and many with me don't either. Please exclude Gnome from
> ther GNU project list. That would be brave of you, still being the head
> of GNU.

I am not familiar with what icaza did to gnome. What's a good source for me
to read to catch up?
> 
> From May 2015:
> Me about freedom 1:
> > * The freedom to study how the program works, and change it so it
> >   does your computing as you wish (freedom 1). Access to the
> >   source code is a precondition for this. 
> > Systemd: http://en.wikipedia.org/wiki/Systemd
> > violates freedom 1: (as well as the *NIX and KISS philosophy)
> 
>  
> > The agenda is very clear: Extend, embrace and extinguish. No other
> > distros will survive in the long term.
> 
> RMS from August 2015:
> > I know Systemd is free software.  As for its technical merits or
> > demerits, I have never seen it so I don't have an opinion.
> 
> Me:
> > Is there any way that you could consider taking away your/FSF/GNU
> > support away from Gnome. That would make a large impact in the Free
> > Software community (and maybe also in the Open Source community).
> 
> The above statement also applies to systemd. Perhaps we should divide
> free software into two groups: 1) Really free software where Freedom 1
> applies and 2) not-so-free software where Freedom 1 does no longer
> applies.
> Here gnome and systemd are in the second kind. Especially systemd, even
> if GPLed, is currently swallowing most of free software excluding large
> groups of people to make contributions. This is not a bright future for
> free software, it is destroying it (every vendor lock-in dream)
> 
> Thank you for your time.
> 
> 
> 
Free software by definition implies freedom 1 applies to it. If software
cannot be modified, it is nonfree.
If software is nonfree, then guix should not support it.

Re: Reminder to keep posts on topic

[Mikhail Kryshen]

Excuse me, Ricardo, but if this project is political (as you have
stated), then there are political issues that are relevant to its
development.  Otherwise, what does it mean for a project to be
political?  And since the "joint statement" is published on the Guix
website, the politics it invokes must be relevant to the project.

Ricardo Wurmus  writes:

> Hi František,
>
> it surprises me that I have to repeat this, but discussions that not
> relate to the development of Guix are off topic on this list.

Then, please, apply the same standards to yourself as you demand of
others and remove the off-topic statement from the Guix website.  Doing
so would not, of course, automatically invalidate the message of the
statement, which is a separate issue that, I agree, should be discussed
elsewhere.

> Please respect the many subscribers to this list by keeping your posts
> to this list on topic.

Yes, please, also respect the readers of the Guix website and remove the
off-topic statement from there.

-- 
Mikhail


signature.asc
Description: PGP signature

Re: i686-linux GCC package on x86_64

[Mathieu Othacehe]

Hey Pierre,

> --8<---cut here---start->8---
> (define-public cross-gcc
>   (package
> (inherit ((@@ (gnu packages cross-base) cross-gcc)
>   "i686-unknown-linux-gnu"
>   #:libc (cross-libc "i686-unknown-linux-gnu")))
> (name "cross-gcc")))
> --8<---cut here---end--->8---

Here if you need @@ for cross-gcc, you'll also need it for cross-libc I
guess.

But the visibility issue you have is because cross-gcc inherits from gcc
who has the property hidden? set to #t.

You can add this to your custom cross-gcc package definition:

--8<---cut here---start->8---
  (properties (alist-delete 'hidden? (package-properties gcc)))
--8<---cut here---end--->8---

Mathieu

Re: i686-linux GCC package on x86_64

[Jelle Licht]

Jelle Licht  writes:
> Would `guix build cross-gcc-i686-unknown-linux-gnu' work?
>

My mail reader did not expand your snippet fully, I overlooked the fact
that you already overrode the name field. Sorry for the noise!

Re: i686-linux GCC package on x86_64

[Jelle Licht]

Pierre Neidhardt  writes:

>[snip]
> --8<---cut here---start->8---
> (define-public cross-gcc
>   (package
> (inherit ((@@ (gnu packages cross-base) cross-gcc)
>   "i686-unknown-linux-gnu"
>   #:libc (cross-libc "i686-unknown-linux-gnu")))
> (name "cross-gcc")))
> --8<---cut here---end--->8---
>
> Then
>
> --8<---cut here---start->8---
> $ guix build cross-gcc
> ...
> guix build: error: cross-gcc: unknown package
> --8<---cut here---end--->8---
>
> Is this expected?
Would `guix build cross-gcc-i686-unknown-linux-gnu' work?

I *think* the guix command line interface uses the package's name field
to resolve the right package objects, not the guile variable name.

In `(gnu packages cross-base)' -> `cross-gcc':

--8<---cut here---start->8---
(name (string-append "gcc-cross-"
 (if libc "" "sans-libc-")
 target))
--8<---cut here---end--->8---

Re: Joint statement on the GNU Project

[zimoun]

Dear Wilson,


On Sat, 12 Oct 2019 at 19:47, Wilson Bustos  wrote:

> For example at the point to change the rules of a human language just for 
> politics reason.

I do not understand your point because you gently asked about this
rule in this message on the 31rst of July.

https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00457.html

Then Miguel (the only translator referenced in
po/doc/guix-manual.es.po) provided you a detailed answer:

https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00458.html

And you agreed on the answer, I quote you using your reply:

<>

And now, you seem so angry... maybe you should take a breath.


> Don't you think that is extreme?

Ah, I am still confused by your current words and the previous ones on July.

<<
>> Right now, yes. If you want to help, that'd make it two. :-)
Ahh ok! I will

>> Well, actually https://translationproject.org is the real platform for the 
>> translation process, but we could define any workflow as needed, I think. We 
>> can agree about that privately or on the tp list (address@hidden), if needed.

Nice! I'm will check that
>>

https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00462.html

Hum? I have not seen any of your patches. Therefore, if you think the
translation is not accurate enough, please submit improvements instead
of spending so much time on pointless emails.
"Speak does not cook the rice."


All the best,
simon

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

[Ludovic Courtès]

Howdy,

Konrad Hinsen  skribis:

>> (Though printing addresses in a REPL isn’t “bad practice” IMO, it’s just
>> that it doesn’t mesh well with the intended use of notebooks.)
>
> And that's exactly the difference between a REPL and a reproducible
> document. Unfortunately, Jupyter tries to be both and thus never
> explains the differences clearly.

Yeah.

>> At the API level, there’s ‘inferior-for-channels’ which does that +
>> registers a GC root + maintains a cache so that the second time you use
>> a given instance of Guix it’s immediately available.
>
> Just what I need...

Awesome, let us know how it goes!

Ludo’.

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

[Konrad Hinsen]

Hi Ludo,

> (Though printing addresses in a REPL isn’t “bad practice” IMO, it’s just
> that it doesn’t mesh well with the intended use of notebooks.)

And that's exactly the difference between a REPL and a reproducible
document. Unfortunately, Jupyter tries to be both and thus never
explains the differences clearly.

> At the API level, there’s ‘inferior-for-channels’ which does that +
> registers a GC root + maintains a cache so that the second time you use
> a given instance of Guix it’s immediately available.

Just what I need...

> Now, I think you can safely use it in your code, I don’t foresee any
> significant change at this point.
>
> As to whether you’d want to talk about it in the MOOC for instance, you

Certainly not. I just want to be sure that the functionality won't go
away. If the API changes a bit, that can be fixed.

I'll start playing with this...

Cheers,
  Konrad.

(Really) Free Software future Was: Re: Proposal to remove the off-topic, ...

[Svante Signell]

On Sun, 2019-10-13 at 21:44 -0400, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies,]]]
> [[[ foreign or domestic, requires you to follow Snowden's example.]]]
> 
> Indeed, gnu-system-discuss is for system-level technical issues.
> We set up gnu-community-private for nontechnical issues.
> Please, everyone, move this discussion there.
> 

The following is definitely on-topic for the gnu-system-discuss mailing
list, as it is technical. 

I'm also Cc:ing this to guix-devel, who made the big mistake of
publishing the joint statement to that list: (however, I'm a big fan of
Guix, it is a major contribution to really free software, see below)

I'd like to bring up two things you Richard was too weak to make a
statement on historically: gnome and systemd.

Gnome: https://en.wikipedia.org/wiki/GNOME When Miguel de Icaza
destroyed the gnome project with his contributions to that project.

>From August 2015:
Me:
> > OK; I understand that you cannot take action for software using the
> GPL that you created (here systemd), even if Freedom 1 is violated.
> > Nevertheless, can you please take your (GNU/FSF) hand off Gnome, it
> is no longer (in my and many others opinion) a GNU project (and
> hasn't been for a long  time, since Miguel took over).
> > 
> Hi again. Sorry to bother you. In the world of free and open
> software, systemd is one of the most mean creatures. And you from
> FSF/GNU still don't have an opinion? Additionally, why are you still
> supporting gnome; they don't adhere to the free software philosophy
> any longer, it died with icaza :(

Me:
>   > Additionally, why are you still supporting gnome;
>   > they don't adhere to the free software philosophy any longer,
> 
RMS:
> How so?
> 
>   >  it died with icaza :(
> 
RMS:
> On the contrary, he betrayed us totally; GNOME has more or less
> got back on track since his departure.

I don't agree and many with me don't either. Please exclude Gnome from
ther GNU project list. That would be brave of you, still being the head
of GNU.

>From May 2015:
Me about freedom 1:
> * The freedom to study how the program works, and change it so it
>   does your computing as you wish (freedom 1). Access to the
>   source code is a precondition for this. 

> Systemd: http://en.wikipedia.org/wiki/Systemd
> violates freedom 1: (as well as the *NIX and KISS philosophy)

 
> The agenda is very clear: Extend, embrace and extinguish. No other
> distros will survive in the long term.

RMS from August 2015:
> I know Systemd is free software.  As for its technical merits or
> demerits, I have never seen it so I don't have an opinion.

Me:
> Is there any way that you could consider taking away your/FSF/GNU
> support away from Gnome. That would make a large impact in the Free
> Software community (and maybe also in the Open Source community).

The above statement also applies to systemd. Perhaps we should divide
free software into two groups: 1) Really free software where Freedom 1
applies and 2) not-so-free software where Freedom 1 does no longer
applies.

Here gnome and systemd are in the second kind. Especially systemd, even
if GPLed, is currently swallowing most of free software excluding large
groups of people to make contributions. This is not a bright future for
free software, it is destroying it (every vendor lock-in dream)

Thank you for your time.

Re: Questions about packaging

[Tanguy Le Carrour]

Le 10/12, Danny Milosavljevic a écrit :
> Also, in
> 
> (define-public icedtea-6
>   (package
> [...]
> ))
> 
> "icedtea-6" is a variable name (in the programming language Guile).
> 
> The package name is there:
> 
> [...]
> (package
>   (name "icedtea")  <-
> )
> 
> We don't have version numbers in package names--but you can request
> a specific version by 
> 
> $ guix package -i xxx@1.2.3
>   ^^^ ^ package version
>   package name

I'll try to use the vocabulary (variable/package) properly from now on!


-- 
Tanguy

Re: Joint statement on the GNU Project

[František Kučera]

Dne 14. 10. 19 v 3:44 Richard Stallman napsal(a):
> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > GNU and free software philosophy is not made to exclude any women or
>   > any men, in fact it does not relate to any other politics but free
>   > software politics. GNU project is apolitical and shall stay so for a
>   > good reason.
>
>   > The only politics for GNU is free software politics.
>
> This is exactly correct.  Most of us have political views about other
> issues, but in connection with GNU we should not go further than hint
> at them -- not argue for them, let alone propose that the GNU Project
> endorse them.  Use your own non-GNU site to present your politics --
> as I do.
>
> I speak for the GNU Project as its head.  That doesn't mean I speak
> for GNU Project participants.  You don't have to agree with the GNU
> Project's free software principles, its goals or its policies to
> participate in the GNU Project.  All that is required is to act in
> accord with them in your work on GNU.
>
I totally agree. And this is one of reasons why I love and support free
software:

One of the things I appreciate about free software is that it brings
people from various (social, political, cultural etc.) groups together
and learns them how to cooperate. For example: One might be a communist,
another one might be a libertarian. They can hate each other. Or they
can collaborate on free software development. What is better? This is a
great positive side-effect of free software – it shows how different
people can cooperate in a peaceful way, it makes people better.

We can have various political or other opinions, but in FSF/GNU we
should focus on our common goal which is the free software. It is a
great goal in itself and it makes the world better even without any
other politics.

Franta

Re: Questions about packaging

[Tanguy Le Carrour]

Hi Danny


Le 10/12, Danny Milosavljevic a écrit :
> On Fri, 11 Oct 2019 09:42:00 +0200
> Tanguy Le Carrour  wrote:
> 
> > Le 10/10, Danny Milosavljevic a écrit :
> > > > 1) Updating a package
> > > > So I would have to update python-cachecontrol from 0.11.6 to 0.12.5.
> > > > Should I create a python-cachecontrol-0.11.6 and fix all the packages
> > > > that depend on it? Only the one that would break?  
> > > 
> > > The latter.  That's one of the things we do at Guix but I would not do at 
> > > work.  
> > 
> > OK. I'll do that!
> > My next question would be "when would someone create a versionned package 
> > name?"
> 
> If it's unavoidable.  One of the reasons is that we don't want to increase our
> maintenance and testing burden unduly and thus would not want 453 versions of
> the same package available at the same time (chances are that some combination
> would not have been tested and/or not work).
> 
> But there are professional engineering standards which allow you to specify 
> which versions of thing A can go with which other versions of thing B.
> 
> The most well-known type of that in software is semantic versioning.
> 
> So it depends on what kind of versioning scheme the project/package in 
> question
> uses.  If it does use semantic versioning or similar then packages which have
> changes making it fundamentally incompatible with what came before will 
> increase
> their major version, basically making that an independent package (Debian for
> example has the major version in that sense in their package NAMES for
> libraries).

Shame on me!
I'm perfectly aware of SemVer [1], it's "just" that I mixed up the
problem with python-cachecontrol and the other one with pytest that was
shadowed by python-cachecontrol!
So, yes, there is no version problem going from 0.11.6 to 0.12.5, has
it's only a change of minor version.
The pytest problem that I did not mention was a major change, with deprecation
of some hooks (pytest_namespace).

In Guix, we have Pytest 4.4.2, but the latest release is 5.2.1.
In that case, would it make sense to define a new "versionned" public
variable for python-pytest? Would I create python-pytest5? Or would I
rename python-pytest to python-pytest4 and add python-pytest for Pytest
5? In this later case, would I have to "fix" all the packages that were
using python-pytest?!

[1]: https://semver.org/

> Eventually in some years, there will be no users (other packages) of Python 2
> anymore.  Once that comes to pass we can drop Python 2.  What we can't do is
> replace Python 2 by Python 3 in those user packages--it would break them.

"in some years" will be next year [2]. But I guess Python2 will still be
around for some more years.

[2]: https://www.python.org/dev/peps/pep-0373/


Thanks again for the time you spent clarifying all this for me!


-- 
Tanguy

Reminder to keep posts on topic

[Ricardo Wurmus]

Hi František,

it surprises me that I have to repeat this, but discussions that not
relate to the development of Guix are off topic on this list.

Please respect the many subscribers to this list by keeping your posts
to this list on topic.

-- 
Ricardo

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen  skribis:

>> That reminds me of an interesting issue regarding
>> bitwise-reproducibility that was raised on the Reproducible Builds
>> mailing list:
>>
>>   
>> https://lists.reproducible-builds.org/pipermail/rb-general/2019-September/001657.html
>
> We ran into this problem as well in the Reproducible Research MOOC. It's
> hard to test equality for notebooks. But we went for solution a) because
> our main goal is to teach good practices for writers of future
> notebooks, rather than patch bad practices of the past with an
> additional layer of build tools.

Yeah.

(Though printing addresses in a REPL isn’t “bad practice” IMO, it’s just
that it doesn’t mesh well with the intended use of notebooks.)

>>> It would be nice in fact to adapt the ideas behind Guix-Jupyter (and
>>> perhaps parts of the code) to Org-mode. Some integration with Emacs will
>>> be necessary to tell Org-mode to start Python etc. from the Guix
>>> environment.
>>
>> I’d love to see that happen!  I thought perhaps we could trick Alex Kost
>> or Pierre Neidhardt to hack on that, let’s see.  :-)
>
> I might also do it myself because I suspect it would be less work to
> write the required Emacs package than to explain how to live without it.
> Tutorial-driven development :-)

Would be sweet!  :-)

> What would be the best way to run code in a specific environment created
> for recorded channels? The obvious approach would be
>
>guix pull -C channels.scm -p /tmp/temp-profile
>/tmp/temp-profile/bin/guix environment –-pure -m manifest.scm –-
>python script.py
>rm -rf /tmp/temp-profile
>
> but doing that properly involves the usual messy precautions for dealing
> with temporary directories, and it's probably expensive to do the "guix
> pull" repeatedly for the same channel file just because the temporary
> profile gets deleted immediately.

At the API level, there’s ‘inferior-for-channels’ which does that +
registers a GC root + maintains a cache so that the second time you use
a given instance of Guix it’s immediately available.

> This looks like a use case for "guix inferior", but is that already
> stable enough to be talked about in public?

It’s still documented as “subject to change”.  :-)

  https://guix.gnu.org/manual/devel/en/html_node/Inferiors.html

Now, I think you can safely use it in your code, I don’t foresee any
significant change at this point.

As to whether you’d want to talk about it in the MOOC for instance, you
could, but maybe with a word of warning because the MOOC may be around
for a long time.

Thanks,
Ludo’.

Re: Proposal to remove the off-topic, not free software related thoughtcrime accusations from the Guix project pages on GNU.ORG websitew

[František Kučera]

Dne 13. 10. 19 v 15:05 Kete via Development of GNU Guix and the GNU
System distribution. napsal(a):
> Besides, there is no way these men are getting these transactions
> without assault or coercion taking place.

Generally speaking, older men have sex or relationships with younger
women – it is not rare and it even comes through mainstream media
without much embarrassment e.g. here:

(no, he is not her grandfather). You can discuss how much normal or
weird it is, but such relationships are possible perfectly legally and
without any violence or even without prostitution.

Franta

Re: Towards reproducibly Jupyter notebooks with Guix-Jupyter

[Konrad Hinsen]

Hi Ludo,

> That reminds me of an interesting issue regarding
> bitwise-reproducibility that was raised on the Reproducible Builds
> mailing list:
>
>   
> https://lists.reproducible-builds.org/pipermail/rb-general/2019-September/001657.html

We ran into this problem as well in the Reproducible Research MOOC. It's
hard to test equality for notebooks. But we went for solution a) because
our main goal is to teach good practices for writers of future
notebooks, rather than patch bad practices of the past with an
additional layer of build tools.

>> It would be nice in fact to adapt the ideas behind Guix-Jupyter (and
>> perhaps parts of the code) to Org-mode. Some integration with Emacs will
>> be necessary to tell Org-mode to start Python etc. from the Guix
>> environment.
>
> I’d love to see that happen!  I thought perhaps we could trick Alex Kost
> or Pierre Neidhardt to hack on that, let’s see.  :-)

I might also do it myself because I suspect it would be less work to
write the required Emacs package than to explain how to live without it.
Tutorial-driven development :-)

What would be the best way to run code in a specific environment created
for recorded channels? The obvious approach would be

   guix pull -C channels.scm -p /tmp/temp-profile
   /tmp/temp-profile/bin/guix environment –-pure -m manifest.scm –-
   python script.py
   rm -rf /tmp/temp-profile

but doing that properly involves the usual messy precautions for dealing
with temporary directories, and it's probably expensive to do the "guix
pull" repeatedly for the same channel file just because the temporary
profile gets deleted immediately.

This looks like a use case for "guix inferior", but is that already
stable enough to be talked about in public?

Konrad.