Re: Video Documentation for GNU GUIX (an Outreachy project)
I would also like to know how to get the tracker number for the patch file
tracker.
Regards,
Lakshmi Prasannakumar
Bangalore
On Wed, Oct 31, 2018 at 10:15 AM Lakshmi Prasannakumar <
lakshmiprasannakuma...@gmail.com> wrote:
> Hi Björn and Gábor,
>
> I've sent the patch file to the patch tracker.
> Now I understand next this is to send you the timeline proposal for the
> internship period , is it so?
> The patch submission took me a little while since my system needed an
> update due to ubuntu version becoming obsolete.
>
> Thanks,
> Lakshmi Prasannakumar
> Bangalore
>
>
> On Tue, Oct 30, 2018 at 11:50 PM Lakshmi Prasannakumar <
> lakshmiprasannakuma...@gmail.com> wrote:
>
>> Thanks Gábor,
>> I'll make these changes and make a patch file and try to send across.
>>
>> Lakshmi Prasannakumar
>> Bangalore
>>
>>
>> On Tue, Oct 30, 2018 at 2:28 AM Gábor Boskovits
>> wrote:
>>
>>> Hello Lakshmi,
>>>
>>> I did a preliminary review, that can make this contribution faster.
>>> Here are my comments:
>>>
>>> (package
>>> (name "r-weights")
>>> (version "1.0")
>>> (source
>>> (origin
>>> (method url-fetch)
>>> (uri (cran-uri "weights" version))
>>> (sha256
>>> (base32
>>> "0186bfpkhxngrshac6bpg37alp6slwhwd43inrm8hqg0vhpfgc4c"
>>> (build-system r-build-system)
>>> (propagated-inputs
>>> `(("r-gdata" ,r-gdata)
>>> ("r-hmisc" ,r-hmisc)
>>> ("r-mice" ,r-mice)))
>>> (home-page
>>> "http://cran.r-project.org/web/packages/weights;)
>>> (synopsis "Weighting and Weighted Statistics")
>>>
>>> Please use lower case for all words except the first.
>>> The importer cannot find out which letters should be lower case,
>>> this has to be done manually.
>>>
>>> (description
>>> "Provides a variety of functions for producing simple weighted
>>> statistics, such as weighted Pearson's correlations, partial
>>> correlations, Chi-Squared statistics, histograms, and t-tests. Also
>>> now includes some software for quickly recoding survey data and
>>> plotting point estimates from interaction terms in regressions (and
>>> multiply imputed regressions). NOTE: Weighted partial correlation
>>> calculations pulled to address a bug.")
>>>
>>> Please, try to repharse this so that it has whole sentences, for
>>> example like "This package provides...".
>>>
>>> (license gpl2+))
>>>
>>> With these small modifications this looks good to me.
>>>
>>
Re: Video Documentation for GNU GUIX (an Outreachy project)
Hi Björn and Gábor,
I've sent the patch file to the patch tracker.
Now I understand next this is to send you the timeline proposal for the
internship period , is it so?
The patch submission took me a little while since my system needed an
update due to ubuntu version becoming obsolete.
Thanks,
Lakshmi Prasannakumar
Bangalore
On Tue, Oct 30, 2018 at 11:50 PM Lakshmi Prasannakumar <
lakshmiprasannakuma...@gmail.com> wrote:
> Thanks Gábor,
> I'll make these changes and make a patch file and try to send across.
>
> Lakshmi Prasannakumar
> Bangalore
>
>
> On Tue, Oct 30, 2018 at 2:28 AM Gábor Boskovits
> wrote:
>
>> Hello Lakshmi,
>>
>> I did a preliminary review, that can make this contribution faster.
>> Here are my comments:
>>
>> (package
>> (name "r-weights")
>> (version "1.0")
>> (source
>> (origin
>> (method url-fetch)
>> (uri (cran-uri "weights" version))
>> (sha256
>> (base32
>> "0186bfpkhxngrshac6bpg37alp6slwhwd43inrm8hqg0vhpfgc4c"
>> (build-system r-build-system)
>> (propagated-inputs
>> `(("r-gdata" ,r-gdata)
>> ("r-hmisc" ,r-hmisc)
>> ("r-mice" ,r-mice)))
>> (home-page
>> "http://cran.r-project.org/web/packages/weights;)
>> (synopsis "Weighting and Weighted Statistics")
>>
>> Please use lower case for all words except the first.
>> The importer cannot find out which letters should be lower case,
>> this has to be done manually.
>>
>> (description
>> "Provides a variety of functions for producing simple weighted
>> statistics, such as weighted Pearson's correlations, partial
>> correlations, Chi-Squared statistics, histograms, and t-tests. Also
>> now includes some software for quickly recoding survey data and
>> plotting point estimates from interaction terms in regressions (and
>> multiply imputed regressions). NOTE: Weighted partial correlation
>> calculations pulled to address a bug.")
>>
>> Please, try to repharse this so that it has whole sentences, for
>> example like "This package provides...".
>>
>> (license gpl2+))
>>
>> With these small modifications this looks good to me.
>>
>
Re: Trying to crosscompile for POWER9
Hi Tobias! Thank you for trying things out for POWER9! I'm also interested in this platform, although I have to admit I don't own any hardware (yet!) and haven't tried it out. I've only read about it so far. Tobias Platen writes: > On 10/22/2018 06:39 PM, Leo Famulari wrote: >> On Sun, Oct 21, 2018 at 08:30:03AM +0200, Tobias Platen wrote: >>> On 10/20/2018 09:09 PM, Tobias Platen wrote: >>> Here are the build logs from guix. I have tried building the toolchain >>> twice, but in both cases glibc failed to build. >> >> [...] >> >>> running configure fragment for sysdeps/powerpc/powerpc64/le >>> checking if powerpc64le-linux-gcc supports binary128 floating point >>> type... no >>> checking if the target machine is at least POWER8... yes >>> configure: error: *** binary128 floating point type (GCC >= 6.2) is >>> required on powerpc64le. >> >> Searching around, I found other distros hit the same problem for their >> POWER ports, and needed to explicitly configure GCC >= 6.2 to build with >> 128-bit floating point types. Specifically, with the option >> '--with-long-double-128': >> >> https://github.com/advancetoolchain/advance-toolchain/commit/e22696eecb39c6b401df14001f01608807e4d934 >> http://lists.busybox.net/pipermail/buildroot/2017-August/200952.html >> >> I hope that helps! >> > I modified the file "gnu/packages/cross-base.scm" and the cross gcc > still does not support 128-bit floating point types. How do I trigger > a rebuild of the cross compiler so I can verify that it is configured > correctly. You can try to cross-build something as usual, I suppose. It's a bit heavy-handed, since it will try to build the entire cross-compilation toolchain also, but it might work. To see if you can build *just* the cross-compiler, you might need to get tricky. For example, you might need to break out a Guile REPL, load some Guix modules, and manually hack around with some of the code in gnu/packages/cross-base.scm. In theory, you ought to be able to create a package or a derivation that builds the cross-compiler you are using, or a cross-compiler that is similar to it. That's all the advice I can think of right now. You're not alone - I've fumbled around quite a bit while learning how Guix does its cross-compilation and bootstrapping. It's not easy going, but hopefully you will be able to find a way forward. Good luck! -- Chris signature.asc Description: PGP signature
Re: guix development
Hi Ali, Ali Nourmohammadi writes: > thank's for your reply. > but lxqt is not defined as a service, right? > so how could i install that? There is no need to define lxqt as a shepherd service. lxqt should be started by a display manager, like SLiM or SDDM. If you include %desktop-services in your config.scm, then you have slim installed by default. Simply install lxqt and shoose lxqt from your login screen to start lxqt. Again. Please CC guix-devel@gnu.org when you reply email. -- Meiyo Peng
Berlin is down
Hi, Berlin (https://berlin.guixsd.org) is down. Cheers, Clément
Re: guix pull: error: symlink: File exists
On Tue, Oct 30, 2018 at 5:05 PM Thorsten Wilms wrote: > Looking for an explanation for having user and root profile guix, since > you seem to be unaware of how that works and I can't be sure of my own > understanding, I found something related: > https://lists.gnu.org/archive/html/help-guix/2017-10/msg00014.html > > Thing is, I did > `ln -s /var/guix/profiles/per-user/root/guix-profile/bin/guix > /usr/local/bin/guix` > during installation and that symlink is still intact. Yet, `guix pull` > and `sudo guix pull` are markedly different. > I see, then I will try to go back to my VM snapshot before I first made a guix pull when trying commands - then I don't understand why the first time it worked for me - and make the symlink, because I need to have it working, and I would like to have it for my user - yes my user can run sudo, but that's not the point - :( > -- > Thorsten Wilms > > thorwil's design for free software: > http://thorwil.wordpress.com/ > > Regards! Laura
Re: [Outreachy] Recording My Contribution
Hello Floridah, Ricardo Wurmus ezt írta (időpont: 2018. okt. 30., K, 22:02): > > > Hello! > > > 2.GNU Guix project #1 > I am one of the mentors of this project. > Thanks for your interest in Guix! > > To contact the Guix project please write a short email to the > guix-devel@gnu.org mailing list to introduce yourself and to get in > touch with the mentors of the video documentation project. > > A common first task is to install Guix on top of a GNU/Linux > distribution of your choice; a good first contribution is to create a > new package definition for an R package from the CRAN repository. You > can get 80% of the work done by using the importer “guix import cran -r > name”. > Yes, installing Guix and getting an R package from CRAN can still be done on time. > I also strongly recommend connecting to the #guix IRC channel on > irc.freenode.net for real-time chat with the community. The community > can help you solve problems that are normal for new contributors. > > Hope to meet you there! > Also hope to meet you there! > -- > Ricardo (co-maintainer of GNU Guix) > > ___ > Mentors mailing list > ment...@lists.outreachy.org > https://lists.outreachy.org/cgi-bin/mailman/listinfo/mentors Best regards, g_bor
Re: guix pull: error: symlink: File exists
On 30/10/2018 19.16, Laura Lazzati wrote: At the same time, a `sudo guix pull` works fine. Thanks for this finding. Sorry, I thought this fixed it for me too, but now every time I run an installed package, I get that guix is 18 days old, asks me to guix pull, and if I run even the hello package, i get that it is not installed and claims to install it with, in my case, apt. Sorry Laura, I did not mean to suggest that this was a fix. It's just that `guix pull` for the root profile stayed functional. My own plain user `guix pull` still results in the same old: Migrating profile generations to '/var/guix/profiles/per-user/thorwil'... guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/thorwil/current-guix-1-link" Looking for an explanation for having user and root profile guix, since you seem to be unaware of how that works and I can't be sure of my own understanding, I found something related: https://lists.gnu.org/archive/html/help-guix/2017-10/msg00014.html Thing is, I did `ln -s /var/guix/profiles/per-user/root/guix-profile/bin/guix /usr/local/bin/guix` during installation and that symlink is still intact. Yet, `guix pull` and `sudo guix pull` are markedly different. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/
Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)
Thanks to Mark H Weaver for writing ... how to say .. the mirror perspective of what I wish I would have written as sole input so far :) On 30/10/2018 14.28, Christopher Lemmer Webber wrote: It used to be that you could pick a Free Software project and send a patch. Now sending a patch is supposed to imply agreeing to the equivalent of an EULA? Everyone is expected to welcome that as progress? The statement above makes it sound like the Code of Conduct is dramatically new. It is based on the fact that there are many projects that existed for some time before adopting a CoC. The EULA comparison is only about CoCs with "covenant" and "we contributors pledge" type of language. While benefiting from and accepting a copyleft license is pretty much a precondition for a patch, that is not the case for a CoC that tries to bind one on contribution. My claim here was that in both cases, there is a policy the community has adopted. One is legal and copyleft, the other is behavioral and a code of conduct. In both cases, your participation in this community is dependent on your willingness to agree to respect the policies and norms that the group upholds. Submitting a patch might involve only the most minimal interaction with one maintainer. Staying within a very narrow subset of rules that a group might uphold should suffice to cause no harm to anyone while allowing people to benefit from the work. The group is not clearly delineated. The actual norms are only shown in how the maintainers and regulars act. The code of conduct does not provide a legal enforcement mechanism, so the EULA comment in that sense does not hold up; this is just a codification of some of the norms that we have. But someone made the EULA comment, and the extent that it *did* make sense (that there are policies, in some way), I wanted to reply to it. What I had in mind is: Unpacking an old-school software that has a shrink-wrap EULA is meant to imply acceptance of the license. Likewise, contributing to Guix is apparently meant to imply that one makes the pledge as outlined in that CoC. In both cases, you are meant to not get one without the other. It happened that one could not read the EULA in advance and it happened that I contributed before reading the CoC carefully. I distrust it's origin and I'm not happy about a few details, though they most likely will never matter. So I could almost, but not quite make such a promise, but I cannot be made to make such a promise. Especially retroactively. Even less can I be made to make a promise that might change: I assume that Ricardo and Ludovic want to have the option of editing the CoC without asking every single contributor. Well, people should better know what the current state of their pledge is. Not that I think the two would introduce a nasty surprise, it's just that the "covenant" and "we as contributors ... pledge" language is dishonest. Reject a contribution, talk to me, warn me, set an ultimatum, ban me if I did wrong by your norms as you see fit, that's all fine and expected with or without CoC anyway, but please don't try to make me say: those norms are mine (independent on whether they could be). If I sound like a drama royal person ... so be it! ;) -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/
Re: Video Documentation for GNU GUIX (an Outreachy project)
Thanks Gábor,
I'll make these changes and make a patch file and try to send across.
Lakshmi Prasannakumar
Bangalore
On Tue, Oct 30, 2018 at 2:28 AM Gábor Boskovits wrote:
> Hello Lakshmi,
>
> I did a preliminary review, that can make this contribution faster.
> Here are my comments:
>
> (package
> (name "r-weights")
> (version "1.0")
> (source
> (origin
> (method url-fetch)
> (uri (cran-uri "weights" version))
> (sha256
> (base32
> "0186bfpkhxngrshac6bpg37alp6slwhwd43inrm8hqg0vhpfgc4c"
> (build-system r-build-system)
> (propagated-inputs
> `(("r-gdata" ,r-gdata)
> ("r-hmisc" ,r-hmisc)
> ("r-mice" ,r-mice)))
> (home-page
> "http://cran.r-project.org/web/packages/weights;)
> (synopsis "Weighting and Weighted Statistics")
>
> Please use lower case for all words except the first.
> The importer cannot find out which letters should be lower case,
> this has to be done manually.
>
> (description
> "Provides a variety of functions for producing simple weighted
> statistics, such as weighted Pearson's correlations, partial
> correlations, Chi-Squared statistics, histograms, and t-tests. Also
> now includes some software for quickly recoding survey data and
> plotting point estimates from interaction terms in regressions (and
> multiply imputed regressions). NOTE: Weighted partial correlation
> calculations pulled to address a bug.")
>
> Please, try to repharse this so that it has whole sentences, for
> example like "This package provides...".
>
> (license gpl2+))
>
> With these small modifications this looks good to me.
>
Re: guix pull: error: symlink: File exists (was: Re: [outreachy] Further steps)
On Thu, Oct 25, 2018 at 4:08 PM Gábor Boskovits wrote: > > > Thorsten Wilms ezt írta (időpont: 2018. okt. 25., Cs > 20:06): > >> >> >> Hi, this error happened here, too, also on a foreign distro, without any >> extra steps. >> >> --- >> Migrating profile generations to '/var/guix/profiles/per-user/thorwil'... >> guix pull: error: symlink: File exists: >> "/var/guix/profiles/per-user/thorwil/current-guix-1-link" >> --- >> >> At the same time, a `sudo guix pull` works fine. >> > > Thanks for this finding. > Sorry, I thought this fixed it for me too, but now every time I run an installed package, I get that guix is 18 days old, asks me to guix pull, and if I run even the hello package, i get that it is not installed and claims to install it with, in my case, apt. > >> >> -- >> Thorsten Wilms >> >> thorwil's design for free software: >> http://thorwil.wordpress.com/ >> > Regards, Laura
Dual Boot GuixSd along side other preexisting distros
Hi Guys, Can you guys please help me with a bit of understanding? I have a ThinkPad T410 on which I am trying to do this. Currently I have a dual boot configuration running Ubuntu and Windows 7. Could that grub install failure because of my /boot not being empty and formatted afresh for GuixSD? If so, can anyone of you please help me in figuring out how to install GuixSD alongside those existing ones(other distros plus special Mr. Windows)? Do I need to reformat my /boot to make it fresh so that Grub install from GuixSD installation could succeed(not sure if this is the reason for failure). if a reformatting is imminent, what will you suggest to do on case I just need to recover my old stuff? Thanks and Regards Nalin Ranjan
Re: guix development
Hi Ali, Ali Nourmohammadi writes: > Hi mr.meiyo peng > Can u tell me how can i install that from local directory. i need to do that. > thank u Sorry, I don't understand what you mean by "install that from local directory". You simply install lxqt as any other package. - Run `guix pull` to update guix. - Add lxqt to your config.scm. - Run `guix system reconfigure config.scm`. I suggest you to read the guix manual first if you have any question. And please CC this mailing list when you reply email. -- Meiyo Peng
Re: [Outreachy] First version of my proposed timeline
> Looks good to me so far. > Thanks! > > If anyone would like to see a more details please write you comments. > Thanks! > Yes, please :) As I mentioned, I sent it more than a week before the deadline so that we can discuss it in case anyone feels that something should be changed, personally I try to avoid sending last minute forms, so I will try to apply for Outreachy at most one day before, just in case something happens, and also to create my personal timeline or TODO list for November. I also have one more question: In the application form, there is a field: (Optional) Community-specific Questions: Some communities or projects may want you to answer additional questions. Please check with your mentor and community coordinator to see if you need to provide any additional information after you save your project application. Would you like me to add something there? > > Best regards, > g_bor > Regards! Laura
Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)
Mark H Weaver writes: > Christopher Lemmer Webber writes: > >> Thorsten Wilms writes: >> >>> On 29/10/2018 09.59, Björn Höfling wrote: In law, there is the term of "conduct implying an intent". So even not signing anything you could argue that by sending a bug or a patch you silently agree with the community guidelines, CoC, etc. You enter the community be interacting the first time. And will be judged by their guidelines. >>> >>> It used to be that you could pick a Free Software project and send a patch. >>> >>> Now sending a patch is supposed to imply agreeing to the equivalent of >>> an EULA? Everyone is expected to welcome that as progress? >> >> Submitting code to a project under a copyleft license is also agreeing >> to policy. > > What is the basis for this claim? > > While I'm generally in favor of the CoC, I strongly oppose the idea that > submitting a patch or communicating with us implies automatic agreement > to our policies. > > We should not claim that someone has "agreed" to anything without their > conscious knowledge and consent. Even if the law would allow us to make > such a claim, we should not do it because it would be unjust. > > Please, it is enough to make our policies clear and highly visible, to > encourage people to read them, and to give the lead project maintainers > the authority to issue warnings, and if deemed necessary, to ban people > from our communication channels who repeatedly or severely violate our > CoC. I support that practice, as long as it's used judiciously, and I > have every confidence in Ludovic and Ricardo to do so. > > We do _not_ need to extract promises from contributors ahead of time > that they will follow our policies, and I think it's a bad idea to ask > them to. It's a worse idea to claim that they've done so implicitly > without their knowledge or consent. > > Mark I suspect we do not disagree Mark, but the way in which you replied to me makes it sound like we do, so let me clarify. :) My short reply was because I was trying to demonstrate, in few words, that the message I was replying to was introducing an inaccuracy. I did not clarify what that was, but I will below. We accept many patches from users where the user does not sign an actual document, but their patch and their name applied on the top is considered sufficient evidence that they have declared their code to be licensed under the GPL. But I should clarify the claim I was making, since I was not trying to say that the legal or mechanistic aspects of this were equivalent. Let me quote what was I was replying to: >>> It used to be that you could pick a Free Software project and send a patch. >>> >>> Now sending a patch is supposed to imply agreeing to the equivalent of >>> an EULA? Everyone is expected to welcome that as progress? The statement above makes it sound like the Code of Conduct is dramatically new. My claim here was that in both cases, there is a policy the community has adopted. One is legal and copyleft, the other is behavioral and a code of conduct. In both cases, your participation in this community is dependent on your willingness to agree to respect the policies and norms that the group upholds. What's interesting to me is that this isn't new at all, it's just codified for some specific things. The Code of Conduct is not a legal document, it is a set of policies about community norms. Many of these norms already existed, and the same process (speak to the person, ask them to change their behavior, if we can't fix it, yes they may be banned) has existed for a long time in free software circles. What is new from the code of conduct perspective is making explicit what some of those norms are, and what participants can expect if they are not upheld. I have seen some accusations that this is censorship or an overreach or equivalent to an EULA to have these norms enforced. And yet the free software community, and especially GNU projects, have long been enforcing of policies. Copyleft is a mechanism for enforcement of policies by law, but even beyond that, I think most of the members of this group would find it perfectly acceptable to ban someone who began to post patches to the list under a license that was incompatible with the GPL and which "poisoned" our ability to use them upon seeing them. The former is a legal agreement, the latter is a norms agreement, but they are both policy, and by participating in our group in general you have an understanding that these policies exist. The code of conduct does not provide a legal enforcement mechanism, so the EULA comment in that sense does not hold up; this is just a codification of some of the norms that we have. But someone made the EULA comment, and the extent that it *did* make sense (that there are policies, in some way), I wanted to reply to it. The free software community has always had policies, has always asked people to respect language, has always had the
Re: Leiningen follow-up
Hello Brett,
Back then, I tried to package leiningen because many clojure libraries
use leiningen as their build systems. However, it turns out that
leiningen depends on leiningen-core[0], which it turns depends on
wagon-http[1], which requires maven. Maven was not packaged then, and if
I recall correctly, it was very tricky to package because it has many
dependencies and it requires itself to build. I gave up after some
time.
Forwarding to the present, thanks to Julien, Gábor and others, we now
have many java packages in guix, including maven. Perhaps it is now
easier to package leiningen (I didn't check).
Earlier this year, I have plan to setup a simple clojure build system
which only use plain old 'compile' in clojure. It is now almost
finish (I was busy at school). I haven't send them to guix-patches yet
because it still lacks accurate documentation and selective compilation
is not working properly yet. The patches are included below for your
reference. I also include 5 packages for testing purpose.
From 3e9074b84bbae63c8e4c636257954db59b12279c Mon Sep 17 00:00:00 2001
From: Alex Vong
Date: Fri, 12 Oct 2018 17:58:00 +0800
Subject: [PATCH 01/11] gnu: clojure: Move from java to lisp.
* gnu/packages/java.scm (clojure): Move from here...
* gnu/packages/lisp.scm (clojure): ...to here.
---
gnu/packages/java.scm | 145 -
gnu/packages/lisp.scm | 147 ++
2 files changed, 147 insertions(+), 145 deletions(-)
diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
index f6d72edee..cea3c4e33 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -1803,151 +1803,6 @@ new Date();"))
`(("java-junit" ,java-junit)
,@(package-inputs ant/java8)
-(define-public clojure
- (let* ((remove-archives '(begin
- (for-each delete-file
- (find-files "." ".*\\.(jar|zip)"))
- #t))
- (submodule (lambda (prefix version hash)
- (origin
-(method url-fetch)
-(uri (string-append "https://github.com/clojure/;
-prefix version ".tar.gz"))
-(sha256 (base32 hash))
-(modules '((guix build utils)))
-(snippet remove-archives)
-(package
- (name "clojure")
- (version "1.9.0")
- (source
- (origin
- (method url-fetch)
- (uri
- (string-append "https://github.com/clojure/clojure/archive/clojure-;
- version ".tar.gz"))
- (sha256
- (base32 "0xjbzcw45z32vsn9pifp7ndysjzqswp5ig0jkjpivigh2ckkdzha"))
- (modules '((guix build utils)))
- (snippet remove-archives)))
- (build-system ant-build-system)
- (arguments
- `(#:modules ((guix build ant-build-system)
-(guix build utils)
-(ice-9 ftw)
-(ice-9 regex)
-(srfi srfi-1)
-(srfi srfi-26))
- #:test-target "test"
- #:phases
- (modify-phases %standard-phases
- (add-after 'unpack 'unpack-submodule-sources
- (lambda* (#:key inputs #:allow-other-keys)
- (for-each
-(lambda (name)
- (mkdir-p name)
- (with-directory-excursion name
-(invoke "tar"
-;; Use xz for repacked tarball.
-"--xz"
-"--extract"
-"--verbose"
-"--file" (assoc-ref inputs name)
-"--strip-components=1"))
- (copy-recursively (string-append name "/src/main/clojure/")
-"src/clj/"))
-'("core-specs-alpha-src"
- "data-generators-src"
- "spec-alpha-src"
- "test-check-src"
- "test-generative-src"
- "tools-namespace-src"))
- #t))
- (add-after 'unpack 'fix-manifest-classpath
- (lambda _
- (substitute* "build.xml"
- (("") ""))
- #t))
- ;; The javadoc target is not built by default.
- (add-after 'build 'build-doc
- (lambda _
- (invoke "ant" "javadoc")))
- ;; Needed since no install target is provided.
- (replace 'install
- (lambda* (#:key outputs #:allow-other-keys)
- (let ((java-dir (string-append (assoc-ref outputs "out")
- "/share/java/")))
- ;; Install versioned to avoid collisions.
- (install-file (string-append "clojure-" ,version ".jar")
-
Re: [Outreachy] First version of my proposed timeline
Hello Laura, Laura Lazzati ezt írta (időpont: 2018. okt. 29., H, 22:50): > > Hi everyone! > > Here goes my first version of the proposed timeline. I wanted to send it > today so that we have enough time to refine it. > I wrote it taking into account the number of Weeks, the days of the month > implied in that week, and the month/year. > > WEEK1: 4-10 (December 2018) > * Study more deeply Guix and GuixSD to have fresh all the needed concepts for > making the videos. > - Read in detail all the available documentation. > - Practice commands or some of their options for which or there was > not enough time during the application for Outreachy and are important for > making the videos, workflows, GuixSD,so on. > - Read my daily journal with notes about how I faced different issues and > solved them during application, > > WEEK2 and WEEK3: 11 - (December 2018) > Study in detail video editing concepts and stack of tools needed for them. > - Video creation and editing concepts (maybe a tutorial?) > - Tools that will be used and needed for creating the videos. > > WEEK3 and WEEK4: - 31 (December 2018) > * Create prototype for first video needed: for example: Installation of Guix > on top of Another distro. > - Create ideas to include in the video and narration. > - create slideshow > - create localized cli > - Generate narration and subtitles. > - Take into account 3 minute timing > * Do more refinement to the English video until it is accepted by the > community > * Push it to the repo for guix members. > > WEEK5: 1-7 (January 2019) > * When video in English with English subtitled is accepted, translate it to > Spanish to have a workflow for other languages. > - translate slideshow, cli, narration and subtitles. > - Generate the new video > * Document the accepted process for the first video. > > WEEK6: 8-14 > * Create the remaining videos about Installation: > -GuixSD on a VM. > -GuixSD on bare metal. > > WEEK7: 15-21 > * Create videos for daily users: > - Using guix package command for installing, upgrading, and removing > packages, and concepts that might arise - ie: transactional. > - Having guix up to date, concept of garbage collector, possibility of > sharing packages with people who do not have guix (yet) > > > WEEK8:22-28 > * Create videos for contributing > - Different ways of contributing > - Troubleshooting and asking for help > > > WEEK9:29-4 ( January / February 2019) > * Contributing or using guix as a developer: > - Differences between profiles and environments, working with them. > - Packaging tutorial > > WEEK10:5-11 > * Videos on common configuration tasks/ videos for daily use as a sysadmin > - Example video: benefits and howto guix works isolating package > installation for unprivileged users, garbage collector - already mentioned > for daily users, but could also be mentioned for sysadmins, they might not > watch the users videos. > > > WEEK11:12-18 > * Translate videos: > - refine the automated process for the slideshow and cli if necessary > - Create audios and subtitles for the other ones > In my case I could try doing so in Spanish, but if any other translator could > try it , the better. > > WEEK12:19-25 > > * Hosting videos, update Guix official webpage, have repo up to date. > * Create entries in blog to announce the availability of the videos > * Update documentation. > > WEEK13 and remaining days: 26-4. (February/ March 2019) > > * Extra week for any other set of videos that could be necessary, suggested > or the proposed ones being suffering modifications - and put this scheduled > week before WEEK 12. > > Regards! > Laura Looks good to me so far. If anyone would like to see a more details please write you comments. Thanks! Best regards, g_bor
Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)
Christopher Lemmer Webber writes: > Thorsten Wilms writes: > >> On 29/10/2018 09.59, Björn Höfling wrote: >>> In law, there is the term of "conduct implying an intent". So even not >>> signing anything you could argue that by sending a bug or a patch you >>> silently agree with the community guidelines, CoC, etc. You enter the >>> community be interacting the first time. And will be judged by their >>> guidelines. >> >> It used to be that you could pick a Free Software project and send a patch. >> >> Now sending a patch is supposed to imply agreeing to the equivalent of >> an EULA? Everyone is expected to welcome that as progress? > > Submitting code to a project under a copyleft license is also agreeing > to policy. What is the basis for this claim? While I'm generally in favor of the CoC, I strongly oppose the idea that submitting a patch or communicating with us implies automatic agreement to our policies. We should not claim that someone has "agreed" to anything without their conscious knowledge and consent. Even if the law would allow us to make such a claim, we should not do it because it would be unjust. Please, it is enough to make our policies clear and highly visible, to encourage people to read them, and to give the lead project maintainers the authority to issue warnings, and if deemed necessary, to ban people from our communication channels who repeatedly or severely violate our CoC. I support that practice, as long as it's used judiciously, and I have every confidence in Ludovic and Ricardo to do so. We do _not_ need to extract promises from contributors ahead of time that they will follow our policies, and I think it's a bad idea to ask them to. It's a worse idea to claim that they've done so implicitly without their knowledge or consent. Mark
