Re: etc/news copyright (was Re: Translating the web site)

2020-09-24 Thread Marius Bakke
Julien Lepiller  writes:

> OK for me too!

Ditto for me (I think I mainly copy-pasted another news item anyway).


signature.asc
Description: PGP signature


Re: Cuirass: "lint -c archival"?

2020-09-24 Thread Christopher Baines

zimoun  writes:

> Does it make sense to add "lint -c archival" when a package is built
> by Cuirass?  Or on the Guix Data Services?
>
> The idea behind is then to ask SWH folks to increase the rate limit
> for a specific IP (or couple of IPs).  Today, the SWH rate is 10 save
> requests per hour, i.e., 240 per day (more or less).  And the new
> chart [1] shows that there are ~2000 builds per day.  Ouch! :-)
>
> [1] 
>
> If it is not possible, then instead does it make sense to add a script
> to etc/?  If SWH accepts to increase the rate for a specific machine,
> the script (fold-packages+save-origin) could run with some delay and
> save all the missing Git references.
>
> Well, I do not know what the GitLab CI in Bordeaux is doing?  About
> Guix packages because there are already some things saving requests
> automatically, I guess.
>
> WDYT?

So, my understanding is that Software Heritage is a potential store for
source material for Guix packages. I think the majority of builds
Cuirass does are because inputs change, rather than the source of a
package.

I'm not sure hooking this up to Cuirass would make the most sense,
because of the above point.

Also, unfortunately, the Guix Data Service doesn't have the ideal data
for this, as it doesn't really store the package source information in
the way that would be useful for this.

Personally though (and I'm rather biased), I think the Guix Data Service
might still be an approach. If you take the view on this that the
Software Heritage is a means to a store item (which I think is right?),
the Guix Data Service knows about those store items (like [1]).

1: 
https://data.guix.gnu.org/gnu/store/5h4dz6ild4fkida5yfv5fhh59vfd8hvk-python-boolean.py-3.6-checkout

It's already storing if substitute servers have a nar for that store
item, so I don't think storing if it's available elsewhere is
particularly out of place.

To make the information actionable though, it would be necessary to
store more information about the sources for packages in the Guix Data
Service database.

This is much more work than just using the existing linter, but it does
have the advantage that you'd be able to look at coverage statistics and
things like that, which the checker doesn't really afford.

Chris


signature.asc
Description: PGP signature


Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

2020-09-24 Thread zimoun
Hi,

On Thu, 24 Sep 2020 at 19:29, Giovanni Biscuolo  wrote:

> P.S.: I also know there's the http://issues.guix.gnu.org/41732#7
> "Implement a wrapper so users can build the Emacs packages using a
> version of their choosing" patch around, but it's for a different
> (expert) use case AFAIU

Now this patch is superseded by . :-)
If I understand correctly #43578 (not yet really tested).


Cheers,
simon



emacs-lucid (was Re: Emacs closure at ~900MB?)

2020-09-24 Thread Giovanni Biscuolo
Hello Pierre,

Pierre Neidhardt  writes:

> Indeed, if you build the Lucid version you get a much smaller Emacs.
> We had discussed this some time ago.

I saw that discussion last June but probably I missed something: have
you already sent a patch to request emacs-lucid inclusion in master?

Given the size "issue" of emacs-with-gtk and the emacs warning on the
long standing Gtk+ bug:

--8<---cut here---start->8---

Warning: due to a long standing Gtk+ bug
https://gitlab.gnome.org/GNOME/gtk/issues/221
Emacs might crash when run in daemon mode and the X11 connection is 
unexpectedly lost.
Using an Emacs configured with --with-x-toolkit=lucid does not have this 
problem.

--8<---cut here---end--->8---

IMHO it's useful to have emacs-lucid in official Guix, with subsitutes
available for end users (I'm not using emacs in daemon mode over X11
over SSH for fear of chrashes).

Thanks a lot for your recipe!

[...]


