bug#45450: Guix, third-party repositories and GNU FSDG

Severity: critical According to the GNU FSDG ([1], emphasis are mine): > A free system distribution must not steer users towards obtaining any nonfree > information for practical use, or encourage them to do so. The system should > have no repositories for nonfree software and no specific

bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

Hi there! :D Em 07/03/2019 01:17, Vagrant Cascadian escreveu: > How many of them are also license:gpl* though? That would hopefully My Guix pull is from commit d22d246a256814784dfb03437949bdc2efd746a5. I made a little recsel trick to get all packages licensed under [A]GPL (any version) and

bug#34565: ungoogled-chromium contains Widevine DRM

Em 20/02/2019 13:18, Julien Lepiller escreveu: > I think the situation is different though. You can see the build script > inside the "origin" record as the liberation procedure that anyone can > see and verify. It's also a procedure targeted at our build farms, so > that they can produce the

bug#33996: Icecat is missing fonts

Em 06/01/2019 08:31, swedebu...@riseup.net escreveu: > After installing Icecat on guixsd v0.16 and starting it it shows only > squares instead of text and pango warns "missing font nimbus ..." This behavior seems similar to what I experience while using Guix in Trisquel 8.0 Flidas. The problem

bug#33993: Missing Texinfo documentation for Guix itself

Note: Replying only to the list as it makes it easy for others and their email clients to filter/split this message according to List-id header field. Em 06/01/2019 07:10, Ricardo Wurmus escreveu: > The installer script creates links from > /var/guix/profiles/per-user/root/current-guix/share/info

bug#33993: Missing Texinfo documentation for Guix itself

This copy of Guix (in Trisquel 8.0 Flidas amd64) was installed using the shell script installer (for which I became root for that, that is, used `sudo -i'). The binary version downloaded was 0.16.0. At least after pulling and upgrading the recipes based on commit

bug#31162: "guix pull" broke itself

2018-04-24T22:57:55+0200 Danny Milosavljevic wrote: > How do I do that? There are several ways to go around this, but since now we are past the fact, that is, it already happened, then I propose the following method: --8<---cut here---start->8--- $ cd

bug#31001: Emacs: "User xyz has no home directory"

> I found this link to describe the same issue in Nix, and the same fix > that worked for me (i.e. install `nscd`): > Indeed, I think that the GNU Guix info pages already documents this. Back in some months ago, it was documented but wasn't felt

bug#30961: Byte compilation problem with emacs-org

> happens when the newer org-mode is byte-compiled, and leads to wrong > .elc files. Doesn't the official Emacs docs recommend against byte compiling? Why we have such nasty thing here? I also noticed some odd behavior with emacs-org coming from GNU Guix, mainly causing the impossibility of

bug#30841: Building Zend PHP (php): tests fail, and "Name or service not known"

> I also made my own "/etc/nsswitch.conf" file, which is attached. The By the way I *did* notice the typo in "ndns" --- it should be "mdns" ---, and I corrected it, restarted nscd, restarted guix-daemon, and tried again, with no good results. I also tried "hosts: files dns", restarted nscd and

bug#30841: Building Zend PHP (php): tests fail, and "Name or service not known"

> situations, due to a change in glibc. The solution was to install "nscd" > (possibly in your host distribution if you are not on GuixSD). > > Could you give it a try? I already have host/foreign distro's "nscd" package installed, and the daemon was/is already running. - Distro: Trisquel 7 -

bug#30841: Building Zend PHP (php): tests fail, and "Name or service not known"

This is known to started happening from a `guix pull' done in 2018-03-10T11:00:56-0300. I did another pull yesterday (2018-03-16T16:30:42-0300) and the problem continued. I didn't bisect this problem yet. That is: I don't know if it started happening in a commit from dates before. Here is

bug#29662: bug#24194: GUIX gc - add warning

Has the person who had the unsubscription issue already solved the specific problem? I'm sending this message to person anyways, if you received it twice, then you are still subscribed. Can some list administrator confirm if the person is already unsubscribed? Finally, Joshua, I think we are

bug#29519: ./pre-inst-env: substitute: Failed to autoload make-session in (gnutls)

I didn't test this yet, but I was wondering about `sudo' "-E"/"--preserve-env" option, wasn't it dropped because it would conflict with other variables that the user has? Or better yet, because it would take package definitions from other places? 2017-12-04T10:07:40+0100 Ludovic Courtès wrote: >

bug#29333: potential dependency bug in packages

I don't use GuixSD, but at least with GNU Guix in foreign distros you have to install the appropriate icon themes from GNU Guix and add a path to the XDG_DATA_DIRS environment variable. however, I think GuixSD has an automated way of dealing with this, perhaps put the themes in the system

bug#29302: Kodi crashed

Please send your reply only to <29...@debbugs.gnu.org>. Forget help-guix now that the bug is reported. Someone has to test this to see if it still affects people as of today. Besides, it would be a good idea to test with DRI3 capable screens (whatever this means). ;) 2017-11-14T23:21:49-0600

bug#26006: New web site is on line!

+1 2017-12-06T18:55:00+0100 Alex Sassmannshausen wrote: > Wow, that looks super cool, well done! > > Really smooth and modern feel. Joyful to explore :-) >

bug#26006: New web site is on line!

This is of course minor issue but we just have to insert proper copyright + license notices in the .scm files. ;) 2017-12-06T18:10:48+0100 Ludovic Courtès wrote: > Hello! > > It’s embarrassing that it took us so long, but I’m happy to say that the > new web site is on line! > >

bug#29519: ./pre-inst-env: substitute: Failed to autoload make-session in (gnutls)

I'm experimenting developing directly to the Git checkout instead of using GUIX_PACKAGE_PATH to develop and test package definitions. Currently this is what I do: --8<---cut here---start->8--- # If the local clone is somewhat dirty, clear it. git reset --hard

bug#29426: guix: "make check" test "utmpx-entries" fails

Thank you very much. It works nicely now. ;) 2017-11-25T18:14:36+0100 Ludovic Courtès wrote: > Hi, > > > This is the culprit: its ‘pid’ is 0, but its type is not BOOT_TIME as > the test expects. Instead, it’s DEAD_PROCESS (8). > > Fixed in commit 4aac8d059a2bec9f075ceea2a089ca029a71912c. > >

bug#29426: guix: "make check" test "utmpx-entries" fails

I did the following: --8<---cut here---start->8--- guix environment guix ./bootstrap ./configure --localstatedir="/var" ./pre-inst-env guile --8<---cut here---end--->8--- And inside Guile REPL: --8<---cut

bug#29426: guix: "make check" test "utmpx-entries" fails

Currently, "make check" test "utmpx-entries" fails, to reproduce, do: --8<---cut here---start->8--- git clone "https://git.savannah.gnu.org/git/guix.git; guix environment guix ./bootstrap ./configure --localstatedir="/var" make check --8<---cut

bug#29365: openmolar looking in /usr/share/openmolar

Adding to what Chris Marusich described: 'substitute* works somewhat in the following way: --8<---cut here---start->8--- (substitute FILE-string-or-FILE-list-of-strings ((EREGEX-string SYMBOLS-to-put-both-entire-match-and-captures-or-NOTHING)

bug#15549: hydra.gnu.org uses nontrivial and nonfree javascript

Do you by chance know of some way I can contribute directly to the development of hydra.gnu.org web site? If there is at least a way to make a copy of the web pages, I can try making a LibreJS-compliant version of them --- the only thing needed would be some server to test them if they need a

bug#28758: texlive@2017: Update to at least revision 44704 to address bug in latexdiff

I have downloaded TeX Live repository but unfortunatelly I found out that the directory structure of the repository is different than the release's. An option would be to make latexdiff into a separate package, with a name such as "texlive-texmf-scripts-latexdiff", and take the source from either

bug#29021: gnu: biber@2.7: "check" phase fails at "dateformats.t" tests

When attempting: $ guix package --fallback -i biber This is the interesting part of the output: --8<---cut here---start->8--- starting phase `configure' running `perl' with arguments ("Build.PL" "--prefix=/gnu/store/0mkxal471rqb55zvnqrapp970irzdb5i-biber-2.7"

bug#28554: teeworlds not starting

Besides what was stated here, one can take problematic package definition and edit it such that it makes use of the missing parts. But doing this directly in the official package definitions is beyond what the community can do. That is, it has to be done by the person interested. In Scheme, it

bug#28758: texlive@2017: Update to at least revision 44704 to address bug in latexdiff

Since Perl 5.26.0, braces in RegExps have to be escaped if one wants Perl to match these literally. However, texlive@2017 --- from June 4th, 2017 --- doesn't implement the fix made to latexdiff ([1][2]) --- made into TeX Live repository in June 26th, 2017. Without the fix, `latexdiff' command is

bug#28754: webkitgtk@2.18.0: WebCore/HysteresisActivity.h: No such file or directory

It seems that packages depending on webkitgtk@2.18.0 might fail to be built. What should we do? See the log below: --8<---cut here---start->8--- In file included from

bug#28602: Unpack fails with no error message when using a .zip source

