Re: Looking for Thunderbird/Icedove
Hello, Björn Höfling skribis: > On Tue, 3 Apr 2018 20:02:23 + > Nils Gillmann wrote: > >> The patches would apply nowhere then, I'm sending a tarball of the >> work. You can ignore the AGPL3 header, it's my default and for what I >> upstream I relicense. >> >> This is Thunderbird 52.6.0, I fear that version newer than 54.x will >> have the same problem I'm debugging in newer Firefox now with >> mandatory rust. >> >> Headsup: The package is wip'ish and generally very ugly in code. > > Thanks for sharing this. I appreciate that you published this in > WIP-state. I just scrolled through the .scm-definition and be impressed > of the length. Will look into the details later. Maybe one of you can post the current patch to guix-patches and people can then work from there? (There’s already a few WIP patches at https://bugs.gnu.org/guix-patches and I think it’s a fine way to let people know that you’ve started working on something but that more work is needed.) Thanks, Ludo’.
Re: 01/01: gnu: Add perl-inline-c.
Ricardo Wurmus skribis: > Nils Gillmann writes: [...] >> Can you tell me why it is safer to say perl-license instead of >> package-license perl? > > Following Ludo’s reference to “(guix licenses)” we can see this comment: > > ;; The license of Perl, GPLv1+ or Artistic (we ignore the latter here). > ;; We define this alias to avoid circular dependencies introduced by the use > ;; of the '(package-license perl)' idiom. Exactly. The problem arose when we started writing (package-license perl) in modules other than perl.scm but that were in a cycle with perl.scm. Ludo’.
Re: [PATCH] gnu: Add systemd.
Hello Guix, Leo Famulari skribis: > On Tue, Apr 03, 2018 at 03:33:22PM -0700, Joshua Branson wrote: >> So this isn't an april fools joke? guixSD may move to systemd? > > It was a joke :) Indeed! That said, if the package can be of any use, I don’t have any objections to its inclusion, especially after all the hard work that Marius and the reviewers put in it. ;-) I suspect the only use case that might work would be running it as an unprivileged user, right? Would that make sense? We’d also have to make sure someone will maintain it though, which is probably a bit of work. Ludo’.
Re: Looking for Thunderbird/Icedove
Ludovic Courtès transcribed 1.1K bytes: > Hello, > > Björn Höfling skribis: > > > On Tue, 3 Apr 2018 20:02:23 + > > Nils Gillmann wrote: > > > >> The patches would apply nowhere then, I'm sending a tarball of the > >> work. You can ignore the AGPL3 header, it's my default and for what I > >> upstream I relicense. > >> > >> This is Thunderbird 52.6.0, I fear that version newer than 54.x will > >> have the same problem I'm debugging in newer Firefox now with > >> mandatory rust. > >> > >> Headsup: The package is wip'ish and generally very ugly in code. > > > > Thanks for sharing this. I appreciate that you published this in > > WIP-state. I just scrolled through the .scm-definition and be impressed > > of the length. Will look into the details later. > > Maybe one of you can post the current patch to guix-patches and people > can then work from there? (There’s already a few WIP patches at > https://bugs.gnu.org/guix-patches and I think it’s a fine way to let > people know that you’ve started working on something but that more work > is needed.) > > Thanks, > Ludo’. > As far as I understood Mark's reply, Mark will work on this and there's no need for my work. For different purposes I'll continue with mine (opt-in optionals somewhere else). Working the coming (54.x version) rust problems with Mozilla based software will be for the benefit of Guix too, so I hope I can tell you how to get past the obstacles created by this.
Python applications that are also libraries
Hi Guix, we have a bunch of packages that are used both as applications and as Python libraries. An example is “deeptools”. As a library we need to propagate other Python inputs; as an application this is not necessary because we have wrappers. I wonder how to deal with this. Should we assume that these packages are used as libraries and default to propagating all Python inputs? Or should we have package variants (or outputs?) that propagate inputs as a side-effect? -- Ricardo
Re: Python applications that are also libraries
Am 04.04.2018 um 11:36 schrieb Ricardo Wurmus: > I wonder how to deal with this. Should we assume that these packages > are used as libraries and default to propagating all Python inputs? Or > should we have package variants (or outputs?) that propagate inputs as a > side-effect? If this is a "pure" application, I'd install it with*out* propagated inputs. This might not be easy to determine, though. https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00456.html -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: An April 1 joke? Re: [PATCH] gnu: Add systemd.
On Mon, 2018-04-02 at 10:38 -0400, Leo Famulari wrote: > On Mon, Apr 02, 2018 at 11:42:16AM +0200, Svante Signell wrote: > > Hi, > > Hi and welcome to the Guix community... Thanks! > > Seeing this on April 1st I really hope it is a joke. If not I'm not > > ever going to support GNU software or anything GNU related any more. > > You should be ashamed of yourselves. > > Yes, it was a joke :) > > Please note that within the Guix mailing lists and IRC chat we do our > best to maintain a friendly and cooperative atmosphere. I was hoping it would be an April 1st joke. And maybe I over-reacted. But fact is that RMS has already abandoned the Free Software community e.g. by continuing to support gnome as a GNU project. So seeing this subject on the guix-devel mailing list, being a GNU project, makes me very sad. And the same happens again: He does not condemn systemd, calling it Free Software due to the GPL license. In my opinion systemd is violating one of the 4 freeedoms of GPL: Freedom 1 (as well as the *NIX and KISS philosophy) * 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. It's really time for a re-definition of Free Software, not only basing such definitions solely on the license at hand. It is also a matter of freedoms of the users of software. Especially in view of that most Free Software nowadays is developed by commercial players, having their own agenda, actively alienating their users (and non-paid, spare time developers).
Re: An April 1 joke? Re: [PATCH] gnu: Add systemd.
Hi, > And the same happens again: He does not condemn systemd, calling it Free > Software due to the GPL license. In my opinion systemd is violating one of > the 4 > freeedoms of GPL: Freedom 1 (as well as the *NIX and KISS philosophy) > * 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. Freedom 1 gives you the right to change the software for yourself, but not the right to force others to change their version. > It's really time for a re-definition of Free Software, not only basing such > definitions solely on the license at hand. It is also a matter of freedoms of > the users of software. Especially in view of that most Free Software nowadays > is > developed by commercial players, having their own agenda, actively alienating > their users (and non-paid, spare time developers). > Do you mean software, where the users can dictate the author what should be changed/made in its software? Martin -- GPG: 7FDE 7190 2F73 2C50 236E 403D CC13 48F1 E644 08EC
Re: An April 1 joke? Re: [PATCH] gnu: Add systemd.
Sorry, I'm not subscribed to this list. Hopefully this reply comes in correct thread order. > Hi, > > > And the same happens again: He does not condemn systemd, calling it Free > > Software due to the GPL license. In my opinion systemd is violating one of > > the 4 > > freeedoms of GPL: Freedom 1 (as well as the *NIX and KISS philosophy) > > * 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. > > > Freedom 1 gives you the right to change the software for yourself, but > not the right to force others to change their version. What made you think of that? I've not said anything about "forcing others to change their version" > > It's really time for a re-definition of Free Software, not only basing such > > definitions solely on the license at hand. It is also a matter of freedoms > of the users of software. Especially in view of that most Free Software > nowadays is developed by commercial players, having their own agenda, actively > alienating their users (and non-paid, spare time developers). > > > > Do you mean software, where the users can dictate the author what should > be changed/made in its software? Again, I don't understand you. Never heard about software where the users have any say in what's being developed except when they pay for it. And as you know money rules. But one fact is that corporations hiring people to develop software are doing that for a purpose (and they all have their own agenda).
Re: An April 1 joke? Re: [PATCH] gnu: Add systemd.
I have to say I also thought you maybe implied what Martin wrote. I think you have some assumptions that I don't understand or have; There definitely looks like some misunderstanding is afoot here. Technically I find systemd to be abhorent, but I don't see how it violates the four freedoms. Please enlighten me if they do. I also wonder what is wrong with the four freedoms? I mean, I think what I understand Ludovic is intending when he says GuixSD is the emacs of operating systems is very important (the ease of exercising the four freedoms); less we end up with docker in vagrant in docker in vagrant in docker ontop of hardware to be able to run a web browser. But if people want to develop and use those kinds of systems I don't see a problem with free software. I see a bunch of other problems, but I have guixsd and don't care to much what everyone chooses (though I'll tell them how wonderful my/our system is). On Wed, 04 Apr 2018 17:33:52 +0200 Svante Signell wrote: > Sorry, I'm not subscribed to this list. Hopefully this reply comes in > correct thread order. > > > Hi, > > > > > And the same happens again: He does not condemn systemd, calling it Free > > > Software due to the GPL license. In my opinion systemd is violating one > > > of the 4 > > > freeedoms of GPL: Freedom 1 (as well as the *NIX and KISS philosophy) > > > * 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. > > > > > > Freedom 1 gives you the right to change the software for yourself, but > > not the right to force others to change their version. > > What made you think of that? I've not said anything about "forcing others to > change their version" > > > > It's really time for a re-definition of Free Software, not only basing > > > such definitions solely on the license at hand. It is also a matter of > > > freedoms > > of the users of software. Especially in view of that most Free Software > > nowadays is developed by commercial players, having their own agenda, > > actively alienating their users (and non-paid, spare time developers). > > > > > > > Do you mean software, where the users can dictate the author what should > > be changed/made in its software? > > Again, I don't understand you. Never heard about software where the users > have any say in what's being developed except when they pay for it. And as > you know money rules. But one fact is that corporations hiring people to > develop software are doing that for a purpose (and they all have their own > agenda). > >
Re: An April 1 joke? Re: [PATCH] gnu: Add systemd.
Hi Svante, Svante Signell writes: > And the same happens again: He does not condemn systemd, calling it Free > Software due to the GPL license. In my opinion systemd is violating one of > the 4 > freeedoms of GPL: Freedom 1 (as well as the *NIX and KISS philosophy) > * 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. Can you elaborate on how you believe systemd is violating Freedom 1? Is your freedom to study systemd, or to change it, being violated somehow? I don't understand. Mark
Re: An April 1 joke? Re: [PATCH] gnu: Add systemd.
Svante Signell writes: > It's really time for a re-definition of Free Software, not only basing such > definitions solely on the license at hand. It is also a matter of freedoms of > the users of software. The Free Software Definition is already expressed in terms of the freedoms of the users of software. It says "A program is free software if the program's users have the four essential freedoms", and then proceeds to list the 4 freedoms: https://www.gnu.org/philosophy/free-sw.html What do you believe is missing from the definition of free software? How would you propose to change it? Regards, Mark
Re: An April 1 joke? Re: [PATCH] gnu: Add systemd.
Hi all, I think that discussions about systemd, the stated or suspected motivations of its developers, and how it relates to free software are not really on-topic for this list. For discussions of the implications for developers of GNU+Linux distributions that are currently using systemd, and whether or not free distributions should use it, I would like to suggest to move this discussion to gnu-system-discuss or a similar list. This list is for the development of Guix and GuixSD, which does not need or use systemd, so a discussion about systemd wouldn’t have any effect on the design of GuixSD anyway. Thanks! -- Ricardo
Re: Python applications that are also libraries
Hartmut Goebel writes: > Am 04.04.2018 um 11:36 schrieb Ricardo Wurmus: >> I wonder how to deal with this. Should we assume that these packages >> are used as libraries and default to propagating all Python inputs? Or >> should we have package variants (or outputs?) that propagate inputs as a >> side-effect? > > If this is a "pure" application, I'd install it with*out* propagated > inputs. This might not be easy to determine, though. It is both. It is often used just as an application, but the procedures that make up the application are just as often used in an interactive Python session or as a library. > https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00456.html This is about wrapping (or not) using virtual envs. I don’t really see how this relates to this problem, but maybe I’m missing something obvious. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: An April 1 joke? Re: [PATCH] gnu: Add systemd.
Memory might serve me wrong, but I think we had such a april's fool in the last years before and it backfired equally *and* we agreed on not doing it again? Would be good if people had more sense for spotting sarcasm and humor, but not everyone has this.
Re: An April 1 joke? Re: [PATCH] gnu: Add systemd.
Hello, On Wed, Apr 04, 2018 at 02:49:51PM +0200, Svante Signell wrote: ... And the same happens again: He does not condemn systemd, calling it Free Software due to the GPL license. In my opinion systemd is violating one of the 4 freeedoms of GPL: Freedom 1 (as well as the *NIX and KISS philosophy) * 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. It's really time for a re-definition of Free Software, not only basing such definitions solely on the license at hand. It is also a matter of freedoms of the users of software. Especially in view of that most Free Software nowadays is developed by commercial players, having their own agenda, actively alienating their users (and non-paid, spare time developers). could please you explain me your point of view? I can see systemd's source code published on github with the license guaranteeing me that I can study it and fork it to change it. Best regards, S_W signature.asc Description: PGP signature
Re: An April 1 joke? Re: [PATCH] gnu: Add systemd.
Nils Gillmann writes: > Memory might serve me wrong, but I think we had such a april's fool > in the last years before and it backfired equally *and* we agreed > on not doing it again? I don’t think this happened. I only found one in 2014: https://lists.gnu.org/archive/html/guix-devel/2014-04/msg0.html (I wonder how the work to rewrite Guix in ECMAscript is coming along…) In other years we don’t seem to have had any April Fools posting on guix-devel, as far as I can see, which is a little sad :) I for one am looking forward to the next one. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Looking for Thunderbird/Icedove
On Wed, 04 Apr 2018 01:14:53 -0400 Mark H Weaver wrote: > No promises, but I'll try to find time in the next few days to make an > attempt at an Icedove package. As de-facto maintainer of the IceCat > package in Guix, I suppose that I'm well-positioned to work on this, > and I certainly agree that Guix should include Icedove. > > Regards, >Mark Sounds nice. Thanks for doing that work. Björn pgpdMnw3vUHMq.pgp Description: OpenPGP digital signature
Treating tests as special case
Last night I was watching Rich Hickey's on Specs and deployment. It is a very interesting talk in many ways, recommended. He talks about tests at 1:02 into the talk: https://www.youtube.com/watch?v=oyLBGkS5ICk and he gave me a new insight which rang immediately true. He said: what is the point of running tests everywhere? If two people test the same thing, what is the added value of that? (I paraphrase) With Guix a reproducibly building package generates the same Hash on all dependencies. Running the same tests every time on that makes no sense. And this hooks in with my main peeve about building from source. The building takes long enough. Testing takes incredibly long with many packages (especially language related) and are usually single core (unlike the build). It is also bad for our carbon foot print. Assuming everyone uses Guix on the planet, is that where we want to end up? Burning down the house. Like we pull substitutes we could pull a list of hashes of test cases that are known to work (on Hydra or elsewhere). This is much lighter than storing substitutes, so when the binaries get removed we can still retain the test hashes and have fast builds. Also true for guix repo itself. I know there are two 'inputs' I am not accounting for: (1) hardware variants and (2) the Linux kernel. But, honestly, I do not think we are in the business of testing those. We can assume these work. If not, any issues will be found in other ways (typically a segfault ;). Our tests are generally meaningless when it comes to (1) and (2). And packages that build differently on different platforms, like openblas, we should opt out on. I think this would be a cool innovation (in more ways than one). Pj.
WIP-packages (Was: Looking for Thunderbird/Icedove)
On Wed, 04 Apr 2018 10:34:10 +0200 l...@gnu.org (Ludovic Courtès) wrote: > Maybe one of you can post the current patch to guix-patches and people > can then work from there? (There’s already a few WIP patches at > https://bugs.gnu.org/guix-patches and I think it’s a fine way to let > people know that you’ve started working on something but that more > work is needed.) The idea of "WIP" (Work in Progress) package tickets is great: Guix is a collaborative project and we can share the efford we made so far to pack a certain piece of software. We all have our reasons to start and stop working on a package definition. If in the meantime someone else has the same idea, they don't need to start thinking about the same start problems again. Björn pgp2vCMbF_1mZ.pgp Description: OpenPGP digital signature
Re: Treating tests as special case
2018-04-05 7:24 GMT+02:00 Pjotr Prins : > Last night I was watching Rich Hickey's on Specs and deployment. It is > a very interesting talk in many ways, recommended. He talks about > tests at 1:02 into the talk: > > https://www.youtube.com/watch?v=oyLBGkS5ICk > > and he gave me a new insight which rang immediately true. He said: > what is the point of running tests everywhere? If two people test the > same thing, what is the added value of that? (I paraphrase) Actually running tests test the behaviour of a software. Unfortunately reproducible build does not guarantee reproducible behaviour. Furthermore there are still cases, where the environment is not the same around these running software, like hardware or kernel configuration settings leaking into the environment. These can be spotted by running tests. Nondeterministic failures can also be spotted more easily. There are a lot of packages where pulling tests can be done, I guess, but probably not for all of them. WDYT? > > With Guix a reproducibly building package generates the same Hash on > all dependencies. Running the same tests every time on that makes no > sense. > > And this hooks in with my main peeve about building from source. The > building takes long enough. Testing takes incredibly long with many > packages (especially language related) and are usually single core > (unlike the build). It is also bad for our carbon foot print. Assuming > everyone uses Guix on the planet, is that where we want to end up? > > Burning down the house. > > Like we pull substitutes we could pull a list of hashes of test cases > that are known to work (on Hydra or elsewhere). This is much lighter > than storing substitutes, so when the binaries get removed we can > still retain the test hashes and have fast builds. Also true for guix > repo itself. > > I know there are two 'inputs' I am not accounting for: (1) hardware > variants and (2) the Linux kernel. But, honestly, I do not think we > are in the business of testing those. We can assume these work. If > not, any issues will be found in other ways (typically a segfault ;). > Our tests are generally meaningless when it comes to (1) and (2). And > packages that build differently on different platforms, like openblas, > we should opt out on. > > I think this would be a cool innovation (in more ways than one). > > Pj. > >
Re: Treating tests as special case
On Thu, 5 Apr 2018 07:24:39 +0200 Pjotr Prins wrote: > Last night I was watching Rich Hickey's on Specs and deployment. It is > a very interesting talk in many ways, recommended. He talks about > tests at 1:02 into the talk: > > https://www.youtube.com/watch?v=oyLBGkS5ICk > > and he gave me a new insight which rang immediately true. He said: > what is the point of running tests everywhere? If two people test the > same thing, what is the added value of that? (I paraphrase) > > With Guix a reproducibly building package generates the same Hash on > all dependencies. Running the same tests every time on that makes no > sense. > > And this hooks in with my main peeve about building from source. The > building takes long enough. Testing takes incredibly long with many > packages (especially language related) and are usually single core > (unlike the build). It is also bad for our carbon foot print. Assuming > everyone uses Guix on the planet, is that where we want to end up? > > Burning down the house. > > Like we pull substitutes we could pull a list of hashes of test cases > that are known to work (on Hydra or elsewhere). This is much lighter > than storing substitutes, so when the binaries get removed we can > still retain the test hashes and have fast builds. Also true for guix > repo itself. > > I know there are two 'inputs' I am not accounting for: (1) hardware > variants and (2) the Linux kernel. But, honestly, I do not think we > are in the business of testing those. We can assume these work. If > not, any issues will be found in other ways (typically a segfault ;). > Our tests are generally meaningless when it comes to (1) and (2). And > packages that build differently on different platforms, like openblas, > we should opt out on. > > I think this would be a cool innovation (in more ways than one). > > Pj. Hi Pjotr, great ideas! Last night I did a guix pull && guix package -i git We have substitutes, right? Yeah, but someone updated git, on my new machine I didn't configure berlin.guixsd.org yet and hydra didn't have any substitutes (build wasn't started yet?). Building git was relatively fast, but all the tests took ages. And it was just git. It should work. The git maintainers ran the tests. Marius when he updated it in commit 5c151862c ran the tests. And that should be enough of testing. Let's skip the tests. On the other hand, if I create a new package definition and forget to run the tests. If upstream is too sloppy, did not run the tests and had no continuous integration. Who will run the tests then? What if I build my package with different sources? And you mentioned different environment conditions like machine and kernel. We still have "only" 70-90% reproducibility. The complement should have tests enabled. And the question "is my package reproducible?" is not trivial to answer, and is not computable. We saw tests that failed only in 2% of the runs and were fine in 98%. If we would run those tests "just once", we couldn't figure out that there is a problem (assuming the problem really is in the software, not just the tests). There could also be practible problems with that: If all write there software nice and with autoconfigure and we just have a "make && make test && make install" it's easy to skip the test. But for more complicated things we have to find a way to tell the build-system how to skip tests. Björn pgp7GsKlVeXcX.pgp Description: OpenPGP digital signature