P.S.: I also know there's the http://issues.guix.gnu.org/41732#7
"Implement a wrapper so users can build the Emacs packages using a
version of their choosing" patch around, but it's for a different
(expert) use case AFAIU

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature


Re: Docker image: from profile/manifest to manifest.scm?

2020-09-24 Thread zimoun
Dear,

On Wed, 23 Sep 2020 at 04:07, zimoun  wrote:

> The 2 questions are:
>
>  1. How can I find this /gnu/store/…-profile/manifest file with only the
>  Docker tools?

I have found an answer to my question. :-)  Well, using “docker export”.

--8<---cut here---start->8---
  docker load < $(guix time-machine -C channels.scm \
-- pack -f docker \
   -m manifest.scm --save-provenance)
  
  docker run -ti 
  docker ps -a
  
  docker export -o foo.tar 
  
  tar -xf foo.tar $(tar -tf foo.tar | grep ’profile/manifest’)
  cat gnu/store/…-profile/manifest
--8<---cut here---end--->8---

Is it possible to automatize these steps?


>  2. What is the status of the converter from profile/manifest to
>  manifest.scm discussed sometimes ago?

Well, the converter extracting an approximation to the manifest.scm and
channels.scm files should be really could to have.


All the best,
simon



Re: NixCon 2020

2020-09-24 Thread Bengt Richter
Hi Pancake,

from your link, I get an html page, with a centered message:
"File not found or corrupt"
which firefox inspect-element says comes from

--8<---cut here---start->8---
File not found or corrupt
--8<---cut here---end--->8---

I'm not sure it was you but I saw a NixCon thing, maybe 2019?,
where the presenter did not mention the role of guix substitutes
provided by trusted servers, and in the Q/A time after did not
appear to know fully how the guix derivation chains of events
work in that regard.

I think the audience may have been left with a less favorable
impression of guix than it could have gotten.

Hopefully you can improve on that :)

On +2020-09-21 15:19:04 +, Buttery Pancake wrote:
> I am planning to do a presentation for NixCon 2020, which will be on 16 and 
> 17 October. This will be a contrast between Guix and Nix.
> 
> I have prepared a self-shot of my presentation,
> https://share.riseup.net/#N9ggM6bRWviQCTro3_qerQ
> 
> Please leave your feed-back.
 
-- 
Regards,
Bengt Richter



Re: Translating the web site

2020-09-24 Thread Julien Lepiller
I've sent them all an email. Let's see what they say.

We still have the issue of the initial copyright line in the packages and guix 
translation. Some are to ludo, and it's easy to change. Some are to the FSF, 
and I'm not suse how we can change that. Should we ask them to allow the 
change? The rest is correctly attributed to the guix authors, but with 
different years.

Le 24 septembre 2020 10:34:24 GMT-04:00, "pelzflorian (Florian Pelz)" 
 a écrit :
>On Thu, Sep 24, 2020 at 09:31:19AM -0400, Julien Lepiller wrote:
>> I'll try to contact everyone today, but some of these emails might
>> end up in a spam folder, because my server is so small. Can you also
>> send something to the translators alias?
>
>So aside from Julien and me that’s,
>(from the French PO file) Simon Tournier,
>(from the German PO file) Mario Blättermann, Jonathan Brielmaier,
>(from the Russian PO file) znavko, Pavlo Marianov, Adam,
>(for Spanish) Miguel, (for Chinese) Meiyo Peng, and, I
>wonder, have Ali Reza Hayati and Amin Bandali been working on the
>manual already; are they listed as part of the guix-i...@gnu.org?
>They had asked how they could help with translating on
>.
>
>Regards,
>Florian


Problem bootstrapping Guix - "make update-guix-package" result: no code for module (gcrypt hash)

2020-09-24 Thread Danny Milosavljevic
Hi,

I'm trying to bootstrap current Guix (master) from Guix past (1.1.0 binary
tarball).

The goal is: I want to have only guix-the-package-manager at a specific guix
commit (!) available inside a Docker image.

