Re: Eliminate environment variable hints?
Hi Andreas,
> On Mon, Feb 18, 2019 at 10:56:13PM +0100, Ricardo Wurmus wrote:
>> when installing a package into a profile Guix very helpfully tells you
>> that you may need to set certain environment variables. It doesn’t tell
>> you that these environment variables can also be set by source’ing the
>> generated etc/profile file.
>
> something I noticed is that I see these recommendations also when the
> environment variables are already set, precisely by sourcing the (previous)
> $HOME/.guix-profile/etc/profile. Now the profile changed, so they need to
> be re-sourced (which I usually do by calling "bash" from bash, since I source
> from the .bashrc).
>
> On the other hand, using the recommended environment variables would survive
> profile changes, since they look like
>export
> PATH="/home/andreas/.guix-profile/bin:/home/andreas/.guix-profile/sbin${PATH:+:}$PATH"
> instead of pointing to /gnu/store/...-profile/bin with a particular hash.
>
> So the two are clearly not equivalent. Which of them is actually
> preferable? I find it a bit confusing that after running
> "guix package -i hello" I cannot run "hello" immediately, unlike in
> Debian.
This only needs to be done when GUIX_PROFILE is not set. The
definitions in etc/profile either reference /gnu/store directories
directly (when GUIX_PROFILE is not set) or they reference the profile
links (when GUIX_PROFILE is set).
When GUIX_PROFILE is set an environment variable like PATH that is
already set to the profile’s “bin” directory will not have to be defined
again after installing another executable.
--
Ricardo
Re: manage /boot/grub/grub.cfg without installing grub binaries to disk
I'm unsure it's related. It's talking about an error while building xxx-etc.drv. Maybe you should have a look at the actual log? See "View build log at..." Raghav RG Gururajan writes: > @Clement > > The code didn't work. I have attached the error with this email. > Original Message > On 18 Feb 2019, 09:16, Raghav "RG" Gururajan wrote: > >> Ah! Got it. Thank you! >> Original Message >> On 17 Feb 2019, 13:26, Clément Lassieur wrote: >> >>> Raghav RG Gururajan writes: >>> @clement Thanks! Btw, shouldn't the first line be "(boot loader (bootloader-configuration)" in the code snippet you sent?? >>> >>> Well, I just gave the value of the bootloader field, but with this your >>> config.scm should look like: >>> >>> (operating-system >>> [...] >>> (bootloader (bootloader-configuration >>> (bootloader >>> (bootloader >>> (inherit grub-bootloader) >>> (installer #~(const #t)) >>> >>> [...] >>> )
Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.
18.02.2019, 14:44, "Tobias Geerinckx-Rice" : > If this is the quality of argument that ‘won’ over PureOS, it's > blaming Guix/Ricardo for not being around to stop others from > being bullied. > > Kind regards, > > T G-R Hi Tobias, I've been reading this conversation from the outside but noticed it seems to be shifting to a meta rather than about the state of chromium itself so it would be nice if it went back on topic. Seeing as the issue here relates to being uncertain shouldn't upstream confirm which parts run under what license in more detail? As I can tell so far this hasn't been done (unless I've missed something) thus the current situation. So the choice here is really about following the FSDG for now until it's revised or going against it causing a split in the community around it. Guix would be in the right but depending on the result there's a chance for a negative return (or a positive one). Are most here sure which direction it will go? From just reading the snippets about PureOS they seemed to have gotten quite a bit of flack until it was removed, won't the same happen to Guix? I've enjoyed using Guix for a bit over a year now and will continue regardless of the outcome. I apologize if this email is in conflict with the standard format as I usually don't engage in responding to mailing lists so my interpretation of the desired style might not be as accurate as of yet. Thank you Simon Nielsen
Re: Eliminate environment variable hints?
Hello,
On Mon, Feb 18, 2019 at 10:56:13PM +0100, Ricardo Wurmus wrote:
> when installing a package into a profile Guix very helpfully tells you
> that you may need to set certain environment variables. It doesn’t tell
> you that these environment variables can also be set by source’ing the
> generated etc/profile file.
something I noticed is that I see these recommendations also when the
environment variables are already set, precisely by sourcing the (previous)
$HOME/.guix-profile/etc/profile. Now the profile changed, so they need to
be re-sourced (which I usually do by calling "bash" from bash, since I source
from the .bashrc).
On the other hand, using the recommended environment variables would survive
profile changes, since they look like
export
PATH="/home/andreas/.guix-profile/bin:/home/andreas/.guix-profile/sbin${PATH:+:}$PATH"
instead of pointing to /gnu/store/...-profile/bin with a particular hash.
So the two are clearly not equivalent. Which of them is actually
preferable? I find it a bit confusing that after running
"guix package -i hello" I cannot run "hello" immediately, unlike in
Debian.
I would not be too worried about bash vs. other shells: The current
suggestions already would not work in csh...
Andreas
Re: Eliminate environment variable hints?
Agreed. For users using other shells, the issue is not knew. The main recommendation I've seen (e.g. for Fish) is that the user kept a POSIX-style shell as a login shell and only drop into the desired shell after the profile has been loaded. This way, Guix and similar configurations (/etc/profile, etc.) can be sourced properly. See here: https://wiki.archlinux.org/index.php/Fish#Setting_fish_as_default_shell -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Eliminate environment variable hints?
Ricardo Wurmus writes: > Hi Guix, > > when installing a package into a profile Guix very helpfully tells you > that you may need to set certain environment variables. It doesn’t tell > you that these environment variables can also be set by source’ing the > generated etc/profile file. > > I have seen the bashrc and bash_profile files of many users and they are > usually full of conflicting environment variable definitions. In these > files I often also see these Guix recommendations. > > I think Guix should suggest sourcing the generated etc/profile file > instead of listing explicit environment variable definitions. It would > be less noisy and less confusing, in my opinion. > > What do you think? > > (What about people who don’t use Bash?) I think this is a good idea. It may also be worth mentioning that these suggestions can also be set in environments using the --search-paths flag. I know that is said in the documentation, but maybe it could be highlighted somehow? Brett Gilio
Eliminate environment variable hints?
Hi Guix, when installing a package into a profile Guix very helpfully tells you that you may need to set certain environment variables. It doesn’t tell you that these environment variables can also be set by source’ing the generated etc/profile file. I have seen the bashrc and bash_profile files of many users and they are usually full of conflicting environment variable definitions. In these files I often also see these Guix recommendations. I think Guix should suggest sourcing the generated etc/profile file instead of listing explicit environment variable definitions. It would be less noisy and less confusing, in my opinion. What do you think? (What about people who don’t use Bash?) -- Ricardo
Re: the upcoming Great Python2 Purge™
On Mon, 18 Feb 2019 11:56:19 +0200 Efraim Flashner wrote: > I checked 'guix refresh -l python2' and I got a list of the python2-* > packages which are leaf packages. I'm not suggesting that we right now > get rid of them, but it seems to me something worth keeping an eye on. > > 'guix package -A ^python2- | wc -l' gave me 737 > the number of leaf python2 packages I found was 222. > > This is only a first round; I didn't check to see if we were to remove > these packages how many more leaf python2 packages we would have. I would also point attention to non-leaf packages, where python2 is often a native-input which might or might not be eliminated. Just out of curiosity I looked at the dependency-graph of icecat and there are 24 edges going to python2 including from icecat itself, rust, curl, clang, fontforge, zziplib, etc. For example, I found out that zziplib uses python2 for creating documents and there is a patch in the next release that will make it work with python3. I'm attaching that icecat->python2 subgraph as a dot-file. Björn icecat-python2.dot Description: application/msword-template pgpI182DmTZbL.pgp Description: OpenPGP digital signature
Re: New topic: packaging
On Sun, 17 Feb 2019 10:02:26 +0100 swedebugia wrote: > Am I late to the party? Yes, you are :-) We decided to split once: We now put the whole "setup and build guix from git" part into one video. And then the real "packaging" part starts in a second video. It might be that we need to break that up again in 2 or 3 parts, but we try it like that first. Björn pgpxzL3p2cgPq.pgp Description: OpenPGP digital signature
Re: New topic: packaging
"Björn Höfling" skrev: (13 februari 2019 10:13:22 CET) >On Mon, 11 Feb 2019 11:38:21 -0300 >Laura Lazzati wrote: > >> Hi Guix again! >> >> Another topic is about showing how to package. >> >> Gábor suggested maybe using my experience about creating a new R >> package. >> >> My idea is to show how to look for a package that is not packaged, >> package it and the workflow for testing it with git am and send it to >> the patches list. WDTY? > >Aggreed on R: There is the importer to show, and R-packages are usually >easy to go. > >We have the rough idea of steps to take in the manual. Point people to >the right chapter here. > >Then it would involve the whole things: > >* git clone ... >* go into guix directory >* Enter the environment: > guix environment guix > --> Explain what happens here and what's so cool about it. >* ./bootstrap >* ./configure --localstatedir=/var >* make >* Then the import begins: >* ./pre-inst-env guix import ... >* [hack file, using emacs, maybe ./pre-inst guix edit new-package] >* ./pre-iinst-env guix build new-package >* Check: > ./pre-inst-env guix lint new-package >* Finally: > Commit, take care of the correct commit messsages >* git format-patch and maybe git send-email > >This is a lot for even a simple R package but I don't see how/where we >could leave out steps without confusing people. > >Björn Hi. Am I late to the party? Here is my two cents. I suggest splitting this in multiple videos. Split after make is finished. I agree it is hard to cover less than this if we want to nudge people into contributing new packages and guide them the whole way. If you decide to go with ./pre-inst guix edit new-package then I suggest we fool proof it by prepending EDITOR=emacs Given this I suggest the video starting after make also include setting up emacs. This might even warrant its own short video. So we end up with 3! Generally I think shorter videos to the point are preferred over long ones bundling multiple things. Maybe we should cut it also after successful build and test and make the comitting a separate video. That gives us 4 in total -- Sent from my k-9 mail for Android.
Re: the upcoming Great Python2 Purge™
Hi Konrad, On Mon, 18 Feb 2019 at 17:31, Konrad Hinsen wrote: > > Hi Ricardo, > > >> "My channel" doesn't exist (because I haven't yet found the time to > >> figure out how to set up and manage a channel, although it's been on my > >> to-do list for a while). > > > > I’d be happy to assist. > > Thanks! I might come back to that offer when I find at least enough time > to figure out precisely what information I might be lacking > (that's meta-lack-of-time). >From my understanding, it is simpler than expected ;-) For example, instead of GUIX_PACKAGE_PATH=~/work/your-repo you create the file ~/.config/guix/channels.scm containing: (cons* (channel (name 'bimsb) (url "file:///home/simon/work/your-repo") (branch "master")) %default-channels) Then: guix pull guix package -s guix package -i etc. > >> But... how about splitting off *all* of Python 2 and everything that > >> depends on it into a separate channel, which would then be maintained > >> by a separate team? > > > > Currently this is not feasible, in my opinion, as a lot of packages in > > Guix still depend on Python 2 for some reason or the other. When Python > > 2 reaches EOL, however, I think this would be a reasonable thing to do. > > Sounds good, then the only remaining issue is defining a transition > protocol. What I'd like to avoid is that packages disappear one by one > from Guix and then have to be dug out one by one from Git history for > setting up a Python 2 channel. First, the package will not disappear. Because now, they are in the Guix tree, one can always reach them with `guix pull --commit' even if they are not "visible" in gnu/packages. Second, I am not sure it is that ugly. :-) If one package "disappears", then you can quickly find the last commit where it is defined with: git rev-list --all | xargs git --no-pager grep 'public python2-stuff' | head -1 Then you can add the package to your channel (or a semi-official one), with its dependencies if needed. To me, this is the best transition protocol. a- the Guix tree is moving forward "reserving its freedom to break third party channels" b- if no one moves the disappeared package, then it means the package is really obsolete. Last about scientific reproducibility, imagine you have your local channel, containing your packages that rocks! Today, you compute some stuff and so on. You "just" have to store the output of `guix describe'. For example, my current one is: Generation 16 Feb 07 2019 15:47:37(current) bimsb d1cba4a repository URL: file:///home/simon/work/guix/bimsb branch: master commit: d1cba4a2cba1eb6c6c33328fea511b75dfcffe39 guix 89ea625 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 89ea6252b6849131ba35d141006e1bbf3a49594f Months later, my "collaborators" want to reproduce my result. With this information (the 2 commit hashes), they will be able to set again all the dependency graph. (however, substitutes should not be there so maybe they should need to build a lot; another story) The `guix pull --commit=' is not super friendly yet with multiple channels. But, it is only UI gaps, isn't it? :-) For example, it should be nice to run: guix pull -C bimsb --commit=d1cba4a -C guix --commit=89ea625 to restore the exact same tree. Today, if I am correct, you can put this information in a manifest file and then instantiate an environment for your computations. From my point of view, it is the long-term practise to have the "scientific" reproducibilty. Please correct me if I am wrong. :-) However, some whistle. 1. Even if inferiors and other improve the travel in time, there is no guarantee that nothing will be break in the future compared to the past (if you see what I mean). 2. Archivist issue: will the current material be still available? > More generally, I think it would be useful to collect in some place all > package definitions that are removed from Guix. For example, a list with > package names plus the last Guix commit that had the package. >From my opinion, when we speak about reproducibility, remove a package is similar to update it. And all this information is tracked by the Git repo. I agree that maybe it is not friendly to dive in and it is really resource hungry. For example, it is not "easy" to find when the package lispf4 have been removed. And if we speak about scientific reproducibility, it appears to me difficult to have the Q that you propose at the Guix commit level. However, it should be easier to find from which commit the package is installed. Somehow, improve the `guix package --list-installed' and/or `guix package --list-generations' commands, i.e., also tracking the channel and the commit. As a user, if I run: guix package -i python-numpy guix pull # the tree is changed do other stuff (install remove pull again etc.) guix package -i python-scipy and I forgot to store the commit hash of my first install. Then, it requires
Re: the upcoming Great Python2 Purge™
Efraim Flashner writes: > I checked 'guix refresh -l python2' and I got a list of the python2-* > packages which are leaf packages. I'm not suggesting that we right now > get rid of them, but it seems to me something worth keeping an eye on. > > 'guix package -A ^python2- | wc -l' gave me 737 > the number of leaf python2 packages I found was 222. > > This is only a first round; I didn't check to see if we were to remove > these packages how many more leaf python2 packages we would have. There are a few leaf packages that are being used to generate the python3 equivalent. So, maybe we should make a list of leaf packages that are otherwise safe to be dismissed. Also, what is the status of somebody deciding to move a lot of these to a channel?
Re: the upcoming Great Python2 Purge�?�
Konrad Hinsen transcribed 1.2K bytes: > Hi Ricardo, > > >> "My channel" doesn't exist (because I haven't yet found the time to > >> figure out how to set up and manage a channel, although it's been on my > >> to-do list for a while). > > > > I’d be happy to assist. > > Thanks! I might come back to that offer when I find at least enough time > to figure out precisely what information I might be lacking > (that's meta-lack-of-time). > > >> But... how about splitting off *all* of Python 2 and everything that > >> depends on it into a separate channel, which would then be maintained > >> by a separate team? > > > > Currently this is not feasible, in my opinion, as a lot of packages in > > Guix still depend on Python 2 for some reason or the other. When Python > > 2 reaches EOL, however, I think this would be a reasonable thing to do. > > Sounds good, then the only remaining issue is defining a transition > protocol. What I'd like to avoid is that packages disappear one by one > from Guix and then have to be dug out one by one from Git history for > setting up a Python 2 channel. > > More generally, I think it would be useful to collect in some place all > package definitions that are removed from Guix. For example, a list with > package names plus the last Guix commit that had the package. > > Konrad. > > package number one which will stay on python2: getmail. In exchanges with the maintainer on their mailinglist it was made clear that Charles has no intention to port it to python3, as except for a few minor additions and fixes, getmail is in maintenance mode.. you get releases every now and then.
Re: the upcoming Great Python2 Purge™
Hi Ricardo, >> "My channel" doesn't exist (because I haven't yet found the time to >> figure out how to set up and manage a channel, although it's been on my >> to-do list for a while). > > I’d be happy to assist. Thanks! I might come back to that offer when I find at least enough time to figure out precisely what information I might be lacking (that's meta-lack-of-time). >> But... how about splitting off *all* of Python 2 and everything that >> depends on it into a separate channel, which would then be maintained >> by a separate team? > > Currently this is not feasible, in my opinion, as a lot of packages in > Guix still depend on Python 2 for some reason or the other. When Python > 2 reaches EOL, however, I think this would be a reasonable thing to do. Sounds good, then the only remaining issue is defining a transition protocol. What I'd like to avoid is that packages disappear one by one from Guix and then have to be dug out one by one from Git history for setting up a Python 2 channel. More generally, I think it would be useful to collect in some place all package definitions that are removed from Guix. For example, a list with package names plus the last Guix commit that had the package. Konrad.
Re: [urgent] GNU Guix in Outreachy May 2019 round?
On Mon, 18 Feb 2019 11:53:04 +0100 Ricardo Wurmus wrote: > Ricardo Wurmus writes: > > [...] > > The application period begins today. So far nobody has come forward > to volunteer as a mentor, so I suppose Guix will not participate in > the upcoming Outreachy round of internships. Hi Ricardo, this round I want to concentrate on other things, so I'm out for mentoring or co-mentoring. If we still find some mentor/project, I can help out with some questions/organisational things. Björn pgplccARrelSA.pgp Description: OpenPGP digital signature
Re: Rust 1.19 fails to build on i686 on ‘staging’
Hi Chris, On Sat, 16 Feb 2019 02:53:30 -0800 Chris Marusich wrote: > > (i.e. the things you did before, just inside a i686-linux guix > > environment. That only provides minimal--almost no--isolation from > > the host, so it should allow us to test whether the personality is the > > only possible culprit) > > Did you mean to say that by using a pure guix environment, we can > achieve a high degree of isolation? * "guix environment" provides very low isolation (almost none) * "guix environment --pure" provides better isolation by at least removing things from $PATH which aren't supposed to be there. * "guix environment -C" provides very good isolation by creating a new initially-empty container. What I meant is that "guix environment -s i686-linux" is very different from guix-daemon (especially it does not set the personality) and might allow us to proceed without error, or with a different error. But apparently the actual problem is that now it always succeeds. Today I think we should reproduce the guix-daemon environment as closely as possible in order to make it fail again--and then use the setup right before it started failing again. In this case if we wanted to have a similar environment to the guix-daemon, I think "guix environment -C" would be the most similar - and should fail. I'm not sure whether guix environment -C sets the personality. If not, then your program should be good for setting the personality. Your program could be simpler if it just used execv(argv[1], argv + 1) (or execv(argv[1], [1])) instead of copying the argument vector; if one wants to skip elements at the front of an array, using the fact that arrays elements are sequential in C, without gaps, ordered by increasing index, can be very useful. > I tried what you suggested. The mrustc invocation still succeeded. So it always succeeds outside guix-daemon container (does that include "guix environment -C" ?), but doesn't succeed inside a guix-daemon container, is that correct? > Just for fun, I also made a simple wrapper program that lets me run > another program using the LINUX32 personality (see attached). I think I > programmed it correctly, but C is not (yet!) my forte, so if I made an > error, please let me know. >From within the same pure environment, I > used this wrapper program to invoke mrustc in the same way, and it > _still_ succeeded. That surprised me, since I expected it to fail. That's strange. Then maybe the personality is not the reason. > Can you think of any other way I can try to reproduce the issue? I'd try guix environment -s i686-linux -C rust@1.19.0 And then try to build it in there (or only run the same steps you ran before--should be enough). Thanks for looking into it. Apparently it seems to be possible to get working--it's just a matter of tuning the environment (maybe even only by removing things). (If it is the personality, I suspect that it changes the system call interface and maybe mrustc assumes the x86_64 syscall interface at all times) pgpde5qteCQa4.pgp Description: OpenPGP digital signature
Re: the upcoming Great Python2 Purge™
Dear, Maybe I am wrong and I miss one point. If you have local packages that depends on Guix packages, then it is not a big issue when the Guix packages are removed. Because you just have to `guix pull --commit=' where points to a Guix commit owning the required packages. And if I have correct, you can put that in a manifest and then instantiate an environment for your local packages. Instead of splitting off all of Python 2 into a separate channel, why not just put the python2 packages which need to be removed. Then nothing breaks and it provides a picture of how many python2 packages necessary to Guix are still there. Speaking about channel, instead of GUIX_PACKAGE_PATH=~/work/guix/bimbs you create the file ~/.config/guix/channels.scm containing: (cons* (channel (name 'bimsb) (url "file:///home/simon/work/guix/bimsb") (branch "master")) %default-channels) Then: guix pull guix package -i Here the url file:///home/simon/work/guix/bimsb is a clone of https://github.com/BIMSBbioinfo/guix-bimsb But you can directly specify Git repo online etc. Hope that helps All the best, simon
Re: manage /boot/grub/grub.cfg without installing grub binaries to disk
Ah! Got it. Thank you! Original Message On 17 Feb 2019, 13:26, Clément Lassieur wrote: > Raghav RG Gururajan writes: > >> @clement >> >> Thanks! Btw, shouldn't the first line be "(boot loader >> (bootloader-configuration)" in the code snippet you sent?? > > Well, I just gave the value of the bootloader field, but with this your > config.scm should look like: > > (operating-system > [...] > (bootloader (bootloader-configuration > (bootloader > (bootloader > (inherit grub-bootloader) > (installer #~(const #t)) > > [...] > ) publickey - raghavgururajan@protonmail.ch - 0xE1982130.asc Description: application/pgp-keys
Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.
On Sat, 16 Feb 2019 12:16:41 +0100 Gábor Boskovits wrote: > It seems to me, that there is a whole bunch of people interested in > this, but due to lack of resources or for some other reasons nothing > is really happening. Do you know any we we could help getting this > resolved? This is a very good point. I also wonder if at the end, working to fix the problem by reviewing chromium source code more carefully would take less resources than discussing endlessly on how to deal with the fact that the source code hasn't been reviewed. Denis. pgp5Jwx_cHBQn.pgp Description: OpenPGP digital signature
Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.
bill-auger wrote: On Sun, 17 Feb 2019 23:33:06 +0100 Ricardo wrote: I don’t feel motivated to apologize to the people involved in PureOS because I wasn’t around when they were pressured / convinced to drop Chromium. no, but you could have been around - you also could have argued for pureos on their side of the debate, and perhaps won favor for chromium at that time; so that none of us would need to be discussing it today, nor ever again - but unfortunately, it is true, you did not do that - so here we are today, raking this ugly old thing out of the mud once again If this is the quality of argument that ‘won’ over PureOS, it's blaming Guix/Ricardo for not being around to stop others from being bullied. Kind regards, T G-R
Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.
On Sun, 17 Feb 2019 23:33:06 +0100 Ricardo wrote: > I don’t feel motivated to apologize to the people involved in PureOS > because I wasn’t around when they were pressured / convinced to drop > Chromium. no, but you could have been around - you also could have argued for pureos on their side of the debate, and perhaps won favor for chromium at that time; so that none of us would need to be discussing it today, nor ever again - but unfortunately, it is true, you did not do that - so here we are today, raking this ugly old thing out of the mud once again On Sun, 17 Feb 2019 23:33:06 +0100 Ricardo wrote: > In day to day Guix activities, we don’t ask developers of other > distros that also happen to subscribe to the FSDG to reach consensus > before making project decisions. of course every distro should have complete autonomy, especially for decisions that only pertain to that one distro - i am only considering the most fundamental decisions that obviously affect all distros equally, and reflect upon the integrity of the FSDG itself, such as which software is FSDG-free and which are not (and clarifying why or why not, and ideally, offering specific guidance for acceptably liberating the most common or troublesome ones) - if we can not all agree on that single most central concern to the FSDG, then what exactly is the value of the FSDG anyways? On Sun, 17 Feb 2019 23:33:06 +0100 Ricardo wrote: > You are suggesting that FSDG > distros form a community beyond the sense that they abide by the same > guidelines. I don’t think that’s reflecting reality. It’s another > thing to discuss if this should be so. yes - awesome!! - that is exactly what i have been proposing and working toward for a long time - in this case, not as just "another thing to discuss"; but it is *the* sole reason that i raised this issue with guix at this time (last september actually[1]) i have repeated it over and over again, that i couldnt care less about the chromium program, specifically - i want to discuss only and exactly this: enticing all FSDG distros to collaborate toward the achievement of common goals and solutions to common problems; as to avoid both redundant efforts and the presenting of conflicting philosophies to users, regarding the nature and essence of "free software" - the chromium program is not itself a fundamental problem, but one, albeit notorious, example of a common problem that affects all FSDG distros, and has been addressed by the group for the purpose of presenting a uniform message regarding it's FSDG status it would be a beautiful thing to have vigorous cross-distro collaboration as a focal point of the FSDG itself, very much in the collaborative spirit of GNU; and i think that most of the distros are already on board with that idea as a worthwhile plan, and have always been participating on the FSDG mailing list under that presumption - last year's re-structuring of the incoming distros community evaluation process was a concrete step in that direction "reality" is only what we make of it - if you see the FSDG as nothing more than a trophy or badge that you earned once upon a time, a milestone that need not be any concerned ever more after, then that is the reality you will have - the FSF does not want to mandate that anyone participate in the on-going group discussions; but it is a very good idea to show that the FSDG distros behave as a community of siblings by, at the very least, presenting a uniform stance on shared freedom issues On Sun, 17 Feb 2019 23:33:06 +0100 Ricardo wrote: > I see no violation of the FSDG here. that is not news, Ricardo - no one sees any obvious licensing violation of the FSDG; not today, nor a year ago, nor five years ago - if there were any known, they could have (and probably would have) been addressed long ago, and maybe we would not be discussing this now - the only clear FSDG problem today is the new one that guix is making for all other distros that are trying to be compliant with the FSDG as it is written, by intentionally doing something that is explicitly against the written recommendation - the "as it is written" part is perhaps dubious; but it is the keystone of a long-standing FSDG anomaly, and guix is in a very good position to help resolve that once and for all, for the benefit of all whether anyone likes it or not, adding chromium into any FSDG distro today, is in direct conflict with that pesky: "what is written" - the solution is almost certainly, that it needs to be re-written; but there is not yet anything to over-write it with - "i see no problem" is clearly not sufficient - we all know it has FSDG problems; and the current wording will remain until someone who cares about chromium offers a convincing liberation procedure to replace it as the FSDG recommendation we are asking for your help with this, for the benefit of all FSDG distros and their users, present and future, because it is only guix that claims to have any new information about
Re: [urgent] GNU Guix in Outreachy May 2019 round?
Am 18.02.19 um 11:53 schrieb Ricardo Wurmus: > The application period begins today. So far nobody has come forward > to volunteer as a mentor, so I suppose Guix will not participate in the > upcoming Outreachy round of internships. Bringing KDE Plasma to guix. Considerable work has already been done on my personal branch, but there is still some work to to. Not sure whether this will be enough work for such a program -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: the upcoming Great Python2 Purge™
Hi Konrad, >> Konrad, going forward it might be reasonable to keep copies of required >> Python 2 packages in your channel. We aren’t going to remove Python 2 >> packages now, but in the future we may not be able to fix unmaintained >> packages and may have to remove them. > > "My channel" doesn't exist (because I haven't yet found the time to > figure out how to set up and manage a channel, although it's been on my > to-do list for a while). I’d be happy to assist. > But... how about splitting off *all* of Python 2 and everything that > depends on it into a separate channel, which would then be maintained > by a separate team? Currently this is not feasible, in my opinion, as a lot of packages in Guix still depend on Python 2 for some reason or the other. When Python 2 reaches EOL, however, I think this would be a reasonable thing to do. -- Ricardo
Re: 01/01: gnu: guile-hall: Update to 0.2.
Hi Alex, [-guix-commits, +guix-devel] >>> Again, this is the result of auto-generation: Hall generically wraps any >>> script files in the scripts directory of a project with all Guile >>> dependencies — rather than the developer having to manually specify >>> these things. >> >> I think this should rather be done by the guile-build-system. We >> already do this in other build systems such as python-build-system. > > That would be lovely as it reduces complexity of the code on the hall > side too :-) > > I have to admit I'm somewhat worried about breaking Guix by adding code > to build systems. I think the logic in hall to do this is fairly solid > — would it just be a matter of integrating this in the > guile-build-system? Yes, it shouldn’t be difficult to add this to the guile-build-system as a build phase. You needn’t worry about breaking Guix. Please send your proposed patch to guix-patches and I’ll review it. I thought that the wrapping logic looked a bit too complicated in comparison with the wrapping phases that other build systems use. Maybe we can simplify this a little. > I guess another issue is that hall genrates autotools compliant code for > now, which means that it uses gnu-build-system rather than > guile-build-system. What is “autotools compliant code”? Does it generate configure.ac, Makefile.am, and all that? In that case the “guile-build-system” may not be the best fit, because it is used for Guile packages that have no proper build system. > Maybe we'll either need to extend guile-build-system to handle autotools > logic or extend gnu-build-system to do guile wrapping (this feels wrong > though). Extending the guile-build-system would be simpler as it is based on the gnu-build-system. Currently, the guile-build-system deletes most build phases and replaces the “build” phase with a custom phase that compiles and installs the Guile modules. We could make it a little smarter so that it uses the gnu-build-system’s phases when autotools things are detected. Alternatively, we could ignore the autotools things that Hall generates and consider those files to be needed only for platforms that don’t use Guix. >> I’m excited about Hall and would love to add support for it in Guile >> Studio (e.g. through a menu in the menu bar). > > I was very excited to see that you went ahead and started the > "integrated Guile development environment" project with Guile Studio. I > would love to have hall be part of that. > > What is the best way to discuss taking this forward? Do you have an > issue tracker? Otherwise we could track it on the Hall tracker? Guile Studio has no home yet. I think it’s fine to track progress on integrating Hall in the Hall tracker. A first step would be to think of what parts of Hall should be exposed in an Emacs user interface and how. (Maybe this could be an independent minor mode that will be installed and activated in Guile Studio by default?) -- Ricardo
Re: the upcoming Great Python2 Purge™
Hi Ricardo, > Konrad, going forward it might be reasonable to keep copies of required > Python 2 packages in your channel. We aren’t going to remove Python 2 > packages now, but in the future we may not be able to fix unmaintained > packages and may have to remove them. "My channel" doesn't exist (because I haven't yet found the time to figure out how to set up and manage a channel, although it's been on my to-do list for a while). But... how about splitting off *all* of Python 2 and everything that depends on it into a separate channel, which would then be maintained by a separate team? This would remove the Python 2 maintenance burden from the Guix team, but still allow shared maintenance (expected to be low-effort) of a coherent distribution of Python 2 packages. If everybody starts a personal channel of whatever subset of those packages they require, there's a lot of duplicated effort and no clear location to turn to for end users. And if parts of Python 2 remain in Guix but other parts move elsewhere, there's needless friction in coordinating two projects that will end up having different policies. Konrad.
Re: [urgent] GNU Guix in Outreachy May 2019 round?
Hello Ricardo, 2019. febr. 18., H 11:53 dátummal Ricardo Wurmus ezt írta: > > Ricardo Wurmus writes: > > > the next Outreachy round of internships will take place from May 2019 to > > August 2019. As a community we would need to decide very soon whether > > we would like to participate in the upcoming round. > > > > To make that decision we need to have people come forward who would like > > to be mentors or co-mentors for an internship project. Being a mentor > > also means to come up with a project idea or to flesh out somebody > > else’s idea. (This is different from GSoC.) > > > > The application period begins on February 18 (this is in five days). > > The sooner we join the more likely we will find a strong intern. > > > > If you have doubts about volunteering as a mentor, you are welcome to > > write to me and/or the current Outreachy mentors off-list. > > The application period begins today. So far nobody has come forward > to volunteer as a mentor, so I suppose Guix will not participate in the > upcoming Outreachy round of internships. > I don't have a project in mind, but willing to comentor if something comes up. I can help on the administration and organisation side, and reviewing, like I did already for the past two rounds. > > -- > Ricardo > > >
Re: [urgent] GNU Guix in Outreachy May 2019 round?
Ricardo Wurmus writes: > the next Outreachy round of internships will take place from May 2019 to > August 2019. As a community we would need to decide very soon whether > we would like to participate in the upcoming round. > > To make that decision we need to have people come forward who would like > to be mentors or co-mentors for an internship project. Being a mentor > also means to come up with a project idea or to flesh out somebody > else’s idea. (This is different from GSoC.) > > The application period begins on February 18 (this is in five days). > The sooner we join the more likely we will find a strong intern. > > If you have doubts about volunteering as a mentor, you are welcome to > write to me and/or the current Outreachy mentors off-list. The application period begins today. So far nobody has come forward to volunteer as a mentor, so I suppose Guix will not participate in the upcoming Outreachy round of internships. -- Ricardo
Re: the upcoming Great Python2 Purge™
Konrad Hinsen writes: > Efraim Flashner writes: > >> I checked 'guix refresh -l python2' and I got a list of the python2-* >> packages which are leaf packages. I'm not suggesting that we right now >> get rid of them, but it seems to me something worth keeping an eye on. > > Please be careful with "leaf packages". The leaves of my software > dependency tree are in my home directory, not in Guix. But I depend on > Guix to supply most of the dependencies of these leaves. > > In the case of Python, any package that provides a Python library API > should not be considered a leaf package. Yes, in the presence of channels this can be tricky. However, we are not committed to supporting third party channels when this results in problems on our end. We reserve the freedom to break third party channels. Konrad, going forward it might be reasonable to keep copies of required Python 2 packages in your channel. We aren’t going to remove Python 2 packages now, but in the future we may not be able to fix unmaintained packages and may have to remove them. -- Ricardo
Re: the upcoming Great Python2 Purge™
Efraim Flashner writes: > I checked 'guix refresh -l python2' and I got a list of the python2-* > packages which are leaf packages. I'm not suggesting that we right now > get rid of them, but it seems to me something worth keeping an eye on. Please be careful with "leaf packages". The leaves of my software dependency tree are in my home directory, not in Guix. But I depend on Guix to supply most of the dependencies of these leaves. In the case of Python, any package that provides a Python library API should not be considered a leaf package. Konrad.
Re: the upcoming Great Python2 Purge™
I checked 'guix refresh -l python2' and I got a list of the python2-* packages which are leaf packages. I'm not suggesting that we right now get rid of them, but it seems to me something worth keeping an eye on. 'guix package -A ^python2- | wc -l' gave me 737 the number of leaf python2 packages I found was 222. This is only a first round; I didn't check to see if we were to remove these packages how many more leaf python2 packages we would have. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted python2-activepapers@0.2.2 python2-ansi2html@1.2.0 python2-apache-libcloud@2.4.0 python2-autograd@0.0.0-0.442205d python2-autopep8@1.3.5 python2-axolotl@0.1.39 python2-behave-web-api@1.0.6 python2-betamax-matchers@0.4.0 python2-bigfloat@0.3.0 python2-binaryornot@0.4.4 python2-biom-format@2.1.7 python2-cachecontrol@0.11.6 python2-capstone@3.0.5 python2-carbon@1.0.2 python2-ccm@2.1.6 python2-celery@4.2.1 python2-clf@0.5.7 python2-conda@4.3.16 python2-consul@0.6.1 python2-cvxopt@1.2.1 python2-cypari2@2.0.3 python2-debian@0.1.28 python2-defusedxml@0.5.0 python2-discogs-client@2.2.1 python2-django-filter@1.1.0 python2-django-simple-math-captcha@1.0.7 python2-dns-lexicon@2.4.0 python2-empy@3.3 python2-enum@0.4.6 python2-eventlet@0.20.1 python2-exif-read@2.1.2 python2-falcon-cors@1.1.7 python2-feather-format@0.4.0 python2-feedgenerator@1.9 python2-file@5.33 python2-flasgger@0.6.3 python2-flask-htmlmin@1.2 python2-flask-httpauth@3.2.3 python2-flask-login@0.4.1 python2-flask-migrate@2.0.3 python2-flask-multistatic@1.0 python2-flask-principal@0.4.0 python2-flask-restful-swagger@0.19 python2-flask-wtf@0.13.1 python2-furl@0.5.6 python2-gdrivefs@0.14.9 python2-ghp-import@0.5.5 python2-git-review@1.27.0 python2-glances@3.0.2 python2-glob2@0.6 python2-gmpy2@2.0.8 python2-gnupg@0.4.3 python2-gpg@1.10.0 python2-grako@3.99.9 python2-graphene@0.10.2 python2-graphite-web@1.0.2 python2-gridmap@0.13.0 python2-gst@1.14.4 python2-guzzle-sphinx-theme@0.7.11 python2-gyp@0.0.0-0.5e2b3dd python2-hdf4@0.9 python2-honcho@1.0.1 python2-httpretty@0.8.14 python2-hy@0.13.0 python2-i3-py@0.6.5 python2-internetarchive@1.7.4 python2-invoke@1.1.0 python2-ipy@0.83 python2-ipywidgets@5.2.2 python2-iso3166@0.9 python2-iso639@0.4.5 python2-isoweek@1.3.3 python2-jellyfish@0.5.6 python2-joblib@0.13.0 python2-josepy@1.1.0 python2-jsonpatch@1.16 python2-jsonrpclib@0.1.7 python2-jsonrpclib-pelix@0.3.2 python2-jupyter-console@5.2.0 python2-keepkey@6.0.2 python2-keystoneclient@1.8.1 python2-kitchen@1.2.5 python2-kivy@1.10.1 python2-ledgerblue@0.1.16 python2-libadalang@0.0.0-0.9b205e9 python2-libarchive-c@2.8 python2-libmpsse@1.3 python2-libvirt@4.10.0 python2-lirc@1.2.1-2.c28708b python2-lit@0.5.1 python2-llfuse@1.3.5 python2-lmdb@0.94 python2-lzstring@1.0.4 python2-mapnik@3.0.16 python2-matplotlib-documentation@2.2.3 python2-mechanicalsoup@0.11.0 python2-mpd2@0.5.5 python2-munch@2.0.4 python2-munkres@1.0.8 python2-musicbrainzngs@0.6 python2-mutagen@1.38 python2-mwclient@0.8.4 python2-natsort@5.4.1 python2-nbxmpp@0.6.9 python2-ndg-httpsclient@0.5.1 python2-neo4j-driver@1.4.0 python2-netcdf4@1.4.2 python2-nltk@3.2.1 python2-nose2@0.6.5 python2-nose-timer@0.7.3 python2-numpy-documentation@1.15.4 python2-odfpy@1.3.3 python2-openid-cla@1.2 python2-openid-teams@1.1 python2-orator@0.9.7 python2-paramunittest@0.2 python2-parsedatetime@2.4 python2-parted@3.11.1 python2-passlib@1.7.1 python2-pastescript@2.0.2 python2-peewee@2.10.2 python2-phonenumbers@8.9.1 python2-pika@0.12.0 python2-plastid@0.4.8 python2-plotly@2.4.1 python2-ply@3.10 python2-polib@1.0.8 python2-publicsuffix2@2.20160818 python2-py2neo@3.1.2 python2-pyaes@1.6.1 python2-pyalsaaudio@0.8.4 python2-pyaudio@0.2.11 python2-pybigwig@0.3.12 python2-pybugz@0.6.11 python2-pycountry@18.5.26 python2-pycryptodome@3.7.3 python2-pydiff@0.2 python2-pydot@1.2.4 python2-pyechonest@9.0.0 python2-pygit2@0.27.3 python2-pykafka@2.4.0 python2-pykka@1.2.1 python2-pylast@2.0.0 python2-pyld@1.0.3 python2-pymysql@0.9.2 python2-pyodbc@4.0.24 python2-pyodbc-c@3.1.4 python2-pyrfc3339@1.1 python2-pystache@0.5.4 python2-pytest-flakes@1.0.1 python2-pytest-subtesthack@0.1.1 python2-pytest-xdist@1.25.0 python2-pyusb@1.0.2 python2-q@2.6 python2-qrcode@6.1 python2-quex@0.68.1 python2-rarfile@2.8 python2-ratelimiter@1.2.0 python2-rdflib@4.2.2 python2-readlike@0.1.3 python2-relatorio@0.8.0 python2-reparser@1.4.3 python2-reportlab@3.5.13 python2-roca-detect@1.0.8 python2-rope@0.11.0 python2-rpython@0.2.1 python2-ruamel.ordereddict@0.4.9 python2-s3cmd@1.6.1 python2-s3transfer@0.1.13 python2-sadisplay@0.4.8 python2-schedule@0.4.3 python2-schema@0.6.6 python2-schematics@1.1.1 python2-scikit-image@0.14.1 python2-screed@1.0 python2-scripttest@1.3 python2-setproctitle@1.1.10 python2-setuptools@40.0.0 python2-shapely@1.6.3 python2-shedskin@0.9.4 python2-slowaes@0.1a1 python2-sockjs-tornado@1.0.6 python2-socksipy-branch@1.01
