Re: Rebasing guile-daemon branch onto master
Hi, On Wed, May 2, 2018 at 2:11 AM Ludovic Courtès wrote: > Awesome! Did you have troubles building it or running the test suite? > (See < https://www.gnu.org/software/guix/manual/html_node/Running-the-Test-Suite.html > .) The normal `guix environment guix` gave me errors while building the guile-daemon branch, but `guix environment guix --ad-hoc guile-sqlite3` fixed those and gave a successful build. A few tests are failing and I am looking into it. -- uniq10
Re: Building guix-modular with cuirass
Hey, > In the near future, I want ‘guix pull’ to install a ‘guix’ binary as > opposed to simply dropping a bunch of modules in ~/.config/guix/latest. > At that point we won’t have this kind of problem anymore. On the same topic, as I explained in a previous email (https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00222.html) my main use-case for cuirass is to evaluate my manifest and build the corresponding packages. I could use 'cuirass-jobs' procedure and set arguments to (#:arguments (subset . "my-package-1" "my-package-2" ...)). The drawback of this approach is that everytime the manifest is updated, a reconfigure of cuirass service is needed to update the package list. I'd like to have an upstream mecanism were cuirass evaluates a local manifest file (or even better take it from a git repository), an build all the corresponding packages. The only configuration input from the user would be the path of his manifest. My first idea would be to add a piece of code in build-aux/hydra/build-manifest.scm that would pull a manifest specified as an argument, evaluates the packages it contains and feed it to cuirass but that sounds a bit hacky. Any better idea ? Thanks, Mathieu
New Spanish PO file for 'shepherd' (version 0.3.3-pre1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'shepherd' has been submitted by the Spanish team of translators. The file is available at: http://translationproject.org/latest/shepherd/es.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/shepherd/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/shepherd.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
New Spanish PO file for 'shepherd' (version 0.3.3-pre1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'shepherd' has been submitted by the Spanish team of translators. The file is available at: http://translationproject.org/latest/shepherd/es.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/shepherd/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/shepherd.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
New Spanish PO file for 'shepherd' (version 0.3.3-pre1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'shepherd' has been submitted by the Spanish team of translators. The file is available at: http://translationproject.org/latest/shepherd/es.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/shepherd/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/shepherd.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH 0/1] Go importer
On Thu, Apr 26, 2018 at 06:22:38PM +0200, Rouby Pierre-Antoine wrote: > This patch is a importer for go packages, it's use git repository and the > 'Gopkg.toml' file (https://golang.github.io/dep/docs/Gopkg.toml.html). Neat! I didn't have a chance to review the code yet but I'm happy to see progress in this area. The examples look promising! I'll review it properly soon... I've noticed several different dependency manifest formats for Go software "in the wild". So, this one is specific to Go software using the Gopkg tool? Skimming the patch, I noticed a few places that I think could use some explanatory comments. For example, the git-checkout procedure. Since a few days have passed, it might be a good time for you to read it over and write some commentary on the sections that are beginning to become confusing, as all code does with time :) Nitpick... > (define-public go-github-com-fsouza-go-dockerclient > (let ((commit "master") (revision "0")) Does "master" refer to the branch? If so, we should avoid using it, since its value will probably change over time. We should stick to commits and tags. Tags can be changed but this is rarely done. signature.asc Description: PGP signature
Packaging a free Firefox
Hi, I find Icecat very buggy, even if I compare it to a home-made Firefox package that inherits Icecat (and thus is very close to Icecat). For example I can't even pay with my credit card with icecat-52-guix, whereas I can with firefox-home-52-guix. (It looks like a javascript issue.) Also, lots of videos don't work, and it's difficult to know whether it's because of technical issues or because of DRM. This may discourage people from using GuixSD. My understanding is that Icecat exists because of two reasons: 1. a trademark/logo issue, 2. the need to remove non-free code from Firefox. But it does more: 3. it only packages the stables versions of Firefox, 4. it adds add-ons, 5. it prevents the installation of non-free plugins, 6. probably other things that I'm not aware of. It seems to me that the trademark/logo issue and the non-free code removal could be dealt with at the Guix packaging level. It's probably just a huge bunch of substitutes to do. The package would be huge, but at least we would have control on it. That would remove a layer of complexity, and probably reduce bugs (that come from that layer). That would also allow us to have a recent version of Firefox. And it would be way better than everyone (I exaggerate a bit) having his home-made non-maintened full-of-security-issues Firefox. What do you think? Clément
Re: Packaging a free Firefox
Clément Lassieur writes: > Hi, > > I find Icecat very buggy, even if I compare it to a home-made Firefox > package that inherits Icecat (and thus is very close to Icecat). For > example I can't even pay with my credit card with icecat-52-guix, > whereas I can with firefox-home-52-guix. (It looks like a javascript > issue.) Also, lots of videos don't work, and it's difficult to know > whether it's because of technical issues or because of DRM. > > This may discourage people from using GuixSD. > > My understanding is that Icecat exists because of two reasons: > 1. a trademark/logo issue, > 2. the need to remove non-free code from Firefox. > > But it does more: > 3. it only packages the stables versions of Firefox, > 4. it adds add-ons, > 5. it prevents the installation of non-free plugins, > 6. probably other things that I'm not aware of. > > It seems to me that the trademark/logo issue and the non-free code > removal could be dealt with at the Guix packaging level. It's probably > just a huge bunch of substitutes to do. The package would be huge, but > at least we would have control on it. > > That would remove a layer of complexity, and probably reduce bugs (that > come from that layer). That would also allow us to have a recent > version of Firefox. > > And it would be way better than everyone (I exaggerate a bit) having his their ^ > home-made non-maintened full-of-security-issues Firefox. > > What do you think? > Clément
Re: Packaging a free Firefox
Clément Lassieur transcribed 1.5K bytes: > > Clément Lassieur writes: > > > Hi, > > > > I find Icecat very buggy, even if I compare it to a home-made Firefox > > package that inherits Icecat (and thus is very close to Icecat). For > > example I can't even pay with my credit card with icecat-52-guix, > > whereas I can with firefox-home-52-guix. (It looks like a javascript > > issue.) Also, lots of videos don't work, and it's difficult to know > > whether it's because of technical issues or because of DRM. > > > > This may discourage people from using GuixSD. > > > > My understanding is that Icecat exists because of two reasons: > > 1. a trademark/logo issue, > > 2. the need to remove non-free code from Firefox. > > > > But it does more: > > 3. it only packages the stables versions of Firefox, > > 4. it adds add-ons, > > 5. it prevents the installation of non-free plugins, > > 6. probably other things that I'm not aware of. > > > > It seems to me that the trademark/logo issue and the non-free code > > removal could be dealt with at the Guix packaging level. It's probably > > just a huge bunch of substitutes to do. The package would be huge, but > > at least we would have control on it. > > > > That would remove a layer of complexity, and probably reduce bugs (that > > come from that layer). That would also allow us to have a recent > > version of Firefox. > > > > And it would be way better than everyone (I exaggerate a bit) having his > their ^ > > home-made non-maintened full-of-security-issues Firefox. > > > > What do you think? > > Clément > > Among other things I've been working on Firefox. Not exactly with the intention of a free one per se, but at least to have it. I've been updating Aurora Nightly for a while. Thing is, it get's tricky after 54.0 due to mandatory Rust. I wanted to give the Rust problem another try soon, if you are serious about this, I can try and summarize it or provide snippets. You'l be able to find the package definitions, but they do not apply to Guix package structure (also I need to relicense it. whatever you'll find AGPL3 licensed is in fact GPL3 licensed now. I am just too busy to fix the headers, will do it on the weekend).. if I have commited the recent changes to the wip version. I seem to remember that the gnuzilla mailinglist did drop some hints about the core issue I had with rust.
Re: Packaging a free Firefox
Nils Gillmann transcribed 2.4K bytes: > Clément Lassieur transcribed 1.5K bytes: > > > > Clément Lassieur writes: > > > > > Hi, > > > > > > I find Icecat very buggy, even if I compare it to a home-made Firefox > > > package that inherits Icecat (and thus is very close to Icecat). For > > > example I can't even pay with my credit card with icecat-52-guix, > > > whereas I can with firefox-home-52-guix. (It looks like a javascript > > > issue.) Also, lots of videos don't work, and it's difficult to know > > > whether it's because of technical issues or because of DRM. > > > > > > This may discourage people from using GuixSD. > > > > > > My understanding is that Icecat exists because of two reasons: > > > 1. a trademark/logo issue, > > > 2. the need to remove non-free code from Firefox. > > > > > > But it does more: > > > 3. it only packages the stables versions of Firefox, > > > 4. it adds add-ons, > > > 5. it prevents the installation of non-free plugins, > > > 6. probably other things that I'm not aware of. > > > > > > It seems to me that the trademark/logo issue and the non-free code > > > removal could be dealt with at the Guix packaging level. It's probably > > > just a huge bunch of substitutes to do. The package would be huge, but > > > at least we would have control on it. > > > > > > That would remove a layer of complexity, and probably reduce bugs (that > > > come from that layer). That would also allow us to have a recent > > > version of Firefox. > > > > > > And it would be way better than everyone (I exaggerate a bit) having his > > their ^ > > > home-made non-maintened full-of-security-issues Firefox. > > > > > > What do you think? > > > Clément > > > > > Among other things I've been working on Firefox. Not exactly with the > intention > of a free one per se, but at least to have it. I've been updating Aurora > Nightly > for a while. > Thing is, it get's tricky after 54.0 due to mandatory Rust. I wanted to give > the > Rust problem another try soon, if you are serious about this, I can try and > summarize > it or provide snippets. You'l be able to find the package definitions, but > they do > not apply to Guix package structure (also I need to relicense it. whatever > you'll > find AGPL3 licensed is in fact GPL3 licensed now. I am just too busy to fix > the > headers, will do it on the weekend).. if I have commited the recent changes > to the > wip version. > I seem to remember that the gnuzilla mailinglist did drop some hints about > the core > issue I had with rust. > Addition: I think constructing and maintaing a free, unbranded version of Firefox (Aurora) or even a branded one with a Guix theme is possible. What icecat does is not that complex but it requires at least more than 1 person checking the sources continuously. Furthermore we'd need a common ground of goals what changes would be applied and what changes are a no-go.
Re: Packaging a free Firefox
While not directly related to Firefox, Next Browser is also a full-featured, highly-compatible webbrowser. I'll package it for Guix very soon: https://github.com/next-browser/next/issues/92 http://next-browser.com/ -- Pierre Neidhardt signature.asc Description: PGP signature
Re: a GUIX_PACKAGE_PATH / modules puzzle
Nils Gillmann writes: > Hi, > > I'm not sure if guile-users / -dev liste is more appropriate. If it is, let > me know. > > I'm currently still using GUIX_PACKAGE_PATH until I got my layout all set up. > There's an issue that I can't seem to get rid of, I'll try my best to > describe it now: > > I have package definitions in 2 repositories (3 to be precise, +1 WIP repo). > Both follow > the exact same layout that can still be understood by Guix and GPP > (GUIX_PACKAGE_PATH). > > Repository 1: /home/user/src/infotropique/ports > Repository 2: /home/user/src/infotropique/pkgs > > The modules are in similar named subfolders, following the layout $REPONAME > $CATEGORY $NAME NAME. > > I only switched to this recently, previously the "CATEGORY NAME NAME" was > located in the root of > the reository. Both repos worked this way. > > After the transition to the new layout, ports works. > pkgs however is throwing errors at me for days. I've tried moving all but one > module > out of the repo, same error. It was a simple easy, no repo-internal > dependencies, module. > The error is always similar to https://ftp.n0.is/pub/pkgs-error.txt > > I can not share the actual repo at this moment on this mailinglist, but maybe > the > repl message is something that someone could give me a hint, even if it's > just a > tiny bit of a "read this manpage" or something like that would help. I've > tried > debugging this for days and any help's welcome. Could this error be coming from the scheme-files procedure in (guix discovery)? It looks like that's the only place where fold-right is invoked in that module, and it seems to match up with the stack trace, unless I'm misreading it (which is possible). You might find it useful to insert some pk statements into that code to try to figure out what is being evaluated as "unspecified". My guess, which could be wrong, is that perhaps scandir* is returning an unspecified value unintentionally at some point? Someone with more experience debugging Guile code can probably provide better advice. -- Chris signature.asc Description: PGP signature
Re: a GUIX_PACKAGE_PATH / modules puzzle
Chris Marusich transcribed 3.0K bytes: > Nils Gillmann writes: > > > Hi, > > > > I'm not sure if guile-users / -dev liste is more appropriate. If it is, let > > me know. > > > > I'm currently still using GUIX_PACKAGE_PATH until I got my layout all set > > up. > > There's an issue that I can't seem to get rid of, I'll try my best to > > describe it now: > > > > I have package definitions in 2 repositories (3 to be precise, +1 WIP > > repo). Both follow > > the exact same layout that can still be understood by Guix and GPP > > (GUIX_PACKAGE_PATH). > > > > Repository 1: /home/user/src/infotropique/ports > > Repository 2: /home/user/src/infotropique/pkgs > > > > The modules are in similar named subfolders, following the layout $REPONAME > > $CATEGORY $NAME NAME. > > > > I only switched to this recently, previously the "CATEGORY NAME NAME" was > > located in the root of > > the reository. Both repos worked this way. > > > > After the transition to the new layout, ports works. > > pkgs however is throwing errors at me for days. I've tried moving all but > > one module > > out of the repo, same error. It was a simple easy, no repo-internal > > dependencies, module. > > The error is always similar to https://ftp.n0.is/pub/pkgs-error.txt > > > > I can not share the actual repo at this moment on this mailinglist, but > > maybe the > > repl message is something that someone could give me a hint, even if it's > > just a > > tiny bit of a "read this manpage" or something like that would help. I've > > tried > > debugging this for days and any help's welcome. > > Could this error be coming from the scheme-files procedure in (guix > discovery)? It looks like that's the only place where fold-right is > invoked in that module, and it seems to match up with the stack trace, > unless I'm misreading it (which is possible). You might find it useful > to insert some pk statements into that code to try to figure out what is > being evaluated as "unspecified". My guess, which could be wrong, is > that perhaps scandir* is returning an unspecified value unintentionally > at some point? Someone with more experience debugging Guile code can > probably provide better advice. > > -- > Chris What I found is that: (pkgs sys-kernel) providing common logics for (pkgs sys-kernel linux linux) [and planned, (pkgs sys-kernel linux-libre)] and (ports sysutils firmware some-firmware) as well as (pkgs sys-kernel linux-headers) created a problem. This, moving the definitions from the old linux module I had out to a common module, was one of the few breaking changes. I wasn't able to resolve this as amirouche told me on irc. I want to remove some last bits of these imports tonight. I was able to update my system with the modules in another place and imports corrected. What's weird to me is that even after cleaning the ccache of guile in the respective locations a package that isn't involved in the new change, like for example numactl, as the only package definition in this place throws errors. In another location it works. I didn't come up with the name "pkgs" for the root of the repository yesterday, I have used this for a couple of months in a working state. Anyways, in which section of the guile Manual would I find "pk"? I've done surprisingly little debugging with Guile itself so far.
Re: Packaging a free Firefox
Clément Lassieur writes: > I find Icecat very buggy, even if I compare it to a home-made Firefox > package that inherits Icecat (and thus is very close to Icecat). For > example I can't even pay with my credit card with icecat-52-guix, > whereas I can with firefox-home-52-guix. (It looks like a javascript > issue.) Also, lots of videos don't work, and it's difficult to know > whether it's because of technical issues or because of DRM. This has not been my experience with IceCat. With two exceptions, IceCat has performed just as well as Firefox for me for everything I have done, including credit card payments. I sometimes watch YouTube videos using IceCat, but I don't view many other videos, so I can't really comment on how well IceCat handles videos. If it requires DRM, of course, it's not going to work in IceCat, which is a good thing. When I use IceCat over TOR, it doesn't always work. When I use IceCat with extensions (plugins? add-ons? I'm not sure what the right terminology is here) like NoScript enabled, it doesn't always work. But when I don't use TOR and I disable those add-ons, everything works just as well as stock Firefox. If you're still having trouble after disabling those things, can you describe the specifics of what you're having trouble with? The exceptions I have experienced with IceCat: 1) A website failed for me because IceCat enables Referer spoofing by default (network.http.referer.spoofSource in about:config). I had to disable that feature to use that website. 2) It used to be that IceCat would crash frequently for me. However, once I changed my gfx.canvas.azure.backends and gfx.content.azure.backends from "cairo" to "skia", this problem stopped for me. I don't know if this is still an issue , since I haven't ever switched it back to "cairo". See here for details: https://lists.gnu.org/archive/html/help-guix/2016-11/msg8.html -- Chris signature.asc Description: PGP signature
