Re: [Orchestration][RFC] A simple draft for channels
On Mon, Mar 19, 2018 at 01:04:00PM +0100, Pjotr Prins wrote: > Maybe we should start thinking that a channel is simply an > architecture dependent Guix 'pack' of substitutes that includes the > pre-built Guix git repo. When deployed in a container we can inject > the keys. When this works we can design a pack repository, making the > channels searchable. Continuing my line of thought: a binary channel in my mind is now a compiled Guix package tree with Guix and possible adaptations (say a special package for Ruby). In other words, a special (timed) version of Guix sitting in /gnu/store/*named-guix-channel/bin/guix. Installing it I would simply create my own profile guix -i named-guix-channel -p ~/opt/named-guix-channel and use that to install new software using the running guix-daemon. I.e. ~/opt/named-guix-channel/bin/guix package -A or maybe better ~/opt/named-guix-channel/bin/named-guix-channel package -A so it can actually live in a shared profile and pick up its own substitute server. Anyone can create a channel and they can even live on trunk as packages: guix package -i bio-ruby-guix-channel (admin add key) bio-ruby-guix-channel package -i bio-ruby Simple but effective. Wouldn't that be cool? To add a channel we may need some mechanism - possibly something like loading a .scm on the command line which fetches the guix-channel binary from a substitute server. The more flexible the better. So (admin add key) guix channel -i URI/my-channel.scm (which does a 'guix package -i my-bio-ruby-guix-channel') my-ruby-guix-channel package -i bio-ruby a version would be (admin add key) guix channel -i URI/my-channel.scm GITHASH/GITTAG (which does a 'guix package -i my-bio-ruby-guix-channel') my-ruby-guix-channel package -i bio-ruby We can start without the 'guix channel' bit. Early channel adopters can work from a compiled source tree. The only immediate adaptation to Guix required is that named-guix-channel can pick up its own compiled package definitions and we have fast binary-channels. Right? Pj. --
Re: broken references in jar manifests
(1) How about adding another file to the META-INF directory which is just
like manifest - just without the line breaks?
That could even be automated.
(2) Also, "jar -i" calculates an index for where which package is
("INDEX.LIST").
Is that also hard-word-wrapped? The specification
https://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR%20Index
only mentions the 72 Byte limit for "manifest and signature files" and then
specifies
Index File Specification separately.
Either would be good enough for the GC retaining the deps, right?
pgpJKeAk_7Ntb.pgp
Description: OpenPGP digital signature
Re: broken references in jar manifests
Le 2018-03-20 11:28, Danny Milosavljevic a écrit :
(1) How about adding another file to the META-INF directory which is
just
like manifest - just without the line breaks?
That could even be automated.
(2) Also, "jar -i" calculates an index for where which package is
("INDEX.LIST").
Is that also hard-word-wrapped? The specification
https://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR%20Index
only mentions the 72 Byte limit for "manifest and signature files" and
then specifies
Index File Specification separately.
Either would be good enough for the GC retaining the deps, right?
The issue is with grafts here: the plain file with full reference to the
store
gets grafted and contains the new entry. The Manifest will not be
updated because
of line breaks, and Java will still look for the version in the
manifest. The GC
will collect it because it doesn't see any reference to the old version
in any
file (because of line breaks), and the package is broken.
Re: [Orchestration][RFC] A simple draft for channels
Pjotr Prins writes: > On Mon, Mar 19, 2018 at 01:04:00PM +0100, Pjotr Prins wrote: >> Maybe we should start thinking that a channel is simply an >> architecture dependent Guix 'pack' of substitutes that includes the >> pre-built Guix git repo. When deployed in a container we can inject >> the keys. When this works we can design a pack repository, making the >> channels searchable. > > Continuing my line of thought: a binary channel in my mind is now a > compiled Guix package tree with Guix and possible adaptations (say a > special package for Ruby). In other words, a special (timed) version > of Guix sitting in /gnu/store/*named-guix-channel/bin/guix. What you describe is essentially “guix pull”. “guix pull” can already use a different branch or a different repository. It has at least two problems in this context: 1) it only keeps a link to the “latest” Guix. There is no way to declare the use of a different variant of Guix. 2) it builds everything from source (Ludo’s branch for splitting the target of “guix pull” into several derivations addresses this) Maybe we should address the first problem next and allow for not only the latest Guix version to be retained. This is not quite the same as a regular profile, because these different variants of Guix surely would provide colliding files. The guix command would need to be changed to pick “latest” by default, but use a different variant if specified. The workflow would be something like that: # fetch Guix from somewhere and record as “foobar” guix pull --url=https://somewhere foobar # use that variant of Guix guix --variant=foobar build hello I don’t think this should be the only mechanism through which people can provide channels. I wouldn’t want to have to essentially fork Guix. For a user this is a problem, too, because channels would no longer be composable (today I can compose multiple package collections with GUIX_PACKAGE_PATH). -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: broken references in jar manifests
Hi Julien, On Tue, 20 Mar 2018 11:50:51 +0100 julien lepiller wrote: > The issue is with grafts here: the plain file with full reference to the > store > gets grafted and contains the new entry. The Manifest will not be > updated because > of line breaks, and Java will still look for the version in the > manifest. The GC > will collect it because it doesn't see any reference to the old version > in any > file (because of line breaks), and the package is broken. Oh okay, so there are two problems. (The specification says that INDEX.LIST is preferred if it exists) pgpv9vWyI6LFl.pgp Description: OpenPGP digital signature
Re: [Orchestration][RFC] A simple draft for channels
Thanks Ricardo: On Tue, Mar 20, 2018 at 11:41:33AM +0100, Ricardo Wurmus wrote: > > Pjotr Prins writes: > > > On Mon, Mar 19, 2018 at 01:04:00PM +0100, Pjotr Prins wrote: > >> Maybe we should start thinking that a channel is simply an > >> architecture dependent Guix 'pack' of substitutes that includes the > >> pre-built Guix git repo. When deployed in a container we can inject > >> the keys. When this works we can design a pack repository, making the > >> channels searchable. > > > > Continuing my line of thought: a binary channel in my mind is now a > > compiled Guix package tree with Guix and possible adaptations (say a > > special package for Ruby). In other words, a special (timed) version > > of Guix sitting in /gnu/store/*named-guix-channel/bin/guix. > > What you describe is essentially “guix pull”. “guix pull” can already > use a different branch or a different repository. > > It has at least two problems in this context: > > 1) it only keeps a link to the “latest” Guix. There is no way to >declare the use of a different variant of Guix. No git hash, no tag, but could be added later. > 2) it builds everything from source (Ludo’s branch for splitting the >target of “guix pull” into several derivations addresses this) That is not good enough. But it seems to me that substitution is only an implementation question. > Maybe we should address the first problem next and allow for not only > the latest Guix version to be retained. This is not quite the same as a > regular profile, because these different variants of Guix surely would > provide colliding files. > > The guix command would need to be changed to pick “latest” by default, > but use a different variant if specified. > > The workflow would be something like that: > > # fetch Guix from somewhere and record as “foobar” > guix pull --url=https://somewhere foobar > > # use that variant of Guix > guix --variant=foobar build hello If we can substitute, that would work. And guix pull would have to be binary too. But yes, with binary instant gratification, that would really be a good start. Different versions can live on different URLs. (hmm, what did I just write?) > I don’t think this should be the only mechanism through which people can > provide channels. I wouldn’t want to have to essentially fork Guix. > For a user this is a problem, too, because channels would no longer be > composable (today I can compose multiple package collections with > GUIX_PACKAGE_PATH). I am not sure composability is required for most use cases. I think we should keep it simple. I am happy to have channels act independently if we can get it this year. Pj.
wrapping up the Newmoon Browser package
Hi! I need some final input on topics I'm more liberal about. Many many moons ago I started the work on Pale Moon. This package has now moved into New Moon, which is what we are allowed to redistribute with modifications (Pale Moon without branding). Issue 1 I addressed so far: The default homepage (after first start and in general default) called a website which is questionable in my opion: https://palemoon.start.me I have patched the default home page to be gnu.org and gnu.org/s/guix Next, can I keep the default bookmarks? They are: - https://www.palemoon.org - http://forum.palemoon.org/index.php - https://www.palemoon.org/faq.shtml - https://www.palemoon.org/releasenotes.shtml Finally, about:addons let's you install Addons from 2 repositories: Pale Moon Add-ons Site and Mozilla Add-ons Site. "Search all add-ons" queries the 2 repositories and lets you install add-ons from the repositories. In an ideal world, I would have figured out the integration for plugins in the gnu-store by now. But I'm still testing, so: How do I treat the addons page and functionality? -- A88C8ADD129828D7EAC02E52E22F9BBFEE348588 https://n0.is
Re: [Orchestration][RFC] A simple draft for channels
Pjotr Prins writes: >> I don’t think this should be the only mechanism through which people can >> provide channels. I wouldn’t want to have to essentially fork Guix. >> For a user this is a problem, too, because channels would no longer be >> composable (today I can compose multiple package collections with >> GUIX_PACKAGE_PATH). > > I am not sure composability is required for most use cases. I think we > should keep it simple. I am happy to have channels act independently > if we can get it this year. Yes, it’s not a big feature as there are practical limits to composing multiple channels. However, simple composition can come in handy. At the MDC, for example, we strictly separate non-free software from free software variants that are not available in Guix upstream. Users can add one or both of these package repositories. This would not be easy with the proposed “Guix fork as channel” implementation. That said, I think that having a more featureful “guix pull” is a good goal in itself. Even better if this happens to scratch your itch wrt channels already. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: broken references in jar manifests
Danny Milosavljevic writes: > Hi Julien, > > On Tue, 20 Mar 2018 11:50:51 +0100 > julien lepiller wrote: > >> The issue is with grafts here: the plain file with full reference to the >> store >> gets grafted and contains the new entry. The Manifest will not be >> updated because >> of line breaks, and Java will still look for the version in the >> manifest. The GC >> will collect it because it doesn't see any reference to the old version >> in any >> file (because of line breaks), and the package is broken. > > Oh okay, so there are two problems. Well, they are closely related. One is that we don’t keep references because they are broken up in the manifest; this is a minor problem, because we can propagate inputs. The more important problem is that it breaks grafts. > (The specification says that INDEX.LIST is preferred if it exists) Interesting. It’s worth playing with it. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Internship on Improve the user experience for the "guix package" command line tool (Outreachy)
Hi Vijayalakshmi,
> I created a patch file for the package definition of python-logwrap that
> I'm including here. I'm a little unsure if my patch is right because my ./
> pre-inst-env.in guix build r-abbyyR fails with some error.
Have you been able to build Guix already and try building the package
using “./pre-inst-env guix build”?
I looked over your patch for python-logwrap. I had to append “.zip”
because Pypi didn’t have a “.tar.gz” file for the sources, so the uri
field now is:
(pypi-uri "logwrap" version ".zip")
Having a zip archive requires the “unzip” command during the “unpack”
phase, so I also added “unzip” to the native-inputs field.
I also noticed that the sources include files that were generated with
Cython. Instead of reusing those, we build them from source. Luckily
all we have to do in this case is to add “python-cython” to the
native-inputs field.
Finally, the tests. At first the tests wouldn’t run. So I looked up the
error message online and found that I need to use “python-pytest-runner”
in addition to “python-pytest”. This allows the tests to run up to a
point until it wants to do coverage tests. For those I needed to add
“python-pytest-cov”.
I changed the description, because I think it wasn’t quite correct.
Attached is my modified version. What do you think? Do you have any
questions about my changes?
>From 520d4cd8d9246ec4a1601906404194610f3905bd Mon Sep 17 00:00:00 2001
From: Vijayalakshmi
Date: Mon, 19 Mar 2018 22:20:25 +0530
Subject: [PATCH] gnu: Add python-logwrap.
* gnu/packages/python.scm (python-logwrap): New variable.
Co-authored-by: Ricardo Wurmus
---
gnu/packages/python.scm | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 76b5460f6..ff250a1ea 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -47,7 +47,8 @@
;;; Copyright © 2017 Brendan Tildesley
;;; Copyright © 2018 Ethan R. Jones
-;;;
+;;; Copyright © 2018 Vijayalakshmi Vedantham
+
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
@@ -524,6 +525,33 @@ pidof, tty, taskset, pmap.")
planar geometric objects. It is based on the @code{GEOS} library.")
(license license:bsd-3)))
+(define-public python-logwrap
+ (package
+(name "python-logwrap")
+(version "3.2.1")
+(source
+ (origin
+ (method url-fetch)
+ (uri (pypi-uri "logwrap" version ".zip"))
+ (sha256
+(base32
+ "1d2k0hvpbi51vl410y8fbs5m0nxnlh2k7gr2nrh3k81ibhzscsra"
+(build-system python-build-system)
+(propagated-inputs
+ `(("python-six" ,python-six)
+ ("python-typing" ,python-typing)))
+(native-inputs
+ `(("unzip" ,unzip)
+ ("python-cython" ,python-cython)
+ ("python-pytest" ,python-pytest)
+ ("python-pytest-cov" ,python-pytest-cov)
+ ("python-pytest-runner" ,python-pytest-runner)))
+(home-page "https://github.com/penguinolog/logwrap";)
+(synopsis "Decorator for logging function arguments")
+(description "This package provides a decorator to log function arguments
+and function call return values in a human-readable way.")
+(license license:asl2.0)))
+
(define-public python2-shapely
(package-with-python2 python-shapely))
--
2.16.2
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
Re: Internship on Improve the user experience for the "guix package" command line tool (Outreachy)
Hi, I'm really sorry about the effort you had to put into this patch. I'll try not to do it again. I had to append “.zip” because Pypi didn’t have a “.tar.gz” file for the > sources, so the uri > field now is: > >(pypi-uri "logwrap" version ".zip") > Did you do this because only .zip is available here ( https://pypi.python.org/pypi/logwrap#downloads)? > > I also noticed that the sources include files that were generated with > Cython. Instead of reusing those, we build them from source. Luckily > all we have to do in this case is to add “python-cython” to the > native-inputs field. > Can I know how you knew this? > Finally, the tests. At first the tests wouldn’t run. So I looked up the > error message online and found that I need to use “python-pytest-runner” > in addition to “python-pytest”. This allows the tests to run up to a > point until it wants to do coverage tests. For those I needed to add > “python-pytest-cov”. > > I changed the description, because I think it wasn’t quite correct. > Again, I'm sorry. Have you been able to build Guix already and try building the package using “./pre-inst-env guix build”? No, I tried last night but I faced some issues, I'll try again tonight. Thanks, Vijayalakshmi
Re: Shepherd release!
Hello, Andreas Enge skribis: > On Mon, Mar 19, 2018 at 05:42:11PM +0100, Ludovic Courtès wrote: >> You probably need to run ‘gettextize’ first. > > That is strange, why have I never heard about this command before? [...] > Then I just went ahead and did "autoreconf -vfi", but this yielded the > following error message: > > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal --force -I m4 > configure.ac:86: error: `po/Makefile.in' is already registered with > AC_CONFIG_FILES. > ../../lib/autoconf/status.m4:288: AC_CONFIG_FILES is expanded from... That’s because gettextize added po/Makefile.in a second time in AC_CONFIG_FILES. I don’t understand why ‘autoreconf’ doesn’t invoke ‘gettextize’ by itself. We’re doing the same as in Guix. Other than that, it’s working as expected. :-) Ludo’.
Re: pypi import certs issues
ng0 skribis: > Ludovic Courtès transcribed 2.7K bytes: >> Hello, >> >> ng0 skribis: >> >> > on commit 72406062b9c3cdb6e9e30266f3cc31d0b2116b68 pypi import has issues: >> > >> > user@abyayala ~$ guix package -l | grep "nss-certs" >> > user@abyayala ~$ env | grep "SSL_" >> > GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt >> > SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt >> > SSL_CERT_DIR=/home/user/.guix-profile/etc/ssl/certs:/etc/ssl/certs [...] >> > guix/build/download.scm:296:6: In procedure tls-wrap: >> > X.509 certificate of 'pypi.python.org' could not be verified: >> > insecure-algorithm >> > signer-not-found >> > invalid >> >> I don’t see that. Could it be that the certs you have in /etc/ssl are >> too old, or something along these lines? What if you do: export SSL_CERT_DIR=/etc/ssl/certs ? Ludo’.
Re: pypi import certs issues
Ludovic Courtès transcribed 911 bytes: > ng0 skribis: > > > Ludovic Courtès transcribed 2.7K bytes: > >> Hello, > >> > >> ng0 skribis: > >> > >> > on commit 72406062b9c3cdb6e9e30266f3cc31d0b2116b68 pypi import has > >> > issues: > >> > > >> > user@abyayala ~$ guix package -l | grep "nss-certs" > >> > user@abyayala ~$ env | grep "SSL_" > >> > GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt > >> > SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt > >> > SSL_CERT_DIR=/home/user/.guix-profile/etc/ssl/certs:/etc/ssl/certs > > [...] > > >> > guix/build/download.scm:296:6: In procedure tls-wrap: > >> > X.509 certificate of 'pypi.python.org' could not be verified: > >> > insecure-algorithm > >> > signer-not-found > >> > invalid > >> > >> I don’t see that. Could it be that the certs you have in /etc/ssl are > >> too old, or something along these lines? > > What if you do: > > export SSL_CERT_DIR=/etc/ssl/certs > > ? > > Ludo’. Okay, that worked. So why is the .guix-profile/etc/ssl/certs not updated? I don't even have nss-certs in my user profile, it is global. Continuing thought: Why is ~/.guix-profile/etc/ssl/certs/ empty? I assume it is just for user-space (space=profile in my line of thought here) certificates which are not global? Thanks -- A88C8ADD129828D7EAC02E52E22F9BBFEE348588 https://n0.is
Re: Internship on Improve the user experience for the "guix package" command line tool (Outreachy)
Hi Vijayalakshmi, welcome to Guix! On Tue, 20 Mar 2018 20:45:02 +0530 Vijayalakshmi Vedantham wrote: > Hi, > > I'm really sorry about the effort you had to put into this patch. > I'll try not to do it again. Seriously: I hope you are not discouraged by that. And I hope you do it again and again. Including the errs. Guix is tough stuff and we all did and do our mistakes. And each one helps to understand the system a bit better. And I really like this community because it is so soft and helpful and polite :-) > > > > I also noticed that the sources include files that were generated > > with Cython. Instead of reusing those, we build them from source. > > Luckily all we have to do in this case is to add “python-cython” to > > the native-inputs field. > > > > Can I know how you knew this? I can't speak for Ricardo but only for me: There is some intrinsic knowledge about each build system and each programming language, how they generate things, and how this relates to "building your software really from source in a FSF-compliant way". Just look at how others have done it in their package definitions. Present your package definition and get it reviewed. People will hint you politeful to this knowledge. > Have you been able to build Guix already and try building the > package using “./pre-inst-env guix build”? > > No, I tried last night but I faced some issues, I'll try again > tonight. Before submitting a patch, try to build it at least twice. If you have trouble to build it, submit it anyway and tell why it doesn't build (twice, because of reproducibility). Take a look at the Manual at https://www.gnu.org/software/guix/manual/guix.html#Packaging-Guidelines and https://www.gnu.org/software/guix/manual/guix.html#Submitting-Patches The latter one is like a checklist to go through before submitting. Happy Guix-ing, Björn pgpkdoaTEn0b_.pgp Description: OpenPGP digital signature
