Cuirass: "lint -c archival"?

[zimoun]

Dear,

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?

All the best,
simon

Re: Translating the web site

[pelzflorian (Florian Pelz)]

Thank you for the heads-up.

On Wed, Sep 23, 2020 at 08:50:46AM -0400, Julien Lepiller wrote:
> Eventually it could be nice to have our own instance, but dividing
> the translator community even further might not be a very good idea.

Hmm it would seem nice if the Translation Project website would point
translators also to projects that do not use their infrastructure.
Have they disagreed on hyperlinking to weblate?

Regards,
Florian

Re: Improve ASDF build system for Common Lisp libraries

[Ricardo Wurmus]

Guillaume Le Vaillant  writes:

> So unless there is a last minute blocker, I'm going to merge wip-lisp
> into staging (given that it should rebuild between 900 and 1000
> packages).

Sounds good to me.  Thanks for working on this!

-- 
Ricardo

Re: Releasing guix binary in Docker format too?

[zimoun]

Hi,

(Sorry Dany I have overlooked this email.)


> > While I was researching gitlab, I came across a feature where they have 
> > their
> > own Docker container registry on there.  Apparently, the Docker CLI can 
> > fetch
> > from whatever server the user wants!
> >
> > $ docker run [options] registry.gitlab.com/group/project/image [arguments]
> >
> > That got me thinking, we could easily also release Guix on something like
> > that.  Is our HTTP webserver enough to have a Docker registry, without
> > installing extra stuff?

Docker images can be quickly really big.  Can Berlin support such traffic?


> > $ docker run localhost/foo
> > Unable to find image 'localhost/foo:latest' locally
> > docker: Error response from daemon: Get "http://localhost/v2/": dial tcp 
> > 127.0.0.1:80: connect: connection refused.
> >
> > Aha!
> >
> > Do we want to do it?
>
> I say YES :). If we have a way to create these containers we can
> distribute them through http IPFS. We'll help write a nice discovery
> web interface which initially can be a simple web page. I don't think
> we need Docker containers for every package. But if there is a demand
> for a specific tool it can be very helpful to distribute software that
> way.

At FOSDEM19, in the session "world domination", we discussed a service
where the user provides a manifest.scm file or click to select various
packages (and optionally a channels.scm file) and then the service
returns the Docker image ready to be pulled (or docker run URL).
Well, this killer-feature "service" seems a far objective. :-)

Proposing a Docker image ready-to-use containing the package manager
could be nice and a first step in that direction, IMHO.

The same way , maybe adding a
Docker (or Singularity) image would be nice to have.


> In fact, one software I am writing depends on a host of programming
> languages including Python, Racket and Rust. A Guix Docker container
> is by far the simplest solution to distribute the software. And Guix
> containers are tiny - which is really nice.

Guix containers tiny?  It depends on what you pack. :-)
(For example, only Emacs is not tiny.)

All the best,
simon

Re: Translating the web site

[Julien Lepiller]

Hi,

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 (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). 
Eventually it could be nice to have our own instance, but dividing the 
translator community even further might not be a very good idea.

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

Le 23 septembre 2020 07:42:34 GMT-04:00, "Ludovic Courtès" 
 a écrit :
>Hello!
>
>Thanks to Florian the web site is now internationalized… but it’s not
>being translated for lack of a framework to do so.  (Specifically, the
>Translation Project refused to host the web site’s POT files after we
>told them we may eventually switch to Weblate, which I can understand.)
>
>Julien, what do you think are the odds of getting a Weblate instance up
>and running soonish?  (Also depending on your availability.)
>
>What do you think can be done in the meantime?  Should we use the
>infrastructure of another project (GNOME?), or should we simply do it
>in
>an ad-hoc fashion by publishing the POT files at guix.gnu.org?
>Thoughts?
>
>Thanks,
>Ludo’.

Re: Improve ASDF build system for Common Lisp libraries

[Guillaume Le Vaillant]

Pierre Neidhardt  skribis:

> I've retested wip-lisp on 851abcf6c9c15d90cb77c57b40d10c3b4835,
> everything seems to work!

Thanks for testing.


> Nit: Maybe enable tests in ecl-numcl ?

Done.


> I've successfully tested Nyxt with the following recipe:
>
> --8<---cut here---start->8---
> (define-public nyxt
> ...
> --8<---cut here---end--->8---

I pushed your recipe for Nyxt in wip-lisp. Thanks.


> I haven't tested StumpWM, can anyone do it?
> If StumpWM passes, feel free to merge this patchset.

I just tested StumpWM's basic functionalities (key bindings, modeline)
and I didn't see any issue.

So unless there is a last minute blocker, I'm going to merge wip-lisp
into staging (given that it should rebuild between 900 and 1000
packages).


signature.asc
Description: PGP signature

Translating the web site

[Ludovic Courtès]

Hello!

Thanks to Florian the web site is now internationalized… but it’s not
being translated for lack of a framework to do so.  (Specifically, the
Translation Project refused to host the web site’s POT files after we
told them we may eventually switch to Weblate, which I can understand.)

Julien, what do you think are the odds of getting a Weblate instance up
and running soonish?  (Also depending on your availability.)

What do you think can be done in the meantime?  Should we use the
infrastructure of another project (GNOME?), or should we simply do it in
an ad-hoc fashion by publishing the POT files at guix.gnu.org?
Thoughts?

Thanks,
Ludo’.

Re: Improve ASDF build system for Common Lisp libraries

[Pierre Neidhardt]

I've retested wip-lisp on 851abcf6c9c15d90cb77c57b40d10c3b4835,
everything seems to work!

Nit: Maybe enable tests in ecl-numcl ?

I've successfully tested Nyxt with the following recipe:

--8<---cut here---start->8---
(define-public nyxt
  (package
(name "nyxt")
;; Package the pre-release because latest stable 1.5.0 does not build
;; anymore.
(version "2-pre-release-1")
(source
 (origin
   (method git-fetch)
   (uri (git-reference
 ;; TODO: Mirror seems to hang, let's fallback to GitHub for now.
 ;; (url "https://source.atlas.engineer/public/nyxt;)
 (url "https://github.com/atlas-engineer/nyxt;)
 (commit version)))
   (sha256
(base32
 "0aipsmzqnlkmy001cihz2jnc0hja8c10rm08jycxr05j3gx3qsxd"))
   (file-name (git-file-name "nyxt" version
(build-system gnu-build-system)
(arguments
 `(#:make-flags (list "nyxt" "NYXT_INTERNAL_QUICKLISP=false"
  (string-append "DESTDIR=" (assoc-ref %outputs "out"))
  "PREFIX=")
   #:strip-binaries? #f ; Stripping breaks SBCL binaries.
   #:phases
   (modify-phases %standard-phases
 (add-after 'unpack 'patch-version ; Version is guessed from .git which 
Guix does not have.
   (lambda* (#:key inputs #:allow-other-keys)
 (let ((version (format #f "~a" ,version))
   (file "source/global.lisp"))
   (chmod file #o666)
   (let ((port (open-file file "a")))
 (format port "(setf +version+ ~s)" version)
 (close-port port)))
 #t))
 (add-before 'build 'make-desktop-version-number
   (lambda _
 (with-output-to-file "version"
   (lambda _
 (format #t "~a" ,version)
 #t

 (delete 'configure)
 (add-before 'build 'fix-common-lisp-cache-folder
   (lambda _
 (setenv "HOME" "/tmp")
 #t))
 (add-after 'install 'wrap-program
   (lambda* (#:key inputs outputs #:allow-other-keys)
 (let* ((bin (string-append (assoc-ref outputs "out") "/bin/nyxt"))
(glib-networking (assoc-ref inputs "glib-networking"))
(libs '("gsettings-desktop-schemas"))
(path (string-join
   (map (lambda (lib)
  (string-append (assoc-ref inputs lib) "/lib"))
libs)
   ":"))
(gi-path (string-join
  (map (lambda (lib)
 (string-append (assoc-ref inputs lib) 
"/lib/girepository-1.0"))
   libs)
  ":"))
(xdg-path (string-join
   (map (lambda (lib)
  (string-append (assoc-ref inputs lib) 
"/share"))
libs)
   ":")))
   (wrap-program bin
 `("GIO_EXTRA_MODULES" prefix
   (,(string-append glib-networking "/lib/gio/modules")))
 `("GI_TYPELIB_PATH" prefix (,gi-path))
 `("LD_LIBRARY_PATH" ":" prefix (,path))
 `("XDG_DATA_DIRS" ":" prefix (,xdg-path)))
   #t))
(native-inputs
 `(("prove" ,sbcl-prove)
   ("sbcl" ,sbcl)))
(inputs
 `(("alexandria" ,sbcl-alexandria)
   ("bordeaux-threads" ,sbcl-bordeaux-threads)
   ("sbcl-containers" ,sbcl-cl-containers)
   ("sbcl-css" ,sbcl-cl-css)
   ("sbcl-json" ,sbcl-cl-json)
   ("sbcl-markup" ,sbcl-cl-markup)
   ("sbcl-ppcre" ,sbcl-cl-ppcre)
   ("sbcl-prevalence" ,sbcl-cl-prevalence)
   ("closer-mop" ,sbcl-closer-mop)
   ("cluffer" ,sbcl-cluffer)
   ("dexador" ,sbcl-dexador)
   ("enchant" ,sbcl-enchant)
   ("fset" ,sbcl-fset)
   ("iolib" ,sbcl-iolib)
   ("local-time" ,sbcl-local-time)
   ("log4cl" ,sbcl-log4cl)
   ("lparallel" ,sbcl-lparallel)
   ("mk-string-metrics" ,sbcl-mk-string-metrics)
   ("moptilities" ,sbcl-moptilities)
   ("osicat" ,sbcl-osicat)
   ("parenscript" ,sbcl-parenscript)
   ("plump" ,sbcl-plump)
   ("quri" ,sbcl-quri)
   ("serapeum" ,sbcl-serapeum)
   ("str" ,sbcl-cl-str)
   ("swank" ,sbcl-slime-swank)
   ("trivia" ,sbcl-trivia)
   ("trivial-clipboard" ,sbcl-trivial-clipboard)
   ("trivial-features" ,sbcl-trivial-features)
   ("trivial-package-local-nicknames" ,sbcl-trivial-package-local-nicknames)
   ("trivial-types" ,sbcl-trivial-types)
   ("unix-opts" ,sbcl-unix-opts)
   ;; WebKitGTK deps
   ("sbcl-cffi-gtk" ,sbcl-cl-cffi-gtk)
   ("sbcl-webkit" ,sbcl-cl-webkit)
   ("glib-networking" 

Re: Releasing guix binary in Docker format too?

[Pjotr Prins]

Hi Danny!

On Tue, Sep 22, 2020 at 11:51:05AM +0200, Danny Milosavljevic wrote:
> Now, Heads has most of its stuff on CI servers that use Docker for a lot of
> things.

It would be very interesting to have a Docker registry for a number of
(complicated) Guix packages. We have bioinformatics packages living in
channels such as
http://git.genenetwork.org/guix-bioinformatics/guix-bioinformatics.
Bonface built a GeneNetwork Docker image for CI. I would like to see
Docker images for vgtools, gemma, sambamba and other products we are
(co)developing.

A Guix Docker container could be the starting point for live installs
on highly divergent systems (including an HPC cluster we are
building).

> While I was researching gitlab, I came across a feature where they have their
> own Docker container registry on there.  Apparently, the Docker CLI can fetch
> from whatever server the user wants!
> 
> $ docker run [options] registry.gitlab.com/group/project/image [arguments]
> 
> That got me thinking, we could easily also release Guix on something like
> that.  Is our HTTP webserver enough to have a Docker registry, without
> installing extra stuff?
> 
> $ docker run localhost/foo
> Unable to find image 'localhost/foo:latest' locally
> docker: Error response from daemon: Get "http://localhost/v2/": dial tcp 
> 127.0.0.1:80: connect: connection refused.
> 
> Aha!
> 
> Do we want to do it?

I say YES :). If we have a way to create these containers we can
distribute them through http IPFS. We'll help write a nice discovery
web interface which initially can be a simple web page. I don't think
we need Docker containers for every package. But if there is a demand
for a specific tool it can be very helpful to distribute software that
way.

In fact, one software I am writing depends on a host of programming
languages including Python, Racket and Rust. A Guix Docker container
is by far the simplest solution to distribute the software. And Guix
containers are tiny - which is really nice.

Pj.

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

[Pierre Neidhardt]

Hi Simon!

zimoun  writes:

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

I haven't heard of any change ever since we discussed it, sorry :p

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature