bug#33497: [PATCH] Re: bug#33497: Our CMake package has no documentation

Marius Bakke writes: > Maxim Cournoyer writes: [...] >>> I'm not very comfortable with pulling python-sphinx into the dependency >>> closure of CMake, because then we can't update it or its dependencies >>> outside of the 'core-updates' c

bug#33497: [PATCHv2] Re: bug#33497: Our CMake package has no documentation

Here's an improved version, following some comments of Marius on #guix. From 2f33a7321e5e37d37f57c229c8079cb4ffd10834 Mon Sep 17 00:00:00 2001 From: Maxim Cournoyer Date: Wed, 20 Mar 2019 21:38:19 -0400 Subject: [PATCH] cmake: Generate documentation. To prevent complicating the dependenci

bug#34934: deeptools is not reproducible

On current master (commit af184b68e78aa51b6ff50b7327dfbbdb1d6e6843), deeptools does not build reproducibly: $ guix build --check --no-grafts deeptools --8<---cut here---start->8--- ... guix build: error: derivation `/gnu/store/hky07zjsvai0x3n99lqmgyh6rhld6v4s-

bug#34935: nanopolish is not reproducible

$ guix build --check --no-grafts nanopolish [...] guix build: error: derivation `/gnu/store/7hzcmcwlw83f0wsqmz9nnl1ah54kwks4-nanopolish-0.10.2-1.50e8b5c.drv' may not be deterministic: output `/gnu/store/m7icaq7642zy0gvnqvymcnn8d088a9s0-nanopolish-0.10.2-1.50e8b5c' differs $ diffoscope "$(guix

bug#33497: [PATCHv2] Re: bug#33497: Our CMake package has no documentation

Marius Bakke writes: > Maxim Cournoyer writes: > >> Here's an improved version, following some comments of Marius on #guix. >> >> From 2f33a7321e5e37d37f57c229c8079cb4ffd10834 Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer >> Date: Wed, 20 Mar 2019

bug#31142: guix package --upgrade reverses the order of packages

On March 28, 2019 12:49:04 PM UTC, "Ludovic Courtès" wrote: >Hello, > >Pierre Neidhardt skribis: > >> This issue fixes the list order, but it was initially supposed to >address >> https://lists.gnu.org/archive/html/help-guix/2018-04/msg00070.html. >> >> In the linked conversation, the issue th

bug#34934: deeptools is not reproducible

Hello Ludovic! Ludovic Courtès writes: > Hi Gábor, > > Gábor Boskovits skribis: > >> Ludovic Courtès ezt írta (időpont: 2019. márc. 23., Szo, >> 18:01): >>> >>> Hi, >>> >>> Maxim Cournoyer skribis: >>> >>> >

bug#34266: pypi importer cannot handle [ and ] correctly

swedebugia writes: > $ ./pre-inst-env guix import pypi beaker > > following redirection to `https://pypi.org/pypi/Beaker/json'... > > Starting download of /tmp/guix-file.p15GJZ > From > https://files.pythonhosted.org/packages/c2/21/b052b2fbfee3def06670923d5d34b0d353d4c278013e4a714c3fb663f150/Beak

bug#24450: bug#33569: Missing sanitizing of '[]' in pypi-importer

swedebugia writes: > E.g. > sdb@komputilo ~/guix-tree$ ~/guix-tree/pre-inst-env guix import pypi > snakemake > ... > (propagated-inputs > `(("python-[reports]" >,#{python-\x5b;reports\x5d;}#) > ("python-appdirs" ,python-appdirs) > ... This one now gives (local branch): --8<-

bug#24450: [PATCH] bug#24450: pypi importer outputs strange character series in optional dependency case.

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" The following patches fix this, and more!

bug#24450: pypi importer outputs strange character series in optional dependency case.

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) >

bug#24450: bug#33047: pypi importer uses incorrect package names

Julien Lepiller writes: > Hi, > > I found that sometimes the pypi importer had trouble importing > packages correctly. For instance, running "guix import pypi txaio" > gave me this list of dependencies: > > (propagated-inputs > `(("python-[all]" ,#{python-\x5b;all\x5d;}#) >("python-[asyncio]

bug#24450: [PATCH] bug#24450: pypi importer outputs strange character series in optional dependency case.

useful, as some packages such as robotframework-sshlibrary use a "src" directory in their hierarchy which would cause the previous scheme to not find requires.txt. From cfde6e09f8f8c692fe252d76ed27e8c50a9e5377 Mon Sep 17 00:00:00 2001 From: Maxim Cournoyer Date: Sat, 30 Mar 2019 23:13:26 -040

bug#33046: pypi importer doesn't print the correct source

hon-wrapt" ,python-wrapt))) (native-inputs `(("python-bumpversion" ,python-bumpversion) ("python-pytest" ,python-pytest) ("python-pytest-cov" ,python-pytest-cov) ("python-sphinx" ,python-sphinx) ("python-tox" ,python

bug#33046: [PATCH v2] bug#33046: pypi importer doesn't print the correct source

Hello, I just noticed that by changing the PyPI URL, the PyPI updater coverage had gone from 15.3% to 0%! Luckily, the fix was trivial and is included in my v2 patch (attached). From 3c9c4229c460b6fdf0da804dddcd3d2cdd3aec4b Mon Sep 17 00:00:00 2001 From: Maxim Cournoyer Date: Sat, 30 Mar 2019

bug#35084: Mesa is not reproducible (tested on staging)

Hello, Mesa doesn't build reproducibly. The diffoscope log is attached. Here's an excerpt: --8<---cut here---start->8--- │ │ ├── kms_swrast_dri.so │ │ │ ├── /gnu/store/02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1/bin/readelf --wide --dynamic {} │ │ │ │ @@

bug#35085: Emacs is not reproducible

Found on the latest staging branch. The diffoscope log produced by: --8<---cut here---start->8--- diffoscope --exclude-command '/gnu/store/.*/bin/stat' --text=emacs.diffoscope /gnu/store/cjmgl8820dhxb400q9zv90b1a1z0px14-emacs-26.1{,-check} --8<---cu

bug#35112: python-cffi is not reproducible

Hello, python-cffi cannot be built reproducibly, with the following difference reported by diffoscope: --8<---cut here---start->8--- │ │ │ │ ├── SOURCES.txt │ │ │ │ │ @@ -137,39 +137,39 @@ │ │ │ │ │ testing/cffi0/__pycache__/_cffi__g123c155excff53609.c │ │ │ │

bug#35311: Python 2 test failures: test_httplib test_urllib2_localnet

Building 'python2' on the core-updates branch, I've seen these two test failures (non-deterministic), although the first one comes up quite steadily on my system: --8<---cut here---start->8--- ;; This buffer is for text that is not saved, and for Lisp evaluation

bug#30109: [PATCH] gnu: shishi: Make shishi keys and database administrator-modifiable.

Hello Danny! Danny Milosavljevic writes: > Fixes . > > * gnu/packages/kerberos.scm (shishi)[arguments]<#:configure-flags>: > Add --with-key-dir, --with-db-dir. > <#:phases>[disable-automatic-key-generation]: New phase. > --- > gnu/packages/kerberos.scm | 21 +

bug#35317: [core-updates] glib is not reproducible

The interesting bits from the diffoscope output has to do with teh file codegen_docbook.cpython-37.pyc: --8<---cut here---start->8--- │ │ │ │ ├── codegen_docbook.cpython-37.pyc │ │ │ │ │┄ xxd not available in path. Falling back to Python hexlify. │ │ │ │ │ @@ -

bug#35311: Python 2 test failures: test_httplib test_urllib2_localnet

Ludovic Courtès writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> Building 'python2' on the core-updates branch, I've seen these two test >> failures (non-deterministic), although the first one comes up quite >> steadily on my system: >

bug#35371: [core-updates] python-cffi fails its test suite

It seems that something in Guix confuses the python-cffi code logic and makes it "think" the platform should be 'win32', while it is 'linux'. The errors output is copied below: --8<---cut here---start->8--- === FAILURES =

bug#35556: Status: [core-updates] python test suite fails on "test_asyncio"

Fixed with commit a5e9413ce8.

bug#35569: [core-updates] bison is not reproducible

It seems that the static library archive 'liby.a' contains build time timestamps: --8<---cut here---start->8--- diffoscope --exclude-command bin/stat /gnu/store/aqcpvkx93zbf1zr46qi5h1yf6a1cj9i1-bison-3.3.2{,-check} --- /gnu/store/aqcpvkx93zbf1zr46qi5h1yf6a1cj9

bug#35371: [core-updates] python-cffi fails its test suite

Maxim Cournoyer writes: [...] > _ test_dlopen > __ > > def test_dlopen(): > ffi = FFI() > ffi.cdef("double sin(double x);") >> m = ffi.dlopen(lib_m)

bug#35573: containerd is not reproducible

On the master branch: --8<---cut here---start->8--- diffoscope --exclude-command=bin/stat /gnu/store/hvjq3730myw4bz1prha0sy1iasjs92zb-containerd-1.2.5{,-check} --- /gnu/store/hvjq3730myw4bz1prha0sy1iasjs92zb-containerd-1.2.5 +++ /gnu/store/hvjq3730myw4bz1prha0s

bug#35603: Go build system mishandles repetitive import paths (was [PATCH] build: go-build-system: Ensure uniform unpacking directory.)

Hello Leo, Leo Famulari writes: > On Sun, Apr 14, 2019 at 12:03:05AM -0400, Maxim Cournoyer wrote: >> From 1f7535fbe28f7ac96e824b792e9f1a140b8c54cd Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer >> Date: Fri, 5 Apr 2019 00:00:08 -0400 >> Subject: [PATCH 3/3] bui

bug#35603: Go build system mishandles repetitive import paths

Hello again, Leo Famulari writes: > Looks like it affects packages that use tarballs (instead of Git > checkouts) and have a repetitive element in the import path. For > example, 'github.com/restic/restic' is also broken. I've fixed restic with commit fb09818277; sorry! Maxim

bug#35615: go-github-com-getsentry-raven-go build fails

On current master: --8<---cut here---start->8--- starting phase `check' go: disabling cache (/homeless-shelter/.cache/go-build) due to initialization failure: mkdir /homeless-shelter: permission denied # github.com/getsentry/raven-go src/github.com/getsentry/ra

bug#35616: go-github-com-spf13-pflag build fails

On master: --8<---cut here---start->8--- starting phase `check' go: disabling cache (/homeless-shelter/.cache/go-build) due to initialization failure: mkdir /homeless-shelter: permission denied # github.com/spf13/pflag src/github.com/spf13/pflag/bool_test.go:17

bug#35701: guix size should account for hard links in its disk space calculation

Consider the following operating system declaration: robot-framework-system.scm Description: Binary data $ guix size `guix system build robot-framework-system.scm` gives: store item totalself /gnu/store/f9fy1b2yf1qxy523732r7z34ymwqz64b

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

I took my time, but finally got around to restructure the changes a bit. I hope it'll be easier to review this time around! Thank you! Maxim From 54e44b7397f17910d95dbdb233d23e5c97c095aa Mon Sep 17 00:00:00 2001 From: Maxim Cournoyer Date: Thu, 28 Mar 2019 00:26:00 -0400 Subject: [PATCH

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

Greetings! Ludovic Courtès writes: > Hello! > > Maxim Cournoyer skribis: > >> Ricardo Wurmus writes: >> >>> Hi Maxim, >>> >>> I would very much like to see your improvements to the pypi importer to >>> be merged. Have you been able

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

Hello Ricardo! Ricardo Wurmus writes: > And finally: Number 9! > >> From 1290f9d1f0d594fdd4723d76b94116be25da9dd5 Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer >> Date: Sat, 30 Mar 2019 20:27:35 -0400 >> Subject: [PATCH 9/9] import: pypi: Preserve package n

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

Hello Ricardo! Ricardo Wurmus writes: > Hi Maxim, > >> Subject: [PATCH 1/9] import: pypi: Do not consider requirements.txt files. >> >> * guix/import/pypi.scm (guess-requirements): Update comment. >> [guess-requirements-from-source]: Do not attempt to parse the file >> requirements.txt. Streaml

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

Hello again! Ricardo Wurmus writes: > Hi Maxim, > > on to patch number 2! Yay! >> From 5f79b0502f62bd1dacc8ea143c1dbd9ef7cfc29d Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer >> Date: Thu, 28 Mar 2019 00:26:00 -0400 >> Subject: [PATCH 2/9] import: pypi: D

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

Hello! Ricardo Wurmus writes: > Patch number 3! Yay! >> From 0c62b541a3e8925b5ca31fe55dbe7536cf95151f Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer >> Date: Thu, 28 Mar 2019 00:26:01 -0400 >> Subject: [PATCH 3/9] import: pypi: Improve parsing of requirement &g

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

Hello again! Ricardo Wurmus writes: > On to the next: > >> From 73e27235cac1275ba7671fd2364325cf5788cb3c Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer >> Date: Thu, 28 Mar 2019 00:26:02 -0400 >> Subject: [PATCH 5/9] import: pypi: Support more types of archi

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

Hello! Ricardo Wurmus writes: > Patch number 6: > >> From fb0547ef225103c0f8355a7eccc41e0d028f6563 Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer >> Date: Thu, 28 Mar 2019 00:26:03 -0400 >> Subject: [PATCH 6/9] import: pypi: Parse wheel METADATA instead of >

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

Ricardo Wurmus writes: > Next up: Seven of Nine, tertiary adjunct of unimatrix zero one: Ehe! I had to look up the reference; I'm not much of a Star Trek fan obviously :-P. >> From 37e499d5d5d5f690aa0a065c730e13f6a31dd30d Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

Hello Ricardo! Ricardo Wurmus writes: >> From cfde6e09f8f8c692fe252d76ed27e8c50a9e5377 Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer >> Date: Sat, 30 Mar 2019 23:13:26 -0400 >> Subject: [PATCH 8/9] import: pypi: Scan source archive to find requires.txt >> fil

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

Ricardo Wurmus writes: > And finally: Number 9! Yay! >> From 1290f9d1f0d594fdd4723d76b94116be25da9dd5 Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer >> Date: Sat, 30 Mar 2019 20:27:35 -0400 >> Subject: [PATCH 9/9] import: pypi: Preserve package name cas

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

Hi again, Ricardo Wurmus writes: > Maxim Cournoyer writes: > >> While I agree that a regexp is a bigger hammer than basic string >> manipulation, I see some merit to it here: >> >> 1) We can be assured of conformance with upstream, again, per PEP-0508. >>

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

Hello! Continued feedback about your much appreciated comments! :-) Ricardo Wurmus writes: > Maxim Cournoyer writes: > >>>> + ;; (extra) requirements. Non-optional requirements must appear >>>> + ;; before any section is defined. >>>

bug#24450: [PATCHv2] Re: pypi importer outputs strange character series in optional dependency case.

Hey Ricardo :-) Ricardo Wurmus writes: > Hi Maxim, > (call-with-input-file requires.txt (lambda (port) - (let loop ((result '())) + (let loop ((required-deps '()) + (test-deps '()) + (inside-test-section? #f) +

bug#24450: [PATCHv3] Re: pypi importer outputs strange character series in optional dependency case.

Here's the current patch set, version 3, with the modifications as discussed in the previous exchanges: From 215d0bde103e7e8df0d1d1df81965e973f38783a Mon Sep 17 00:00:00 2001 From: Maxim Cournoyer Date: Thu, 28 Mar 2019 00:26:00 -0400 Subject: [PATCH 01/12] import: pypi: Do not con

bug#24450: pypi importer outputs strange character series in optional dependency case.

Hey ng0! ng0 writes: > Hi Maxim, > > great to see this fixed. Weird it bumped into my view after > almost 3 years. Yes! Bugs don't really expire, do they? :-) > I trust that other people will have tested > it, I'm all over the place and mostly doing NetBSD and GNUnet > now. I'm glad to know y

bug#33046: Status: pypi importer doesn't print the correct source

Fixed per commit 4b60ab8c006964d026dee8cf5f1260eba0b2bb81. Closing. Thanks! Maxim

bug#24450: [PATCHv3] Re: pypi importer outputs strange character series in optional dependency case.

Maxim Cournoyer writes: > Here's the current patch set, version 3, with the modifications > as discussed in the previous exchanges [...] I've now merged this patch series (version 3) into master, with top commit 4b60ab8c006964d026dee8cf5f1260eba0b2bb81. Closing. Thank you! Maxim

bug#37162: ‘guix pack -f docker’ creates an image without /etc/passwd

Hi Ludovic, Ludovic Courtès writes: > ‘guix pack -f docker’ currently creates an image without > /etc/{passwd,group,shadow}. > > It’s OK most of the time, but again it looks like a gratuitous annoyance > for those cases where having them around matters (that’s also the reason > why guix-daemon c

bug#37162: ‘guix pack -f docker’ creates an image without /etc/passwd

Hello Ricardo, Ricardo Wurmus writes: > Hi Maxim, > >> Ludovic Courtès writes: >> >>> ‘guix pack -f docker’ currently creates an image without >>> /etc/{passwd,group,shadow}. >>> >>> It’s OK most of the time, but again it looks like a gratuitous annoyance >>> for those cases where having them a

bug#37071: guix import pypi httpie fails

Hello, Ludovic Courtès writes: > Hi, > > Robert Vollmert skribis: > >> $ guix import pypi httpie >> …0.2.tar.gz 83KiB 291KiB/s 00:00 [##] >> 100.0% >> ….py3-none-any.whl 58KiB201KiB/s 00:00 [##] >> 100.0% >> guix import: warnin

bug#37162: ‘guix pack -f docker’ creates an image without /etc/passwd

Hello! Sorry for the late reply. Ludovic Courtès writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> Ricardo Wurmus writes: >> >>> Hi Maxim, >>> >>>> Ludovic Courtès writes: >>>> >>>>> ‘guix p

bug#37300: Imported packages' indentation doesn't respect Guix conventions

The package definitions imported by Guix importers do not respect Guix conventions regarding indentation. Consider: guix pypi import transaction (package (name "python-transaction") (version "2.4.0") (source (origin (method url-fetch) (uri (pypi-uri "transaction" version))

bug#33517: Problem booting when using btrfs subvolume for /gnu/store

Hello, "Svante v. Erichsen" writes: > The subvolume and the mount point are independent issues. > > For example, I have a subvolume named @ as root volume: > > (file-system > (device "/dev/mapper/hd") > (mount-point "/") > (type "btrfs") > (options "compress=lzo,ssd,subvol=@")) > > It al

bug#37318: OpenNTPD generated config is convoluted

For the documented following openntpd-service-type definition: --8<---cut here---start->8--- (openntpd-configuration (listen-on '("127.0.0.1" "::1")) (sensor '("udcf0 correction 7")) (constraint-from '("www.gnu.org"))

bug#37318: OpenNTPD generated config is convoluted

I also can't seem to make it sync, see my test below. Tests: # Set the date to somewhere in the past sudo date -s 'Tue Sep 3 12:00:00 JST 2019' # Set the hwclock to the same wrong date sudo hwclock --systohc Then I launched (open)ntpd manually in verbose mode: sudo /gnu/store/j4abi03pc4b0gfs2

bug#37318: OpenNTPD generated config is convoluted

The problem of OpenNTPD not syncing was caused by the use of constraint directives; ntpd would print the message (when run in debug mode with the -v option): --8<---cut here---start->8--- constraint: failed to load constraint ca --8<---cut here--

bug#37318: [PATCH] OpenNTPD generated config is convoluted

: Maxim Cournoyer Date: Fri, 6 Sep 2019 18:52:51 +0900 Subject: [PATCH 1/4] gnu: openntpd: Fix error CA errors when using constraints. The error printed by nttpd was "constraint: failed to load constraint ca" when libressl tried loading the file /etc/ssl/cert.pem. The problem was investigat

bug#37318: [PATCH] OpenNTPD generated config is convoluted

Hello, Efraim Flashner writes: > On Sat, Sep 07, 2019 at 01:21:27PM +0900, Maxim Cournoyer wrote: >> Hello, >> >> The attached patches fix this issue as well as the openntpd package not >> being able to load the CA cert used to authenticate constraint servers. &

bug#37373: python-ipython-documentation build is not reproducible

Here's the diff produced by diffoscope: --- /gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0 +++ /gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-ipython-documentation-7.5.0-check ├── share │ ├── doc │ │ ├── python-ipython-documentation-7.5.0 │ │ │ ├── html │ │ │

bug#37376: python-rpy2 is not reproducible [awaiting fix from core-updates]

See the output of diffoscope below: diffoscope --exclude-command stat /gnu/store/lvmrrr9a5hr0xj26snygszlmgrdv6nma-python-rpy2-3.0.4-1.19868a8{,-check} --- /gnu/store/lvmrrr9a5hr0xj26snygszlmgrdv6nma-python-rpy2-3.0.4-1.19868a8 +++ /gnu/store/lvmrrr9a5hr0xj26snygszlmgrdv6nma-python-rpy2-3.0.4-1.1

bug#37089: texlive-union includes log files with timestamps

Here's an actual example of the problem: diffoscope --exclude-command stat /gnu/store/igc79crx5ya5vwyzkd2l95nlpbk647in-texlive-union-49435{,-check} --- /gnu/store/igc79crx5ya5vwyzkd2l95nlpbk647in-texlive-union-49435 +++ /gnu/store/igc79crx5ya5vwyzkd2l95nlpbk647in-texlive-union-49435-check ├── sha

bug#37377: python-matplotlib-documentation build fails on master

As of commit 83aa6562173e06e8fafd4857a2e708feabfe56f8: --8<---cut here---start->8--- starting phase `build' Running Sphinx v2.1.2 WARNING: while setting up extension matplotlib.sphinxext.mathmpl: directive 'math' is already registered, it will be overridden /gn

bug#37378: python-apache-libcloud fails its test suite

This is happening on master. The tests results are reported as: == 14 failed, 9148 passed, 24 skipped, 532 warnings in 173.14 seconds == And here's a sample of a failure output: --8<---cut here---start->8--- self = , url = 'https://ecs.%s.amazonaws.co

bug#37373: python-ipython-documentation build is not reproducible

Hello Gábor, Gábor Boskovits writes: > Hello, > > > Maxim Cournoyer ezt írta (időpont: 2019. szept. > 11., Sze, 2:30): > >> Here's the diff produced by diffoscope: >> >> --- >> /gnu/store/crwhhm91cgms8fnydvqkmbqbjrypqv48-python-i

bug#36785: Impossible to pull on foreign distro

Hello, Gábor Boskovits writes: > Hello Ludo, > > Ludovic Courtès ezt írta (időpont: 2019. szept. 18., Sze, > 0:04): > >> Hi, >> >> Ludovic Courtès skribis: >> >> > Indeed. I added ‘pk’ calls to print ‘%profile-directory’ and >> > (canonicalize-profile %user-profile-directory), and here’s what

bug#36785: Impossible to pull on foreign distro

Hello, Ludovic Courtès writes: > Maxim Cournoyer skribis: > >> Indeed, the default recommended invocation to update the root's guix >> could be changed to be 'sudo -i guix pull', which should work on all >> systems including Ubuntu. > > Oh rig

bug#36785: Impossible to pull on foreign distro

Hello, Ludovic Courtès writes: > Maxim Cournoyer skribis: > >> Indeed, the default recommended invocation to update the root's guix >> could be changed to be 'sudo -i guix pull', which should work on all >> systems including Ubuntu. > > Oh rig

bug#36785: Impossible to pull on foreign distro

Hello, Ludovic Courtès writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> --- a/doc/guix.texi >> +++ b/doc/guix.texi >> @@ -2387,8 +2387,8 @@ Success, you've now booted into Guix System! From >> then on, you can update the >> system whene

bug#33517: Problem booting when using btrfs subvolume for /gnu/store

Hi Christopher, Christopher Baines writes: > Ludovic Courtès writes: > >> Hello, >> >> Christopher Baines skribis: >> >>> Unfortunately, it's not a proper solution, as it obviously breaks when >>> you actually want to strip the mount point off so that grub can find the >>> right files. >> >> I

bug#36785: Impossible to pull on foreign distro

to something it wasn't really meant for ;-). I've attached a simple patch implementing the idea. Thanks for your patience! Maxim >From a289eb3fd6239287d4a802fbba69abf21604591f Mon Sep 17 00:00:00 2001 From: Maxim Cournoyer Date: Sat, 28 Sep 2019 00:11:28 +0900 Subject: [PATCH] doc: Add a &

bug#36785: Impossible to pull on foreign distro

Hello Ludovic! Ludovic Courtès writes: > Hi Maxim! > > Maxim Cournoyer skribis: > >> From a289eb3fd6239287d4a802fbba69abf21604591f Mon Sep 17 00:00:00 2001 >> From: Maxim Cournoyer >> Date: Sat, 28 Sep 2019 00:11:28 +0900 >> Subject: [PATCH] doc: A

bug#37744: Per-user profile directory hijack (CVE-2019-17365 for Nix)

Hello, Tobias Geerinckx-Rice writes: > Ludo', > > Thanks for your report :-p > > The 1777 is obviously very bad, no question. However: question: > > Ludovic Courtès 写道： >> I don’t see how to let the daemon create ‘per-user/$USER’ on behalf >> of >> the client for clients connecting over TCP. O

bug#37842: Multiple channels with the same name hangs 'guix pull'

Hello! When using a channels.scm file such as: --8<---cut here---start->8--- (cons* (channel (name 'my-channel) (url "https://gitlab.com/Apteryks/sfl-guix-channel";)) (channel (name 'my-channel) (url "https://gitlab.com/Ap

bug#37504: "legacy" NTP configuration fallback fails

Hello Marius, Marius Bakke writes: [...] >>> Backtrace: >>> In srfi/srfi-1.scm: >>>592:29 19 (map1 (#< type: # …)) >>>592:29 18 (map1 (#< type: # …)) >>>592:29 17 (map1 (#< type: # …)) >>>592:29 16 (map1 (#< type: # …)) >>>592:29 15 (map1 (#< type: # …)) >>>592:29 14 (ma

bug#38250: PHP 7.3.11 fails its test suite

Whenever I tried building PHP as of Guix commit 2484e0b3e481e2b1fcb6761d0dbf80da98089de4, the following tests fail: = FAILED TEST SUMMARY - Test disk_free_space a

bug#35192: `current-source-directory' fails when file-name #f

Hello Alex! Alex Sassmannshausen writes: > Hello, > > re: /guix/utils.scm:748: > > When file-name is #f (e.g. in a geiser repl), the procedure's match > fails. `assq' returns ('filename . #f). This is handled in the match > bodies cond clause, but excluded as possibility by the encapsulating >

bug#38253: Volatile? argument seems to be ignored for system disk images

Jelle Licht writes: > I am trying to dive into some of the code that goes into generating > system disk images for guix, and I ran into the following: > > It seems that commit 932e1f92404d917a91af28737d6631ec45b56875 did more > than what the commit log said: > >> vm: Make sure disk image initrds

bug#38261: Recent changes to emacs build system

Hello Brett, Thank you for the heads-up concerning the latest changes to the way Emacs find its libraries and the adjustments done to the emacs-build-system. bre...@posteo.net writes: > On 19.11.2019 01:32, bre...@posteo.net wrote: >> On 19.11.2019 01:27, bre...@posteo.net wrote: >>> On 18.11.20

bug#38273: bug#38274: emacs doesn't open files

Hello Jesse, Jesse Gibbons writes: > On Tue, 2019-11-19 at 08:35 -0700, Jesse Gibbons wrote: >> guix describe : >> Generation 139 Nov 19 2019 08:11:32(current) >> guix 7b40d59 >> repository URL: https://git.savannah.gnu.org/git/guix.git >> branch: master >> commit: 7b40d5

bug#38261: Recent changes to emacs build system

bre...@posteo.net writes: [...] > Thank you for your work Maxim, I think most of them are resolved > now. I do wonder about what prompted the change, though. Perhaps you > might share? > > Brett The main motivation was to gain the ability to install Emacs in a given profile and have it use the E

bug#38273: emacs doesn't open files

Hello Simon, zimoun writes: > Hi, > > I do experiment the same issue. > > $ guix describe > Generation 56Nov 19 2019 12:52:57(current) > guix 7b40d59 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: 7b40d59114e1462d6d8140f325a66b12e91d

bug#38273: emacs doesn't open files

Hello Zimoun, zimoun writes: > Hi Maxim, > > Thank you to looking. > > On Tue, 19 Nov 2019 at 22:51, Maxim Cournoyer > wrote: > >> Did you sort out your issue? Perhaps logging out then back in could >> define the missing EMACSLOADPATH environment varia

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Hello all, Really sorry about this ugly regression :-/. I'm surprised that a 22000 characters in an environment variable would be an issue though, given that that's probably around 22 KiB of memory and some people tested huge variables (>18 MiB) without facing any hard limit other than RAM [0].

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Hello, Ludovic Courtès writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> Really sorry about this ugly regression :-/. > > Should we revert 47b3b4c2aa49e21f4cc32c97ff7bbbd069bb849c so we can > address this without pressure in the meantime? > > I think I m

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Hello Ludovic, Ludovic Courtès writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> There would be a couple more commits to include in the revert to undo >> the changes (one to the build system, others to adapt the renaming of >> the emacs-set-load-path phase fo

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Hello again, Ludovic Courtès writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> There would be a couple more commits to include in the revert to undo >> the changes (one to the build system, others to adapt the renaming of >> the emacs-set-load-path phase fo

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Hello Ludovic, Ludovic Courtès writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> I could reproduce the gnome-session crash by generating a Guix VM with >> the attached OS configuration (it has about 100 Emacs packages installed >> to its system profile, which

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

need to be adapted to finalize the move to a guix.d-less installation directory (some recipes refer to it), but this is trivial to do. The documentation would need to be adapted as well. I can take care of this if someones deems the attached patches fit to fix the problems mentioned in this ticket.

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Hello Clément, clem...@lassieur.org (Clément Lassieur) writes: [...] >> If those affected judge the situation dire enough, I don't mind >> reverting the changes to the Emacs library loading mechanism for the >> time being. > > Please, do so :) > > Lots of users don't have that bug, but there's s

bug#38399: Recent $EMACSLOADPATH changes break emacs-org

Hello Diego, Diego Nicola Barbato writes: > Hi Guix, > > Since the recent changes to the way Guix handles Emacs packages Emacs > loads the wrong ‘org’ (the one bundled with Emacs instead of the one > provided by the ‘emacs-org’ package installed with Guix). This happens > because in EMACSLOADPA

bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

Hello, Jelle Licht writes: > Maxim Cournoyer writes: > >> [...] >> I've tested these changes with a Gnome VM and the EMACSLOADPATH is now >> reduced to just the Emacs' lisp directory as well as the >> share/emacs/site-lisp directory of any profile. Than

bug#44053: Poor profile generation performance on spinning disks

Hi Simon, zimoun writes: > Hi Maxim, > > About performance reported by [1], > > 1: > > the commit [2], > > 2: > > > improves the situation. Although I agree

bug#47259: python-pillow-simd package vulnerable to at least CVE-2021-25293

Hi, Maxime Devos writes: > Maxim Cournoyer schreef op di 22-03-2022 om 22:57 [-0400]: >> Léo Le Bouter writes: >> >> > Hello! >> > >> > pillow-simd is a fork of pillow ( >> > https://github.com/uploadcare/pillow-simd), it's currentl

bug#54558: mcomix refuses to run, missing GTK libraries

Hi Liliana, Liliana Marie Prikler writes: > * gnu/packages/image-viewers.scm (mcomix): Update to 2.0.1. > [source]: Use sourceforge once again. > [inputs]: Add ‘python’. > [arguments]: Convert to a list of G-Expressions. > <#:tests?>: Drop. > <#:phases>: Rename ‘configure’ to ‘patch-sources’. A

bug#54557: “fakechroot” execution engine doesn’t work for Bash

Hi Ludovic, Ludovic Courtès writes: [...] > The message comes from ld.so. My guess is that the problem comes from > Bash’s terrible ‘malloc’ replacement: > [...] > [Time passes…] I confirmed this hypothesis by running: > > guix pack -RR -S /bin=bin -m manifest.scm > > on this manifest: >

bug#54544: Network Issue

Hi Raghav, Raghav Gururajan writes: > Hello Guix! > > About beginning of this month, I started facing network issue. The > WiFi stops working and `sudo herd restart networking` didn't overcome > it. When I shutdown, I see "ath: phy0: Unable to reset channel, reset > status -22" in the screen. I

bug#41625: Sporadic guix-offload crashes due to EOF errors

Hello, Maxim Cournoyer writes: > Hi Marius, > > Marius Bakke writes: > >> Maxim Cournoyer skriver: >> >>>> Is running ‘guix offload test /etc/guix/machines.scm overdrive1’ on >>>> berlin enough to reproduce the issue? If so, we could monito

<    1   2   3   4   5   6   7   8   9   10   >