Because the package "guix" in guix is always behind a little bit, that
means I have to first check out that commit from source code, then use
make update-guix-package in order to update the guix package definition
in gnu/packages/package-management.scm to that commit and then use guix pack
in order to pack guix into a tarball, which I then extract and then copy into
a previously-empty docker image.

Or so I thought.

What I have currently is on https://gitlab.com/daym/guix-on-docker/ .
Especially see Dockerfile.

You can build it on your machine using

$ docker build --build-arg 
BOOTSTRAP_GUIX_COMMIT_ID=0b21bf6245b36ea21d2eeaf2340a99aa4d5894db .

(or a newer commit--it doesn't matter) and see it fail.

(it will first download 
https://ftp.gnu.org/gnu/guix/guix-binary-1.1.0.x86_64-linux.tar.xz
and then check out guix anonymously from 
https://git.savannah.gnu.org/git/guix.git at
the specified commit)

Or you can look at the CI logs on
https://gitlab.com/daym/guix-on-docker/-/pipelines and see it fail there.

The failure is when it does that:

&& ENV="guix environment --pure guix --ad-hoc git guile-readline guile-json 
guile-zlib guile
-lzlib bash which --" \
&& ${ENV} make update-guix-package \
&& ./pre-inst-env guix pack --verbosity=2 -f tarball --localstatedir -r 
/tmp/guix.tar.gz --profile-name=current-guix guix \

and it prints the following:

(see https://gitlab.com/daym/guix-on-docker/-/jobs/755694619 )

make[1]: Leaving directory '/master'
accepted connection from pid 17760, user root
git rev-parse HEAD
ff43f128b7c142ae3f758d34137e562e6f7ef0e0
./pre-inst-env "/gnu/store/s08nkx9dzpvn41s4k277p9b27abpcjvp-profile/bin/guile"  
\
   ./build-aux/update-guix-package.scm  \
   "`git rev-parse HEAD`"
accepted connection from pid 17766, user root
source code for commit ff43f128b7c142ae3f758d34137e562e6f7ef0e0: 
/gnu/store/3bz5q9g2p11pazy4g4vq8x8qp86c7ngh-guix-1.1.0-28.ff43f12-checkout (GC 
root: guix-1.1.0-28.ff43f12-checkout)
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /master/./build-aux/update-guix-package.scm
;;; compiled 
/root/.cache/guile/ccache/3.0-LE-8-4.3/master/build-aux/update-guix-package.scm.go
;;; compiling /master/gnu/packages/package-management.scm
;;; compiled 
/root/.cache/guile/ccache/3.0-LE-8-4.3/master/gnu/packages/package-management.scm.go
Backtrace:
In ice-9/boot-9.scm:
  3223:13 19 (_)
In ice-9/threads.scm:
390:8 18 (_ _)
In ice-9/boot-9.scm:
  3507:20 17 (_)
   2806:4 16 (save-module-excursion _)
  3527:26 15 (_)
In unknown file:
  14 (primitive-load-path "guix/store" #)
In guix/store.scm:
 23:0 13 (_)
In ice-9/boot-9.scm:
   3380:4 12 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
  3393:24 11 (_)
   222:29 10 (map1 (((guix utils)) ((guix config)) ((guix #)) ((?)) ?))
   222:29  9 (map1 (((guix config)) ((guix deprecation)) ((guix ?)) ?))
   222:29  8 (map1 (((guix deprecation)) ((guix memoization)) ((?)) ?))
   222:29  7 (map1 (((guix memoization)) ((guix serialization)) (#) ?))
   222:29  6 (map1 (((guix serialization)) ((guix monads)) ((# #)) ?))
   222:29  5 (map1 (((guix monads)) ((guix records)) ((guix #)) (#) ?))
   222:29  4 (map1 (((guix records)) ((guix base16)) ((guix #)) (#) ?))
   222:29  3 (map1 (((guix base16)) ((guix base32)) ((gcrypt #)) # ?))
   222:29  2 (map1 (((guix base32)) ((gcrypt hash)) ((guix #)) (#) ?))
   222:17  1 (map1 (((gcrypt hash)) ((guix profiling)) ((rnrs #)) # ?))
   3300:6  0 (resolve-interface (gcrypt hash) #:select _ #:hide _ # _ ?)

ice-9/boot-9.scm:3300:6: In procedure resolve-interface:
no code for module (gcrypt hash).

What now?

Am I doing it wrong?


pgplakbT9rMEL.pgp
Description: OpenPGP digital signature


Re: Translating the web site

2020-09-24 Thread zimoun
On Thu, 24 Sep 2020 at 16:37, pelzflorian (Florian Pelz)
 wrote:
>
> On Thu, Sep 24, 2020 at 09:31:19AM -0400, Julien Lepiller wrote:
> > I'll try to contact everyone today, but some of these emails might
> > end up in a spam folder, because my server is so small. Can you also
> > send something to the translators alias?
>
> So aside from Julien and me that’s,
> (from the French PO file) Simon Tournier,

All fine with me.

Thanks for working this.
simon



Re: Translating the web site

2020-09-24 Thread pelzflorian (Florian Pelz)
On Thu, Sep 24, 2020 at 09:31:19AM -0400, Julien Lepiller wrote:
> I'll try to contact everyone today, but some of these emails might
> end up in a spam folder, because my server is so small. Can you also
> send something to the translators alias?

So aside from Julien and me that’s,
(from the French PO file) Simon Tournier,
(from the German PO file) Mario Blättermann, Jonathan Brielmaier,
(from the Russian PO file) znavko, Pavlo Marianov, Adam,
(for Spanish) Miguel, (for Chinese) Meiyo Peng, and, I
wonder, have Ali Reza Hayati and Amin Bandali been working on the
manual already; are they listed as part of the guix-i...@gnu.org?
They had asked how they could help with translating on
.

Regards,
Florian



Re: Translating the web site

2020-09-24 Thread zimoun
On Thu, 24 Sep 2020 at 15:23, Julien Lepiller  wrote:

> Sorry, it's translate.fedoraproject.org

Cool!
Well, managing the website translation with Weblate could be a
real-world example to test if Weblate helps in the translation
process.

All the best,
simon



Re: Translating the web site

2020-09-24 Thread Julien Lepiller



Le 24 septembre 2020 09:18:52 GMT-04:00, "Ludovic Courtès"  a 
écrit :
>Hi,
>
>Julien Lepiller  skribis:
>
>>>Julien Lepiller  skribis:
>>>
 As soon as we can host the translation files on a separate project
>on
 savannah, we can get it running at translate.fedora-project.org
>>>
>>>Sounds good.  Do we need to host POT files on our side?  I naively
>>>though Weblate would host them.
>>
>> No, weblate works with a git repository: it clones a repo and
>presents translation files to the users. Wher a file it translated, it
>commits it locally and remotely.
>
>OK.
>
>>>A Savannah project would be a sledgehammer; what about having a
>>>sub-directory at guix.gnu.org with all the POT files?  All we’d need
>to
>>>do is add a couple of nginx ‘location’ blocks to the config in
>>>maintenance.git.
>>
>> So, we really need a git repository. I guess it could be hosted on,
>say, git.guix.gnu.org :)
>
>Right, or, even easier: a sub-repository on Savannah under ‘guix’.
>Would you like to file a support request on the Savannah web interface
>so they create a new repo (just like we did for Cuirass, Guix Data
>Service, etc.)?

We can't restrict commit access to one repo in a project with savannah. Are you 
OK with giving commit access to an external tool? It would be configured to 
push to that separate repo, but basically you're giving commit access to all of 
our repos (maintenance and guix itself) to fedora people :)

>
 (it's a bit weird, but I think it's better than hosted.weblate.org
 which uses some google stuff. If we prefer hosted, there's ~1 month
 delay for them to consider an application).
>>>
>>>Who is “them” in this last sentence?  
>>
>> hosted.weblate.org's admins. They try to make a bit of money from
>their project, so normally their service is paid, but they accept free
>software projects for free, but the application can take time.
>
>OK but like you said we probably don’t want to use hosted.weblate.org
>if
>they use tracking services.
>
>So let’s focus on Fedora’s instance.  (GNOME would be be a bit “closer”
>to us, so to speak, but I don’t know if they run an instance nor if
>they’d accept us.)
>
>>>Those at 
>have
>>>the same statement, but it should rather be the same license as the
>>>manual (GFDL).  Perhaps a ‘Makevars’ issue too?  Since there are a
>>>handful of translators involved, we can probably just contact them
>and
>>>change that sentence.
>>>
>>>Thoughts?
>>
>> I agree, the robot should have taken care of making sure the list of
>authors is maintained in the po files, so we have a complete list from
>that.
>
>OK, so Someone™ should email them to change the sentence to something
>like “[…] under the same license as the Guix manual.”

I'll try to contact everyone today, but some of these emails might end up in a 
spam folder, because my server is so small. Can you also send something to the 
translators alias?

>
>Thanks,
>Ludo’.



Re: Translating the web site

2020-09-24 Thread Julien Lepiller



Le 24 septembre 2020 08:02:14 GMT-04:00, zimoun  a 
écrit :
>Hi Julien,
>
>On Thu, 24 Sep 2020 at 13:26, Julien Lepiller 
>wrote:
>
>> >> As soon as we can host the translation files on a separate project
>on
>> >> savannah, we can get it running at translate.fedora-project.org
>
>Maybe I am doing wrong but  seems down
>or unreachable?

Sorry, it's translate.fedoraproject.org

>
>Cheers,
>simon



Re: Translating the web site

2020-09-24 Thread Ludovic Courtès
Hi,

Julien Lepiller  skribis:

>>Julien Lepiller  skribis:
>>
>>> As soon as we can host the translation files on a separate project on
>>> savannah, we can get it running at translate.fedora-project.org
>>
>>Sounds good.  Do we need to host POT files on our side?  I naively
>>though Weblate would host them.
>
> No, weblate works with a git repository: it clones a repo and presents 
> translation files to the users. Wher a file it translated, it commits it 
> locally and remotely.

OK.

>>A Savannah project would be a sledgehammer; what about having a
>>sub-directory at guix.gnu.org with all the POT files?  All we’d need to
>>do is add a couple of nginx ‘location’ blocks to the config in
>>maintenance.git.
>
> So, we really need a git repository. I guess it could be hosted on, say, 
> git.guix.gnu.org :)

Right, or, even easier: a sub-repository on Savannah under ‘guix’.
Would you like to file a support request on the Savannah web interface
so they create a new repo (just like we did for Cuirass, Guix Data
Service, etc.)?

>>> (it's a bit weird, but I think it's better than hosted.weblate.org
>>> which uses some google stuff. If we prefer hosted, there's ~1 month
>>> delay for them to consider an application).
>>
>>Who is “them” in this last sentence?  
>
> hosted.weblate.org's admins. They try to make a bit of money from their 
> project, so normally their service is paid, but they accept free software 
> projects for free, but the application can take time.

OK but like you said we probably don’t want to use hosted.weblate.org if
they use tracking services.

So let’s focus on Fedora’s instance.  (GNOME would be be a bit “closer”
to us, so to speak, but I don’t know if they run an instance nor if
they’d accept us.)

>>Those at  have
>>the same statement, but it should rather be the same license as the
>>manual (GFDL).  Perhaps a ‘Makevars’ issue too?  Since there are a
>>handful of translators involved, we can probably just contact them and
>>change that sentence.
>>
>>Thoughts?
>
> I agree, the robot should have taken care of making sure the list of authors 
> is maintained in the po files, so we have a complete list from that.

OK, so Someone™ should email them to change the sentence to something
like “[…] under the same license as the Guix manual.”

Thanks,
Ludo’.



Re: Translating the web site

2020-09-24 Thread zimoun
Hi Julien,

On Thu, 24 Sep 2020 at 13:26, Julien Lepiller  wrote:

> >> As soon as we can host the translation files on a separate project on
> >> savannah, we can get it running at translate.fedora-project.org

Maybe I am doing wrong but  seems down
or unreachable?

Cheers,
simon



Re: Translating the web site

2020-09-24 Thread Julien Lepiller



Le 24 septembre 2020 03:25:56 GMT-04:00, "Ludovic Courtès" 
 a écrit :
>Hi,
>
>Julien Lepiller  skribis:
>
>> As soon as we can host the translation files on a separate project on
>> savannah, we can get it running at translate.fedora-project.org
>
>Sounds good.  Do we need to host POT files on our side?  I naively
>though Weblate would host them.

No, weblate works with a git repository: it clones a repo and presents 
translation files to the users. Wher a file it translated, it commits it 
locally and remotely.

>
>A Savannah project would be a sledgehammer; what about having a
>sub-directory at guix.gnu.org with all the POT files?  All we’d need to
>do is add a couple of nginx ‘location’ blocks to the config in
>maintenance.git.

So, we really need a git repository. I guess it could be hosted on, say, 
git.guix.gnu.org :)

>
>> (it's a bit weird, but I think it's better than hosted.weblate.org
>> which uses some google stuff. If we prefer hosted, there's ~1 month
>> delay for them to consider an application).
>
>Who is “them” in this last sentence?  

hosted.weblate.org's admins. They try to make a bit of money from their 
project, so normally their service is paid, but they accept free software 
projects for free, but the application can take time.

>
>> Eventually it could be nice to have our own instance, but dividing
>the
>> translator community even further might not be a very good idea.
>
>Yeah.
>
>> To get the project, we need to clarify the license on the translation
>files, as we discussed before. How should we proceed on that?
>
>There was a question about copyright holders for translations; to me
>it’s clearly individual translators, and translations that indicate
>otherwise are probably the result of misconfiguration in ‘Makevars’
>and/or copy/paste.
>
>The PO files at  and
> state:
>
>  This file is distributed under the same license as the guix package.
>
>which is perfect.
>
>Those at  have
>the same statement, but it should rather be the same license as the
>manual (GFDL).  Perhaps a ‘Makevars’ issue too?  Since there are a
>handful of translators involved, we can probably just contact them and
>change that sentence.
>
>Thoughts?

I agree, the robot should have taken care of making sure the list of authors is 
maintained in the po files, so we have a complete list from that.

>
>Ludo’.



Re: etc/news copyright (was Re: Translating the web site)

2020-09-24 Thread Julien Lepiller
OK for me too!

Le 24 septembre 2020 05:18:30 GMT-04:00, Konrad Hinsen 
 a écrit :
>Ludovic Courtès  writes:
>
>>> I attach a patch adding copyright notices, but I guess the authors
>>> should agree.  I put them in Cc.
>>
>> If the authors agree, fine with me!
>
>Since I am in CC, I must be one of the authors, though I don't really
>remember what I could have contributed. Anyway, this is fine with me as
>well!
>
>Konrad.


Re: Cuirass: "lint -c archival"?

2020-09-24 Thread zimoun
Hi,

On Thu, 24 Sep 2020 at 09:28, Mathieu Othacehe  wrote:

> > The idea behind is then to ask SWH folks to increase the rate limit
> > for a specific IP (or couple of IPs).  Today, the SWH rate is 10 save
> > requests per hour, i.e., 240 per day (more or less).  And the new
> > chart [1] shows that there are ~2000 builds per day.  Ouch! :-)
>
> Yesterday almost 18.000 derivations were added, and even if only 10.000
> were built, it is indeed quite substantial.

That's good news. :-)

On average, it is ~2000, right?

Well, we could set a limit for the extra days, sending the X first
buildings where X is in agreement with SWH.
It would be far from perfect and some packages would not be saved, but
it seems better than the current situation (depends on the
submitter/reviewer only).

This would be something in the meantime; while waiting the SWH
sources.json loads accepts more than 'url-fetch' sources.


> > If it is not possible, then instead does it make sense to add a script
> > to etc/?  If SWH accepts to increase the rate for a specific machine,
> > the script (fold-packages+save-origin) could run with some delay and
> > save all the missing Git references.
>
> Adding some sort of "post build" hook to Cuirass that would trigger an
> SHW archival would be possible, even though it would require to
> implement this mechanism.

Cool!  Yakafonkon. ;-)

> Having a cron job archiving missing references would also be possible I
> guess, but I may have a preference for the first option.

Because I am lazy, the "post build" hook appears to me more
complicated to implement than a cron job with a Scheme script (that I
almost already have :-)).  Hey, "Now is better than never. Although
never is often better than *right* now." :-)


Thanks,
simon



Re: etc/news copyright (was Re: Translating the web site)

2020-09-24 Thread Konrad Hinsen
Ludovic Courtès  writes:

>> I attach a patch adding copyright notices, but I guess the authors
>> should agree.  I put them in Cc.
>
> If the authors agree, fine with me!

Since I am in CC, I must be one of the authors, though I don't really
remember what I could have contributed. Anyway, this is fine with me as
well!

Konrad.



Re: etc/news copyright (was Re: Translating the web site)

2020-09-24 Thread Ludovic Courtès
Hi,

"pelzflorian (Florian Pelz)"  skribis:

> I guess we should add proper copyright notices to etc/news.scm too?
>
> Sorry for not starting its translations with a proper copyright, but I
> wasn’t sure because of etc/news.scm’s license:
>
> “;; Copying and distribution of this file, with or without modification, are
> ;; permitted in any medium without royalty provided the copyright notice and
> ;; this notice are preserved.”

Yes, it’s the kind of all-permissive license found on gnu.org web pages
and recommended for short documents (info "(maintain) License Notices
for Other Files").

> I attach a patch adding copyright notices, but I guess the authors
> should agree.  I put them in Cc.

If the authors agree, fine with me!

Ludo’.



etc/news copyright (was Re: Translating the web site)

2020-09-24 Thread pelzflorian (Florian Pelz)
On Thu, Sep 24, 2020 at 09:25:56AM +0200, Ludovic Courtès wrote:
> Julien Lepiller  skribis:
> > To get the project, we need to clarify the license on the translation 
> > files, as we discussed before. How should we proceed on that?
> 
> There was a question about copyright holders for translations; to me
> it’s clearly individual translators, and translations that indicate
> otherwise are probably the result of misconfiguration in ‘Makevars’
> and/or copy/paste.
> 
> The PO files at  and
>  state:
> 
>   This file is distributed under the same license as the guix package.
> 
> which is perfect.
> 
> Those at  have
> the same statement, but it should rather be the same license as the
> manual (GFDL).  Perhaps a ‘Makevars’ issue too?  Since there are a
> handful of translators involved, we can probably just contact them and
> change that sentence.
> 
> Thoughts?
> 
> Ludo’.

I’m fine with any licensing changes you see fit.

I guess we should add proper copyright notices to etc/news.scm too?

Sorry for not starting its translations with a proper copyright, but I
wasn’t sure because of etc/news.scm’s license:

“;; Copying and distribution of this file, with or without modification, are
;; permitted in any medium without royalty provided the copyright notice and
;; this notice are preserved.”

I attach a patch adding copyright notices, but I guess the authors
should agree.  I put them in Cc.

Regards,
Florian
>From c84d333eea4ed5a654214d5cfa3186237c57bd69 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Thu, 24 Sep 2020 10:37:51 +0200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] news: Update copyright.

* etc/news.scm: Add missing copyright headers.
---
 etc/news.scm | 5 +
 1 file changed, 5 insertions(+)

diff --git a/etc/news.scm b/etc/news.scm
index 1ef238ca2d..86c1555fc7 100644
--- a/etc/news.scm
+++ b/etc/news.scm
@@ -2,8 +2,13 @@
 ;;
 ;; Copyright © 2019, 2020 Ludovic Courtès 
 ;; Copyright © 2019, 2020 Tobias Geerinckx-Rice 
+;; Copyright © 2019, 2020 Konrad Hinsen 
+;; Copyright © 2019 Miguel 
+;; Copyright © 2019, 2020 Julien Lepiller 
+;; Copyright © 2019, 2020 Florian Pelz 
 ;; Copyright © 2020 Mathieu Othacehe 
 ;; Copyright © 2020 Jan (janneke) Nieuwenhuizen 
+;; Copyright © 2020 Marius Bakke 
 ;; Copyright © 2020 Maxim Cournoyer 
 ;;
 ;; Copying and distribution of this file, with or without modification, are
-- 
2.28.0



Re: Releasing guix binary in Docker format too?

2020-09-24 Thread Danny Milosavljevic
Also, while doing that, using the guix binary 1.1.0 tarball from the website and
issuing guix pull (ONLY), a lot of weird stuff is updated, like libx11, fribidi,
graphviz, cairo, pixman, libjpeg-turbo, pango etc.  Is that really necessary?
I guess it's because of the profile hooks, but still... why.

I want to stress that the profile I'm building contains only guix, the package
manager.  Does that really need all those (presumably build-) dependencies?


pgpkWeUt8KUbp.pgp
Description: OpenPGP digital signature


Re: Cuirass: "lint -c archival"?

2020-09-24 Thread Mathieu Othacehe


Hello zimoun,

> The idea behind is then to ask SWH folks to increase the rate limit
> for a specific IP (or couple of IPs).  Today, the SWH rate is 10 save
> requests per hour, i.e., 240 per day (more or less).  And the new
> chart [1] shows that there are ~2000 builds per day.  Ouch! :-)

Yesterday almost 18.000 derivations were added, and even if only 10.000
were built, it is indeed quite substantial. 

> If it is not possible, then instead does it make sense to add a script
> to etc/?  If SWH accepts to increase the rate for a specific machine,
> the script (fold-packages+save-origin) could run with some delay and
> save all the missing Git references.

Adding some sort of "post build" hook to Cuirass that would trigger an
SHW archival would be possible, even though it would require to
implement this mechanism.

Having a cron job archiving missing references would also be possible I
guess, but I may have a preference for the first option.

Thanks,

Mathieu

-- 
https://othacehe.org



Re: Translating the web site

2020-09-24 Thread Ludovic Courtès
Hi,

Julien Lepiller  skribis:

> As soon as we can host the translation files on a separate project on
> savannah, we can get it running at translate.fedora-project.org

Sounds good.  Do we need to host POT files on our side?  I naively
though Weblate would host them.

A Savannah project would be a sledgehammer; what about having a
sub-directory at guix.gnu.org with all the POT files?  All we’d need to
do is add a couple of nginx ‘location’ blocks to the config in
maintenance.git.

> (it's a bit weird, but I think it's better than hosted.weblate.org
> which uses some google stuff. If we prefer hosted, there's ~1 month
> delay for them to consider an application).

Who is “them” in this last sentence?  

> Eventually it could be nice to have our own instance, but dividing the
> translator community even further might not be a very good idea.

Yeah.

> To get the project, we need to clarify the license on the translation files, 
> as we discussed before. How should we proceed on that?

There was a question about copyright holders for translations; to me
it’s clearly individual translators, and translations that indicate
otherwise are probably the result of misconfiguration in ‘Makevars’
and/or copy/paste.

The PO files at  and
 state:

  This file is distributed under the same license as the guix package.

which is perfect.

Those at  have
the same statement, but it should rather be the same license as the
manual (GFDL).  Perhaps a ‘Makevars’ issue too?  Since there are a
handful of translators involved, we can probably just contact them and
change that sentence.

Thoughts?

Ludo’.