Does the .zip file have a a single directory on the root? If not, then we can call it a zipbomb/tarbomb. These bombs are bad because they can replace things without notice, and can be very difficult to track what was added. Last time I checked Guix expects only a single directory in the root of

bug#25034: red-eclipse: "data" directory in "$out/", not in "$out/share"

I have sent a patch as an attempt to fix this issue, see [[https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28164]]. -- - [[https://libreplanet.org/wiki/User:Adfeno]] - Palestrante e consultor sobre /software/ livre (não confundir com gratis). - "WhatsApp"? Ele não é livre. Por favor, use o GNU

bug#25034: red-eclipse: "data" directory in "$out/", not in "$out/share"

It turns out that I couldn't figure out how to do so. So far I have tried: - Attempt 1 - Add the output path as "prefix" variable to #:make-flags. But I don't think this will work because $(prefix) seems hard-coded in "src/system-install.mk". - Attempt 2 - Change "copy-paths"

bug#27686: emacs-ess: Not installed in "${output}/share/emacs/site-lisp/guix.d"

Indeed, I also wonder if the "guix.d" directory is a good idea to keep or not. Thank you very much for the fix too. :) -- - [[https://libreplanet.org/wiki/User:Adfeno]] - Palestrante e consultor sobre /software/ livre (não confundir com gratis). - "WhatsApp"? Ele não é livre. Por favor, use o

bug#27590: artanis has a bundled and customized copy of guile-json package

Also see the reply given by Mx. Ginrut: [[https://lists.gnu.org/archive/html/artanis/2017-07/msg1.html]].

bug#27590: artanis has a bundled and customized copy of guile-json package

, I assume however that '->json-string was similar to 'scm->json-string. >From 8ec0eaaa0e552e7d99be369a4251b2577ac927ac Mon Sep 17 00:00:00 2001 From: Adonay Felipe Nogueira <adf...@openmailbox.org> Date: Fri, 28 Jul 2017 11:18:03 -0300 Subject: [PATCH] gnu: artanis: Unbundled guil

bug#27590: artanis has a bundled and customized copy of guile-json package

I have compared the two. Note however that I didn't test them, I only read the diffs, so my notes might not accurately reflect nested/complex cases. Discarding the new features implemented in guile-json since the bundled customization and the deprecation of (json ...) macro, it seems that

bug#27590: artanis has a bundled and customized copy of guile-json package

I have asked for more information on the artanis mailing list, see [[https://lists.gnu.org/archive/html/artanis/2017-07/msg0.html]].

bug#27686: emacs-ess: Not installed in "${output}/share/emacs/site-lisp/guix.d"

It seems that Emacs ESS mode isn't installed in the same location as other packages are. Also note that emacs-ess doesn't use the Emacs build system. I don't know if this is indeed the issue (and if we can force it to use such build system), but I think this is an important note to make. The

bug#27590: artanis has a bundled and customized copy of guile-json package

Commit 71b0418843ef0aa8de97734851879a0479c81f69 in the Git repository of GNU Artanis introduces this issue. The affected files are at "artanis/third-party/json/upstream". There is another file at "artanis/third-party/json.scm", but I don't know if it is from guile-json. The file at

bug#27489: glibc fails to build on i686

Removing the "~/.config/guix/latest" symbolic link as was suggested by Mx. Weaver worked, now my root user can pull and also upgrade the "guix" package. Thank you all for the suggestion. :) Besides, as was also suggested: I'll use the "master" branch instead.

bug#27489: glibc fails to build on i686

NOTE: This message isn't meant to sound aggressive, it's just a question from a novice Guix user. Here is my situation: - I'm using Guix in a foreign distribution (Trisquel 7). - In 2017-06-12, I pulled and upgraded Guix and packages successfully as root. - Last weekend I did (all as root):

bug#26659: [contact....@cryptolab.net: Re: fonts bug in icecat?]

Or you can do "the inverse", by doing this: 1. *Do not* install fontconfig from Guix, but make sure to have fontcofig installed in your foreign distro. 2. Make the file "$XDG_CONFIG_HOME/fontconfig/fonts.conf" with contents: # Begin of file ~/.guix-profile/share/fonts # End of file

bug#26659: [contact....@cryptolab.net: Re: fonts bug in icecat?]

Another report made by me which might be related to this issue: I noticed that the copy of Inkscape that I installed through Guix doesn't include the fonts that are provided by the foreign distro (Trisquel 7) so far, although it does include the fonts that are inside "$XDG_DATA_HOME/fonts" (and

bug#25035: scribus: No module named _sysconfigdata_nd

This bug still exists if one installs Scribus through Guix in a foreign system distribution. Even though I still have both LD_LIBRARY_PATH and PYTHONPATH variables unset and I don't have Python installed through Guix. However, today I decided to test with: $ guix environment --ad-hoc scribus

bug#26202: Guix in foreign distributions: setting XDG_DATA_DIRS causes user session to not start

It turns out that the XDG_DATA_DIRS bug is due to foreign distributions using some Xsession.d scripts that do tests to check if that variable is empty, and if it does exist, then they do nothing. This causes the system to simply not set XDG_DATA_DIRS to useful values for foreign distributions,

bug#25037: abiword: Not openning file chooser, and GLib-GIO-ERROR error

The command `env` prints this: # Begin of output LC_PAPER=pt_BR.UTF-8 XDG_VTNR=7 GUIX_LOCPATH=/home/adfeno/.guix-profile/lib/locale SSH_AGENT_PID=1933 XDG_SESSION_ID=c2 LC_ADDRESS=pt_BR.UTF-8 LC_MONETARY=pt_BR.UTF-8 XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/adfeno

bug#25035: scribus: No module named _sysconfigdata_nd

Hi all, A reply just so that we can further investigate this issue later on. The variable $LD_LIBRARY_PATH is indeed unset.

bug#24834: Samba commands expect configuration file inside store

Here's a patch that tries to fix this issue. I already tested it, but please do so also just in case. Respectfully, Adonay. >From 086396d33e113a6d991b7c63063844c66a5610ca Mon Sep 17 00:00:00 2001 From: Adonay Felipe Nogueira <adf...@openmailbox.org> Date: Sat, 3 Dec 2016 21:22:56 -020

bug#25035: scribus: No module named _sysconfigdata_nd

Note: Sorry friends, I pressed the wrong reply button (private reply). Now, I'm replyng to the bugs mailing list. I'm running Guix on a foreign distribution, and $PYTHONPATH is unset. The foreign distribution in question is Trisquel 7 (which is based on the Ubuntu 14.04). I'll read some

bug#25034: red-eclipse: "data" directory in "$out/", not in "$out/share"

Simple to check, simply list the contents of Red Eclipse's store entry. The "data" directory is at the root. Shouldn't it be "$out/share/red-eclipse/data"? Or "$out/share/red-eclipse"? Respectfully, Adonay.

bug#24834: Samba commands expect configuration file inside store

Tested the patch today It seems that, during the `install' phase, something tries to make "/etc/samba" directory. The log from the start of the error is attached. I did `guix build samba` as normal user, and since I'm new to this situation, I must ask: should I run it as root instead? Or should

bug#24834: Samba commands expect configuration file inside store

Tested the patch today It seems that, during the `install' phase, something tries to make "/etc/samba" directory. The log from the start of the error is attached. I did `guix build samba` as normal user, and since I'm new to this situation, I must ask: should I run it as root instead? Or should

bug#24834: Samba commands expect configuration file inside store

Thank you for the suggestion! I'll reinstall Samba from Guix here, and will test it. I plan to do so this weekend. Respectfully, Adonay.

bug#24834: Samba commands expect configuration file inside store

# Begin of terminal interaction $ strace ".guix-profile/sbin/samba/smbd" stat64("/gnu/store/...-samba-4.5.0/etc/samba/smb.conf", 0xbfeb41b0) = -1 ENOENT (No such file or directory) open("/gnu/store/...-samba-4.5.0/etc/samba/smb.conf", O_RDONLY| O_LARGEFILE) = -1 ENOENT (No such file or directory)

bug#23633: artanis package installation broken

I sent another patch to fix my typos in the Makefile and typo in a Scheme script, made by someone else, see: . signature.asc Description: This is a digitally signed message part

bug#23633: artanis package installation broken

I was thinking of editing the current recipe so as to get the package from their current repository commit. What do you think? Should we do as I said just now, or should we do as you suggested? There's still one patch that I made for Artanis, that is supposed to correct a mistake I did in the

bug#23633: artanis package installation broken

I have sent a patch that tries to fix the issue. See: -- # pt-BR: Brasileiro | en: Brazilian * pt-BR: Palestra sobre liberdade de software (movimento filosófico político-social, não tecnológico). * en: Gives talks about software freedom

bug#24550: Epiphany, errors in terminal, and missing icons

Sorry, I was in such a hurry that I forgot to tell the version of Epiphany. It's version 3.22.0. I have changed the themes to test if the icons would appear. # Before Window: "Trisquel" (from one "trisquel"-related package???) GTK+: "Trisquel" (from "trisquel-gtk-theme" package) Icons: