bug#36257: Youtube-Dl-GUI

[Raghav Gururajan]

Hello Guix!

Sorry for another report today. Just wanted to make this is aware of.

NOTE: This post pertains ONLY to package "youtube-dl-gui" and NOT "youtube-dl".

ISSUE: After installation, the app icon does not appear in GNOME Dash.

STEPS TO RE-PRODUCE:
1) Install "youtube-dl-gui"
2) Reboot
3) Open GNOME Dash
4) Search for "youtube".
5) The app does not appear. (ISSUE)

SUGESSTION: May be missing ".desktop" file?

Thank you!

Regards,
RG.

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

[Ricardo Wurmus]

Maxim Cournoyer  writes:

>> This allows you to match “eof-object” and '() directly.  Whenever I see
>> “string-null?” I think it might be better to “match” on the empty list
>> directly.
>
> string-null? and an empty list are not the same, unless I'm missing something.

Yes, sorry, I meant “null?”.  Using “string-null?” is equivalent to
matching the empty string, of course.

>> But really, that’s up to you.  I only feel strongly about avoiding “(if
>> … (cond …))”.
>
> Due to the problem mentioned above, I stayed with "cond".

Okay!  Thanks.

-- 
Ricardo

bug#36254: Acknowledgement (Youtube-Viewer)

[Tobias Geerinckx-Rice]

Raghav,

Raghav Gururajan wrote:
it appears "youtube-viewer" (both GUI and CUI) opens video 
without

"youtube-dl" ONLY IF the video format is of lower quality.
So most videos like songs from VEVO channels does not open and 
require

"youtube-dl" as a dependency.


Test videos about GNU Guix, on the other hand, opened fine.

...

SUGGESTION: Bundling "youtube-dl" with "youtube-viewer" as a 
dependency.


We only unbundle software in Guix, but  I've added youtube-dl as 
an input and patched youtube-viewer to use it in 
58637415bedb8a91d916ab6ed6f318f7b7023c00.


I can now successfully play ‘Dmitri Shostakovich -  Waltz No. 2 
(by TheWickedNorth)’ which failed to play before.


Could you confirm whether this solves your problem?

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#36256: dependency error with docker-compose

[Edison Ibáñez]

Regards,

When installing docker-compose note that the version is outdated and
therefore the dependencies are broken which causes the following error:

Traceback (most recent call last):
  File 
"/gnu/store/zm3188ipzi262s0m8bxm24br77yh9pd8-python-3.7.0/lib/python3.7/site-packages/pkg_resources/__init__.py",
 line 574, in _build_master
ws.require(__requires__)
  File 
"/gnu/store/zm3188ipzi262s0m8bxm24br77yh9pd8-python-3.7.0/lib/python3.7/site-packages/pkg_resources/__init__.py",
 line 892, in require
needed = self.resolve(parse_requirements(requirements))
  File 
"/gnu/store/zm3188ipzi262s0m8bxm24br77yh9pd8-python-3.7.0/lib/python3.7/site-packages/pkg_resources/__init__.py",
 line 783, in resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (jsonschema 3.0.1 
(/gnu/store/1iq4qvdhl5qbw8dy7kxknky6rxi0v3wc-python-jsonschema-3.0.1/lib/python3.7/site-packages),
 Requirement.parse('jsonschema<3,>=2.5.1'), {'docker-compose'})

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/gnu/store/kf538ibrwbvmmscjb402rpf8hh369g47-docker-compose-1.24.0/bin/.docker-compose-real",
 line 6, in 
from pkg_resources import load_entry_point
  File 
"/gnu/store/zm3188ipzi262s0m8bxm24br77yh9pd8-python-3.7.0/lib/python3.7/site-packages/pkg_resources/__init__.py",
 line 3088, in 
@_call_aside
  File 
"/gnu/store/zm3188ipzi262s0m8bxm24br77yh9pd8-python-3.7.0/lib/python3.7/site-packages/pkg_resources/__init__.py",
 line 3072, in _call_aside
f(*args, **kwargs)
  File 
"/gnu/store/zm3188ipzi262s0m8bxm24br77yh9pd8-python-3.7.0/lib/python3.7/site-packages/pkg_resources/__init__.py",
 line 3101, in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File 
"/gnu/store/zm3188ipzi262s0m8bxm24br77yh9pd8-python-3.7.0/lib/python3.7/site-packages/pkg_resources/__init__.py",
 line 576, in _build_master
