bug#34565: ungoogled-chromium contains Widevine DRM
Marius Bakke transcribed 1.2K bytes:
> Giovanni Biscuolo writes:
>
> > Hello,
> >
> > maybe Marius Bakke have something interesting to say about his
> > judgements on this "DRM matter"
>
> [...]
>
> > to sum it up: AFAIU for users to be able to use Widevine they must
> > create a custom package definition _outside_ official Guix channels
> > *and* download the shared object "libwidevinecdm.so" from Chromium,
> > installing it "manually" system wide or locally
>
> This analysis is correct. For DRM to work, the user has to build with
> "enable_widevine=true", and then somehow obtain 'libwidevinecdm.so' and
> make the browser use it.
Can this bug be closed?
The wording is very vague ("may") and for Guix to distribute widevine.so
legally, you have to get permission and sign an NDA with Google, both of
which are reportedly hard for 3rd party devs even, not sure how hard it is
for new operating systems. Your stand on software with NDAs should be clear
(as per policy not applicable, no NDAs).
So even if traces of the code to build this might still be left, you have
to master additional steps to make it work, and after having read some
of widevine.so I doubt it would work out of the box with Guix System
(elfpatching could get it to work with Guix, but you are still entering
the field where official distribution requires legal paperwork).
signature.asc
Description: PGP signature
bug#24450: pypi importer outputs strange character series in optional dependency case.
Hi Maxim,
great to see this fixed. Weird it bumped into my view after
almost 3 years. I trust that other people will have tested
it, I'm all over the place and mostly doing NetBSD and GNUnet
now.
Sorry if I have written a reply before, the thread was
marked as unread here.
Maxim Cournoyer transcribed 3.5K bytes:
> ng0 writes:
>
> > I think this should not happen with pypi import:
> >
> > (inputs
> > `(("python-certifi==2016.2.28"
> >,python-certifi==2016.2.28)
> > ("python-dateutil==2.5.3"
> >,python-dateutil==2.5.3)
> > ("python-flask-babel==0.11.1"
> >,python-flask-babel==0.11.1)
> > ("python-flask==0.11.1" ,python-flask==0.11.1)
> > ("python-lxml==3.6.0" ,python-lxml==3.6.0)
> > ("python-ndg-httpsclient==0.4.1"
> >,python-ndg-httpsclient==0.4.1)
> > ("python-pyasn1-modules==0.0.8"
> >,python-pyasn1-modules==0.0.8)
> > ("python-pyasn1==0.1.9" ,python-pyasn1==0.1.9)
> > ("python-pygments==2.1.3"
> >,python-pygments==2.1.3)
> > ("python-pyopenssl==0.15.1"
> >,python-pyopenssl==0.15.1)
> > ("python-pyyaml==3.11" ,python-pyyaml==3.11)
> > ("python-requests[socks]==2.10.0"
> >,#{python-requests\x5b;socks\x5d;==2.10.0}#)
> > ("python-setuptools" ,python-setuptools)))
> >
> >
> > I can understand the version numbers, I can also understand the optional
> > socks building/module of the python-requests, but why does it read like
> > Gobbledygook? Can't we improve the output here?
> >
> > For version numbers, this is not a format which happened recently which
> > is exclusive for python build system right? This is just bad formated
> > because of the pypi query.
> > I will first try and not pin the application to these version numbers,
> > maybe itjustworks™.
> >
> >
> > To reproduce: "guix import pypi searx"
>
> This would now give (change to be sent for review soon):
>
> --8<---cut here---start->8---
> ./pre-inst-env guix import pypi searx
>
> Starting download of /tmp/guix-file.1wD8K4
> From
> https://files.pythonhosted.org/packages/75/3f/5941ad2d500ff7cf6f8da1022c78013dcd2207941d533586a8e7bfe699d3/searx-0.15.0.tar.gz...
> …5.0.tar.gz 1.6MiB 729KiB/s 00:02 [##]
> 100.0%
> (package
> (name "python-searx")
> (version "0.15.0")
> (source
> (origin
> (method url-fetch)
> (uri (pypi-uri "searx" version))
> (sha256
> (base32
> "1gmww73q7wydkvlyz73wnr3sybpjn40wha7avnz9ak9m365zcjxf"
> (build-system python-build-system)
> (propagated-inputs
> `(("python-certifi" ,python-certifi)
> ("python-dateutil" ,python-dateutil)
> ("python-flask" ,python-flask)
> ("python-flask-babel" ,python-flask-babel)
> ("python-idna" ,python-idna)
> ("python-lxml" ,python-lxml)
> ("python-pygments" ,python-pygments)
> ("python-pyopenssl" ,python-pyopenssl)
> ("python-pyyaml" ,python-pyyaml)
> ("python-requests" ,python-requests)))
> (native-inputs
> `(("python-babel" ,python-babel)
> ("python-cov-core" ,python-cov-core)
> ("python-mock" ,python-mock)
> ("python-nose2" ,python-nose2)
> ("python-pep8" ,python-pep8)
> ("python-plone.testing" ,python-plone.testing)
> ("python-selenium" ,python-selenium)
> ("python-splinter" ,python-splinter)
> ("python-transifex-client"
>,python-transifex-client)
> ("python-unittest2" ,python-unittest2)
> ("python-zope.testrunner"
>,python-zope.testrunner)))
> (home-page "https://github.com/asciimoo/searx";)
> (synopsis
> "A privacy-respecting, hackable metasearch engine")
> (description
> "A privacy-respecting, hackable metasearch engine")
> (license #f))
> --8<---cut here---end--->8---
>
>
>
>
bug#35417: Tor Service
Julien Lepiller transcribed 565 bytes: > Le 24 avril 2019 18:34:22 GMT+02:00, Raghav Gururajan a > écrit : > >Hello Guix! > > > >Including "tor-service-type" does not invoke and add "tor" package into > >the system. Without "tor" package, tor commands cannot be used. > >Therefore, "tor-service-type" is of little or no use, if it does not > >invoke and add "tor" package into the system. > > > >Regards, > >RG. > > Hi, > > What kind of command do you want to run? The tor service runs tor and you can > configure, eg. your browser to use it through a socks proxy. So it is of some > use :) My guess is that this is about torsocks.
bug#34922: guile-wm crashes on login
If I remember my interaction with guile-wm correctly this is expected behavior out of the box. Upstream has probably moved on to other interests, because there are more errors at runtime once you get to launch into guile-wm. For a couple of years now volunteers have been asking about how to help and so on but nothing has happened. jesse transcribed 26K bytes: > I am trying to use guile-wm, but it fails when I launch it. > I define an operating system that includes guile-wm as a package and use > it to build a virtual machine image. Here is the operating system > definition: > ~ > > (use-modules (gnu) (gnu system nss)) > (use-service-modules desktop) > (use-package-modules certs gnome guile-wm) > > (operating-system > (host-name "piranhaplant") > (timezone "America/Boise") > (locale "en_US.utf8") > > (bootloader (bootloader-configuration > (bootloader grub-bootloader) > (target "/dev/sda"))) > > (file-systems (cons (file-system > (device (file-system-label "mini8")) > (mount-point "/") > (type "ext4")) > %base-file-systems)) > > (users > %base-user-accounts) > > (packages (cons* nss-certs > gvfs > guile-wm > %base-packages)) > > (services (cons* (gnome-desktop-service) > %desktop-services)) > > (name-service-switch %mdns-host-lookup-nss)) > > > ~ > > When I try to log in, it flashes an error so fast I cannot record it, > then returns to the login screen. When I launch it from a console, it > sends the following to stderr: > > ~ > > ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 > ;;; or pass the --no-auto-compile argument to disable. > ;;; compiling > /gnu/store/q549b5c0fwds1l8bycvabva3jwr86p63-guile-wm-1.0-1.f3c7b3b/bin/.guile-wm-real > ;;; compiling > /gnu/store/q549b5c0fwds1l8bycvabva3jwr86p63-guile-wm-1.0-1.f3c7b3b/share/guile/site/2.2/guile-wm/shared.scm > ;;; compiling > /gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml.scm > ;;; compiling > /gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/connection.scm > ;;; compiling > /gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/struct.scm > ;;; compiling > /gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/type.scm > ;;; compiling > /gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/enum.scm > ;;; compiling > /gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/records.scm > ;;; compiled > /root/.cache/guile/ccache/2.2-LE-8-3.A/gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/records.scm.go > ;;; compiled > /root/.cache/guile/ccache/2.2-LE-8-3.A/gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/enum.scm.go > ;;; compiled > /root/.cache/guile/ccache/2.2-LE-8-3.A/gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/type.scm.go > ;;; compiling > /gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/union.scm > ;;; compiled > /root/.cache/guile/ccache/2.2-LE-8-3.A/gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/union.scm.go > ;;; compiled > /root/.cache/guile/ccache/2.2-LE-8-3.A/gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/struct.scm.go > ;;; compiled > /root/.cache/guile/ccache/2.2-LE-8-3.A/gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/connection.scm.go > ;;; compiling > /gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/doc.scm > ;;; compiled > /root/.cache/guile/ccache/2.2-LE-8-3.A/gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/doc.scm.go > ;;; compiling > /gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/auth.scm > ;;; WARNING: compilation of > /gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/auth.scm > failed: > ;;; no code for module (xcb xml xproto) > ;;; WARNING: compilation of > /gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml.scm > failed: > ;;; no code for module (xcb xml xproto) > ;;; compiling > /gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/core.scm > ;;; WARNING: compilation of > /gnu/store/gv2n0k75d5svzcgwqna33nvhvczrj3z2-guile-xcb-1.3-1.db7d5a3/share/guile/site/2.2/xcb/xml/core.scm > failed: > ;;; no code for module (xcb xml xproto)
bug#30939: shepherd: detailed output should be placed into well-known location and not tty
Ludovic Courtès transcribed 839 bytes: > Hello, > > ng0 skribis: > > > Sometimes I succeed building a system generation with an OpenSMTPD > > config-file > > which has syntax error that aren't picked up at configure time. When I > > reboot, > > not being aware of this, I have to switch to tty to read the reasons why it > > crashed. > > Because this is a desktop system, I have to start the service again to see > > the error output directly from the daemon. > > I think shepherd could capture stdout/stderr of the processes it starts > and make it available, in a way similar in spirit to what ‘journalctl’ > does. That would allow you to see the output of the daemon that failed. That sounds good. > That’s the only solution I can think of. Of course we don’t have to do > that if the daemon writes error messages to syslog, but not all of them do. > > Thanks, > Ludo’. Well, just a way to catch them would be good. Thanks
bug#30939: shepherd: detailed output should be placed into well-known location and not tty
Hi Ludovic, Ludovic Courtès transcribed 790 bytes: > Hi ng0, > > ng0 skribis: > > > Problem, not just when a service is misbehaving after successful system > > reconfigure: > > > > $ sudo herd start smtpd > > Password: > > Service smtpd could not be started. > > herd: failed to start service smtpd > > > > > > > > This is on virtual terminal in X11, as well as in /var/log/messages, > > /var/log/shepherd.log, etc. > > This is not enough. If I wanted more info, I'd expect that > > sudo herd status smtpd would give it (which it does not), so the only > > reliable source of information so far is tty 1. Can we fix that in > > one of the next shepherd releases? Or is this something we have to > > fix in Guix? > > So you’re saying that you’d like shepherd to show more info as to why > the service could not be started, right? > > Thanks, > Ludo’. Must have been late and too many failed attempts at what I'm trying to do. Yes. So I can't make any daemons I run out there fail, but for the current case I have in Guix for this: Sometimes I succeed building a system generation with an OpenSMTPD config-file which has syntax error that aren't picked up at configure time. When I reboot, not being aware of this, I have to switch to tty to read the reasons why it crashed. Because this is a desktop system, I have to start the service again to see the error output directly from the daemon. I think I know why this happens (that the output goes to tty), but nevertheless it would be good if shepherd were more capable than beint captain obvious: Start: "Oh, you see it is started". Crashed: "Oh, no has your daemon crashed?", like it is now. Okay, I just looked at some other daemon controls I run, and maybe it's good that shepherd is limited in its output. It does this one job. What I'd like to have as a sysadmin is the ability to tail something like say /var/log/shepherd.fail.log and services which are failing log into this file (or a set of files in /var/log/shepherd/ in files like $daemonname.fail.log). Given the absence of the kitchensink of tools in systemd, you got used to something like "status" and immediate "HELLO! This is why I failed: (5 lines)". With shepherd, you can't even grep for the failures in locations newcomers to the system would assume (like: /var/log/shepherd.log (it is the daemon control application)). Long store short, greping for failures to fix daemon configurations and not having to look at tty 1 (which can be noisy depending on what you run, I have some notorious tty spammers) would be good. And not sacrifice the simplicity of Shepherd :)
bug#30939: shepherd: detailed output should be placed into well-known location and not tty
Problem, not just when a service is misbehaving after successful system reconfigure: $ sudo herd start smtpd Password: Service smtpd could not be started. herd: failed to start service smtpd This is on virtual terminal in X11, as well as in /var/log/messages, /var/log/shepherd.log, etc. This is not enough. If I wanted more info, I'd expect that sudo herd status smtpd would give it (which it does not), so the only reliable source of information so far is tty 1. Can we fix that in one of the next shepherd releases? Or is this something we have to fix in Guix?
bug#30916: Request: add a short description field for os-configuration
Danny Milosavljevic transcribed 2.9K bytes:
> Hi Martin,
>
> On Sat, 24 Mar 2018 14:56:03 +0100
> Martin Castillo wrote:
>
> > ng0 wrote:
> > > So basically you want a field in the operating-system declaration where
> > > you
> > > can _manually_ set a description of a certain maximum length which will be
> > > added to the GRUB entry of the generated system generation?
> > yes
>
> I wonder whether this description can be generated instead - we have all
> the information we need - the packages, the users that are there etc.
But how much space do we have in the GRUB descriptions? I have computers with
800x600 or what
it was resolution for the screen, and while this would be a nice feature I
wonder if there's
some implications in GRUB menu readability.
I'm not an expert in GRUB, I can boot without a menu, but GRUB is a small
operating system
on its own :)
> Or a description could be generated only if a custom description is not
> specified.
>
> In fact it's easy to add this and would be a nice intro project for a
> person interested in Guix development. I can mentor.
>
> The thing used to fill the Guix bootloader entries is .
>
> There's a procedure "operating-system-boot-parameters" which is used
> to generate instances from an
> declaration.
>
> (operating-system-bootcfg calls operating-system-boot-parameters)
> (perform-action calls operating-system-bootcfg)
> (perform-action is in the top-level guix script)
>
> are serialized to disk into:
>
> /var/guix/profiles/system-704-link$ cat parameters
> (boot-parameters (version 0) (label "GNU with Linux-Libre 4.14.14 (beta)")
> (root-device "dayas:/") (kernel
> "/gnu/store/fnk2xhicbrjsvbq082p6x0ch6npkrg0z-linux-libre-4.14.14/bzImage")
> (kernel-arguments ("crashkernel=256M" "modprobe.blacklist=pcspkr,snd_pcsp"
> "quiet" "acpi_osi=Linux" "clocksource=acpi_pm" "allow-discards"
> "root_trim=yes")) (initrd
> "/gnu/store/nvhkdssz1m1p8xrggi78y8pd7jz4p3ng-raw-initrd/initrd")
> (bootloader-name grub) (store (device "dayas:/") (mount-point "/")))
>
> But I wouldn't change the serialization format or what fields
> contain.
>
> Just change operating-system-bootcfg to take a "description" parameter.
> And change operating-system-boot-parameters to take a "description" parameter
> and
> use it to calculate the label.
>
> And change perform-action to calculate the value for to "description"
> parameter in this way:
> - Taking it from (or the command line?)
> - Falling back to an automatic value (comparing it to the previous
> generation) otherwise.
>
> That's it.
--
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is
signature.asc
Description: PGP signature
bug#30916: Request: add a short description field for os-configuration
Martin Castillo transcribed 2.5K bytes: > Hi, > > On 23.03.2018 15:15, ng0 wrote: > > > Could you be a more specific what you think is missing? > > Your request is written in a very open way, and the space in GRUB menus is > > limited as far as I assume. > > Sure, > > Currently the grub menu looks like > GNU with Linux-Libre 4.15.12 (beta) > GNU system, old configurations... > > and in the submenu > GNU with Linux-Libre 4.15.6 (beta) (#1, 2017-12-18 13:45) > GNU with Linux-Libre 4.15.8 (beta) (#2, 2017-12-22 12:15) > GNU with Linux-Libre 4.15.11 (beta) (#3, 2018-03-23 15:32) > > but I'd like to have something like > > GNU with Linux-Libre 4.15.12 (beta) [Add ssh-service on port ] > GNU system, old configurations... > > and in the submenu > GNU with Linux-Libre 4.15.6 (beta) (#1, 2017-12-18 13:45) > GNU with Linux-Libre 4.15.8 (beta) (#2, 2017-12-22 12:15) [Add user bob] > GNU with Linux-Libre 4.15.11 (beta) (#3, 2018-03-23 15:32) [Add xfce] > > where the description at the end comes from a field in the operating > system configuration (or the bootloader configuration). > > -- > GPG: 7FDE 7190 2F73 2C50 236E 403D CC13 48F1 E644 08EC > So basically you want a field in the operating-system declaration where you can _manually_ set a description of a certain maximum length which will be added to the GRUB entry of the generated system generation? I don't see automatic generation happening, as there's so much that can be changed and automated summary would easily mess up the GRUB list. I wouldn't want that. If anything, optional entry with a manual note is the way to do it. -- A88C8ADD129828D7EAC02E52E22F9BBFEE348588 https://n0.is signature.asc Description: PGP signature
bug#30916: Request: add a short description field for os-configuration
Martin Castillo transcribed 1.6K bytes: > hi, > > the grub entries for old system generations aren't very helpful. It > would be nice, if there was a field in the operating system declaration > stating what was changed in this generation, that would be added to the > boot entry label. > > Martin > -- > GPG: 7FDE 7190 2F73 2C50 236E 403D CC13 48F1 E644 08EC > Hi, Could you be a more specific what you think is missing? Your request is written in a very open way, and the space in GRUB menus is limited as far as I assume. -- A88C8ADD129828D7EAC02E52E22F9BBFEE348588 https://n0.is
bug#30776: FVWM provides no .desktop file
宋文武 transcribed 408 bytes: > ng0 writes: > > > When adding FVWM to the system profile and not using startx or something > > like adding fvwm execution to the file in $HOME the login manager would > > source, it does not appear in the selection of window managers to start. > > > > We should install a .desktop file for it. > > Hello, as your commit c217df913e00327f5c9b779fd97e222c4c22dab9 had fix > this, so I close this bug now. Thanks! Oops. I intended to add the bug ID to the commit message. Sorry, I forgot that I had this bug created. Thanks! -- A88C8ADD129828D7EAC02E52E22F9BBFEE348588 https://n0.is
bug#30808: [feature-request] improve integration of proxies in guix
Currently we have the http_proxy env var which can be set in the environment if guix-daemon and is honored by downloads of substitutes. As discussed a couple of days ago on IRC, adding the ability to use proxies for all parts of guix that are concerned with data retrieved via network would be very good for deplyoment of Guix in environments we usually do not consider (corporate firewalls, places with high censorship, people who generally do want to use proxies or have to use proxies, the list of reasons and possibilities is longer than I want to type.
bug#30776: FVWM provides no .desktop file
When adding FVWM to the system profile and not using startx or something like adding fvwm execution to the file in $HOME the login manager would source, it does not appear in the selection of window managers to start. We should install a .desktop file for it. -- A88C8ADD129828D7EAC02E52E22F9BBFEE348588 https://n0.is
bug#30607: freedoom build problems
While trying to install freedoom (with "guix package --fallback --no-build-hook
-i freedoom") I get:
26.4 MB will be downloaded:
/gnu/store/40i2anq8kspp3m7n62b8a8mb6l3clpk6-freedoom-0.11.3
Downloading
https://mirror.hydra.gnu.org/guix/nar/gzip/40i2anq8kspp3m7n62b8a8mb6l3clpk6-freedoom-0.11.3...
freedoom-0.11.3 25.2MiB668KiB/s 00:01 [ ]
2.2%
gzip: stdin: unexpected end of file
guix substitute: error: corrupt input while restoring
'/gnu/store/40i2anq8kspp3m7n62b8a8mb6l3clpk6-freedoom-0.11.3/share/games/doom/freedm.wad'
from #{read pipe}#
--
ng0
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
http://krosos.org | https://n0.is/~ng0/ | https://crash.cx
signature.asc
Description: PGP signature
bug#30523: mcomix test failure after core-updates merge
On 90e37ea088b8ab5ff0d3c4f92c7205f8acdd8d09 from master, mcomix is failing to run its testsuite: [...] copying mcomix/images/tango-add-bookmark.png -> build/lib/mcomix/images copying mcomix/images/zoom.png -> build/lib/mcomix/images copying mcomix/images/tango-enhance-image.png -> build/lib/mcomix/images phase `build' succeeded after 0.3 seconds starting phase `check' running "python setup.py" with command "test" and parameters () running test running egg_info writing requirements to mcomix.egg-info/requires.txt writing mcomix.egg-info/PKG-INFO writing top-level names to mcomix.egg-info/top_level.txt writing dependency_links to mcomix.egg-info/dependency_links.txt writing entry points to mcomix.egg-info/entry_points.txt warning: manifest_maker: standard file '-c' not found reading manifest file 'mcomix.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' warning: no previously-included files found matching 'mcomix/images/mcomix-large.png' writing manifest file 'mcomix.egg-info/SOURCES.txt' running build_ext Traceback (most recent call last): File "", line 1, in File "setup.py", line 110, in 'Operating System :: POSIX :: BSD'], File "/gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14/lib/python2.7/distutils/core.py", line 151, in setup dist.run_commands() File "/gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14/lib/python2.7/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14/lib/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14/lib/python2.7/site-packages/setuptools/command/test.py", line 210, in run self.run_tests() File "/gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14/lib/python2.7/site-packages/setuptools/command/test.py", line 231, in run_tests testRunner=self._resolve_as_ep(self.test_runner), File "/gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14/lib/python2.7/unittest/main.py", line 94, in __init__ self.parseArgs(argv) File "/gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14/lib/python2.7/unittest/main.py", line 149, in parseArgs self.createTests() File "/gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14/lib/python2.7/unittest/main.py", line 158, in createTests self.module) File "/gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14/lib/python2.7/unittest/loader.py", line 130, in loadTestsFromNames suites = [self.loadTestsFromName(name, module) for name in names] File "/gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14/lib/python2.7/unittest/loader.py", line 103, in loadTestsFromName return self.loadTestsFromModule(obj) File "/gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14/lib/python2.7/site-packages/setuptools/command/test.py", line 42, in loadTestsFromModule tests.append(self.loadTestsFromName(submodule)) File "/gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14/lib/python2.7/unittest/loader.py", line 100, in loadTestsFromName parent, obj = obj, getattr(obj, part) AttributeError: 'module' object has no attribute 'test_support' phase `check' failed after 0.3 seconds builder for `/gnu/store/6031jjx3pnw3m4wkbng2sfz6w4cv3x22-mcomix-1.2.1.drv' failed with exit code 1 guix package: error: build failed: build of `/gnu/store/6031jjx3pnw3m4wkbng2sfz6w4cv3x22-mcomix-1.2.1.drv' failed -- ng0 :: https://crash.cx A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/ signature.asc Description: PGP signature
bug#30401: gitolite some important hooks not working
On Sun, 11 Feb 2018, Ricardo Wurmus wrote: > n...@crash.cx writes: > >> A paste that lost its formatting but speaks for itself: >> >> Counting objects: 4, done. >> Delta compression using up to 4 threads. >> Compressing objects: 100% (3/3), done. >> Writing objects: 100% (4/4), 1.03 KiB | 1.03 MiB/s, done. >> Total 4 (delta 0), reused 0 (delta 0) >> remote: Can't locate Data/Dumper.pm in @INC (you may need to >> install the Data::Dumper module) (@INC contains: >> /gnu/store/v3k3dmkdaz3giap6ir06dj12sid42086-gitolite-3.6.6/share/gitolite/lib >> /home/git/.guix-profile/lib/perl5/site_perl /etc/perl >> /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 >> /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 >> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 >> /usr/share/perl/5.24 /usr/local/lib/site_perl >> /usr/lib/x86_64-linux-gnu/perl-base .) at > > Have you tried propagating the perl-data-dumper package? Or did you try > wrapping the executable in the PERL5LIB environment variable after > adding the package? > >> Installing the module + perl into the profile didn't help either. > > The gitolite executables need to be made aware of the location of the > Perl modules, so it’s expected that this wouldn’t help. I had no time to reply so far or to try and other solutions. Turns out so far that it works when you make /usr/bin/perl as a special file type link available on the system, as the problem is some unchanged hook lines pointing to this instead of the store. As repo hooks are not attached to the changes in the store I think it's okay. Eventually we should come up with a solution for those hooks. -- ng0 :: https://crash.cx A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/
bug#30401: gitolite some important hooks not working
A paste that lost its formatting but speaks for itself: Counting objects: 4, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (4/4), 1.03 KiB | 1.03 MiB/s, done. Total 4 (delta 0), reused 0 (delta 0) remote: Can't locate Data/Dumper.pm in @INC (you may need to install the Data::Dumper module) (@INC contains: /gnu/store/v3k3dmkdaz3giap6ir06dj12sid42086-gitolite-3.6.6/share/gitolite/lib /home/git/.guix-profile/lib/perl5/site_perl /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at /gnu/store/v3k3dmkdaz3giap6ir06dj12sid42086-gitolite-3.6.6/share/gitolite/lib/Gitolite/Common.pm line 65. remote: BEGIN failed--compilation aborted at /gnu/store/v3k3dmkdaz3giap6ir06dj12sid42086-gitolite-3.6.6/share/gitolite/lib/Gitolite/Common.pm line 65. remote: Compilation failed in require at /gnu/store/v3k3dmkdaz3giap6ir06dj12sid42086-gitolite-3.6.6/share/gitolite/lib/Gitolite/Rc.pm line 25. remote: BEGIN failed--compilation aborted at /gnu/store/v3k3dmkdaz3giap6ir06dj12sid42086-gitolite-3.6.6/share/gitolite/lib/Gitolite/Rc.pm line 25. remote: Compilation failed in require at /gnu/store/v3k3dmkdaz3giap6ir06dj12sid42086-gitolite-3.6.6/share/gitolite/lib/Gitolite/Hooks/Update.pm line 13. remote: BEGIN failed--compilation aborted at /gnu/store/v3k3dmkdaz3giap6ir06dj12sid42086-gitolite-3.6.6/share/gitolite/lib/Gitolite/Hooks/Update.pm line 13. remote: Compilation failed in require at hooks/update line 7. remote: BEGIN failed--compilation aborted at hooks/update line 7. remote: error: hook declined to update refs/heads/master To snow.crash.cx:gitolite-admin ! [remote rejected] master -> master (hook declined) error: failed to push some refs to 'g...@snow.crash.cx:gitolite-admin' Installing the module + perl into the profile didn't help either. There's a service NixOS provides which we could replicate, but for now I have a crash recovery to make and would like to get gitolite up and running. Ideas, input, even small hacks welcome. guix package -l: Generation 1Feb 09 2018 13:28:26 perl-data-dumper-concise 2.023 out /gnu/store/fckd34g3njmjc8yl4vk3hkqj5cbv9mvj-perl-data-dumper-concise-2.023 Generation 2Feb 09 2018 13:32:57(current) + perl 5.26.0 out /gnu/store/9g4fpfz86vjkx83v5696vm5dzg2sc9qj-perl-5.26.0 env: DICPATH=/home/git/.guix-profile/share/hunspell:/run/current-system/profile/share/hunspell LANG=en_US.UTF-8 GTK_DATA_PREFIX=/run/current-system/profile GST_PLUGIN_PATH=/home/git/.guix-profile/lib/gstreamer-1.0 GIT_SSL_CAINFO=/run/current-system/profile/etc/ssl/certs/ca-certificates.crt LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules GUILE_LOAD_COMPILED_PATH=/run/current-system/profile/lib/guile/2.2/site-ccache:/run/current-system/profile/share/guile/site/2.2 USER=git TZDIR=/gnu/store/bzj472nmnnj5hcfd5yvfiqip1wzw84p9-tzdata-2017b/share/zoneinfo GUIX_LOCPATH=/run/current-system/locale PWD=/home/git HOME=/home/git XDG_DATA_DIRS=/home/git/.guix-profile/share:/run/current-system/profile/share SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt GIT_EXEC_PATH=/run/current-system/profile/libexec/git-core SHELL=/gnu/store/ars9lm9jk9hgdifg0gqvf1jrvz5mdg1j-bash-4.4.12/bin/bash TERM=st-256color PERL5LIB=/home/git/.guix-profile/lib/perl5/site_perl SHLVL=1 MANPATH=/run/current-system/profile/share/man:/home/git/.guix-profile/share/man:/run/current-system/profile/share/man SSL_CERT_DIR=/etc/ssl/certs BASH_LOADABLES_PATH=/run/current-system/profile/lib/bash LOGNAME=git GUILE_LOAD_PATH=/run/current-system/profile/share/guile/site/2.2 XDG_CONFIG_DIRS=/home/git/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg DBUS_FATAL_WARNINGS=0 PATH=/home/git/.guix-profile/bin:/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin INFOPATH=/run/current-system/profile/share/info:/home/git/.guix-profile/share/info:/run/current-system/profile/share/info XCURSOR_PATH=/home/git/.icons:/home/git/.guix-profile/share/icons:/run/current-system/profile/share/icons _=/run/current-system/profile/bin/env -- ng0 :: https://crash.cx A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/
bug#30265: Fish shell has wrong path variables
On Sat, 27 Jan 2018, l...@gnu.org (Ludovic Courtès) wrote: > Hi ng0 and Meiyo, > > n...@n0.is skribis: > >> On Sat, 27 Jan 2018, Meiyo Peng wrote: >>> Hi, >>> >>> I am using GuixSD 0.14. After upgrading fish shell to latest >>> version(v2.7.1) and >>> running `guix gc`, fish shell does not work well. >> >> Can you explain a bit more about your setup? I assume you use >> fish as you user shell and not just as a shell you switch into >> from a Bash enabled user, correct? > > Note that the current ‘guix’ package, 0.14.0-7.33988f9, includes Fish > completion support, which was not the case before: > > --8<---cut here---start->8--- > $ ls -R $(guix build guix)/share/fish > /gnu/store/apji9j8cwf9xpd5jk5mk8s6r1a391yvq-guix-0.14.0-7.33988f9/share/fish: > vendor_completions.d > > /gnu/store/apji9j8cwf9xpd5jk5mk8s6r1a391yvq-guix-0.14.0-7.33988f9/share/fish/vendor_completions.d: > guix.fish > --8<---cut here---end--->8--- > > Could it be the reason why you’re having problems now that you didn’t > experience earlier? > > Any ideas, ng0? > > Thanks, > Ludo’. > > > > No, I'm pretty sure this has nothing to do with adding fish support to Guix. -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
bug#30265: Fish shell has wrong path variables
Hi Meiyo, thanks for your report. Indeed, Fish has some problems in Guix. On Sat, 27 Jan 2018, Meiyo Peng wrote: > Hi, > > I am using GuixSD 0.14. After upgrading fish shell to latest version(v2.7.1) > and > running `guix gc`, fish shell does not work well. Can you explain a bit more about your setup? I assume you use fish as you user shell and not just as a shell you switch into from a Bash enabled user, correct? > #+BEGIN_EXAMPLE > meiyo@guix ~$ fish > fish: > echo $_ " "; __fish_pwd >^ > in command substitution > called on standard input > > fish: > __fish_pwd > ^ > in command substitution > called on standard input > > in command substitution > called on standard input > > fish: > echo $_ " "; __fish_pwd >^ > in command substitution > called on standard input > #+END_EXAMPLE > > > __fish_pwd is a fish function. It's defined in > `share/fish/functions/__fish_pwd.fish`. The error message shows that fish > cannot load __fish_pwd's function definition from disk. After doing some > research, I found out that the error was caused by wrong environment > variables. > > Fish shell is installed in: > > #+BEGIN_EXAMPLE > /gnu/store/ajbbi9cgj9j0my7v5habp0lcysaf2a51-fish-2.7.1/ > #+END_EXAMPLE > > > But the environment variable $fish_function_path does not exist. And these > environment variables point to non-existent paths: > > #+BEGIN_EXAMPLE > __fish_bin_dir /gnu/store/4jkxcz8kpy621ycmqn3rvs0fv6c98h6p-fish-2.7.1/bin > __fish_datadir > /gnu/store/4jkxcz8kpy621ycmqn3rvs0fv6c98h6p-fish-2.7.1/share/fish > #+END_EXAMPLE > > > Setting $fish_function_path to the correct path reduces the error message. > > #+BEGIN_EXAMPLE > set fish_function_path > /gnu/store/ajbbi9cgj9j0my7v5habp0lcysaf2a51-fish-2.7.1/share/fish/functions > #+END_EXAMPLE > > > `share/fish/config.fish` states $__fish_datadir is set by fish.cpp, > and $fish_function_path is derived from $__fish_datadir. > > #+BEGIN_SRC fish > # __fish_datadir, __fish_sysconfdir, __fish_help_dir, __fish_bin_dir > # are expected to have been set up by read_init from fish.cpp > > > # Set up function and completion paths. Make sure that the fish > # default functions/completions are included in the respective path. > > if not set -q fish_function_path > set fish_function_path $configdir/fish/functions > $__fish_sysconfdir/functions $__extra_functionsdir $__fish_datadir/functions > end > > if not contains -- $__fish_datadir/functions $fish_function_path > set fish_function_path $fish_function_path $__fish_datadir/functions > end > #+END_SRC > > In conclusion, I think some path related variables are not set correctly when > fish is compiled from source code and that caused the bug I met. But since I'm > not good at C++ programming, I will not dive deeper. > > I hope that the information provided above is helpful. > > > Meiyo Peng It's more or less known, I assume this is related to bug#27206 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27206 Which to my knowledge and sources I've read doesn't require C knowledge but more knowledge of how Fish interacts on system/vendor level and some testing with the resources I've provided in the other thread/bug. -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
bug#23199: XFCE is missing documentation
In my opinion this bug can be closed due to WONTFIX from upstream at this URL: > https://docs.xfce.org/contribute/documentation quote: >> Documentation >> Introduction >> Since Xfce 4.10 there are no application manuals in the >> packages. Reason for this change is that hardly any >> documentation was contributed over the years mainly because >> people had problems with the various formats (docbook and >> mallard) or with the complexity of the VCS1). >> >> To make the documentation barrier lower it was decided to start >> a documentation wiki where contributors, developers and >> translators can work on good and up-to-date documentation. >> >> From the various dialogs and links in the Xfce applications, >> we redirect to the sections in this wiki. So, we won't see any offline Documentation here. I've looked at 3 other OS before reading this, and none of the do anything different wrt Manual including/excluding. With this in mind, I'm closing the bug report. -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
bug#30161: gnucobol: depends on non-optional runtime depedencies
For a simple hello world (as per their own Manual) GNU Cobol depends on: * ncurse * bdb * gmp -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/ signature.asc Description: PGP signature
bug#30157: texlive-20170524-texmf.tar.xz' failed: 410, "Gone"
Mathieu Lirzin transcribed 2.4K bytes: > Hello, > > ng0 writes: > > > Mathieu Lirzin transcribed 1.0K bytes: > >> > >> While building my system configuration after a ‘guix pull’ with guix > >> "d36d4c55c4a3faf47ee09e1010cb6617c6e39a48", I encountered the following > >> error. > >> > >> --8<---cut here---start->8--- > >> Téléchargement de « > >> https://mirror.hydra.gnu.org/guix/nar/5rnvmy02yazy8iwaa91kijbbqp8qmflz-texlive-20170524-texmf.tar.xz > >> »... > >> guix substitute: error: download from > >> 'https://mirror.hydra.gnu.org/guix/nar/5rnvmy02yazy8iwaa91kijbbqp8qmflz-texlive-20170524-texmf.tar.xz' > >> failed: 410, "Gone" > >> guix system: error: build failed: some substitutes for the outputs > >> of derivation > >> `/gnu/store/j3m0a6rwrz9jmass4zlndpn5y0x8g5n4-texlive-20170524-texmf.tar.xz.drv' > >> failed (usually happens due to networking issues); try `--fallback' > >> to build derivation from source > >> --8<---cut here---end--->8--- > > > this is expected as we don't build substitutes for some parts of texlive, > > notable > > this one. The resulting size would be ~5GB and as far as I understand it > > this would > > need longer to transfer to you than to build locally (given that your > > machine can > > build it). > > Hum, > > That makes sense, however the command bailing out is kind of confusing. > Would it be possible to configure those heavy packages so that they > automatically fallback to native compilation. > > Anyway I don't understand how the full texlive end up being built when > running ‘guix system build /etc/config.scm’ since the configuration > contains only the following services and packages: > > (packages (cons* nss-certs ;for HTTPS access >gvfs ;for user mounts > samba > cifs-utils > nfs-utils >%base-packages)) > > (services (cons* (console-keymap-service "fr") > (xfce-desktop-service) > (mate-desktop-service) > (service cups-service-type > (cups-configuration >(web-interface? #t) >(extensions (list cups-filters hplip > (extra-special-file "/usr/bin/env" > (file-append coreutils "/bin/env")) > %desktop-services)) > > The only reference of texlive I have is ”texlive-tiny“ which is only in > my user profile and is already built. I suspect that it's somewhere in one of the dependency graphs of those applications, you can check with guix size `guix build foo` to get a view on that. It's definitely not gvfs, and mate triggered a build of webkitgtk-2 here, so you have to figure out yourself I guess ( can take some time ). > Thank you for the explanation. > > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 > -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/ signature.asc Description: PGP signature
bug#30157: texlive-20170524-texmf.tar.xz' failed: 410, "Gone"
Mathieu Lirzin transcribed 1.0K bytes: > Hello, > > While building my system configuration after a ‘guix pull’ with guix > "d36d4c55c4a3faf47ee09e1010cb6617c6e39a48", I encountered the following > error. > > --8<---cut here---start->8--- > Téléchargement de « > https://mirror.hydra.gnu.org/guix/nar/5rnvmy02yazy8iwaa91kijbbqp8qmflz-texlive-20170524-texmf.tar.xz > »... > guix substitute: error: download from > 'https://mirror.hydra.gnu.org/guix/nar/5rnvmy02yazy8iwaa91kijbbqp8qmflz-texlive-20170524-texmf.tar.xz' > failed: 410, "Gone" > guix system: error: build failed: some substitutes for the outputs of > derivation > `/gnu/store/j3m0a6rwrz9jmass4zlndpn5y0x8g5n4-texlive-20170524-texmf.tar.xz.drv' > failed (usually happens due to networking issues); try `--fallback' to build > derivation from source > --8<---cut here---end--->8--- > > Thanks. > > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37 > Hi, this is expected as we don't build substitutes for some parts of texlive, notable this one. The resulting size would be ~5GB and as far as I understand it this would need longer to transfer to you than to build locally (given that your machine can build it). -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/ signature.asc Description: PGP signature
bug#25453: Inconsistent keyboard layout affecting encrypted root
Ludovic Courtès transcribed 1.1K bytes: > Hi! > > Christopher Baines skribis: > > > I'm using a UK keyboard layout with a computer that I recently installed > > GuixSD on with a encrypted root parition. Immediately after installation > > when I attempted to boot in to the new system for the first time I had > > to enter the passphrase twice, and in doing this, first I had to use the > > keyboard layout under which I carried out the installation (the layout > > which I had intended to use), and then during the early boot stage of > > the system I had to enter the passphrase using a different keyboard > > layout. > > Currently installing a keymap is something done by the ‘console-keymap’ > Shepherd service, which invokes ‘loadkeys’. That happens after > “cryptsetup --open” has opened your encrypted root device, hence the > problem. > > Should we install the keymap right in the initrd, before we’ve mounted > the root partition? That would require copying the right keymap(s) and > probably ‘loadkeys’ to the initrd, which might make it quite big. > > Suggestions? How do others handle it? Yes, this has been annoying me to the point of simply taking it for granted for now, and replacing it in my own set of defaults. To answer your question: Others handle it in the initrd aswell. For example in Gentoo with OpenRC, you set the keyboardlayout for the initrd. In Archlinux iirc before and after adoption of systemd you set the keymap for it. In Debian if memory serves me right you set the keyboard layout. I think I don't need to go on... What's the size difference for the initrd then in numbers? I don't think we have to wory about size as we'll never run on devices smaller than router devices (at least that's my current assumption looking at the size of a typical minimal GuixSD, it's possible but requires lots of customization). > Thanks for your report, > Ludo’. > > > -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/ signature.asc Description: PGP signature
bug#27206: Fish: figure out a solution for the vendor path extension to fish
ng0 transcribed 2.7K bytes:
> Ludovic Courtès transcribed 1.0K bytes:
> > ng0 skribis:
> >
> > > ng0 transcribed 0.4K bytes:
> > >> A feature-bug I forgot to report a while ago.
> > >> It has been described on the mailinglist (or was
> > >> it in my blog or some release announcement I made?)
> > >>
> > >> Fish doesn't pick up stuff like 'fish-guix' from store
> > >> without modifications to the path where fish searches
> > >> for vendor or sysadmin installed systemwide 'things'
> > >> for fish.
> > >
> > > I have many more fish packages in a branch which
> > > I want to get into guix, but they are stuck because
> > > of this. Help welcome, otherwise I'll promise to
> > > fix it one day.
> > >
> > > Currently the only workaround is to symlink individual files from your
> > > ~/.guix-profile/whereever/things/went/ to ~/.config/fish/{approriate
> > > subdirs}
> >
> > Does Fish have an environment variable that can be used to specify the
> > search path for extensions, similar to BASH_LOADABLES_PATH? If it does,
> > we could use that.
> >
> > Otherwise, perhaps we can consider it an upstream issue in a way?
> >
> > Thanks,
> > Ludo’.
>
> Late night reply, so I'll be short.
> I have some open reading material on how Nix solved this,
> which is the only system coming close to our layout. Everyone
> else can just point to one of the canonical paths.
>
> I haven't concluded yet if Nix' solution is usable for us
> as they sometimes take shortcuts.
>
> I'll post the links within the next 7 days, more likely on
> the weekend.
>
> Thanks, goodnight
Long 7 days ;)
Here are the links from my bookmarks, for those who want to look into fixing
this:
https://github.com/NixOS/nixpkgs/pull/24314
https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/virtualization/docker/default.nix
https://github.com/NixOS/nixpkgs/issues/5331
https://github.com/NixOS/nix/pull/626
https://github.com/NixOS/nix/issues/440
https://github.com/NixOS/nixpkgs/blob/master/pkgs/shells/fish/default.nix
If it helps, because our zsh integration (for zsh-extensions) isn't that good
either and the links reference some of the Zsh work in Nix:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/programs/zsh/zsh.nix
https://github.com/NixOS/nixpkgs/commit/003cd41310b5b7839eb4c402d84dc25068026c3e
--
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
signature.asc
Description: PGP signature
bug#28578: xorg not starting on x200 due to recent commit
ng0 transcribed 2.1K bytes: > Mike Gerwitz transcribed 1.6K bytes: > > On Sun, Dec 24, 2017 at 11:59:11 -0600, Christopher Lemmer Webber wrote: > > > It looks the same. Maybe the Libreboot version is responsible... I'm > > > not sure. > > > > I just received mine recently from Libiquity and I haven't had a chance > > to play around with any of the flashing tools, so I don't know my > > version atm. If you know the steps to run a suitable comparison, I'd be > > happy to do so. > > > > If you don't have it figured out by March I'll be at LP2018 if you want > > to do a more hands-on comparison. > > > > -- > > Mike Gerwitz > > Free Software Hacker+Activist | GNU Maintainer & Volunteer > > GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 > > https://mikegerwitz.com > > Chris, fyi libreboot is working towards a new release now (they have started > testing machines and call out for testers), so maybe whatever you experience > will be gone with a new version of libreboot. Of course I meant to write: _could be_ gone. > -- > GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 > GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys > WWW: https://n0.is -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys WWW: https://n0.is signature.asc Description: PGP signature
bug#28578: xorg not starting on x200 due to recent commit
Mike Gerwitz transcribed 1.6K bytes: > On Sun, Dec 24, 2017 at 11:59:11 -0600, Christopher Lemmer Webber wrote: > > It looks the same. Maybe the Libreboot version is responsible... I'm > > not sure. > > I just received mine recently from Libiquity and I haven't had a chance > to play around with any of the flashing tools, so I don't know my > version atm. If you know the steps to run a suitable comparison, I'd be > happy to do so. > > If you don't have it figured out by March I'll be at LP2018 if you want > to do a more hands-on comparison. > > -- > Mike Gerwitz > Free Software Hacker+Activist | GNU Maintainer & Volunteer > GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 > https://mikegerwitz.com Chris, fyi libreboot is working towards a new release now (they have started testing machines and call out for testers), so maybe whatever you experience will be gone with a new version of libreboot. -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys WWW: https://n0.is signature.asc Description: PGP signature
bug#29791: microscheme
Hi, Quiliro Ordonez Baca transcribed 0.3K bytes: > Hello. > I found Microscheme on the repos for using Arduino. Please tell me where > I can find information on how to use Arduino and MicroScheme. By the way > the web page on the package definition for microscheme: (microscheme.org) > is unavailable. I suggest using the git page: > https://github.com/ryansuchocki/microscheme/blob/master/README.md This is one bug (home-page unavailable), and an advice/discussion. Can you ask on the help or devel list for the advice on using micrscheme with Arduino? I'm putting this bug (homepage is actually leading to a parked advertisment site) on my list of things to fix. I have a couple of dead links, permanent redirects etc which I am working on to fix and send as a series of patches. Thanks for reporting this, it's important. -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys WWW: https://n0.is signature.asc Description: PGP signature
bug#29642: guix 0.14.0 cannot use HTTPS with guile 2.0
藍挺瑋 transcribed 1.7K bytes: > This problem happens on Fedora 27, which uses Guile 2.0.14. Do we still support building with guile 2.0? That's a maintenance version of Guile, 2.2 is the new stable. > $ guix package -i hello > The following package will be installed: >hello 2.10/gnu/store/pa4w02b89d6sq33840dxfl5vbqbwz5iy-hello-2.10 > > substitute: Backtrace: > substitute: In ice-9/boot-9.scm: > substitute: 160: 9 [catch #t # ...] > substitute: In unknown file: > substitute:?: 8 [apply-smob/1 #] > substitute: In ice-9/boot-9.scm: > substitute: 66: 7 [call-with-prompt prompt0 ...] > substitute: In ice-9/eval.scm: > substitute: 432: 6 [eval # #] > substitute: In ice-9/boot-9.scm: > substitute: 2412: 5 [save-module-excursion # ice-9/boot-9.scm:4084:3 ()>] > substitute: 4089: 4 [# ()>] > substitute: 1734: 3 [%start-stack load-stack ...] > substitute: 1739: 2 [#] > substitute: In unknown file: > substitute:?: 1 [primitive-load "/usr/bin/guix"] > substitute: In guix/ui.scm: > substitute: 1452: 0 [run-guix-command substitute "--query"] > substitute: > substitute: guix/ui.scm:1452:12: In procedure run-guix-command: > substitute: guix/ui.scm:1452:12: In procedure setvbuf: Wrong type > argument in position 1 (expecting port that supports 'setvbuf'): > # > guix package: error: corrupt input while restoring archive from socket > > If I revert commit 866f37f, this problem can be avoided. The commit > (download: Improve efficiency of 'write-request' over TLS.) added the > following code to guix/build/download.scm: > > (cond-expand > (guile-2.0 #f) > (else (setvbuf record 'line))) > > The info page of guile doesn't list 'guile-2.0' feature. I know there is > a feature called 'guile-2.2', but I cannot find 'guile-2.0'. > > > > -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys WWW: https://n0.is signature.asc Description: PGP signature
bug#29485: perl-geo-ip has /usr/share/ within the code
ng0 transcribed 2.5K bytes:
> I'm searching for a good solution to analyze some logs. Geo::IP
> is good enough. Now the problem is this:
>
> user@abyayala /gnu/store/5mhrli41qbcpns3gg0yf1vv07lvpg8hm-perl-geo-ip-1.51$
> egrep -nr "/usr/" lib/perl5/site_perl/5.26.0/
> lib/perl5/site_perl/5.26.0/Geo/IP/Record.pod:9: my $gi =
> Geo::IP->open("/usr/local/share/GeoIP/GeoIPCity.dat", GEOIP_STANDARD);
> lib/perl5/site_perl/5.26.0/Geo/IP.pm:5075:# default path
> /usr/local/share/GeoIP
> lib/perl5/site_perl/5.26.0/Geo/IP.pm:5159:my $def_db_file =
> '/usr/local/share/GeoIP/GeoIP.dat';
> lib/perl5/site_perl/5.26.0/Geo/IP.pm:5962: my $gi =
> Geo::IP->open("/usr/local/share/GeoIP/GeoIPCity.dat", GEOIP_STANDARD);
> lib/perl5/site_perl/5.26.0/Geo/IP.pm:5984: my $g =
> Geo::IP->open('/usr/local/share/GeoIP/GeoIPv6.dat') or die;
> lib/perl5/site_perl/5.26.0/Geo/IP.pm:6046:I, typically
> I.
> lib/perl5/site_perl/5.26.0/Geo/IP.pm:6078:typically
> I.
> lib/perl5/site_perl/5.26.0/Geo/IP.pm:6226: my $g =
> Geo::IP->open('/usr/local/share/GeoIP/GeoIPv6.dat') or die;
>
> However this is not really a problem unless you are on GuixSD.
> As we do not package the DB of MaxDB (yet) you'll need for this, it's
> not a problem. I'm filing this bug to remind myself to fix Geo::IP once
> I have revisited the discussion we had about the DB a while back.
> --
> GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
> GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys
> WWW: https://n0.is
They comment this in the file:
# --- unfortunately we do not know the path so we assume the
# default path /usr/local/share/GeoIP
# if thats not true, you can set $Geo::IP::PP_OPEN_TYPE_PATH
But I think we should fix it once we have the data set.
WDYT?
--
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys
WWW: https://n0.is
signature.asc
Description: PGP signature
bug#29485: perl-geo-ip has /usr/share/ within the code
I'm searching for a good solution to analyze some logs. Geo::IP
is good enough. Now the problem is this:
user@abyayala /gnu/store/5mhrli41qbcpns3gg0yf1vv07lvpg8hm-perl-geo-ip-1.51$
egrep -nr "/usr/" lib/perl5/site_perl/5.26.0/
lib/perl5/site_perl/5.26.0/Geo/IP/Record.pod:9: my $gi =
Geo::IP->open("/usr/local/share/GeoIP/GeoIPCity.dat", GEOIP_STANDARD);
lib/perl5/site_perl/5.26.0/Geo/IP.pm:5075:# default path /usr/local/share/GeoIP
lib/perl5/site_perl/5.26.0/Geo/IP.pm:5159:my $def_db_file =
'/usr/local/share/GeoIP/GeoIP.dat';
lib/perl5/site_perl/5.26.0/Geo/IP.pm:5962: my $gi =
Geo::IP->open("/usr/local/share/GeoIP/GeoIPCity.dat", GEOIP_STANDARD);
lib/perl5/site_perl/5.26.0/Geo/IP.pm:5984: my $g =
Geo::IP->open('/usr/local/share/GeoIP/GeoIPv6.dat') or die;
lib/perl5/site_perl/5.26.0/Geo/IP.pm:6046:I, typically
I.
lib/perl5/site_perl/5.26.0/Geo/IP.pm:6078:typically
I.
lib/perl5/site_perl/5.26.0/Geo/IP.pm:6226: my $g =
Geo::IP->open('/usr/local/share/GeoIP/GeoIPv6.dat') or die;
However this is not really a problem unless you are on GuixSD.
As we do not package the DB of MaxDB (yet) you'll need for this, it's
not a problem. I'm filing this bug to remind myself to fix Geo::IP once
I have revisited the discussion we had about the DB a while back.
--
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys
WWW: https://n0.is
signature.asc
Description: PGP signature
bug#24279: XTerm menu doesn't work (no font found error)
Maxim Cournoyer transcribed 0.5K bytes: > I can reproduce this on GuixSD (foreign distros are OK). > > By going to tty0 (Ctrl-Alt-F1) we can see the following text which gets > output at every crash: > > --8<---cut here---start->8--- > Warning: Unable to load any usable ISO8059 font > ERROR: Aborting: no font found > --8<---cut here---end--->8--- > > Apparently there is a patch which might fix that problem, available > here: https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00165.html > > Maxim Good catch, it was just forgotten. Would you like to work on the suggestions Ludovic gave John? It's unlikely that John will work on them after John more-or-less left Guix. -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys WWW: https://n0.is signature.asc Description: PGP signature
bug#29059: network-manager-service extension package not fully functional
Ricardo Wurmus transcribed 0.7K bytes: > Hi ng0, > > So, actually, it’s just this? > > (service network-manager-service-type >(network-manager-configuration > (vpn-plugins (list network-manager-openvpn > > > And the error message is this? > > > Nov 14 12:16:35 localhost NetworkManager[421]: [1510661795.5451] > > audit: op="connection-activate" uuid="…" name="VPN HS-BO" pid=639 uid=1000 > > result="fail" reason="The VPN service > > 'org.freedesktop.NetworkManager.openvpn' was not installed." > > Please always provide a clear and minimal test case. Otherwise we have > no chance of reproducing the problem. > > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net More or less. To be more precise: Before I packaged the vpnc plugin, I just had the openvpn plugin with a config and error message as you described. With vpnc it's the same, I filed this bug with the assumption that both errors are related. nothing provides org.freedesktop.NetworkManager.openvpn or org.freedesktop.NetworkManager.vpnc The files that should provide them are missing, I've double checked this. The subject line for the bug could've been better. I have this really unnecessary and sadly mandatory presence lecture tomorrow, I'll prepare the vpnc package and send it then, so that you can apply what I work with. Of course you need an VPNC test case, I only need this because of the eduroam here in Bochum. -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dl.n0.is/dist/keys/ WWW: https://we.make.ritual.n0.is signature.asc Description: PGP signature
bug#29059: network-manager-service extension package not fully functional
Ludovic Courtès transcribed 0.8K bytes: > Hi ng0, > > ng0 skribis: > > > paste from my current systemconfig: > > > > ;; networking with network-manager > > (service wpa-supplicant-service-type wpa-supplicant) > > (service network-manager-service-type > > (network-manager-configuration > >(vpn-plugins (list network-manager-openvpn > > network-manager-vpnc > > > > > > Context here: > > https://c.n0.is/systems/tree/guixsd/workstations/abyayala/config.scm > > > > and this mess is the vpnc plugin for NM: > > https://c.n0.is/ng0_guix/packages/tree/ng0/packages/personalized.scm#n213 > > I’m sorry but I can’t offer to address a bug that’s not in Guix proper. > That said, you’re welcome to submit network-manager-vpnc for inclusion! > > Thanks, > Ludo’. > Sorry, I mentioned in my initial message that vpnc AND openvpn are affected. The error message is the same for OpenVPN and VPNC plugin. This is not resolved. -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dl.n0.is/dist/keys/ WWW: https://we.make.ritual.n0.is signature.asc Description: PGP signature
bug#29059: network-manager-service extension package not fully functional
ng0 transcribed 2.7K bytes:
> Ludovic Courtès transcribed 1.0K bytes:
> > ng0 skribis:
> >
> > > I have come to the conclusion (logs will be reproduced next week and
> > > added)
> > > that network-manager-openvpn might not be functional when
> > > used with the network-manager service, as
> > > network-manager-vpnc is structured in a similar way
> > > and it's similar structured in code and how it's being
> > > activated.
> > >
> > > I can only test the case for vpnc as I'm debugging
> > > the package right now. It kind-of-works, but the rule
> > > is not being found when you try to activate the
> > > vpnc connection.
> >
> > Could you clarify a bit what you think is broken?
> >
> > VPN extensions are definitely found (as can be seen for instance in
> > ‘nm-connection-editor’) in my experience with a config like this:
> >
> >(network-manager-service-type
> > config =>
> > (network-manager-configuration
> > (inherit config)
> > (vpn-plugins (list (specification->package+output
> > "network-manager-openvpn")
> >
> > Thanks,
> > Ludo’.
> >
>
> Like this, where "…" is a removed uuid:
>
> Nov 14 12:16:35 localhost NetworkManager[421]: [1510661795.5451]
> audit: op="connection-activate" uuid="…" name="VPN HS-BO" pid=639 uid=1000
> result="fail" reason="The VPN service 'org.freedesktop.NetworkManager.vpnc'
> was not installed."
>
> NetworkManager-vpnc is in my profile (I have to send this in)
> and the vpnc file and profile is correct.
paste from my current systemconfig:
;; networking with network-manager
(service wpa-supplicant-service-type wpa-supplicant)
(service network-manager-service-type
(network-manager-configuration
(vpn-plugins (list network-manager-openvpn
network-manager-vpnc
Context here:
https://c.n0.is/systems/tree/guixsd/workstations/abyayala/config.scm
and this mess is the vpnc plugin for NM:
https://c.n0.is/ng0_guix/packages/tree/ng0/packages/personalized.scm#n213
--
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://dl.n0.is/dist/keys/
WWW: https://we.make.ritual.n0.is
signature.asc
Description: PGP signature
bug#29059: network-manager-service extension package not fully functional
Ludovic Courtès transcribed 1.0K bytes: > ng0 skribis: > > > I have come to the conclusion (logs will be reproduced next week and added) > > that network-manager-openvpn might not be functional when > > used with the network-manager service, as > > network-manager-vpnc is structured in a similar way > > and it's similar structured in code and how it's being > > activated. > > > > I can only test the case for vpnc as I'm debugging > > the package right now. It kind-of-works, but the rule > > is not being found when you try to activate the > > vpnc connection. > > Could you clarify a bit what you think is broken? > > VPN extensions are definitely found (as can be seen for instance in > ‘nm-connection-editor’) in my experience with a config like this: > >(network-manager-service-type > config => > (network-manager-configuration > (inherit config) > (vpn-plugins (list (specification->package+output > "network-manager-openvpn") > > Thanks, > Ludo’. > Like this, where "…" is a removed uuid: Nov 14 12:16:35 localhost NetworkManager[421]: [1510661795.5451] audit: op="connection-activate" uuid="…" name="VPN HS-BO" pid=639 uid=1000 result="fail" reason="The VPN service 'org.freedesktop.NetworkManager.vpnc' was not installed." NetworkManager-vpnc is in my profile (I have to send this in) and the vpnc file and profile is correct. -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dl.n0.is/dist/keys/ WWW: https://we.make.ritual.n0.is signature.asc Description: PGP signature
bug#29276: awesome-4.2 crashes when reloading awesome
It's already an improvement from the last version of awesome, but here's what I found just now (no logs): log in to awesome press 'Control-Super-r' expected: reload awesome config actual behavior: "login command not found" message before taking you to SLIM again. I'm not volunteering to fix this, I'm no longer using awesome :) -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dl.n0.is/dist/keys/ WWW: https://we.make.ritual.n0.is signature.asc Description: PGP signature
bug#29196: upstreaming of reproducibility related patches
Jan Nieuwenhuizen transcribed 1.0K bytes: > ng0 writes: > > > as I wrote in #29135, we should upstream the patches we > > gather for reproducibility. Share with upstream what is > > applicable to more software than just Guix included > > definitions of the software etc. > > > We have no list for this so far > > We need to share this, to avoid duplicate work elsewhere. > > What about the reproducible builds list? Well, list as in a list that lists our patches, not a mailinglist ;) > https://lists.reproducible-builds.org/listinfo/rb-general > General discussions about reproducible builds > > > At the reproducible-builds summit last week in Berlin some work has been > done on the topic of upstreaming patches. I think some effort has gone > (is going?) into a email template that starts by explaining what > reproducible-builds is, why it is important and why upstream should > consider taking the patch. > > Greetings, > janneke > > -- > Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org > Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com > -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ WWW: https://ng0.infotropique.org signature.asc Description: PGP signature
bug#29196: upstreaming of reproducibility related patches
Hi, as I wrote in #29135, we should upstream the patches we gather for reproducibility. Share with upstream what is applicable to more software than just Guix included definitions of the software etc. Attached to it: the usual conversation, outreach, public relations, discussions thing. We have no list for this so far, so we should first look into the patch-file patches (the obvious ones, in gnu/packages/patches/), and after that into some maybe not so obvious fixes we keep in the definitions themselves (via substitute etc). So we need a list, and then motivated people can work on this. Even if people is just a couple. It helps. We need to share this, to avoid duplicate work elsewhere. -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ WWW: https://ng0.infotropique.org signature.asc Description: PGP signature
bug#29113: Warnings when starting vim: Relink with for IFUNC symbol `longjmp'
SM > -lICE > -lXpm > -lXt > -lX11 > -lXdmcp > -lSM > -lICE > -lm > -lncurses > -lnsl > -lacl > -lattr > -lgpm > -ldl > -L/gnu/store/12yp700dkx6rf17lkf8pgq43nxmhr0lx-lua-5.3.4/lib > -llua > -Wl,-E > > -Wl,-rpath,/gnu/store/gqz3akl1w51v33vcfjsbg1mym5ww3sww-perl-5.26.0/lib/perl5/5.26.0/x86_64-linux-thread-multi/CORE > -fstack-protector-strong > -L/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib > > -L/gnu/store/gqz3akl1w51v33vcfjsbg1mym5ww3sww-perl-5.26.0/lib/perl5/5.26.0/x86_64-linux-thread-multi/CORE > -lperl > -lpthread > -lnsl > -ldl > -lm > -lcrypt > -lutil > -lc > > -L/gnu/store/2dlpgzv0rmfd7v71d6h2gc7r2251hzwh-python-3.5.3/lib/python3.5/config-3.5m > -lpython3.5m > -lpthread > -ldl > -lutil > -lm > -L/gnu/store/1hl6bvvh1rxwj6p5npf36m2r3n7xvqdw-tcl-8.6.6/lib > -ltcl8.6 > -ldl > -lpthread > -lieee > -lm > -Wl,-rpath,/gnu/store/vam0l4xw5v09b0kdfsm7hkfsv0c3ypy2-ruby-2.4.2/lib > -L/gnu/store/vam0l4xw5v09b0kdfsm7hkfsv0c3ypy2-ruby-2.4.2/lib > -lruby-static > -lpthread > -ldl > -lcrypt > -lm > -L/gnu/store/vam0l4xw5v09b0kdfsm7hkfsv0c3ypy2-ruby-2.4.2/lib > > > > > -- > ウィルソン ブランドン > 早稲田大学基幹理工学研究科応用数学専攻 > > Brandon M. Wilson > Waseda University > School of Fundamental Science and Engineering > Department of Applied Mathematics -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ https://www.infotropique.org https://ng0.infotropique.org signature.asc Description: PGP signature
bug#28948: feh does encounter certificate errors with valid certificates
Ricardo Wurmus transcribed 1.6K bytes:
>
> Marius Bakke writes:
>
> > ng0 writes:
> >
> >> feh https://i.imgur.com/263enxT.jpg
> >> feh opens image
> >>
> >> Problem:
> >> user@abyayala ~/src/guix/guix$ feh https://i.imgur.com/263enxT.jpg
> >> feh WARNING: open url: server certificate verification failed. CAfile:
> >> none CRLfile: none
> >> feh WARNING: https://i.imgur.com/263enxT.jpg - File does not exist
> >> feh: No loadable images specified.
> >> See 'man feh' for detailed usage information
> >>
> >> nss etc are in my profile, no problem with other curl based applications.
> >
> > The attached patch should fix the problem. Can you try it?
Thanks! I'll test it in the next couple of days.
> We’ve done something similar in r-curl IIRC. I wonder if we should just
> patch libcurl, so that all users of libcurl would benefit from this change.
In my opinion that would be preferable.
> > +diff --git a/src/imlib.c b/src/imlib.c
> > +index dfb79aa..82a9865 100644
> > +--- a/src/imlib.c
> > b/src/imlib.c
> > +@@ -429,6 +429,10 @@ static char *feh_http_load_image(char *url)
> > + if (opt.insecure_ssl) {
> > + curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER,
> > 0);
> > + curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST,
> > 0);
> > ++ } else {
> > ++ // Allow the user to specify custom CA
> > certificates.
> > ++ curl_easy_setopt(curl, CURLOPT_CAINFO,
> > ++ getenv("CURL_CA_BUNDLE"));
> > + }
>
> Is it safe to pass the empty string to curl_easy_setopt, in case
> CURL_CA_BUNDLE is unset? Do we need to check the value first or can we
> pass it without checking?
>
> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>
--
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://dist.ng0.infotropique.org/dist/keys/
https://www.infotropique.org https://ng0.infotropique.org
signature.asc
Description: PGP signature
bug#29059: network-manager-service extension package not fully functional
I have come to the conclusion (logs will be reproduced next week and added) that network-manager-openvpn might not be functional when used with the network-manager service, as network-manager-vpnc is structured in a similar way and it's similar structured in code and how it's being activated. I can only test the case for vpnc as I'm debugging the package right now. It kind-of-works, but the rule is not being found when you try to activate the vpnc connection. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ https://www.infotropique.org https://ng0.infotropique.org signature.asc Description: PGP signature
bug#28987: guix import crate fails on 648c896ad3b198a1742c1ee8f66a1922aa98c1d8
My Guix checkout on commit 648c896ad3b198a1742c1ee8f66a1922aa98c1d8 gives me for 'guix import crate x25519-dalek': Backtrace: 5 (primitive-load "/gnu/store/17w867lpc1grxs4aykzj5039fms…") In guix/ui.scm: 1384:12 4 (run-guix-command _ . _) In guix/scripts/import.scm: 114:11 3 (guix-import . _) In guix/scripts/import/crate.scm: 86:19 2 (guix-import-crate . _) In guix/import/crate.scm: 49:30 1 (crate-fetch _ #) In unknown file: 0 (string-split #f #\/) ERROR: In procedure string-split: ERROR: In procedure string-split: Wrong type argument in position 1 (expecting string): #f -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ https://www.infotropique.org https://ng0.infotropique.org signature.asc Description: PGP signature
bug#28948: feh does encounter certificate errors with valid certificates
feh https://i.imgur.com/263enxT.jpg feh opens image Problem: user@abyayala ~/src/guix/guix$ feh https://i.imgur.com/263enxT.jpg feh WARNING: open url: server certificate verification failed. CAfile: none CRLfile: none feh WARNING: https://i.imgur.com/263enxT.jpg - File does not exist feh: No loadable images specified. See 'man feh' for detailed usage information nss etc are in my profile, no problem with other curl based applications. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ https://www.infotropique.org https://ng0.infotropique.org signature.asc Description: PGP signature
bug#28823: lxqt-common is deprecated
ng0 transcribed 2.8K bytes: > Ludovic Courtès transcribed 0.9K bytes: > > Hi ng0, > > > > ng0 skribis: > > > > > ng0 transcribed 1.7K bytes: > > >> Ludovic Courtès transcribed 0.2K bytes: > > >> > Hello, > > >> > > > >> > Since nothing depends on lxqt-common, I suggest removing it. We can > > >> > always revisit this decision later if needed. > > > > [...] > > > > > Okay, we still require it. > > > The last LXQT release is 0.11.1, and lxqt-session requires lxqt-common. > > > > Are you sure? lxqt-session in master does not depend on lxqt-common. > > I am not working with master, I am working with what has been released, > ie the tarballs on download.lxqt.org or whatever the url was. This still > requires lxqt-common, and as I have no idea about the release cycle of > LXQT I would prefer to keep it (and to find a workaround for it not building). > > > > lxqt-notificationsd 0.11.1 still depends on lxqt-common. > > > Probably some more packages depend on it, but more than 1 is already > > > enough > > > for me NOT to kick it out. > > > > lxqt-notificationsd is not in master though. > > Sure, but I'm working on LXQT. Something not existing doesn't mean no one > is using it as a base to include packages depending on this… this is my way > to say: hey. I need this for stuff that seeks its way into Guix master for > another Desktop ;) > > > In master, there are really zero packages depending on it, per “guix > > refresh -l”. > > > > Currently lxqt-common does not build, due to the modified tarball. > > Could you figure out a way forward? > > Okay, I did not know about the original issue. I will try, I'll report back. > > > Thanks in advance! > > > > Ludo’. > > Let's drop it: http://lxqt.org/release/2017/10/21/lxqt-0120/ writes: > lxqt-common > > Dropped: With this release we drop lxqt-common, and all > files are moved to the packages in which they best fit. > The lxqt-themes portion was split out into the new package > lxqt-theme. Please read the notes for packagers. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ https://www.infotropique.org https://ng0.infotropique.org signature.asc Description: PGP signature
bug#28823: lxqt-common is deprecated
Ludovic Courtès transcribed 0.9K bytes: > Hi ng0, > > ng0 skribis: > > > ng0 transcribed 1.7K bytes: > >> Ludovic Courtès transcribed 0.2K bytes: > >> > Hello, > >> > > >> > Since nothing depends on lxqt-common, I suggest removing it. We can > >> > always revisit this decision later if needed. > > [...] > > > Okay, we still require it. > > The last LXQT release is 0.11.1, and lxqt-session requires lxqt-common. > > Are you sure? lxqt-session in master does not depend on lxqt-common. I am not working with master, I am working with what has been released, ie the tarballs on download.lxqt.org or whatever the url was. This still requires lxqt-common, and as I have no idea about the release cycle of LXQT I would prefer to keep it (and to find a workaround for it not building). > > lxqt-notificationsd 0.11.1 still depends on lxqt-common. > > Probably some more packages depend on it, but more than 1 is already enough > > for me NOT to kick it out. > > lxqt-notificationsd is not in master though. Sure, but I'm working on LXQT. Something not existing doesn't mean no one is using it as a base to include packages depending on this… this is my way to say: hey. I need this for stuff that seeks its way into Guix master for another Desktop ;) > In master, there are really zero packages depending on it, per “guix > refresh -l”. > > Currently lxqt-common does not build, due to the modified tarball. > Could you figure out a way forward? Okay, I did not know about the original issue. I will try, I'll report back. > Thanks in advance! > > Ludo’. > -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ https://www.infotropique.org https://ng0.infotropique.org signature.asc Description: PGP signature
bug#28823: lxqt-common is deprecated
ng0 transcribed 1.7K bytes: > Ludovic Courtès transcribed 0.2K bytes: > > Hello, > > > > Since nothing depends on lxqt-common, I suggest removing it. We can > > always revisit this decision later if needed. > > > > Objections? > > Yes, I have objections. > Please give me 14 days (until 2017-10-30) time to look into my current LXQT > branch > and the work that needs to be done for an LXQT Desktop to report > on wether LXQT really moved away from this or if it is still > needed by applications we do not (yet!) have. > > > Thanks, > > Ludo’. > > Okay, we still require it. The last LXQT release is 0.11.1, and lxqt-session requires lxqt-common. lxqt-notificationsd 0.11.1 still depends on lxqt-common. Probably some more packages depend on it, but more than 1 is already enough for me NOT to kick it out. I would appreciate if we would drop this until the tarballs no longer require it. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ https://www.infotropique.org https://ng0.infotropique.org signature.asc Description: PGP signature
bug#28823: lxqt-common is deprecated
Ludovic Courtès transcribed 0.2K bytes: > Hello, > > Since nothing depends on lxqt-common, I suggest removing it. We can > always revisit this decision later if needed. > > Objections? Yes, I have objections. Please give me 14 days (until 2017-10-30) time to look into my current LXQT branch and the work that needs to be done for an LXQT Desktop to report on wether LXQT really moved away from this or if it is still needed by applications we do not (yet!) have. > Thanks, > Ludo’. > -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ https://www.infotropique.org https://ng0.infotropique.org signature.asc Description: PGP signature
bug#28823: lxqt-common is deprecated
Ludovic Courtès transcribed 1.2K bytes:
> ng0 skribis:
>
> > Ludovic Courtès transcribed 0.8K bytes:
>
> [...]
>
> >> > Looking at the deprecated repo, it is not clear what needs to be
> >> > done. Possibly the now deprecated lxqt-common has been broken up in
> >> > various per-component repositories.
> >>
> >> Andreas, ng0: any idea?
> >>
> >> Thanks,
> >> Ludo’.
> >>
> >
> > So the Archlinux PKGBUILD uses:
> > source=(
> >
> > "https://github.com/lxde/$pkgname/releases/download/$pkgver/$pkgname-$pkgver.tar.xz";
> >
> > "https://github.com/lxde/$pkgname/releases/download/$pkgver/$pkgname-$pkgver.tar.xz.asc";
> > Gentoo uses:
> > if [[ ${PV} = ** ]]; then
> > inherit git-r3
> > EGIT_REPO_URI="git://git.lxde.org/git/lxde/${PN}.git"
> > else
> > SRC_URI="https://downloads.lxqt.org/lxqt/${PV}/${P}.tar.xz";
> > KEYWORDS="~amd64 ~arm ~arm64 ~x86"
> > fi
> >
> > I seem to remember that for the lxqt I work on in one of my branches
> > I used the lxqt.org domain.
>
> Using tarballs from downloads.lxqt.org sounds like a good idea.
>
> However, regardless of this, what’s up with the lxqt-common deprecation?
> Is it replaced by something else? Should we just remove it?
>
> I’m clueless about LXQt so any suggestions is welcome. :-)
And so am I. I have no idea, not until I start reading into the topic of
the inner connections and the current state of LXQT. As long as we don't know
for sure, and other projects don't remove it from their package repositories
I see no immediate need to remove it.
> Ludo’.
>
--
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://dist.ng0.infotropique.org/dist/keys/
https://www.infotropique.org https://ng0.infotropique.org
signature.asc
Description: PGP signature
bug#28823: lxqt-common is deprecated
Ludovic Courtès transcribed 0.8K bytes:
> Hi,
>
> Maxim Cournoyer skribis:
>
> > Our lxqt-common package's source currently points to
> > https://github.com/lxde/lxqt-common/archive/0.9.1.tar.gz, which
> > redirects to
> > https://github.com/lxde/lxqt-common-deprecated--do-not-use-anymore-/archive/0.9.1.tar.gz.
> >
> > Notice the "deprecated--do-not-use-anymore" in the URL.
>
> Weird, their README.md doesn’t say a work about deprecation.
>
> > This has the immediate effect of breaking the hash of the archive.
>
> Oh right, because auto-generated archives use the project name for the
> top-level directory. Bummer.
>
> > Looking at the deprecated repo, it is not clear what needs to be
> > done. Possibly the now deprecated lxqt-common has been broken up in
> > various per-component repositories.
>
> Andreas, ng0: any idea?
>
> Thanks,
> Ludo’.
>
So the Archlinux PKGBUILD uses:
source=(
"https://github.com/lxde/$pkgname/releases/download/$pkgver/$pkgname-$pkgver.tar.xz";
"https://github.com/lxde/$pkgname/releases/download/$pkgver/$pkgname-$pkgver.tar.xz.asc";
Gentoo uses:
if [[ ${PV} = ** ]]; then
inherit git-r3
EGIT_REPO_URI="git://git.lxde.org/git/lxde/${PN}.git"
else
SRC_URI="https://downloads.lxqt.org/lxqt/${PV}/${P}.tar.xz";
KEYWORDS="~amd64 ~arm ~arm64 ~x86"
fi
I seem to remember that for the lxqt I work on in one of my branches
I used the lxqt.org domain.
--
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://dist.ng0.infotropique.org/dist/keys/
https://www.infotropique.org https://ng0.infotropique.org
signature.asc
Description: PGP signature
bug#28745: tarballs generated on github are generated on demand (leading to different hash sums)
ng0 transcribed 2.1K bytes: … > Since some of our own dependencies are on github (at the very least > guile-git), we need to come up with a solution. … Correction: libgit2 is on github, a dependency of guile-git (which is on gitlab). -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.krosos.org/dist/keys/ https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28745: tarballs generated on github are generated on demand (leading to different hash sums)
Past and recent discussion in our IRC channel and on the mailing list show that we can not rely on tarballs on github keeping the same hash forever. According to github they are "generated on demand", leading to regular hash mismatches. Since some of our own dependencies are on github (at the very least guile-git), we need to come up with a solution. Right now we have around 449 packages with tarball sources from github in our gnu/packages. We could: - Move them all to use git-download and just use the commit that has been tagged in the versions that produce the tarballs on github. - Mirror the content somewhere reliable in snapshots for some time. Problem here: we start to rely on this "somewhere" to be trustworthy and introduce one more point to trust (however due to pre-recorded hash sum this is just an annoyance, not a grave issue). - Your idea here. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.krosos.org/dist/keys/ https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#26006: [Website] Integral update proposal
Ludovic Courtès transcribed 1.2K bytes:
> Hello ng0,
>
> ng0 skribis:
>
> > what's missing for this branch to be merged? I took a quick build on this
> > (and because I like the code as a reference), and it looks good. Builds,
> > maybe some changes from master have to be applied to it (like using
> > https instead of http at the download URLs).
> >
> > Anything missing we could help out with?
>
> Sure, not that much is missing. I must say that I’m really sorry that
> we failed to move forward on this after all the great work sirgazil did!
>
> IIRC one of the problems is that the /packages page by default shows all
> packages, which is too much. We should fix that.
>
> Then I think there were tiny issues here and there, nothing big though
> (since the new site was written from scratch, some of the fine-tuning we
> did on the old one was lost.)
>
> Last, we’ll need to setup redirects for the old blog post URLs, and
> perhaps for a few other pages.
>
> If you could build it, browse it, report/fix issues, and identify
> redirects that need to be made, that would help tremendously! I’ve felt
> lonely while working on it, so I’m really happy if you can take a closer
> look. ;-)
>
> Let’s team up and get this done!
>
> Thanks,
> Ludo’.
Aside:
I wasn't able to make use of the guix build -f build.scm
for my adaption of its code base
but haunt build on its own worked. The build.scm was
complaining about this:
user@abyayala ~/src/krosos.org$ guix build -f build.scm
substitute: updating list of substitutes from 'https://berlin.guixsd.org'...
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'...
100.0%
The following derivation will be built:
/gnu/store/jpqazlp2jh66q1yqsxasiqfkwjlx6pcr-gexp.drv
@ build-started /gnu/store/jpqazlp2jh66q1yqsxasiqfkwjlx6pcr-gexp.drv -
x86_64-linux /var/log/guix/drvs/jp//qazlp2jh66q1yqsxasiqfkwjlx6pcr-gexp.drv.bz2
Backtrace:
9 (primitive-load "/tmp/guix-build-gexp.drv-0/haunt.scm")
In ice-9/eval.scm:
721:20 8 (primitive-eval (use-modules ((apps base builder) # …) …))
In ice-9/psyntax.scm:
1234:36 7 (expand-top-sequence ((use-modules ((apps base …) …) …)) …)
1181:24 6 (parse _ (("placeholder" placeholder)) ((top) #(# # …)) …)
284:10 5 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) …)
In ice-9/boot-9.scm:
3369:20 4 (process-use-modules _)
230:17 3 (map1 (((apps base builder) #:prefix base:) ((# …) …) …))
3370:31 2 (_ ((apps base builder) #:prefix base:))
2795:6 1 (resolve-interface _ #:select _ #:hide _ #:prefix _ # _ …)
In unknown file:
0 (scm-error misc-error #f "~A ~S" ("no code for modu…" …) …)
ERROR: In procedure scm-error:
ERROR: no code for module (apps base builder)
`/gnu/store/g0f0rsway1cik45kwdwbxfmqpv6nmqyg-krosos-web-site/deploy.sh' ->
`./deploy.sh'
`/gnu/store/g0f0rsway1cik45kwdwbxfmqpv6nmqyg-krosos-web-site/haunt.scm' ->
`./haunt.scm'
`/gnu/store/g0f0rsway1cik45kwdwbxfmqpv6nmqyg-krosos-web-site/build.scm' ->
`./build.scm'
`/gnu/store/g0f0rsway1cik45kwdwbxfmqpv6nmqyg-krosos-web-site/.gitignore' ->
`./.gitignore'
`/gnu/store/g0f0rsway1cik45kwdwbxfmqpv6nmqyg-krosos-web-site/COPYING' ->
`./COPYING'
`/gnu/store/g0f0rsway1cik45kwdwbxfmqpv6nmqyg-krosos-web-site/guix.packages' ->
`./guix.packages'
`/gnu/store/g0f0rsway1cik45kwdwbxfmqpv6nmqyg-krosos-web-site/guix.scm' ->
`./guix.scm'
`/gnu/store/g0f0rsway1cik45kwdwbxfmqpv6nmqyg-krosos-web-site/README' ->
`./README'
builder for `/gnu/store/jpqazlp2jh66q1yqsxasiqfkwjlx6pcr-gexp.drv' failed to
produce output path `/gnu/store/0n9cp4djm8r3gpcdmbbnc2lgcxdicjm1-gexp'
@ build-failed /gnu/store/jpqazlp2jh66q1yqsxasiqfkwjlx6pcr-gexp.drv - 1 builder
for `/gnu/store/jpqazlp2jh66q1yqsxasiqfkwjlx6pcr-gexp.drv' failed to produce
output path `/gnu/store/0n9cp4djm8r3gpcdmbbnc2lgcxdicjm1-gexp'
guix build: error: build failed: build of
`/gnu/store/jpqazlp2jh66q1yqsxasiqfkwjlx6pcr-gexp.drv' failed
Same for guix-artwork/website:
user@abyayala ~/re-src/guix-artwork/website$ guix build -f build.scm
substitute: updating list of substitutes from 'https://berlin.guixsd.org'...
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'...
100.0%
The following derivation will be built:
/gnu/store/z8h6fkc6wnimdpd3sj2gzfbrwa94v2qh-gexp.drv
@ build-started /gnu/store/z8h6fkc6wnimdpd3sj2gzfbrwa94v2qh-gexp.drv -
x86_64-linux /var/log/guix/drvs/z8//h6fkc6wnimdpd3sj2gzfbrwa94v2qh-gexp.drv.bz2
Backtrace:
9 (primitive-load "/tmp/guix-build-gexp.drv-0/haunt.scm")
In ice-9/eval.scm:
721:20 8 (primitive-eval (use-modules ((apps base builder) #
bug#28659: v0.13: guix pull fails; libgit2-0.26.0 and 0.25.1 content hashes fail
Leo Famulari transcribed 2.3K bytes: > On Sun, Oct 01, 2017 at 09:20:42PM +0200, Jan Nieuwenhuizen wrote: > > Jan Nieuwenhuizen writes: > > > > The changing of the libgit-0.26.0 checksum was already reported about 3 > > weeks ago (github seems to only show relative dates) > > > > https://github.com/libgit2/libgit2/issues/4343 > > > > and the bug is still open. It seems to be a github thing. As I > > understand it, currently our options are to update the hash and pray it > > won't happen again or host libgit2 tarballs ourselves. > > I contacted GitHub about this issue a few weeks ago and they said that: > > 1) They do not guarantee bit-reproducibility of the snapshots they > generate automatically for each release tag, and they wish that people > would not rely on them as we do. However, since people *are* relying on > them, they are discussing this issue internally. > 2) This is the relevant code change: > https://git.kernel.org/pub/scm/git/git.git/commit/?id=22f0dcd9634a818a0c83f23ea1a48f2d620c0546 > > In the meantime, we can add this to the list of reasons that > reproducibility is difficult in the long term. > > I don't have any solutions in mind besides keeping substitutes available > for as long as possible and, for users, using substitutes. We might also > petition upstream projects to offer a "real" release tarball. Given that we depend on this for our core functionality, can't we just keep this on our ftp directory at gnu.org as a fall-back source in a list? -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://krosos.org/dist/keys/ https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#26006: [Website] Integral update proposal
Hi, what's missing for this branch to be merged? I took a quick build on this (and because I like the code as a reference), and it looks good. Builds, maybe some changes from master have to be applied to it (like using https instead of http at the download URLs). Anything missing we could help out with? -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://krosos.org/dist/keys/ https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28479: icecat-52.3.0-gnu1 includes Google in search engines
Mark H Weaver transcribed 0.8K bytes: > Mark H Weaver writes: > > > ng0 writes: > > > >> With a completely new system (had to set this up for testing Mate) > >> and guix package -i icecat (for the recent release) and no pre-existing > >> configuration, the default was Google, not DuckDuckGo. > > > > On my GuixSD system, I just tried the following: > > > > * Quit IceCat, and wait for the process to really be gone. > > * Move ~/.mozilla to ~/.mozilla-OLD. > > * Restart IceCat. > > > > and I found that DuckDuckGo was the default search engine. > > > > I'm not sure what you did, but I suspect that you had a ~/.mozilla > > directory in place where Google was configured to be the default search > > engine. > > Any response to this, ng0? Do you still believe that Google is the > default search engine for our IceCat package? > > Mark > I was busy and haven't forgotten about this. So: What I reported was on a new install from scratch. When I simply rename my .mozilla and start icecat so that a new profile is created, I get DuckDuckGo. Let's just close this, I have no idea what happened on the previous install. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://krosos.org/dist/keys/ https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28479: icecat-52.3.0-gnu1 includes Google in search engines
Mark H Weaver transcribed 1.1K bytes: > ng0 writes: > > > Mark H Weaver transcribed 0.4K bytes: > >> > >> ng0 writes: > >> > >> > Is this an upstream bug? Should we patch to remove Google? > >> > > >> > I've just compared a completely new system (and Icecat profile) > >> > with my default profile, both include Google in search engines. > >> > > >> > There's also Bing and Yahoo, I'm not sure if all 3 were present > >> > before this version. > >> > >> Why would it be considered a bug to give users the convenient option to > >> use those search engines? > >> > >>Mark > > > > For example the branch of firefox which Parabola distributes > > makes changes not to default to Google. > > Among the changes that GNU IceCat makes to Firefox ESR: it makes > DuckDuckGo the default search engine. Last I checked, that was indeed > the case for our IceCat package. Do you have reason to believe > otherwise? With a completely new system (had to set this up for testing Mate) and guix package -i icecat (for the recent release) and no pre-existing configuration, the default was Google, not DuckDuckGo. > > People rarely change defaults, so we should give the option to use > > Google but default to for example searx.me or duckduckgo.com. > > Agreed, and I think that's exactly what IceCat does. Please let me know > if you think I'm mistaken about that. > > Mark > -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://krosos.org/dist/keys/ https://www.infotropique.org https://www.krosos.org signature.asc Description: PGP signature
bug#28479: icecat-52.3.0-gnu1 includes Google in search engines
Ludovic Courtès transcribed 1.3K bytes: > Hello, > > ng0 skribis: > > > Mark H Weaver transcribed 0.4K bytes: > >> Hi, > >> > >> ng0 writes: > >> > >> > Is this an upstream bug? Should we patch to remove Google? > >> > > >> > I've just compared a completely new system (and Icecat profile) > >> > with my default profile, both include Google in search engines. > >> > > >> > There's also Bing and Yahoo, I'm not sure if all 3 were present > >> > before this version. > >> > >> Why would it be considered a bug to give users the convenient option to > >> use those search engines? > >> > >>Mark > > > > For example the branch of firefox which Parabola distributes > > makes changes not to default to Google. People rarely > > change defaults, so we should give the option to use Google > > but default to for example searx.me or duckduckgo.com. > > I sort-of agree with both of you. :-) > > Using a centralized search engine, be it Google or DuckDuckGo or even > searx.me, is a threat to privacy. Of course the dominating position of > Google makes it worse than the others, but let’s not pretend the others > are white as snow. > > Besides, this is a discussion to have with IceCat upstream IMO. There’s > nothing Guix-specific here. So I’d close this one as “wontfix”. > > WDYT? > > Ludo’. > I agree. I'll take this upstream soon. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://krosos.org/dist/keys/ https://www.infotropique.org https://www.krosos.org signature.asc Description: PGP signature
bug#28479: icecat-52.3.0-gnu1 includes Google in search engines
Mark H Weaver transcribed 0.4K bytes: > Hi, > > ng0 writes: > > > Is this an upstream bug? Should we patch to remove Google? > > > > I've just compared a completely new system (and Icecat profile) > > with my default profile, both include Google in search engines. > > > > There's also Bing and Yahoo, I'm not sure if all 3 were present > > before this version. > > Why would it be considered a bug to give users the convenient option to > use those search engines? > >Mark For example the branch of firefox which Parabola distributes makes changes not to default to Google. People rarely change defaults, so we should give the option to use Google but default to for example searx.me or duckduckgo.com. I keep my configs in git and just pull them every time I set up a new system, so I wouldn't know if Icecat has always included Google and the others. Maybe my view on this problem (privacy issues) goes beyond our guidelines? -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://krosos.org/dist/keys/ https://www.infotropique.org https://www.krosos.org signature.asc Description: PGP signature
bug#28479: icecat-52.3.0-gnu1 includes Google in search engines
Is this an upstream bug? Should we patch to remove Google? I've just compared a completely new system (and Icecat profile) with my default profile, both include Google in search engines. There's also Bing and Yahoo, I'm not sure if all 3 were present before this version. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://krosos.org/dist/keys/ https://www.infotropique.org https://www.krosos.org signature.asc Description: PGP signature
bug#28478: Adjust Enlightenment First-Time Dialogue
Quoting from IRC where I went through the Dialogue:
language, not configurable ("System default") which is okay.
Keyboard shows nothing.
Profile is okay (works).
Maybe write an Networkmanager and/or Wicd dialogue part and contribute it
upstream, and/or skip the "Install/enable Connman" step.
Maybe disable the Update checking (will probably only work for user-installed
addons?) step.
--
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://krosos.org/dist/keys/
https://www.infotropique.org https://www.krosos.org
signature.asc
Description: PGP signature
bug#28355: Guix snapshot version in the download URL
Ben Woodcroft transcribed 2.4K bytes:
> Hi,
>
> At https://www.gnu.org/software/guix/manual/guix.html#Binary-Installation
> the binary download link is
>
> |ftp://alpha.gnu.org/gnu/guix/guix-binary-0.13.0.314-a8d0c.system.tar.xz|
>
> |Unfortunately, this link does not exist even after the system is replaced
> with the correct string. The '||.314-a8d0c' needs to be removed. The
> relevant section in doc/guix.texi is:|
>
> |Download the binary tarball from
> @indicateurl{ftp://alpha.gnu.org/gnu/guix/guix-binary-@value{VERSION}.@var{system}.tar.xz},
> where @var{system} is @code{x86_64-linux} for an @code{x86_64} machine
> already running the kernel Linux, and so on.
> |
>
> |Is there some way to replace VERSION with the stable version?|
>
> |Thanks, ben
> |
>
I think we could just define @RELEASE_VERSION and use that for the link.
--
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org
signature.asc
Description: PGP signature
bug#26931: GuixSD rebooting fails when tmux is running
Ludovic Courtès transcribed 1.7K bytes: > Hi, > > Leo Famulari skribis: > > > On Sun, May 14, 2017 at 11:36:17PM +0200, Ludovic Courtès wrote: > >> What does /var/log/shepherd.log show around the time where you hit > >> “halt”? > >> > >> I get something like this: > >> > >> --8<---cut here---start->8--- > >> 18:06:26 Service mcron has been stopped. > >> 18:06:26 sending all processes the TERM signal > > > > For me, this is where it gets stuck: > > > > -- > > 2017-05-16 19:12:53 sending all processes the TERM signal > > 2017-05-16 19:12:58 waiting for process termination (processes left: (1 > > 494)) > > 2017-05-16 19:13:00 waiting for process termination (processes left: (1 > > 494)) > > 2017-05-16 19:13:02 waiting for process termination (processes left: (1 > > 494)) > > -- > > > > In my experience, it will wait here forever. > > > > And from `ps aux`: > > > > leo494 0.0 0.1 27232 3676 ?Ss 19:12 0:00 tmux > > The bug was 100% reproducible in a VM, and AFAICS it is fixed by > 7f090203d5fb033eb1b64778b03afad5bb35f5f2. > > The problem was that the tmux server process would be left as a zombie, > and then the loop would always see it because the parent process of the > tmux server process is PID 1 and for some reason the PID 1 either didn’t > get SIGCHLD or the handler didn’t run. > > The test that this commit adds does exactly the same thing: launch tmux > and then invoke “halt”. I tried to create a synthetic test not > involving tmux, simply creating a process that gets PID 1 as its parent, > but it wouldn’t trigger the bug. I’m unclear as to why tmux triggers it > and no that other simple test. > > Thanks, > Ludo’. > > > > I just found this upstream issue: https://github.com/tmux/tmux/issues/311 which has been fixed in tmux 2.5. I think we should take this bug to upstream, even if it's just to get more insight if it is a tmux bug. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28260: tcsh/csh needs separate /etc/profile - like file
I am looking into making usage of different shells easier on GuixSD.
I already noticed that our SLIM-service needs a change
to work for tcsh, but it seems as if we should also create
a file in the %base-services or a small service:
quote man tcsh(1):
> Startup and shutdown
> A login shell begins by executing commands from the system files
> /etc/csh.cshrc and /etc/csh.login. It then executes commands from files in
> the user's home directory: first ~/.tcshrc (+) or, if ~/.tcshrc is not
> found, ~/.cshrc, then the contents of ~/.history (or the value of the
> histfile shell variable) are loaded into memory, then ~/.login, and finally
> ~/.cshdirs (or the value of the dirsfile shell variable) (+). The
> shell may read /etc/csh.login before instead of after /etc/csh.cshrc, and
> ~/.login before instead of after ~/.tcshrc or ~/.cshrc and ~/.history, if so
> compiled; see the version shell variable. (+)
>
> Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc on
> startup.
It might take a while for me to find time for this and to test it,
but I will try and add such a file (/etc/csh.login) via a service.
However this _seems_ to be only a problem with SLIM as far as I could test,
as I am able to log in using tcsh (in a profile which never used bash and
uses tcsh as its user shell) at the tty. SLIM fails for login_command
reasons. Nevertheless it should be safer to add this for tcsh users
who are new to Guix and who did not add basic stuff to their .tcshrc
such as
> setenv PATH
> $HOME/.guix-profile/bin:$HOME/.guix-profile/sbin:/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin
> setenv INFOPATH
> $HOME/.guix-profile/share/info:/run/current-system/profile/share/info:$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
> setenv GUILE_LOAD_COMPILED_PATH
> $HOME.guix-profile/lib/guile/2.2/site-ccache:$HOME.guix-profile/share/guile/site/2.2:/run/current-system/profile/lib/guile/2.2/site-ccache:/run/current-system/profile/share/guile/site/2.2
> setenv GUILE_LOAD_PATH
> $HOME/.guix-profile/share/guile/site/2.2:/run/current-system/profile/share/guile/site/2.2
> setenv GIT_EXEC_PATH $HOME/.guix-profile/libexec/git-core
I will also look at the ~/.guix-profile/etc/profile variant
and see that we can generate a similar file for tcsh.
> export
> INFOPATH="${GUIX_PROFILE:-/gnu/store/1n2ay00nvsybwszvjdm7acc39pm0k851-profile}/share/info${INFOPATH:+:}$INFOPATH"
a very simple solution could be
setenv INFOPATH $GUIX_PROFILE/share/info
which of course does not include the
> export
> INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
which can be set in /etc/profile so I assume it
could be (untested):
setenv INFOPATH $GUIX_PROFILE/share/info:INFOPATH
We can also test very easily for tcsh if that helps
solving any future problems:
> [abyayala] 8:08am ~ > echo $shell
> /gnu/store/kfv79p5di3bz3jl4j1vn91v69ga6sqk3-tcsh-6.20.00/bin/tcsh
> [abyayala] 8:08am ~ > exit
> # now we are back in bash again (no tcsh-only environment here)
> user@abyayala ~$ echo $shell
>
> # as you can see bash returns empty here
> # and so does zsh aswell.
--
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org
signature.asc
Description: PGP signature
bug#27778: Changing package source URLs from git:// to https://
Leo Famulari transcribed 3.2K bytes: > On Thu, Jul 20, 2017 at 06:06:31PM -0400, Leo Famulari wrote: > > Let's change these packages to use HTTPS or HTTP! > > Well, I don't know any benefit to using HTTP over GIT, so I'm not going > to change the packages whose sources are not available over HTTPS. > > Not available over HTTPS, as far as I can tell: Yep, 2f30.org and psyced.org have no http/https access for the git. psyced.org has an .onion which is advised to be used, but we can't take on the position that it is generally safe to use tor without risks for everyone. … > > suckless.scm: (url "git://git.2f30.org/human.git") … > > messaging.scm: (url "git://git.psyced.org/git/psyclpc") … -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28231: log-file: echo name at the end of builds
ng0 transcribed 2.2K bytes: > When a build invoked with --no-build-hook -K --log-file fails, this is the > last output you'll see: > > 14:01.58 565 compiler warnings present. > mach configuremachphase `configure' failed after 869.5 seconds > note: keeping build directory `/tmp/guix-build-thunderbird-52.2.1.drv-0' > builder for > `/gnu/store/n7qma1ypp2px1shd88r736ykjg5dngll-thunderbird-52.2.1.drv' failed > with exit code 1 > @ build-failed > /gnu/store/n7qma1ypp2px1shd88r736ykjg5dngll-thunderbird-52.2.1.drv - 1 > builder for > `/gnu/store/n7qma1ypp2px1shd88r736ykjg5dngll-thunderbird-52.2.1.drv' failed > with exit code 1 > guix build: error: build failed: build of > `/gnu/store/n7qma1ypp2px1shd88r736ykjg5dngll-thunderbird-52.2.1.drv' failed > > As far as I remember from builds I have aborted at the beginning, the > logfile name is displayed when the build process beginns. > > In my opinion we should also display them at the end builds (however they > end). > If we don't record logs of failed builds, we should start doing that. On days where I run not so many builds, I can get the name with ls -al /var/log/guix/drvs/ | grep "Aug 25" (for today) and then look at the timestamps in the folders I get. That's not very reliable, so it should be improved. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28231: log-file: echo name at the end of builds
When a build invoked with --no-build-hook -K --log-file fails, this is the last output you'll see: 14:01.58 565 compiler warnings present. mach configuremachphase `configure' failed after 869.5 seconds note: keeping build directory `/tmp/guix-build-thunderbird-52.2.1.drv-0' builder for `/gnu/store/n7qma1ypp2px1shd88r736ykjg5dngll-thunderbird-52.2.1.drv' failed with exit code 1 @ build-failed /gnu/store/n7qma1ypp2px1shd88r736ykjg5dngll-thunderbird-52.2.1.drv - 1 builder for `/gnu/store/n7qma1ypp2px1shd88r736ykjg5dngll-thunderbird-52.2.1.drv' failed with exit code 1 guix build: error: build failed: build of `/gnu/store/n7qma1ypp2px1shd88r736ykjg5dngll-thunderbird-52.2.1.drv' failed As far as I remember from builds I have aborted at the beginning, the logfile name is displayed when the build process beginns. In my opinion we should also display them at the end builds (however they end). If we don't record logs of failed builds, we should start doing that. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28230: offloading does not transfer build logs
Short and simple, currently we have this, assuming that you have first build mutt on a different machine via offloading builds afterwards produce this: guix build --no-build-hook --log-file mutt guix build: error: no build log for '/gnu/store/zmx9c4akha95l13c5066phgm6vgdbbf9-mutt-1.8.3.drv' Expected behavior would be that you get the location of the build log. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28168: rofi - Failed to set locale and relink messages
Fredrik Salomonsson transcribed 136K bytes: > > > > > Failed to set locale. > > > > > > then it exits. > > > > > > I've set: > > > GUIX_LOCPATH=$HOME/.guix-profile/lib/locale > > > LANG=en_US.UTF-8 > > > > > > Using glibc-locales > > > > Does setting LC_ALL instead of LANG help? The LC_* variables take > > precedence over LANG. > > setting LC_ALL didn't work. Same error. How recent is the guix you have? Did you run guix pull and guix package -u .* recently? -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28167: decide how to deal with gschemas
Creating manual page database for 59 packages... done in 2.152 s warning: collision encountered: /gnu/store/7dq7vkvrykv3wm9l8j617v3xbn44g51i-epiphany-3.24.3/share/glib-2.0/schemas/gschemas.compiled /gnu/store/1c7w0pjf80z8l6yb9a8wmni8za3mpx85-simple-scan-3.24.1/share/glib-2.0/schemas/gschemas.compiled warning: arbitrarily choosing /gnu/store/7dq7vkvrykv3wm9l8j617v3xbn44g51i-epiphany-3.24.3/share/glib-2.0/schemas/gschemas.compiled 1. How do we deal with these gschema collisions? I know eventually we should solve almost all collisions we have, but gschemas seems more important than the usual ones. 2. I also think we should formalize how to deal with the collisions or specific groups of collisions, so that we might have a better way to tackle these issues. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28111: qemu testsuite fails
ng0 transcribed 2.2K bytes: > Maybe this occurs just occasionally, nevertheless worth > reporting. I have no time to look into fixing it right now. > > TEST: tests/vhost-user-test... (pid=27813) > /i386/vhost-user/read-guest-mem: OK > /i386/vhost-user/migrate:OK > /i386/vhost-user/multiqueue: OK > /i386/vhost-user/reconnect: OK > /i386/vhost-user/connect-fail: ** > ERROR:tests/vhost-user-test.c:809:test_connect_fail: child process > (/i386/vhost-user/connect-fail/subprocess [27843]) failed unexpectedly > qemu-system-i386: Failed to set msg fds. > qemu-system-i386: vhost VQ 0 ring restore failed: -1: Input/output error (5) > qemu-system-i386: Failed to set msg fds. > qemu-system-i386: vhost VQ 1 ring restore failed: -1: Input/output error (5) > FAIL > GTester: last random seed: R02S8558f45fe09086531252e03ae246aedb > (pid=27854) > /i386/vhost-user/flags-mismatch: OK > Ran it again, the second time I can't reproduce this. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28111: qemu testsuite fails
Maybe this occurs just occasionally, nevertheless worth reporting. I have no time to look into fixing it right now. TEST: tests/vhost-user-test... (pid=27813) /i386/vhost-user/read-guest-mem: OK /i386/vhost-user/migrate:OK /i386/vhost-user/multiqueue: OK /i386/vhost-user/reconnect: OK /i386/vhost-user/connect-fail: ** ERROR:tests/vhost-user-test.c:809:test_connect_fail: child process (/i386/vhost-user/connect-fail/subprocess [27843]) failed unexpectedly qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 0 ring restore failed: -1: Input/output error (5) qemu-system-i386: Failed to set msg fds. qemu-system-i386: vhost VQ 1 ring restore failed: -1: Input/output error (5) FAIL GTester: last random seed: R02S8558f45fe09086531252e03ae246aedb (pid=27854) /i386/vhost-user/flags-mismatch: OK -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28095: Graphviz test-suite probably requires ksh-93
This bug is for myself as a reference and to close it once we have fixed the comment in the graphviz package. If you read https://github.com/ellson/graphviz/issues/1267 you'll find out that ksh-93, which we don't have (yet) is the shell which should be able to run the test suite of graphviz. I'm currently debugging the build of ksh-93 and I also need to read every header of it to check if we have one bit of AT&T proprietary copyright in there. As fedora packages it, the chances are high that it can just be used as-is, but we should check it nevertheless. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28088: "The name org.a11y.Bus was not provided by any .service files" with multiple applications
ng0 transcribed 1.6K bytes: > Upon starting for example emacs in spectrwm I get this message: > [1] Doneemacs > user@abyayala ~$ > ** (emacs-25-2:19121): WARNING **: Error retrieving accessibility bus > address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was > not provided by any .service files > > It works alright, but I have seen the exact same message while > trying to figure out why mate-terminal does not start. > -- > ng0 > GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 > GnuPG: https://n0is.noblogs.org/my-keys > https://www.infotropique.org https://krosos.org It is worth mentioning that this only happens with a desktop-services ressembling services list + no xfce-service or gnome-service in the system config. Reconfiguring and adding GNOME, switching tp GNOME makes this message not appear. We need to narrow down where this error comes from. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28088: "The name org.a11y.Bus was not provided by any .service files" with multiple applications
Upon starting for example emacs in spectrwm I get this message: [1] Doneemacs user@abyayala ~$ ** (emacs-25-2:19121): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files It works alright, but I have seen the exact same message while trying to figure out why mate-terminal does not start. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#28087: "guix build: error: no build log for gnu-store-pathto.drv" with previously offloaded successful build
I offload my builds by default. The build in question succeeded. Now I wanted to read the log of the successful build to check the configure options. I thought I'd just do: guix build --log-file --no-grafts --check --no-build-hook --rounds=2 --verbosity=5 mate-session-manager Verbosity was just added later, and so was --check and --no-grafts and --rounds. The only time I did not get was when the build was grafted, which got me a log file with the content of the graft locationA -> locationB in it. Every other try just gives me: guix build: error: no build log for '/gnu/store/l5cznxxdnbf803mkjavmg9kajicy7751-mate-session-manager-1.18.1.drv' Is this a bug or just a mistake of where I put "--log-file"? -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27862: tor-hidden-service should support IPv6
Ludovic Courtès transcribed 0.4K bytes: > ng0 skribis: > > > Right now the tor-hidden-service only supports IPv4 naming scheme, > > while it is possible to define IPv6 for tor aswell. > > ‘tor-hidden-service’ does not interpret addresses. So one could write, > say: > > (80 . "[::1]:80") Oh. Okay, I did not even try it because I live on the dark side of IPv6 ;) Then all which needs to be done is a small extension of the documentation of tor-hidden-service. > and that’d be IPv6 (talking to localhost over IPv6 is great ;-)). > It is what you had in mind? > > > Someone should fix this. > > I agree, someone! > > Thanks, > Ludo’. > -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27206: Fish: figure out a solution for the vendor path extension to fish
Ludovic Courtès transcribed 1.0K bytes:
> ng0 skribis:
>
> > ng0 transcribed 0.4K bytes:
> >> A feature-bug I forgot to report a while ago.
> >> It has been described on the mailinglist (or was
> >> it in my blog or some release announcement I made?)
> >>
> >> Fish doesn't pick up stuff like 'fish-guix' from store
> >> without modifications to the path where fish searches
> >> for vendor or sysadmin installed systemwide 'things'
> >> for fish.
> >
> > I have many more fish packages in a branch which
> > I want to get into guix, but they are stuck because
> > of this. Help welcome, otherwise I'll promise to
> > fix it one day.
> >
> > Currently the only workaround is to symlink individual files from your
> > ~/.guix-profile/whereever/things/went/ to ~/.config/fish/{approriate
> > subdirs}
>
> Does Fish have an environment variable that can be used to specify the
> search path for extensions, similar to BASH_LOADABLES_PATH? If it does,
> we could use that.
>
> Otherwise, perhaps we can consider it an upstream issue in a way?
>
> Thanks,
> Ludo’.
Late night reply, so I'll be short.
I have some open reading material on how Nix solved this,
which is the only system coming close to our layout. Everyone
else can just point to one of the canonical paths.
I haven't concluded yet if Nix' solution is usable for us
as they sometimes take shortcuts.
I'll post the links within the next 7 days, more likely on
the weekend.
Thanks, goodnight
--
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org
signature.asc
Description: PGP signature
bug#27925: website: guix build -f guix.scm errors
I tested if the errors I get with my websites are reproducible in some
way. The guix.scm I use there is derived from the one of the guix website,
so I ran the same in the 'guix-artwork' repository, with comparaible (equal?)
errors:
user@abyayala ~/Downloads/guix-artwork/website$ git pull
remote: Counting objects: 314, done.
remote: Compressing objects: 100% (167/167), done.
remote: Total 314 (delta 150), reused 297 (delta 137)
Receiving objects: 100% (314/314), 4.03 MiB | 735.00 KiB/s, done.
Resolving deltas: 100% (150/150), completed with 46 local objects.
From git://git.savannah.gnu.org/guix/guix-artwork
462daff..badfa7c master -> origin/master
* [new branch] wip-website-update -> origin/wip-website-update
Updating 462daff..badfa7c
Fast-forward
website/posts/state-of-aarch64-on-guix.md | 88
website/www/donate.scm| 4
website/www/help.scm | 14 +-
3 files changed, 105 insertions(+), 1 deletion(-)
create mode 100644 website/posts/state-of-aarch64-on-guix.md
user@abyayala ~/Downloads/guix-artwork/website$ guix build -f guix.scm
guix build: warning: failed to load '(mystery hack evolution)':
ERROR: In procedure module-lookup: Unbound variable: version-major+minor
The following derivation will be built:
/gnu/store/74wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv
process 11821 acquired build slot '/var/guix/offload/192.168.1.179/0'
load on machine '192.168.1.179' is 0.0 (normalized: 0.0)
@ build-started /gnu/store/74wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv -
x86_64-linux /var/log/guix/drvs/74//wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv.bz2
sending 0 store items to '192.168.1.179'...
offloading '/gnu/store/74wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv' to
'192.168.1.179'...
@ build-remote /gnu/store/74wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv
192.168.1.179
@ build-started /gnu/store/74wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv -
x86_64-linux /var/log/guix/drvs/74//wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv.bz2
Backtrace:
In ice-9/boot-9.scm:
230:29 19 (map1 (((srfi srfi-1)) ((www)) ((www utils)) ((www #
230:17 18 (map1 (((www)) ((www utils)) ((www news
3370:31 17 (_ ((www)))
2792:17 16 (resolve-interface (www) #:select _ #:hide _ #:prefix _ ?)
2718:10 15 (_ (www) _ _ #:ensure _)
2986:16 14 (try-module-autoload _ _)
2316:4 13 (save-module-excursion #)
3006:22 12 (_)
In unknown file:
11 (primitive-load-path "www" #)
In ice-9/eval.scm:
721:20 10 (primitive-eval (define-module (www) #:use-module (?) ?))
In ice-9/psyntax.scm:
1234:36 9 (expand-top-sequence ((define-module (www) # (www ?) ?)) ?)
1181:24 8 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
284:10 7 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) ?)
In ice-9/eval.scm:
293:34 6 (_ #)
In ice-9/boot-9.scm:
2866:4 5 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
2075:24 4 (call-with-deferred-observers #)
2879:24 3 (_)
230:17 2 (map1 (((www utils)) ((www shared)) ((www download)) # ?))
2795:6 1 (resolve-interface _ #:select _ #:hide _ #:prefix _ # _ ?)
In unknown file:
0 (scm-error misc-error #f "~A ~S" ("no code for modu?" ?) ?)
ERROR: In procedure scm-error:
ERROR: no code for module (www utils)
`/gnu/store/q5iy01hm75854mgh98zavxxqbzi72fql-guix-web-site/haunt.scm' ->
`./haunt.scm'
`/gnu/store/q5iy01hm75854mgh98zavxxqbzi72fql-guix-web-site/.gitignore' ->
`./.gitignore'
`/gnu/store/q5iy01hm75854mgh98zavxxqbzi72fql-guix-web-site/www.scm' ->
`./www.scm'
`/gnu/store/q5iy01hm75854mgh98zavxxqbzi72fql-guix-web-site/COPYING' ->
`./COPYING'
`/gnu/store/q5iy01hm75854mgh98zavxxqbzi72fql-guix-web-site/README' -> `./README'
`/gnu/store/q5iy01hm75854mgh98zavxxqbzi72fql-guix-web-site/guix.scm' ->
`./guix.scm'
builder for `/gnu/store/74wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv' failed to
produce output path `/gnu/store/hf1imhlb38vci2f9nxdljmx0msxg7661-gexp'
@ build-failed /gnu/store/74wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv - 1 builder
for `/gnu/store/74wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv' failed to produce
output path `/gnu/store/hf1imhlb38vci2f9nxdljmx0msxg7661-gexp'
derivation '/gnu/store/74wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv' offloaded to
'192.168.1.179' failed: build of
`/gnu/store/74wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv' failed
@ build-failed /gnu/store/74wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv - 1 builder
for `/gnu/store/74wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv' failed with exit
code 100
guix build: error: build failed: build of
`/gnu/store/74wjk41xpgmpinsrfq2fkxq0kf1yfajj-gexp.drv' failed
--
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org
signature.asc
Description: PGP signature
bug#27556: libpng has wrong hash. [Fwd: Re: why has the hash for libpng-apng 1.6.28 changed?]
ng0 transcribed 2.5K bytes: > Leo Famulari transcribed 2.2K bytes: > > On Sun, Jul 30, 2017 at 09:37:22AM +, ng0 wrote: > > > Efraim Flashner transcribed 4.1K bytes: > > > > On Wed, Jul 26, 2017 at 06:56:51AM +, ng0 wrote: > > > > > My really strong guess is that we never updated the hash for > > > > > libpng-apng when the libpng was updated fron which libpng-apng > > > > > inherits its version. > > > > [...] > > > > > > git blame shows that back in February I updated libpng to 1.6.28 from > > > > 1.6.25, but that the last time libpng-apng was touched was by ng0 back > > > > in January. > > > > > > > > commit: 864738baaa7bb75c08647ccfc684736479e67f7f > > > > Aha, that must be it! > > > > > Okay, so I will send the update for libpng-apng (which due to its > > > inheritance of libpng is just the hash) and I will also add a second > > > commit which adds a comment above libpng that we must update libpng-apng > > > when we update libpng, if that's already possible (libpng-apng might not > > > immediately be up to date, but we don't update libpng immediately aswell > > > due to it being a core-updates candidate). > > > > I think we should give libpng-apng its own version because, as you said, > > libpng-apng may not be developed at the same pace as libpng. This way, > > we won't end up with a broken libpng-apng again. I appended a patch how I understood your idea. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org From 4326cad38700df43909eb6f430217fdfa4eca89f Mon Sep 17 00:00:00 2001 From: ng0 Date: Tue, 1 Aug 2017 15:37:28 + Subject: [PATCH] gnu: libpng-apng: Update to 1.6.28. Fixes <https://bugs.gnu.org/27556>. * gnu/packages/image.scm (libpng-apng): Update to 1.6.28. Remove inherit of 'libpng'. (version): Use own version, remove 'package-version libpng'. (source): Add it. (arguments): Update hash of libpng-apng source. --- gnu/packages/image.scm | 32 ++-- 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm index 139be6281..3be675fc2 100644 --- a/gnu/packages/image.scm +++ b/gnu/packages/image.scm @@ -14,7 +14,7 @@ ;;; Copyright © 2016 Eric Bavier ;;; Copyright © 2016 Arun Isaac ;;; Copyright © 2016, 2017 Kei Kebreau -;;; Copyright © 2017 ng0 +;;; Copyright © 2017 ng0 ;;; Copyright © 2017 Hartmut Goebel ;;; ;;; This file is part of GNU Guix. @@ -91,11 +91,27 @@ library. It supports almost all PNG features and is extensible.") (license license:zlib) (home-page "http://www.libpng.org/pub/png/libpng.html";))) +;; libpng-apng could be not in sync with libpng, +;; reference bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27556 (define-public libpng-apng (package -(inherit libpng) (name "libpng-apng") -(version (package-version libpng)) +(version "1.6.28") +(source + (origin + (method url-fetch) + (uri (list (string-append "mirror://sourceforge/libpng/libpng16/" + version "/libpng-" version ".tar.xz") + (string-append + "ftp://ftp.simplesystems.org/pub/libpng/png/src"; + "/libpng16/libpng-" version ".tar.xz") + (string-append + "ftp://ftp.simplesystems.org/pub/libpng/png/src/history"; + "/libpng16/libpng-" version ".tar.xz"))) + (sha256 +(base32 + "0ylgyx93hnk38haqrh8prd3ax5ngzwvjqw5cxw7p9nxmwsfyrlyq" +(build-system gnu-build-system) (arguments `(#:phases (modify-phases %standard-phases @@ -111,7 +127,7 @@ library. It supports almost all PNG features and is extensible.") (and (apply-patch "the-patch") (for-each apply-patch (find-files "\\.patch" - #t)) + #t)) (add-before 'configure 'no-checks (lambda _ (substitute* "Makefile.in" @@ -126,15 +142,19 @@ library. It supports almost all PNG features and is extensible.") version "/libpng-" version "-apng.patch.gz")) (sha256 (base32 - "026r0gbkf6d6v54wca02cdxln8sj4m2c1yk62sj2aasv2ki2ffh5")) + "0m5nv70n9903x3xzxw9qqc6sgf2rp106ha0x6gix0xf8wcrljaab")) (nat
bug#27900: broken checkout? can't run autotools (automake) anymore in guix repository
Danny Milosavljevic transcribed 0.8K bytes: > Hi ng0, > > >guix environment --fallback --ad-hoc guix autoconf automake@1.15.1 > > make guile guile-ssh pkg-config gcc-toolchain libgcrypt gnutls guile-json > > zlib bzip2 sqlite help2man gettext texinfo guile-git > > I only ever do > > $ guix environment --fallback --pure guix > > (The "--pure" is important) Nice. This fixed my issue. My pure environment is not so pure because I'm having issues with bashrc and bash_profile at the moment (bash_profile isn't respecting some of my files which provide all the bash things I have), but it worked. > and it works fine, bootstrapping too (via ./bootstrap - which invokes > autoreconf). > > I mean I guess your ad-hoc-everything way should be possible, but why would > you do that? Well I only started using the guix environment subcommands recently and I am experimenting. --ad-hoc seemed logical to me, but as we use pure with guix, it already provides everything guix needs. So no reason to use adhoc. It makes the setup flaky should the guix package ever change its inputs (I don't know whether it did in fact do that). > > I do sometimes specify extra ad-hoc packages, like so: > > $ guix environment --fallback --pure guix --ad-hoc guile-ncurses-with-gpm > > The order of the arguments is sometimes important. I think of "--ad-hoc" > like "--" for many other UNIX commands (startx etc). > Okay, thanks for your help! -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27900: broken checkout? can't run autotools (automake) anymore in guix repository
Starting With one of the commits since yesterday evening I get this when I try to run ~/guix_dev clean OR ~/guix_dev enter and then "make". An excerpt from my guix_dev: clean) make clean-recursive ;; enter) guix environment --fallback --ad-hoc guix autoconf automake@1.15.1 make guile guile-ssh pkg-config gcc-toolchain libgcrypt gnutls guile-json zlib bzip2 sqlite help2man gettext texinfo guile-git ;; This happens with automake AND automake@1.15.1, yesterday it used to work as it is (without specifying automake 1.15.1). user@abyayala ~/src/guix/guix [env]$ ~/guix_dev clean cd . && /bin/sh /home/user/src/guix/guix/build-aux/missing automake-1.15 --gnu Makefile configure.ac:11: error: version mismatch. This is Automake 1.15.1, configure.ac:11: but the definition used by this AM_INIT_AUTOMAKE configure.ac:11: comes from Automake 1.15. You should recreate configure.ac:11: aclocal.m4 with aclocal and run automake again. configure.ac:23: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its use is discouraged. configure.ac:23: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead, configure.ac:23: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your Makefile.am files. Makefile.am:491: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS WARNING: 'automake-1.15' is probably too old. You should only need it if you modified 'Makefile.am' or 'configure.ac' or m4 files included by 'configure.ac'. The 'automake' program is part of the GNU Automake package: <http://www.gnu.org/software/automake> It also requires GNU Autoconf, GNU m4 and Perl in order to run: <http://www.gnu.org/software/autoconf> <http://www.gnu.org/software/m4/> <http://www.perl.org/> make: *** [Makefile:2956: Makefile.in] Error 63 So what am I supposed to do now? -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#26302: [website] translations
Ludovic Courtès transcribed 1.1K bytes: > Hi, > > ng0 skribis: > > > One thing I like about the template of https://taler.net is the usage of > > javascript free translations of text (jinja2 is used), easy to select > > and write. > > I think translations of web sites are useful, necessary and important. > > > > > > We must provide this in the long run on the Guix web site aswell. > > FWIW I agree. > > I wouldn’t want to use JS for that, though. > > It may be that the simplest solution would be to use Gettext since, > after all, the web site is a regular Scheme program. > > I would welcome work in this direction! > > Ludo’. I made some progress here, but only in theory and discussion. It might take some time until I can write it down, and my approach to websites and their translations might not be what we as Guix would want. I'll update this with more info, I'll basically intend to use my own project website as a testing ground for this with the version after the current work in progress version. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27556: libpng has wrong hash. [Fwd: Re: why has the hash for libpng-apng 1.6.28 changed?]
Leo Famulari transcribed 2.2K bytes: > On Sun, Jul 30, 2017 at 09:37:22AM +0000, ng0 wrote: > > Efraim Flashner transcribed 4.1K bytes: > > > On Wed, Jul 26, 2017 at 06:56:51AM +, ng0 wrote: > > > > My really strong guess is that we never updated the hash for > > > > libpng-apng when the libpng was updated fron which libpng-apng > > > > inherits its version. > > [...] > > > > git blame shows that back in February I updated libpng to 1.6.28 from > > > 1.6.25, but that the last time libpng-apng was touched was by ng0 back > > > in January. > > > > > > commit: 864738baaa7bb75c08647ccfc684736479e67f7f > > Aha, that must be it! > > > Okay, so I will send the update for libpng-apng (which due to its > > inheritance of libpng is just the hash) and I will also add a second > > commit which adds a comment above libpng that we must update libpng-apng > > when we update libpng, if that's already possible (libpng-apng might not > > immediately be up to date, but we don't update libpng immediately aswell > > due to it being a core-updates candidate). > > I think we should give libpng-apng its own version because, as you said, > libpng-apng may not be developed at the same pace as libpng. This way, > we won't end up with a broken libpng-apng again. I agree. Does someone of you want to make the patches and commits, or should I prepare and send some? -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27556: libpng has wrong hash. [Fwd: Re: why has the hash for libpng-apng 1.6.28 changed?]
Efraim Flashner transcribed 4.1K bytes:
> On Wed, Jul 26, 2017 at 06:56:51AM +0000, ng0 wrote:
> > Leo Famulari transcribed 2.3K bytes:
> > > On Sun, Jul 23, 2017 at 10:15:47AM +, ng0 wrote:
> > > > - Forwarded message -
> > > >
> > > > > Date: Sun, 23 Jul 2017 18:21:19 +0900 (JST)
> > > > > To: ng0
> > > > > Cc: daisu...@users.sourceforge.net
> > > > > Subject: Re: why has the hash for libpng-apng 1.6.28 changed?
> > > > >
> > > > > Hi,
> > > > >
> > > > > I calculated the hash for libpng-apng files on my local orignals.
> > > > >
> > > > > md5sum
> > > > > 9f2b36bccf89c5f4097111f0f73c1798 libpng-1.6.28-apng.patch.README.txt
> > > > > fca7c6d87c8352e645facefc2e1dd153 libpng-1.6.28-apng.patch.gz
> > > > >
> > > > > sha1sum
> > > > > cb620589ecf9c28a4ecc00e6225dd41ca660a959
> > > > > libpng-1.6.28-apng.patch.README.txt
> > > > > 4fa952f5ad374fce8d478b7e54ee4298a0b8d159 libpng-1.6.28-apng.patch.gz
> > > > >
> > > > > Local file time stamps are
> > > > > 2017-01-06 21:02:10.938833896 +0900
> > > > > libpng-1.6.28-apng.patch.README.txt
> > > > > 2017-01-06 21:02:10.938833896 +0900 libpng-1.6.28-apng.patch.gz
> > > > >
> > > > > That values equals on sourceforge.net.
> > > > > https://sourceforge.net/projects/libpng-apng/files/libpng16/1.6.28/
> > > > >
> > > > > I don't really understand what happend, but it look just fine.
> > > > >
> > > > > Cheers,
> > > > > ---
> > > > > daisu...@users.sourceforge.net
> > >
> > > Okay, this doesn't help us, so we need to inspect the different tarballs
> > > ourselves. Do you have an old copy of the patch you can share?
> >
> > Yes. I mean no. I am not sure. I have libpng-apng git checkout
> > and also the 1.6.25 extracted tarball directory (but not sure
> > when I got it), and the tarballs for 1.6.5 and 1.6.28.
> >
> > But I think I found our problem:
> >
> > user@shadownet ~/re-src$ guix hash tarballs/libpng-1.6.28-apng.patch.gz
> > 0m5nv70n9903x3xzxw9qqc6sgf2rp106ha0x6gix0xf8wcrljaab
> > user@shadownet ~/re-src$ guix hash tarballs/libpng-1.6.25-apng.patch.gz
> > 026r0gbkf6d6v54wca02cdxln8sj4m2c1yk62sj2aasv2ki2ffh5
> >
> > (inputs
> > `(("apng" ,(origin
> > (method url-fetch)
> > (uri
> > (string-append "mirror://sourceforge/libpng-apng/libpng16/"
> > version "/libpng-" version "-apng.patch.gz"))
> > (sha256
> > (base32
> > "026r0gbkf6d6v54wca02cdxln8sj4m2c1yk62sj2aasv2ki2ffh5"))
> >
> > My really strong guess is that we never updated the hash for
> > libpng-apng when the libpng was updated fron which libpng-apng
> > inherits its version.
> >
> > I don't have the time to look at our git history right now,
> > but you could do that, look at wether libpng-apng was touched
> > since 1.6.25->1.6.28 update of libpng.
> >
>
> git blame shows that back in February I updated libpng to 1.6.28 from
> 1.6.25, but that the last time libpng-apng was touched was by ng0 back
> in January.
>
> commit: 864738baaa7bb75c08647ccfc684736479e67f7f
Okay, so I will send the update for libpng-apng (which due to its
inheritance of libpng is just the hash) and I will also add a second
commit which adds a comment above libpng that we must update libpng-apng
when we update libpng, if that's already possible (libpng-apng might not
immediately be up to date, but we don't update libpng immediately aswell
due to it being a core-updates candidate).
>
> --
> Efraim Flashner אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted
--
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org
signature.asc
Description: PGP signature
bug#27862: tor-hidden-service should support IPv6
ng0 transcribed 1.3K bytes: > Right now the tor-hidden-service only supports IPv4 naming scheme, > while it is possible to define IPv6 for tor aswell. > > Someone should fix this. man tor: HIDDEN SERVICE OPTIONS The following options are used to configure a hidden service. … HiddenServicePort VIRTPORT [TARGET] Configure a virtual port VIRTPORT for a hidden service. You may use this option multiple times; each time applies to the service using the most recent HiddenServiceDir. By default, this option maps the virtual port to the same port on 127.0.0.1 over TCP. You may override the target port, address, or both by specifying a target of addr, port, addr:port, or unix:path. (You can specify an IPv6 target as [addr]:port. Unix paths may be quoted, and may use standard C escapes.) You may also have multiple lines with the same VIRTPORT: when a user connects to that VIRTPORT, one of the TARGETs from those lines will be chosen at random. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27862: tor-hidden-service should support IPv6
Right now the tor-hidden-service only supports IPv4 naming scheme, while it is possible to define IPv6 for tor aswell. Someone should fix this. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27861: python-graphene testsuite fails on x86_64
With the added 'python-pytest-3.0' dependency, the question for the dependency is solved (which is a current failure), afterwards you get to this one: phase `build' succeeded after 1.3 seconds starting phase `check' running "python setup.py" with command "test" and parameters () running test running egg_info writing top-level names to graphene.egg-info/top_level.txt writing graphene.egg-info/PKG-INFO writing requirements to graphene.egg-info/requires.txt writing dependency_links to graphene.egg-info/dependency_links.txt warning: manifest_maker: standard file '-c' not found reading manifest file 'graphene.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' warning: no previously-included files matching 'tests/*' found anywhere in distribution warning: no previously-included files matching '*' found under directory 'tests' warning: no previously-included files matching '*' found under directory 'tests_py35' warning: no previously-included files matching '*' found under directory 'examples' writing manifest file 'graphene.egg-info/SOURCES.txt' running build_ext = test session starts == platform linux -- Python 3.5.3, pytest-3.0.7, py-1.4.32, pluggy-0.4.0 rootdir: /tmp/guix-build-python-graphene-0.10.2.drv-0/graphene-0.10.2, inifile: plugins: django-3.1.2 collected 0 items = no tests ran in 0.03 seconds = phase `check' failed after 2.6 seconds builder for `/gnu/store/zkrdnmi2a5ashb863hdfpl0dxy5nhn4z-python-graphene-0.10.2.drv' failed with exit code 1 @ build-failed /gnu/store/zkrdnmi2a5ashb863hdfpl0dxy5nhn4z-python-graphene-0.10.2.drv - 1 builder for `/gnu/store/zkrdnmi2a5ashb863hdfpl0dxy5nhn4z-python-graphene-0.10.2.drv' failed with exit code 1 derivation '/gnu/store/zkrdnmi2a5ashb863hdfpl0dxy5nhn4z-python-graphene-0.10.2.drv' offloaded to '192.168.1.179' failed: build of `/gnu/store/zkrdnmi2a5ashb863hdfpl0dxy5nhn4z-python-graphene-0.10.2.drv' failed Some deprecated features have been used. Set the environment variable GUILE_WARN_DEPRECATED to "detailed" and rerun the program to get more information. Set it to "no" to suppress this message. @ build-failed /gnu/store/zkrdnmi2a5ashb863hdfpl0dxy5nhn4z-python-graphene-0.10.2.drv - 1 builder for `/gnu/store/zkrdnmi2a5ashb863hdfpl0dxy5nhn4z-python-graphene-0.10.2.drv' failed with exit code 100 guix build: error: build failed: build of `/gnu/store/zkrdnmi2a5ashb863hdfpl0dxy5nhn4z-python-graphene-0.10.2.drv' failed -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27556: libpng has wrong hash. [Fwd: Re: why has the hash for libpng-apng 1.6.28 changed?]
Leo Famulari transcribed 2.3K bytes:
> On Sun, Jul 23, 2017 at 10:15:47AM +0000, ng0 wrote:
> > - Forwarded message -
> >
> > > Date: Sun, 23 Jul 2017 18:21:19 +0900 (JST)
> > > To: ng0
> > > Cc: daisu...@users.sourceforge.net
> > > Subject: Re: why has the hash for libpng-apng 1.6.28 changed?
> > >
> > > Hi,
> > >
> > > I calculated the hash for libpng-apng files on my local orignals.
> > >
> > > md5sum
> > > 9f2b36bccf89c5f4097111f0f73c1798 libpng-1.6.28-apng.patch.README.txt
> > > fca7c6d87c8352e645facefc2e1dd153 libpng-1.6.28-apng.patch.gz
> > >
> > > sha1sum
> > > cb620589ecf9c28a4ecc00e6225dd41ca660a959
> > > libpng-1.6.28-apng.patch.README.txt
> > > 4fa952f5ad374fce8d478b7e54ee4298a0b8d159 libpng-1.6.28-apng.patch.gz
> > >
> > > Local file time stamps are
> > > 2017-01-06 21:02:10.938833896 +0900 libpng-1.6.28-apng.patch.README.txt
> > > 2017-01-06 21:02:10.938833896 +0900 libpng-1.6.28-apng.patch.gz
> > >
> > > That values equals on sourceforge.net.
> > > https://sourceforge.net/projects/libpng-apng/files/libpng16/1.6.28/
> > >
> > > I don't really understand what happend, but it look just fine.
> > >
> > > Cheers,
> > > ---
> > > daisu...@users.sourceforge.net
>
> Okay, this doesn't help us, so we need to inspect the different tarballs
> ourselves. Do you have an old copy of the patch you can share?
Yes. I mean no. I am not sure. I have libpng-apng git checkout
and also the 1.6.25 extracted tarball directory (but not sure
when I got it), and the tarballs for 1.6.5 and 1.6.28.
But I think I found our problem:
user@shadownet ~/re-src$ guix hash tarballs/libpng-1.6.28-apng.patch.gz
0m5nv70n9903x3xzxw9qqc6sgf2rp106ha0x6gix0xf8wcrljaab
user@shadownet ~/re-src$ guix hash tarballs/libpng-1.6.25-apng.patch.gz
026r0gbkf6d6v54wca02cdxln8sj4m2c1yk62sj2aasv2ki2ffh5
(inputs
`(("apng" ,(origin
(method url-fetch)
(uri
(string-append "mirror://sourceforge/libpng-apng/libpng16/"
version "/libpng-" version "-apng.patch.gz"))
(sha256
(base32
"026r0gbkf6d6v54wca02cdxln8sj4m2c1yk62sj2aasv2ki2ffh5"))
My really strong guess is that we never updated the hash for
libpng-apng when the libpng was updated fron which libpng-apng
inherits its version.
I don't have the time to look at our git history right now,
but you could do that, look at wether libpng-apng was touched
since 1.6.25->1.6.28 update of libpng.
user@shadownet ~/re-src$ ls -al *png* ; ls -al tarballs/*png*
libpng-1.6.25:
total 3416
drwxr-xr-x 8 user users 4096 Mar 24 14:51 ./
drwxr-xr-x 282 user users 12288 Jul 22 09:39 ../
-rw-r--r-- 1 user users 44739 Sep 1 2016 aclocal.m4
-rw-r--r-- 1 user users 1207 Sep 1 2016 ANNOUNCE
drwxr-xr-x 2 user users 4096 Mar 24 14:51 arm/
-rwxr-xr-x 1 user users 7979 Aug 3 2015 autogen.sh
-rw-r--r-- 1 user users 285838 Sep 1 2016 CHANGES
-rw-r--r-- 1 user users 30349 Sep 1 2016 CMakeLists.txt
-rwxr-xr-x 1 user users 7333 Feb 21 2015 compile
-rwxr-xr-x 1 user users 42938 Feb 21 2015 config.guess
-rw-r--r-- 1 user users 3307 Sep 1 2016 config.h.in
-rwxr-xr-x 1 user users 35987 Feb 21 2015 config.sub
-rwxr-xr-x 1 user users 477565 Sep 1 2016 configure
-rw-r--r-- 1 user users 14688 Sep 1 2016 configure.ac
drwxr-xr-x 15 user users 4096 Mar 24 14:51 contrib/
-rwxr-xr-x 1 user users 23566 Feb 21 2015 depcomp
-rw-r--r-- 1 user users 40303 Sep 1 2016 example.c
-rw-r--r-- 1 user users 17971 Sep 1 2016 INSTALL
-rwxr-xr-x 1 user users 14675 Feb 21 2015 install-sh
-rw-r--r-- 1 user users 270700 Sep 1 2016 libpng.3
-rw-r--r-- 1 user users 2396 Sep 1 2016 libpng-config.in
-rw-r--r-- 1 user users 228244 Sep 1 2016 libpng-manual.txt
-rw-r--r-- 1 user users293 Sep 1 2016 libpng.pc.in
-rw-r--r-- 1 user users764 Sep 1 2016 libpngpf.3
-rw-r--r-- 1 user users 4937 Sep 1 2016 LICENSE
-rw-r--r-- 1 user users 324089 Sep 1 2016 ltmain.sh
-rw-r--r-- 1 user users 13620 Sep 1 2016 Makefile.am
-rw-r--r-- 1 user users 89190 Sep 1 2016 Makefile.in
drwxr-xr-x 2 user users 4096 Mar 24 14:51 mips/
-rwxr-xr-x 1 user users 6872 Feb 21 2015 missing
-rw-r--r-- 1 user users 2432 Sep 1 2016 png.5
-rw-r--r-- 1 user users 2498 Jul 12 2000 pngbar.jpg
-rw-r--r-- 1 user users 2399 Jul 12 2000 pngbar.png
-rw-r--r-- 1 user users 155048 Sep 1 2016 png.c
-rw-r--r-- 1 user users 22842 Sep 1 2016 pngconf.h
-rw-r--r-- 1 user users 5368 Sep 1 2016 pngdebug.h
-rw-r--r-- 1 user users 29224 Sep 1 2016 pngerror.c
-rw-r--r-- 1 user users 33379 Sep 1 2016 pngget.c
-rw-r--r-- 1 u
bug#27556: libpng has wrong hash. [Fwd: Re: why has the hash for libpng-apng 1.6.28 changed?]
- Forwarded message - > Date: Sun, 23 Jul 2017 18:21:19 +0900 (JST) > To: ng0 > Cc: daisu...@users.sourceforge.net > Subject: Re: why has the hash for libpng-apng 1.6.28 changed? > > Hi, > > I calculated the hash for libpng-apng files on my local orignals. > > md5sum > 9f2b36bccf89c5f4097111f0f73c1798 libpng-1.6.28-apng.patch.README.txt > fca7c6d87c8352e645facefc2e1dd153 libpng-1.6.28-apng.patch.gz > > sha1sum > cb620589ecf9c28a4ecc00e6225dd41ca660a959 libpng-1.6.28-apng.patch.README.txt > 4fa952f5ad374fce8d478b7e54ee4298a0b8d159 libpng-1.6.28-apng.patch.gz > > Local file time stamps are > 2017-01-06 21:02:10.938833896 +0900 libpng-1.6.28-apng.patch.README.txt > 2017-01-06 21:02:10.938833896 +0900 libpng-1.6.28-apng.patch.gz > > That values equals on sourceforge.net. > https://sourceforge.net/projects/libpng-apng/files/libpng16/1.6.28/ > > I don't really understand what happend, but it look just fine. > > Cheers, > --- > daisu...@users.sourceforge.net > > > From: ng0 > Subject: why has the hash for libpng-apng 1.6.28 changed? > Date: Sat, 22 Jul 2017 09:06:28 + > Message-ID: <20170722090628.rvnmyvafhkgrnl7t@abyayala> > > ng0> Hi, > ng0> > ng0> I noticed that the hash for libpng-apng at the source changed, for > version 1.6.28. > ng0> > ng0> Can you tell me what happened? As libpng-apng is a recent addition in our > ng0> system (GNU Guix) I'm not yet aware of any bad or good practices or the > ng0> lack of them libpng-apng applies. > ng0> My current guess is that you changed the tarball in place, or that > ng0> Sourceforge changed it in place. We'll diff the tarball contents and see > ng0> what changed, but a maintainers reply will also be good. > ng0> > ng0> Greetings, > ng0> -- > ng0> ng0 > ng0> GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 > ng0> GnuPG: https://n0is.noblogs.org/my-keys > ng0> https://www.infotropique.org https://krosos.org > - End forwarded message - -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27556: Fix for bug#27556
ng0 transcribed 3.1K bytes: > Appended. I haven't asked upstream why it changed > all I know is that I am currently packaging software > which depends on this library and I'd like to drop > my local correction. I have sent an email to the upstream maintainer, asking why the hash has been changed in place. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27732: Changing display manager can render system unbootable
Marius Bakke transcribed 1.6K bytes: > Hello! > > When changing display manager in the system configuration and invoking > `guix system reconfigure`, the existing desktop environment will be > killed. If you invoked the command from within said desktop environment, > the reconfigure command will be forcefully terminated. > > If you're unlucky, this might happen during `grub-install`. After > logging in on a console and rebooting, this is what I got: > > --8<---cut here---start->8--- > Welcome to GRUB! > > Attempting to decrypt master key... > Enter passphrase for hd1,gpt2 (): > Slot 0 opened > error: file `/boot/grub/x86_64-efi/normal.mod' not found. > Entering rescue mode... > grub rescue> > --8<---cut here---end--->8--- > > It can be recovered by booting by copying /boot/grub/x86_64-efi/* from a > healthy system to the partially installed one. > > I'm not sure how to mitigate this, since the DE restart is arguably a > feature. A command analogous to `nixos-rebuild boot` might be of aid for > those of us aware of this problem. This is weird. I was aware of this and simply waited a reasonable long time until I forced a reboot from such a system. I've done this countless times in the past and it always worked. But the situation is unfortunate and a fix would be good. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27556: Fix for bug#27556
Appended. I haven't asked upstream why it changed
all I know is that I am currently packaging software
which depends on this library and I'd like to drop
my local correction.
--
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org
From 40764bb662ff7534f6e7afa55bfb709bfef19e49 Mon Sep 17 00:00:00 2001
From: ng0
Date: Wed, 12 Jul 2017 15:20:36 +
Subject: [PATCH] gnu: libpng-apng: Correct the hash.
Fixes <http://bugs.gnu.org/27556>.
* gnu/packages/image.scm (libpng-apng)[source]: Correct the hash.
---
gnu/packages/image.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
index 139be6281..3ae1072e2 100644
--- a/gnu/packages/image.scm
+++ b/gnu/packages/image.scm
@@ -14,7 +14,7 @@
;;; Copyright © 2016 Eric Bavier
;;; Copyright © 2016 Arun Isaac
;;; Copyright © 2016, 2017 Kei Kebreau
-;;; Copyright © 2017 ng0
+;;; Copyright © 2017 ng0
;;; Copyright © 2017 Hartmut Goebel
;;;
;;; This file is part of GNU Guix.
@@ -126,7 +126,7 @@ library. It supports almost all PNG features and is
extensible.")
version "/libpng-" version "-apng.patch.gz"))
(sha256
(base32
-
"026r0gbkf6d6v54wca02cdxln8sj4m2c1yk62sj2aasv2ki2ffh5"))
+
"0m5nv70n9903x3xzxw9qqc6sgf2rp106ha0x6gix0xf8wcrljaab"))
(native-inputs
`(("libtool" ,libtool)))
(synopsis "APNG patch for libpng")
--
2.13.2
signature.asc
Description: PGP signature
bug#27556: libpng has wrong hash.
Leo Famulari transcribed 2.9K bytes: > On Sun, Jul 02, 2017 at 08:13:44PM +0000, ng0 wrote: > > I don't know if they moved the file around, renamed it or > > whatever, but the hash is now > > "0m5nv70n9903x3xzxw9qqc6sgf2rp106ha0x6gix0xf8wcrljaab". > > We should use this in icecat as intended (I use it for > > firefox nightly I work on) so that these errors get > > attention. > > > > @ build-started > > /gnu/store/l2ajzgighkr23qhyrqzy3qm64gy7v75y-libpng-1.6.28-apng.patch.gz.drv > > - x86_64-linux > > /var/log/guix/drvs/l2//ajzgighkr23qhyrqzy3qm64gy7v75y-libpng-1.6.28-apng.patch.gz.drv.bz2 > > > > Starting download of > > /gnu/store/lsgx25nk7cg24hn6cn898jrkhs8aily3-libpng-1.6.28-apng.patch.gz > > From > > http://downloads.sourceforge.net/project/libpng-apng/libpng16/1.6.28/libpng-1.6.28-apng.patch.gz... > > following redirection to > > `https://netix.dl.sourceforge.net/project/libpng-apng/libpng16/1.6.28/libpng-1.6.28-apng.patch.gz'... > > ...-apng.patch.gz 11KiB 1.2MiB/s 00:00 [] > > 100.0% > > sha256 hash mismatch for output path > > `/gnu/store/lsgx25nk7cg24hn6cn898jrkhs8aily3-libpng-1.6.28-apng.patch.gz' > > expected: 026r0gbkf6d6v54wca02cdxln8sj4m2c1yk62sj2aasv2ki2ffh5 > > actual: 0m5nv70n9903x3xzxw9qqc6sgf2rp106ha0x6gix0xf8wcrljaab > > @ build-failed > > /gnu/store/l2ajzgighkr23qhyrqzy3qm64gy7v75y-libpng-1.6.28-apng.patch.gz.drv > > - 1 sha256 hash mismatch for output path > > `/gnu/store/lsgx25nk7cg24hn6cn898jrkhs8aily3-libpng-1.6.28-apng.patch.gz' > > expected: 026r0gbkf6d6v54wca02cdxln8sj4m2c1yk62sj2aasv2ki2ffh5 > > actual: 0m5nv70n9903x3xzxw9qqc6sgf2rp106ha0x6gix0xf8wcrljaab > > cannot build derivation > > `/gnu/store/x1dqpvyjz4v25z4al6kll6i3n3whv9h3-libpng-apng-1.6.28.drv': 1 > > dependencies couldn't be built > > guix build: error: build failed: build of > > `/gnu/store/x1dqpvyjz4v25z4al6kll6i3n3whv9h3-libpng-apng-1.6.28.drv' failed > > Clarification: This is libpng-apng, not libpng. Right, my mistake. It still is wrong, and that's been the case for at least 3 weeks. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27388: offloading: Add support for keyfile-less keys as used by GnuPG
ng0 transcribed 2.6K bytes: > ng0 transcribed 2.3K bytes: > > At the moment the field (private-key) in /etc/guix/machines.scm expects > > to be a file. > > When you use GnuPG authentication keys for ssh logins, you have no > > pubkey file, but you have a very long pubkey which can be used with > > ~/.ssh/authorized_keys and similar mechanisms. > > > > Example: > > > > user@abyayala ~/src/guix/guix$ cat /etc/guix/machines.scm > > (list (build-machine > > … > >(privat-key "ssh-rsa > > B3NzaC1yc2EDAQABAAACAQDgRM0G+Dnl/wlrHNb9sr3/yW9tHA8weIbwvfly/NRW6LHSLIPvsLksabVQsYbUH6i2aK2ZlE3Oo+H/R2wrs7dmVCo57O4MbZk8Kb0fatN3qhq6g/+bNobVIexS5XN6g5JcmXM4ZzR8Q0rEd46oaxFWy8nDSw4RR1d+OU5/Z/LHR1VUTCQKU0Q1Jv//4YFVq/BEf6oj4SU9+/Li9kUo9f++i4PaiWyrQDm1FAYtMGW5MBKH3ohO1dlPgqNjdeqTjZfgvCMPdbyV6Xwtz7KVkCR0+r9u7JefCCKUXL3Ap4VPtjhyCLoRuqJ+ZIp9XR2wf3rVGR6KRcLWPEXLkGfAPCs+7uAnfReBxNiWYt+FHuQpeyUld8u8E0G8u9FSf/l25A85QrQK0EUrVHdFc1q8tcCeq0EomoIPl7GnwtDIwYmkWtViCz0ivVRvNBUTXvq0XtI/9kLgcBgKfzap8dLeVSXJrUhYlbcOZNnstzkmut1ce8my5TwSRzr2dxgUF8563cM3cdLu+C9bdMWvR/s4xwu6Q5opbehdFHd2Hj/Lnqv+xwNKNFkhZCHiyum8L/VKQAsboXgJ7/sB7CHsEcBif73RWj3bFcMnPHHlJgxXB1aOH4kM+y6fF8wW/bGC/9gGiYXzovdbopv3B89oyuT73aoXg4TIPz6gv6Bg1OiGpfseGw== > > (none)") > > … > > Actually this might be the wrong approach. > > The key you see above is the public key equivalent to the ssh pubkey. > The private key is only in the GnuPG keyring. > > Solution for this kind of situations are welcome. For now I'll use > ssh pubkeys. > -- > ng0 > OpenPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 > https://krosos.org/~/ng0/ https://www.infotropique.org Ignore the second message in this thread. I tried to provide a possible solution which lead to the believe that this is considered solved. It isn't. This wishlist bug is still wanted. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27556: libpng has wrong hash.
I don't know if they moved the file around, renamed it or whatever, but the hash is now "0m5nv70n9903x3xzxw9qqc6sgf2rp106ha0x6gix0xf8wcrljaab". We should use this in icecat as intended (I use it for firefox nightly I work on) so that these errors get attention. @ build-started /gnu/store/l2ajzgighkr23qhyrqzy3qm64gy7v75y-libpng-1.6.28-apng.patch.gz.drv - x86_64-linux /var/log/guix/drvs/l2//ajzgighkr23qhyrqzy3qm64gy7v75y-libpng-1.6.28-apng.patch.gz.drv.bz2 Starting download of /gnu/store/lsgx25nk7cg24hn6cn898jrkhs8aily3-libpng-1.6.28-apng.patch.gz From http://downloads.sourceforge.net/project/libpng-apng/libpng16/1.6.28/libpng-1.6.28-apng.patch.gz... following redirection to `https://netix.dl.sourceforge.net/project/libpng-apng/libpng16/1.6.28/libpng-1.6.28-apng.patch.gz'... ...-apng.patch.gz 11KiB 1.2MiB/s 00:00 [] 100.0% sha256 hash mismatch for output path `/gnu/store/lsgx25nk7cg24hn6cn898jrkhs8aily3-libpng-1.6.28-apng.patch.gz' expected: 026r0gbkf6d6v54wca02cdxln8sj4m2c1yk62sj2aasv2ki2ffh5 actual: 0m5nv70n9903x3xzxw9qqc6sgf2rp106ha0x6gix0xf8wcrljaab @ build-failed /gnu/store/l2ajzgighkr23qhyrqzy3qm64gy7v75y-libpng-1.6.28-apng.patch.gz.drv - 1 sha256 hash mismatch for output path `/gnu/store/lsgx25nk7cg24hn6cn898jrkhs8aily3-libpng-1.6.28-apng.patch.gz' expected: 026r0gbkf6d6v54wca02cdxln8sj4m2c1yk62sj2aasv2ki2ffh5 actual: 0m5nv70n9903x3xzxw9qqc6sgf2rp106ha0x6gix0xf8wcrljaab cannot build derivation `/gnu/store/x1dqpvyjz4v25z4al6kll6i3n3whv9h3-libpng-apng-1.6.28.drv': 1 dependencies couldn't be built guix build: error: build failed: build of `/gnu/store/x1dqpvyjz4v25z4al6kll6i3n3whv9h3-libpng-apng-1.6.28.drv' failed -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
bug#27386: offloading documentation and env
Ludovic Courtès transcribed 2.2K bytes:
> ng0 skribis:
>
> > I think the method as described never really worked.
> >
> > When I do as you (and the manual) suggested, I no longer
> > have any results for ssh host env | grep "GUILE_".
> >
> > When I extend it like this it works. I include the full
> > paste to show that previously I had the sourcing of /etc/profile
> > in it:
> >
> > user@shadownet ~$ cat .bashrc
> > # Bash initialization for interactive non-login shells and
> > # for remote shells (info "(bash) Bash Startup Files").
> >
> > # Export 'SHELL' to child processes. Programs such as 'screen'
> > # honor it and otherwise use /bin/sh.
> > export SHELL
> >
> > if [ -n "$SSH_CLIENT" -a -z "`type -P cat`" ]
> > then
> > # We are being invoked from a non-interactive SSH session
> > # (as in "ssh host command") but 'cat' cannot be found
> > # in $PATH. Source /etc/profile so we get $PATH and other
> > # essential variables.
> > source /etc/profile
> > fi
> >
> > # Adjust the prompt depending on whether we're in 'guix environment'.
> > if [ -n "$GUIX_ENVIRONMENT" ]
> > then
> > PS1='\u@\h \w [env]\$ '
> > else
> > PS1='\u@\h \w\$ '
> > fi
> > source ~/.guix-profile/etc/profile
> > alias ls='ls -p --color'
> > alias ll='ls -l'
> > GUILE_LOAD_COMPILED_PATH="${GUILE_LOAD_COMPILED_PATH}:/run/current-system/profile/lib/guile/2.2/site-ccache:/run/current-system/profile/share/guile/site/2.2"
> > GUILE_LOAD_PATH="${GUILE_LOAD_PATH}:/run/current-system/profile/share/guile/site/2.2"
>
> The difference compared to /etc/skel/.bashrc is the last two lines,
> right?
Yes. And that I source ~/.guix-profile/etc/profile before those lines.
> On my GuixSD installation they’re not needed because /etc/profile
> sources /run/current-system/profile/etc/profile, which already defines
> these two variables.
Well this file is the same on both systems involved:
user@abyayala ~$ cat /etc/profile
# Crucial variables that could be missing in the profiles' 'etc/profile'
# because they would require combining both profiles.
# FIXME: See <http://bugs.gnu.org/20255>.
export
MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/man
export
INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
export XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share
export
XDG_CONFIG_DIRS=$HOME/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg
# Ignore the default value of 'PATH'.
unset PATH
# Load the system profile's settings.
GUIX_PROFILE=/run/current-system/profile \
. /run/current-system/profile/etc/profile
# Prepend setuid programs.
export PATH=/run/setuid-programs:$PATH
# Since 'lshd' does not use pam_env, /etc/environment must be explicitly
# loaded when someone logs in via SSH. See <http://bugs.gnu.org/22175>.
# We need 'PATH' to be defined here, for 'cat' and 'cut'. Do this before
# reading the user's 'etc/profile' to allow variables to be overridden.
if [ -f /etc/environment -a -n "$SSH_CLIENT" \
-a -z "$LINUX_MODULE_DIRECTORY" ]
then
. /etc/environment
export `cat /etc/environment | cut -d= -f1`
fi
if [ -f "$HOME/.guix-profile/etc/profile" ]
then
# Load the user profile's settings.
GUIX_PROFILE="$HOME/.guix-profile" \
. "$HOME/.guix-profile/etc/profile"
else
# At least define this one so that basic things just work
# when the user installs their first package.
export PATH="$HOME/.guix-profile/bin:$PATH"
fi
# Set the umask, notably for users logging in via 'lsh'.
# See <http://bugs.gnu.org/22650>.
umask 022
# Allow GStreamer-based applications to find plugins.
export GST_PLUGIN_PATH="$HOME/.guix-profile/lib/gstreamer-1.0"
if [ -n "$BASH_VERSION" -a -f /etc/bashrc ]
then
# Load Bash-specific initialization code.
. /etc/bashrc
fi
> But maybe your global profile is slightly different from mine, which
> would explain this. FWIW I have:
>
> --8<---cut here---start->8---
> $ guix package -I gui -p /run/current-system/profile
> guix 0.13.0-2.de9d8f0out
> /gnu/store/js4ml3w20ysh4znp9wl0da0ljji4kisl-guix-0.13.0-2.de9d8f0
> guile 2.2.2 out /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2
> --8<---cut here---end--->8---
user@shadownet ~$ guix package -I gui -p /run/current-system/profile
guix0.13.0-2.de9d8f0out
/gnu/store/nrd0v38d61l8y16vqkb1gws0bw45q885-guix-0.13.0-2.de9d8f0
guile 2.2.2 out /gnu/store/1pzfigry5bnh3n146w0ib77vkd2g6jdc-guile-2.2.2
So it is not different.
The system in use is this:
https://gitlab.com/ng0/systems/blob/master/servers/pragmatique/shadownet.scm
> Anyway, if you have ideas on how to improve the doc, they’re welcome.
>
> Thanks for your feedback!
>
> Ludo’.
--
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
infotropique: https://www.infotropique.org
signature.asc
Description: PGP signature
bug#26443: vim-full 8.0.0494 and above fails its testsuite
ng0 transcribed 2.7K bytes: > Currently vim-full in version 8.0.0494 is failing its testsuite: … We are able to build vim-full again. Closing. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys infotropique: https://www.infotropique.org signature.asc Description: PGP signature
bug#27386: offloading documentation and env
Ludovic Courtès transcribed 1.8K bytes:
> ng0 skribis:
>
> > Ludovic Courtès transcribed 2.2K bytes:
> >> ng0 skribis:
> >>
> >> > Ludovic Courtès transcribed 2.8K bytes:
>
> [...]
>
> >> The problem here is that
> >> /run/current-system/profile/share/guile/site/2.2, which is where the
> >> Guix modules are on GuixSD as I wrote above, is missing from the search
> >> path.
> >>
> >> The session started when you run “ssh shadownet env” does not spawn a
> >> login shell; thus ~/.profile and similar are *not* sourced. I’m using
> >
> > I was aware of this, but I thought we had (guix) available nevertheless
> > and I was just pushing the wrong buttons.
> >
> >> Bash, so on my accounts, I have this in .bashrc (‘.bashrc’ is for
> >> non-login shells):
> >>
> >> --8<---cut here---start->8---
> >> if [ -n "$SSH_CLIENT" -a -z "`type -P cat`" ]
> >> then
> >> # We are being invoked from a non-interactive SSH session
> >> # (as in "ssh host command") but 'cat' cannot be found
> >> # in $PATH. Source /etc/profile so we get $PATH and other
> >> # essential variables.
> >> source /etc/profile
> >> fi
> >> --8<---cut here---end--->8---
> >>
> >> That way, “ssh HOST COMMAND” effectively gets the same environment as a
> >> login shell.
> >
> > I use the same on this computer, but at the end of it I source some
> > files, among them ~/.guix-profile/etc/profile
> >
> > I would guess that sourcing ~/.guix-profile/etc/profile gets into
> > the way and that moving this to .bash_profile could fix the issue.
> >
> > What do you think?
>
> ~/.guix-profile/etc/profile won't add /run/current-system/… to the
> search path. You really need to source /etc/profile, which in turn will
> source ~/.guix-profile/etc/profile (on GuixSD).
>
> HTH,
> Ludo’.
I think the method as described never really worked.
When I do as you (and the manual) suggested, I no longer
have any results for ssh host env | grep "GUILE_".
When I extend it like this it works. I include the full
paste to show that previously I had the sourcing of /etc/profile
in it:
user@shadownet ~$ cat .bashrc
# Bash initialization for interactive non-login shells and
# for remote shells (info "(bash) Bash Startup Files").
# Export 'SHELL' to child processes. Programs such as 'screen'
# honor it and otherwise use /bin/sh.
export SHELL
if [ -n "$SSH_CLIENT" -a -z "`type -P cat`" ]
then
# We are being invoked from a non-interactive SSH session
# (as in "ssh host command") but 'cat' cannot be found
# in $PATH. Source /etc/profile so we get $PATH and other
# essential variables.
source /etc/profile
fi
# Adjust the prompt depending on whether we're in 'guix environment'.
if [ -n "$GUIX_ENVIRONMENT" ]
then
PS1='\u@\h \w [env]\$ '
else
PS1='\u@\h \w\$ '
fi
source ~/.guix-profile/etc/profile
alias ls='ls -p --color'
alias ll='ls -l'
GUILE_LOAD_COMPILED_PATH="${GUILE_LOAD_COMPILED_PATH}:/run/current-system/profile/lib/guile/2.2/site-ccache:/run/current-system/profile/share/guile/site/2.2"
GUILE_LOAD_PATH="${GUILE_LOAD_PATH}:/run/current-system/profile/share/guile/site/2.2"
I suggest that we fix the offloading documentation.
If questions are asked (I'm not the first) there are obviously problems
with how it is written.
If no one else takes on this, I will.
--
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
infotropique: https://www.infotropique.org
signature.asc
Description: PGP signature
bug#27386: offloading documentation and env
Ludovic Courtès transcribed 2.2K bytes: > ng0 skribis: > > > Ludovic Courtès transcribed 2.8K bytes: > > [...] > > >> >> The test is to run something like: > >> >> > >> >> $ ssh localhost env |grep GUILE_ > >> >> > >> >> GUILE_LOAD_COMPILED_PATH=/home/ludo/.guix-profile/lib/guile/2.2/site-ccache:/home/ludo/.guix-profile/share/guile/site/2.2:/run/current-system/profile/lib/guile/2.2/site-ccache:/run/current-system/profile/share/guile/site/2.2 > >> >> > >> >> GUILE_LOAD_PATH=/home/ludo/.guix-profile/share/guile/site/2.2:/run/current-system/profile/share/guile/site/2.2 > >> >> > >> >> and you should see /run/current-system/profile/share/guile/site/2.2. If > >> >> not, you’ll have to add it somehow. > >> > >> What does the above give for you? > >> > >> HTH, > >> Ludo’. > > > > This is issued from computer A (abyayala) to computer B (shadownet). > > > > user@abyayala ~$ ssh shadownet env |grep GUILE_ > > GUILE_LOAD_COMPILED_PATH=/gnu/store/m91mxi586pi2qshzys9zfsmzij8nf547-profile/lib/guile/2.2/site-ccache:/gnu/store/m91mxi586pi2qshzys9zfsmzij8nf547-profile/share/guile/site/2.2 > > GUILE_LOAD_PATH=/gnu/store/m91mxi586pi2qshzys9zfsmzij8nf547-profile/share/guile/site/2.2 > > The problem here is that > /run/current-system/profile/share/guile/site/2.2, which is where the > Guix modules are on GuixSD as I wrote above, is missing from the search > path. > > The session started when you run “ssh shadownet env” does not spawn a > login shell; thus ~/.profile and similar are *not* sourced. I’m using I was aware of this, but I thought we had (guix) available nevertheless and I was just pushing the wrong buttons. > Bash, so on my accounts, I have this in .bashrc (‘.bashrc’ is for > non-login shells): > > --8<---cut here---start->8--- > if [ -n "$SSH_CLIENT" -a -z "`type -P cat`" ] > then > # We are being invoked from a non-interactive SSH session > # (as in "ssh host command") but 'cat' cannot be found > # in $PATH. Source /etc/profile so we get $PATH and other > # essential variables. > source /etc/profile > fi > --8<---cut here---end--->8--- > > That way, “ssh HOST COMMAND” effectively gets the same environment as a > login shell. I use the same on this computer, but at the end of it I source some files, among them ~/.guix-profile/etc/profile I would guess that sourcing ~/.guix-profile/etc/profile gets into the way and that moving this to .bash_profile could fix the issue. What do you think? > If you’re using a different shell, then make sure its startup file does > something similar. > > HTH! > > Ludo’. > > > > -- ng0 OpenPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 infotropique: https://www.infotropique.org personal: https://ng-0.github.io https://krosos.org/ signature.asc Description: PGP signature