return cls._build_from_requirements(__requires__)
  File 
"/gnu/store/zm3188ipzi262s0m8bxm24br77yh9pd8-python-3.7.0/lib/python3.7/site-packages/pkg_resources/__init__.py",
 line 589, in _build_from_requirements
dists = ws.resolve(reqs, Environment())
  File 
"/gnu/store/zm3188ipzi262s0m8bxm24br77yh9pd8-python-3.7.0/lib/python3.7/site-packages/pkg_resources/__init__.py",
 line 778, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'jsonschema<3,>=2.5.1'
  distribution was not found and is required by docker-compose

Try to update it as seen in the following link:

https://bin.disroot.org/?d21a1c74236d7ebd#FlZ2iQxLIkrclC1O45wr7YuUI5bjBcjStwc710J6TWo=

but I keep getting the same error

I hope you can help me

bug#36254: Acknowledgement (Youtube-Viewer)

[Raghav Gururajan]

After discussion in Guix IRC Channel, it appears "youtube-viewer" (both GUI and
CUI) opens video without "youtube-dl" ONLY IF the video format is of lower
quality. So most videos like songs from VEVO channels does not open and require
"youtube-dl" as a dependency.

SUGGESTION: Bundling "youtube-dl" with "youtube-viewer" as a dependency.

Regards,
RG.

bug#36255: Nix importer returns error

[Marlin]

Trying to use the nix importer results in this
https://dpaste.de/C4sz
nothing else happens and it gets stuck at the last message.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

bug#36254: Youtube-Viewer

[Raghav Gururajan]

Hello Guix!

NOTE: Package "youtube-viewer" installs both "gtk-youtube-viewer" (GUI) and
"youtube-viewer" (CUI). This bug pertains ONLY to the GUI. Not sure about the
CUI as I never tried.

ISSUE: In "gtk-youtube-viewer", by default, when you search for a video and
double-click on it; it should open the video in mplayer or mpv or vlc. But this
does not happen unless you separately install "youtube-dl". This causes problem
for "Guix Way"; where one has to get stuck with the version of "youtube-dl" that
"youtube-viewer" supports. So the user do not get freedom to maintain "youtube-
viewer" and "youtube-dl" separately, which is actually a feature of Guix.

STEPS TO RE-PRODUCE:
1) Remove "youtube-dl", if installed.
2) Install mpv or vlc
3) Install "youtube-viewer"
4) Open "gtk-youtube-viewer"
5) Search for a video.
6) Open a video by double-clicking.
7) Video does not open. (ISSUE)
8) Install "youtube-dl"
9) Reboot
10) Repeat steps 4, 5 and 6.
11) Video now opens. (ISSUE)

SUGGESTION: Make GUI and CUI either as separate packages ("gtk-youtube-viewer"
and "youtube-viewer") or as separate outputs ("youtube-viewer:gui" and "youtube-
viewer:cui"); AND bundle the required "youtube-dl" version as a dependency.

Thank you!

Regards,
RG.

bug#36215: guix system docker-image fails when store items contain non-ascii characters

[Björn Höfling]

On Fri, 14 Jun 2019 23:05:06 +0200
Björn Höfling  wrote:

> qemu-system-x86_64: warning: hub 0 is not connected to host network

[..]

> ERROR: In procedure lstat:
> In procedure lstat: No such file or directory:
> "/guixsd-system-root/gnu/store/6w65nzbc3ah30y5kr4zx9rcgknpjr1f5-nss-certs-3.43/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem"
> ^MESC[Kregistering 177 items [  152.952990] Kernel panic - not
> syncing: Attempted to kill init! exitcode=0x0100 [

I looked a bit around the code, added some debugging outputs and found
out that finally in gnu/build/vm.scm in procedure load-in-linux-vm a
QEMU VM is started where the docker image will be created in.

To test things, I entered a container with qemu-minimal:

guix environment -N -C --share=/dev/kvm --share=/tmp/.X11-unix/ --ad-hoc 
coreutils less findutils emacs qemu-minimal nss-certs

And started an existing VM with the store being available over virtfs:

[env] $ qemu-system-x86_64 -m 2048 -smp 2 \
 -boot menu=on \
 -drive file=guixsd0.2018-02-19.qcow2 \
 -drive format=raw,file=swap.img \
 -virtfs 
local,id=store_dev,path=/gnu/store,security_model=none,mount_tag=store

In that machine, I mounted the fs:

mount -t 9p -o trans=virtio store /mnt

When I then looked at /mnt/...nss-certs.../..., the non-ascii
characters are looking all good.

I think the encoding-problem is more in the script.

Björn




pgp13bHoDtthb.pgp
Description: OpenPGP digital signature

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

[ng0]

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#36248: poor error tracing

[Robert Vollmert]

I’m not sure if this lies more with guile or with guix, but there’s definitely
room for improvment either way.

I was working on https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36084,
haskell-check.scm was changed as follows:

-   ("ghc-clock-bootstrap" ,ghc-clock-bootstrap)
+   ("ghc-clock-bootstrap" ,(@@ (gnu packages haskell) ghc-clock-bootstrap))

In haskell.scm I had a working package definition for ghc-clock-bootstrap,
and added a definition for ghc-clock along these lines:

+(define-public ghc-clock
+  (package
+(inherit ghc-clock-bootstrap)
+(name "ghc-clock")
+;;(version "0.7.2")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append
+ "https://hackage.haskell.org/package/;
+ "clock/"
+ "clock-" version ".tar.gz"))
+   (sha256
+(base32 "07v91s20halsqjmziqb1sqjp2sjpckl9by7y28aaklwqi2bh2rl8"))
+   (patches
+(search-patches
+ "ghc-clock-disable-library.patch"
+(inputs
+ `(("ghc-tasty" ,ghc-tasty)
+   ("ghc-tasty-quickcheck" ,ghc-tasty-quickcheck)))
+(arguments
+ `(#:tests? #t
+

This is broken due to the reference to version, fixed by uncommenting the
version field. The problem is with the error messages:

  guix build ghc-clock

gave pages of warnings, ending with a plain

  guix build: error: ghc-clock: unknown package

Knowing I’d edited haskell.scm and it worked fine before, I ran

  guild compile haskell.scm

which hung.

Finally

  guild compile haskell-check.scm

very subtly pointed me at some issue with version in haskell.scm. Full
output below.


~/guix [env]$ ./pre-inst-env guix build ghc-clock
;;; note: source file /home/rob/guix/gnu/packages/haskell.scm
;;;   newer than compiled /home/rob/guix/gnu/packages/haskell.go
;;; note: source file /home/rob/guix/gnu/packages/haskell.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/gnu/packages/haskell.go
;;; note: source file /home/rob/guix/gnu/packages/haskell.scm
;;;   newer than compiled 
/home/rob/.cache/guile/ccache/2.2-LE-8-3.A/home/rob/guix/gnu/packages/haskell.scm.go
;;; note: source file /home/rob/guix/gnu/packages/haskell-check.scm
;;;   newer than compiled /home/rob/guix/gnu/packages/haskell-check.go
;;; note: source file /home/rob/guix/gnu/packages/haskell-check.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/2.2/site-ccache/gnu/packages/haskell-check.go
guix build: warning: failed to load '(gnu packages abiword)':
In procedure string-append: Wrong type (expecting string): #
guix build: warning: failed to load '(gnu packages android)':
In procedure module-lookup: Unbound variable: googletest
guix build: warning: failed to load '(gnu packages antivirus)':
In procedure module-lookup: Unbound variable: bzip2
guix build: warning: failed to load '(gnu packages avr)':
In procedure module-lookup: Unbound variable: binutils
guix build: warning: failed to load '(gnu packages axoloti)':
In procedure module-lookup: Unbound variable: gcc-4.9
guix build: warning: failed to load '(gnu packages benchmark)':
In procedure module-lookup: Unbound variable: openmpi
guix build: warning: failed to load '(gnu packages bioconductor)':
In procedure module-lookup: Unbound variable: perl-module-build
guix build: warning: failed to load '(gnu packages bootloaders)':
no binding `bc' in module (gnu packages algebra)
guix build: warning: failed to load '(gnu packages chemistry)':
In procedure module-lookup: Unbound variable: python2-numpy
guix build: warning: failed to load '(gnu packages commencement)':
In procedure module-lookup: Unbound variable: gnu-make
guix build: warning: failed to load '(gnu packages debug)':
In procedure module-lookup: Unbound variable: gnu-make
guix build: warning: failed to load '(gnu packages games)':
In procedure module-lookup: Unbound variable: python
guix build: warning: failed to load '(gnu packages image-viewers)':
In procedure module-lookup: Unbound variable: curl
guix build: warning: failed to load '(gnu packages julia)':
In procedure module-lookup: Unbound variable: libuv
guix build: warning: failed to load '(gnu packages kodi)':
In procedure module-lookup: Unbound variable: libdvdnav
guix build: warning: failed to load '(gnu packages license)':
In procedure module-lookup: Unbound variable: perl
guix build: warning: failed to load '(gnu packages make-bootstrap)':
In procedure module-lookup: Unbound variable: coreutils
guix build: warning: failed to load '(gnu packages maven)':
In procedure module-lookup: Unbound variable: java-plexus-container-default
guix build: warning: failed to load '(gnu packages profiling)':
In procedure module-lookup: Unbound variable: openmpi
guix build: warning: failed to load '(gnu packages syndication)':
In procedure module-lookup: Unbound variable: curl
guix build: error: ghc-clock: unknown package

~/guix [env]$ ./pre-inst-env guild compile gnu/packages/haskell.scm 
;;; note: source 

bug#36238: Problems cross-compiling on core-updates

[Carl Dong]

Unfortunately b1593c1c4fd8f4fc6df4c43cab51334426e3aa76 still doesn't work, I've
attached the log.


Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"


r7dqzwhva6pgi4g3hasvbj3yf9wgq4-bison-3.4.1.drv.bz2
Description: BZip2 compressed data

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

[Maxim Cournoyer]

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 consider requirements.txt files.

PyPI packages are mandated to have a setup.py file, which contains a listing
of the required dependencies.  The setuptools/distutils machinery embed
metadata in the archives they produce, which contains this information. There
is no need nor gain to collect the requirements from a "requirements.txt"
file, as it is not the true record of dependencies for PyPI packages and may
contain extraneous requirements or not exist at all.

* guix/import/pypi.scm (guess-requirements): Update comment.
[guess-requirements-from-source]: Do not attempt to parse the file
requirements.txt.  Streamline logic.
* tests/pypi.scm (test-requires.txt): Rename from test-requirements, to hint
at the file being tested.
("pypi->guix-package"): Adapt so that the fake package contains a requires.txt
file rather than a requirements.txt file.
("pypi->guix-package, wheels"): Likewise.
---
 guix/import/pypi.scm | 35 +--
 tests/pypi.scm   | 23 ---
 2 files changed, 25 insertions(+), 33 deletions(-)

diff --git a/guix/import/pypi.scm b/guix/import/pypi.scm
index 3a20fc4b9b..8269aa61d7 100644
--- a/guix/import/pypi.scm
+++ b/guix/import/pypi.scm
@@ -206,35 +206,26 @@ cannot determine package dependencies"))
   (call-with-temporary-directory
(lambda (dir)
  (let* ((pypi-name (string-take dirname (string-rindex dirname #\-)))
-(req-files (list (string-append dirname "/requirements.txt")
- (string-append dirname "/" pypi-name ".egg-info"
-"/requires.txt")))
-(exit-codes (map (lambda (file-name)
-   (parameterize ((current-error-port (%make-void-port "rw+"))
-  (current-output-port (%make-void-port "rw+")))
- (system* "tar" "xf" tarball "-C" dir file-name)))
- req-files)))
-   ;; Only one of these files needs to exist.
-   (if (any zero? exit-codes)
-   (match (find-files dir)
- ((file . _)
-  (read-requirements file))
- (()
-  (warning (G_ "No requirements file found.\n"
+(requires.txt (string-append dirname "/" pypi-name
+ ".egg-info" "/requires.txt"))
+(exit-code (parameterize ((current-error-port (%make-void-port "rw+"))
+  (current-output-port (%make-void-port "rw+")))
+ (system* "tar" "xf" tarball "-C" dir requires.txt
+   (if (zero? exit-code)
+   (read-requirements (string-append dir "/" requires.txt))
(begin
- (warning (G_ "Failed to extract requirements files\n"))
+ (warning
+  (G_ "Failed to extract file: ~a from source.~%")
+  requires.txt)
  '())
   '(
 
-  ;; First, try to compute the requirements using the wheel, since that is the
-  ;; most reliable option. If a wheel is not provided for this package, try
-  ;; getting them by reading either the "requirements.txt" file or the
-  ;; "requires.txt" from the egg-info directory from the source tarball. Note
-  ;; that "requirements.txt" is not mandatory, so this is likely to fail.
+  ;; First, try to compute the requirements using the wheel, else, fallback to
+  ;; reading the "requires.txt" from the egg-info directory from the source
+  ;; tarball.
   (or (guess-requirements-from-wheel)
   (guess-requirements-from-source)))
 
-
 (define (compute-inputs source-url wheel-url tarball)
   "Given the SOURCE-URL of an already downloaded TARBALL, return a list of
 name/variable pairs describing the required inputs of this package.  Also
diff --git a/tests/pypi.scm b/tests/pypi.scm
index 6daa44a6e7..a0271fffad 100644
--- a/tests/pypi.scm
+++ b/tests/pypi.scm
@@ -23,7 +23,7 @@
   #:use-module (gcrypt hash)
   #:use-module (guix tests)
   #:use-module (guix build-system python)
-  #:use-module ((guix build utils) #:select (delete-file-recursively which))
+  #:use-module ((guix build utils) #:select (delete-file-recursively which mkdir-p))
   #:use-module (srfi srfi-64)
   #:use-module (ice-9 match))
 
@@ -55,11 +55,12 @@
 (define test-source-hash
   "")
 
-(define test-requirements
-"# A comment
+(define test-requires.txt "\
+# A comment
  # A comment after a 

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

[Maxim Cournoyer]

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)
 + (optional? #f))
  (let ((line (read-line port)))
 -  ;; Stop when a section is encountered, as sections contains 
 optional
 -  ;; (extra) requirements.  Non-optional requirements must appear
 -  ;; before any section is defined.
 -  (if (or (eof-object? line) (section-header? line))
 +  (if (eof-object? line)
;; Duplicates can occur, since the same requirement can be
;; listed multiple times with different conditional 
 markers, e.g.
;; pytest >= 3 ; python_version >= "3.3"
;; pytest < 3 ; python_version < "3.3"
 -  (reverse (delete-duplicates result))
 +  (map (compose reverse delete-duplicates)
 +   (list required-deps test-deps))
>>>
>>> Looks like a list of lists to me.  “delete-duplicates” now won’t delete
>>> a name that is in both “required-deps” as well as in “test-deps”.  Is
>>> this acceptable?
>>
>> It is acceptable, as this corner case cannot exist given the current
>> code (a requirement can exist in either required-deps or test-deps, but
>> never in both). It also doesn't make sense that a run time requirement
>> would also be listed as a test requirement, so that corner case is not
>> likely to exist in the future either.
>
> I mentioned it because I believe I’ve seen this in the past where the
> importer would return some of the same inputs as both regular inputs and
> test dependencies.

OK!

>>> Personally, I’m not a fan of using data structures for returning
>>> multiple values, because we can simply return multiple values.
>>
>> I thought the Guile supported multiple values return value would be
>> great here as well, but I've found that for this specific case here, a
>> list of lists worked better, since the two lists contain requirements to
>> be processed the same, which "map" can readily do (i.e. less ceremony is
>> required).
>
> “map” can also operate on more than one list at a time:
>
> (call-with-values
>   (lambda ()
> (values (list 1 2 3)
> (list 9 8 7)))
>   (lambda (a b) (map + a b)))
>
> => (10 10 10)

That's what I meant by "requires more ceremony".  I can simply apply
"map" to the return value of the function and get what I need, rather
than having to use "values" in the callee, then "call-with-values" in
the caller and establish a binding for each list.
  
> Of course, it would be simpler to just use a single list of tagged
> items.

Do you feel strongly about it? I don't; I'm open to try to use a tagged
list if you feel this is worth it.

Maxim

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

[Maxim Cournoyer]

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.
 +  (if (or (eof-object? line) (section-header? line))
 +  (reverse result)
 +  (cond
 +   ((or (string-null? line) (comment? line))
 +(loop result))
 +   (else
 +(loop (cons (clean-requirement line)
 +result))
 +
>>>
>>> I think it would be better to use “match” here instead of nested “let”,
>>> “if” and “cond”.  At least you can drop the “if” and just use cond.
>>>
>>> The loop let and the inner let can be merged.
>>
>> I'm not sure I understand; wouldn't merging the named let with the plain
>> let mean adding an extra LINE argument to my LOOP procedure?  I don't
>> want that.
>
> Let’s forget about merging the nested “let”, because you would indeed
> need to change a few more things.  It’s fine to keep that as it is.  But
> (if … (cond …)) is not pretty.  At least it could be done in one “cond”:
>
> (cond
>  ((or (eof-object? line) (section-header? line))
>   (reverse result))
>  ((or (string-null? line) (comment? line))
>   (loop result))
>  (else
>   (loop (cons (clean-requirement line)
>   result

Agreed and fixed, thanks.

>> Also, how could the above code be expressed using "match"? I'm using
>> predicates which tests for (special) characters in a string; I don't see
>> how the more primitive pattern language of "match" will enable me to do
>> the same.
>
> “match” has support for predicates, so you could do something like this:
>
> (match line
>  ((or (eof-object) (? section-header?))
>   (reverse result))
>  ((or '() (? comment?))
>   (loop result))
>  (_ (loop (cons (clean-requirement line) result

Oh, that's neat! I had no idea that predicates could be used with
"match".  '() would need to be replaced by "" to match the empty
string.  Another gotcha with "match", is that the "or" seems to evaluate
every component, no matter if a early true condition was found; this
resulted in the following error:

--8<---cut here---start->8---
+ (wrong-type-arg
+   "string-trim"
+   "Wrong type argument in position ~A (expecting ~A): ~S"
+   (1 "string" #)
+   (#))
result: FAIL
--8<---cut here---end--->8---

Due to the "(or (eof-object) (? section-header?)" match clause
evaluating the section-header? predicate despite the line being an EOF
character.

> This allows you to match “eof-object” and '() directly.  Whenever I see
> “string-null?” I think it might be better to “match” on the empty list
> directly.

string-null? and an empty list are not the same, unless I'm missing something.

> But really, that’s up to you.  I only feel strongly about avoiding “(if
> … (cond …))”.

Due to the problem mentioned above, I stayed with "cond".

Thanks!

Maxim

bug#23961: fixed a while back

[Robert Vollmert]

commit 314b63e0b4372681aec165113ae2a0349eaaa357
Author: Danny Milosavljevic 
Date:   Wed Jul 11 11:02:51 2018 +0200

import: hackage: Support "custom-setup" field.

Fixes .

* guix/import/cabal.scm (make-cabal-parser): Modify.
(is-custom-setup): New variable.
(lex-custom-setup): New procedure.
(is-id): Modify.
(lex-version): Modify.
(): New record type.
(eval-cabal): Modify.
(dependencies): Add parameter.

bug#36242: Repacked source checkouts get a misleading file name

[Marius Bakke]

Efraim Flashner  writes:

> On Sun, Jun 16, 2019 at 11:04:26AM +0200, Marius Bakke wrote:
>> Hello,
>> 
>> When repacking a source checkout (e.g. by using git-fetch with a
>> snippet), the generated file name contains only the first two version
>> identifiers.
>> 
>> E.g. `guix build -S eudev` returns
>> 
>> /gnu/store/7lgsxmr0rk9f8fbq6k0kj1aqb7lnrlll-eudev-3.2.tar.xz
>> 
>> ...even though it should be "3.2.8".
>> 
>> This patch fixes it:
>> 
>
>> From 0c44561d0d45de91f4674d659b86d740642ae801 Mon Sep 17 00:00:00 2001
>> From: Marius Bakke 
>> Date: Sun, 16 Jun 2019 10:50:15 +0200
>> Subject: [PATCH] packages: Keep full version in file name when repacking
>>  source checkouts.
>> 
>> * guix/packages.scm (patch-and-repack): If ORIGINAL-FILE-NAME is a source
>> checkout, drop the '-checkout' part so the version-detecting code works.
>> ---
>>  guix/packages.scm | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>> 
>> diff --git a/guix/packages.scm b/guix/packages.scm
>> index c94a651f27..5b8969e079 100644
>> --- a/guix/packages.scm
>> +++ b/guix/packages.scm
>> @@ -505,11 +505,17 @@ specifies modules in scope when evaluating SNIPPET."
>>  (and=> (file-extension file-name)
>> (cut string-every char-set:hex-digit <>)))
>>  
>> +  (define (checkout? directory)
>> +;; Return true if DIRECTORY is a checkout (git, svn, etc).
>> +(string-suffix? "-checkout" directory))
>> +
>>(define (tarxz-name file-name)
>>  ;; Return a '.tar.xz' file name based on FILE-NAME.
>> -(let ((base (if (numeric-extension? file-name)
>> -original-file-name
>> -(file-sans-extension file-name
>> +(let ((base (cond ((numeric-extension? file-name)
>> +   original-file-name)
>> +  ((checkout? file-name)
>> +   (string-drop-right file-name 9))
>> +  (else (file-sans-extension file-name)
>>(string-append base
>>   (if (equal? (file-extension base) "tar")
>>   ".xz"
>> -- 
>> 2.22.0
>> 
>
> Pinging Mark and Ludo, similar to https://issues.guix.info/issue/34066

Whoops, was not aware of that report!  Closing as duplicate.


signature.asc
Description: PGP signature

bug#36242: Repacked source checkouts get a misleading file name

[Efraim Flashner]

On Sun, Jun 16, 2019 at 11:04:26AM +0200, Marius Bakke wrote:
> Hello,
> 
> When repacking a source checkout (e.g. by using git-fetch with a
> snippet), the generated file name contains only the first two version
> identifiers.
> 
> E.g. `guix build -S eudev` returns
> 
> /gnu/store/7lgsxmr0rk9f8fbq6k0kj1aqb7lnrlll-eudev-3.2.tar.xz
> 
> ...even though it should be "3.2.8".
> 
> This patch fixes it:
> 

> From 0c44561d0d45de91f4674d659b86d740642ae801 Mon Sep 17 00:00:00 2001
> From: Marius Bakke 
> Date: Sun, 16 Jun 2019 10:50:15 +0200
> Subject: [PATCH] packages: Keep full version in file name when repacking
>  source checkouts.
> 
> * guix/packages.scm (patch-and-repack): If ORIGINAL-FILE-NAME is a source
> checkout, drop the '-checkout' part so the version-detecting code works.
> ---
>  guix/packages.scm | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/guix/packages.scm b/guix/packages.scm
> index c94a651f27..5b8969e079 100644
> --- a/guix/packages.scm
> +++ b/guix/packages.scm
> @@ -505,11 +505,17 @@ specifies modules in scope when evaluating SNIPPET."
>  (and=> (file-extension file-name)
> (cut string-every char-set:hex-digit <>)))
>  
> +  (define (checkout? directory)
> +;; Return true if DIRECTORY is a checkout (git, svn, etc).
> +(string-suffix? "-checkout" directory))
> +
>(define (tarxz-name file-name)
>  ;; Return a '.tar.xz' file name based on FILE-NAME.
> -(let ((base (if (numeric-extension? file-name)
> -original-file-name
> -(file-sans-extension file-name
> +(let ((base (cond ((numeric-extension? file-name)
> +   original-file-name)
> +  ((checkout? file-name)
> +   (string-drop-right file-name 9))
> +  (else (file-sans-extension file-name)
>(string-append base
>   (if (equal? (file-extension base) "tar")
>   ".xz"
> -- 
> 2.22.0
> 

Pinging Mark and Ludo, similar to https://issues.guix.info/issue/34066


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#36242: Repacked source checkouts get a misleading file name

[Marius Bakke]

Hello,

When repacking a source checkout (e.g. by using git-fetch with a
snippet), the generated file name contains only the first two version
identifiers.

E.g. `guix build -S eudev` returns

/gnu/store/7lgsxmr0rk9f8fbq6k0kj1aqb7lnrlll-eudev-3.2.tar.xz

...even though it should be "3.2.8".

This patch fixes it:

From 0c44561d0d45de91f4674d659b86d740642ae801 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Sun, 16 Jun 2019 10:50:15 +0200
Subject: [PATCH] packages: Keep full version in file name when repacking
 source checkouts.

* guix/packages.scm (patch-and-repack): If ORIGINAL-FILE-NAME is a source
checkout, drop the '-checkout' part so the version-detecting code works.
---
 guix/packages.scm | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/guix/packages.scm b/guix/packages.scm
index c94a651f27..5b8969e079 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -505,11 +505,17 @@ specifies modules in scope when evaluating SNIPPET."
 (and=> (file-extension file-name)
(cut string-every char-set:hex-digit <>)))
 
+  (define (checkout? directory)
+;; Return true if DIRECTORY is a checkout (git, svn, etc).
+(string-suffix? "-checkout" directory))
+
   (define (tarxz-name file-name)
 ;; Return a '.tar.xz' file name based on FILE-NAME.
-(let ((base (if (numeric-extension? file-name)
-original-file-name
-(file-sans-extension file-name
+(let ((base (cond ((numeric-extension? file-name)
+   original-file-name)
+  ((checkout? file-name)
+   (string-drop-right file-name 9))
+  (else (file-sans-extension file-name)
   (string-append base
  (if (equal? (file-extension base) "tar")
  ".xz"
-- 
2.22.0



signature.asc
Description: PGP signature

bug#36238: Problems cross-compiling on core-updates

[Marius Bakke]

Carl Dong  writes:

> Hi all,
>
> I noticed that cross-compiling isn't working on the core-updates branch. I'm 
> on
> commit cfd4e4d06e3cda0f3eed8d6b9277ce53e55404b8 and all you need to reproduce 
> is
> to invoke:
>
> ./pre-inst-env guix build --target=aarch64-linux-gnu coreutils
>
> Attached is the build log.

Including the plain text for posterity:

--8<---cut here---start->8---
starting phase `build'
  LEX  examples/c/reccalc/scan.stamp
  GEN  lib/alloca.h
  GEN  lib/fcntl.h
  GEN  lib/configmake.h
  GEN  lib/limits.h
  GEN  lib/inttypes.h
  GEN  lib/textstyle.h
  GEN  lib/math.h
  GEN  lib/signal.h
  GEN  lib/spawn.h
  GEN  lib/stdio.h
  GEN  lib/stdlib.h
  GEN  lib/string.h
  GEN  lib/sys/resource.h
  GEN  lib/time.h
  GEN  lib/unitypes.h
  GEN  lib/sys/time.h
  GEN  lib/unistd.h
  GEN  lib/sys/times.h
  GEN  lib/sys/types.h
  GEN  lib/sys/wait.h
  GEN  lib/uniwidth.h
  GEN  lib/wchar.h
  GEN  lib/wctype.h
make[1]: Entering directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
make[1]: Entering directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
  LEX  examples/c/reccalc/scan.stamp
  LEX  examples/c/reccalc/scan.stamp
make[1]: Leaving directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
mv: cannot stat 'examples/c/reccalc/scan.stamp.tmp': No such file or directory
make[1]: *** [Makefile:6855: examples/c/reccalc/scan.stamp] Error 1
make[1]: Leaving directory '/tmp/guix-build-bison-3.4.1.drv-0/bison-3.4.1'
make: *** [Makefile:6847: examples/c/reccalc/scan.c] Error 2
command "make" "-j" "48" failed with status 2
--8<---cut here---end--->8---

This looks like a parallelism issue, and should be fixed in
b1593c1c4fd8f4fc6df4c43cab51334426e3aa76.  Thanks!


signature.asc
Description: PGP signature

bug#36240: indent-code.el is not aware of (package (inherit ...)) style

[Robert Vollmert]

When encountering a package definition that starts

  (package (inherit other-package))

etc/indent-code.el will indent the rest of the package body
to align with the start of (inherit. That seems to be a
common idiom, used in roughly half of the instances:

guix/gnu/packages$ git grep '(inherit ' | wc -l
905
guix/gnu/packages$ git grep '(inherit ' | grep package | wc -l
425

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

[Maxim Cournoyer]

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.
>> 2) It is easier to extend; we might want to add parsing for the version
>> spec in order to disregard dependencies specified for Python < 3, for
>> example.
>>
>> The use of the PEP-0508 grammar to define the regexp is useful to detail
>> in a more human-friendly language the components of the regexp.  We
>> could have otherwise used the more cryptic regexp for Python
>> distribution names:
>>
>> --8<---cut here---start->8---
>> ^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$
>> --8<---cut here---end--->8---
>>
>> So I guess that what I'm saying is that I prefer this approach to using
>> string-index with invalid characters, for the reasons above.
>>
>> [0]  https://www.python.org/dev/peps/pep-0508/
>
> Okay, sounds good.  Please make sure to note this in a comment, so that
> I won’t be asking myself this same question in a year :)

Done!

Maxim