bug#40142: CVE checker return false positives

[Brice Waegeneire]

Hello,

The CVE checker of “guix lint” returns false positives:
┌
│ LANGUAGE=C guix lint git 2>&1
├───
│ gnu/packages/version-control.scm:149:2: git@2.25.1: probably 
vulnerable to CVE-2020-2136, CVE-2019-1003010, CVE-2018-1000110, 
CVE-2018-1000182
│ 
/gnu/store/8q0nfd6vnc6lnjh13rwl7fyimwlv7fml-guix-module-union/share/guile/site/3.0/gnu/packages/version-control.scm:153:12: 
git@2.25.1: can be upgraded to 2.25.2
│ 
/gnu/store/8q0nfd6vnc6lnjh13rwl7fyimwlv7fml-guix-module-union/share/guile/site/3.0/gnu/packages/version-control.scm:154:11: 
git@2.25.1: source not archived on Software Heritage

└


• [CVE-2020-2136]: “Jenkins Git Plugin 4.2.0 and earlier […]”
• [CVE-2019-1003010]: “[…] Jenkins Git Plugin 3.9.1 and earlier […]”
• [CVE-2018-1000110]: “[…] Jenkins Git Plugin version 3.7.0 and earlier
  […]”
• [CVE-2018-1000182]: “[…] Jenkins Git Plugin 3.9.0 and older […]”

Also note the missing / on the first line and it output on `stderr'
instead of `stdout'.

[CVE-2020-2136] 

[CVE-2019-1003010] 

[CVE-2018-1000110] 

[CVE-2018-1000182] 

Brice.

bug#23811: shepherd: tests/respawn-throttling.sh fails sporadically

[Brice Waegeneire]

Hello,

#23811 (merged with #28588) are about the same tests failing as
the recently closed #30299 and were reported 4 et 3 years.
I suggest to close then too.

Brice.

bug#40144: --rounds has no effect when used in conjunction with --check

[Brice Waegeneire]

Hello,

Since this bug is already known[0] this report is just to keep of it.

“guix --check --rounds=3 hello” only build the package once instead of
three time.

[0]: http://logs.guix.gnu.org/guix/2020-03-18.log#213921

Brice.

bug#39926: Regression introduced by Shepherd 0.7.0 ('make check-system TESTS=btrfs-root-os' fails)

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès  writes:

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> Maxim Cournoyer  writes:
>>
>> [...]
>>
>>> Comparing with the above uname output, we can see that it validates the
>>> hostname matches against "liberigilo", yet it is "gnu"!  Perhaps
>>> Shepherd 0.7.0 introduced some problem with the hostname service?
>>
>> Another data point: the same happen when running './pre-inst-env make
>> check-system TESTS=installed-os', so this is not Btrfs specific.
>
> Fixed by be0a672c30ad1401019abb5cb83d59be171813d0.
>
> I wonder how this could have worked before: ‘reboot’ never gets a reply,
> so it’s supposed to hang until it’s killed when the ‘user-processes’
> service is stopped.
>
> Thanks,
> Ludo’.

Hey, weird!  Anyway, thanks for fixing it!  How did you debug this?  I'm 
curious.

Maxim

bug#39475: Xfce desktop - multiple programs from other desktop environments

[Michael Rohleder]

Michael Rohleder  writes:
> "Scott C. MacCallum"  writes:
>> After the installation of all the available desktop environments, in the 
>> Xfce desktop environment there are multiple programs from some of the other 
>> desktop environments to choose from, not just the Xfce default ones.
>
> Isnt this more a feature than a bug?
>
> afaik, the installation of xfce in gentoo, debian and ubuntu behaves the
> same...

Ok, to close this?

If so, we can also close 39459, 39463, 39467 that are all the same, basically.
In all cases and DE combinations, this is a feature, not a bug, imho.


-- 
The question of whether computers can think is just like the question of
whether submarines can swim.
-- Edsger W. Dijkstra


signature.asc
Description: PGP signature

bug#23811: shepherd: tests/respawn-throttling.sh fails sporadically

[Marius Bakke]

Brice Waegeneire  writes:

> Hello,
>
> #23811 (merged with #28588) are about the same tests failing as
> the recently closed #30299 and were reported 4 et 3 years.
> I suggest to close then too.

Good catch, closing!


signature.asc
Description: PGP signature

bug#40079: emacs-elpy-1.31.0: failed to build

[Marius Bakke]

sirgazil via Bug reports for GNU Guix  writes:

> I couldn't upgrade the packages in my user profile because "emacs-elpy" check 
> phase fails. 
>
>
> ## Steps to reproduce
>
> 1. guix pull
> 2. guix build emacs-elpy
>
>
> ## Unexpected result
>
>
> The output of the check phase:
>
> ---
> starting phase `check'
>
> Can’t guess python-indent-offset, using defaults: 4

This seems to stem from the update of 'python-black' in
5f603fab23e7df7e7b76566b3add24b65e92f807.  Reverting that commit makes
this package build.

@Ricardo: Any objections to reverting the commit?


signature.asc
Description: PGP signature

bug#40031: OpenScad Test errors

[Marius Bakke]

Ekaitz Zarraga  writes:

> ‐‐‐ Original Message ‐‐‐
> On Wednesday, March 11, 2020 10:51 PM, Leo Famulari  
> wrote:
>
>> On Wed, Mar 11, 2020 at 08:48:43PM +, Ekaitz Zarraga wrote:
>>
>> > Hi,
>> > My installation of GuixSD fails to install OpenSCAD.
>> > Running `guix environment --pure --ad-hoc openscad` fails with the errors 
>> > I attach.
>> > Can you reproduce or is it just a problem with my installation?
>> > Ideas about how can I correct this?
>>
>> Try running it again the build with --keep-failed and then looking in
>> the build directory for test suite logs. There is not much to go on in
>> the build log you sent.
>
>
>
> I made it.
> I opened the folder and it's compiled and it runs pretty well.
>
> The tests have the following errors which are exclusively related with the 
> test tooling, in my opinion.
>
> ```
> Unable to open a connection to the X server.
> DISPLAY=:1
> Can't create OpenGL OffscreenView. Code: -1.
>
> Error: openscad failed with return code 1
>
> Test time =   0.06 sec
> ```
>
> The tests compare the *image* of what it's supposed to render OpenSCAD with 
> some already rendered images.
> The problem is it's trying to access a screen and it's unable to do it.
> There's `xvfb` for X testing but it's like it's not working.
>
> Ideas?

It looks like this problem fixed itself.  OpenSCAD builds successfully
on 'master' now, at least for i686 and x86_64:

https://ci.guix.gnu.org/search?query=openscad

Closing the bug, thanks for reporting it!


signature.asc
Description: PGP signature

bug#40153: The guix package fails to build attempting to install something directly under /etc

[Maxim Cournoyer]

Repro:

./pre-inst-env guix build -e '((@@ (gnu packages package-management) 
current-guix))'

--8<---cut here---start->8---
 /gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31/bin/mkdir -p 
'/gnu/store/n0w0xfnwf7j5h7138x2682rf247syp05-guix-1.0.1-15.0984481+/lib/systemd/system'
 /gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31/bin/install -c -m 
644 etc/guix-daemon.service etc/guix-publish.service 
'/gnu/store/n0w0xfnwf7j5h7138x2682rf247syp05-guix-1.0.1-15.0984481+/lib/systemd/system'
 /gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31/bin/mkdir -p 
'/etc/init.d'
/gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31/bin/mkdir: cannot 
create directory ‘/etc/init.d’: Permission denied
make[3]: *** [Makefile:4851: install-nodist_sysvinitserviceDATA] Error 1
make[3]: Leaving directory '/tmp/guix-build-guix-1.0.1-15.0984481+.drv-0/source'
make[2]: *** [Makefile:5382: install-am] Error 2
make[2]: Leaving directory '/tmp/guix-build-guix-1.0.1-15.0984481+.drv-0/source'
make[1]: *** [Makefile:4899: install-recursive] Error 1
make[1]: Leaving directory '/tmp/guix-build-guix-1.0.1-15.0984481+.drv-0/source'
make: *** [Makefile:5376: install] Error 2
command "make" "install" failed with status 2
builder for 
`/gnu/store/k7ca5pbfb4vqfwggj6s9vjpcv8k0swcd-guix-1.0.1-15.0984481+.drv' failed 
with exit code 1
build of /gnu/store/k7ca5pbfb4vqfwggj6s9vjpcv8k0swcd-guix-1.0.1-15.0984481+.drv 
failed
View build log at 
'/var/log/guix/drvs/k7/ca5pbfb4vqfwggj6s9vjpcv8k0swcd-guix-1.0.1-15.0984481+.drv.bz2'.
guix build: error: build of 
`/gnu/store/k7ca5pbfb4vqfwggj6s9vjpcv8k0swcd-guix-1.0.1-15.0984481+.drv' failed
--8<---cut here---end--->8---

bug#35644: emacs module support doesn't work

[Marius Bakke]

Caleb Ristvedt  writes:

> I can confirm that it now works. I did a bit of looking through the commit
> history and playing around with 'guix time-machine', and whatever changed
> to fix
> it, it wasn't a change that touched gnu/packages/emacs.scm. I know it fell
> between 7ab5c4e0e8 and 5ce153b110, though.
>
> Thanks for bringing this up, I guess we can close this now?

Thank you both for the report and investigation.  Closing!


signature.asc
Description: PGP signature

bug#40153: The guix package fails to build attempting to install something directly under /etc

[Leo Famulari]

On Fri, Mar 20, 2020 at 02:48:46PM -0400, Maxim Cournoyer wrote:
> Repro:
> 
> ./pre-inst-env guix build -e '((@@ (gnu packages package-management) 
> current-guix))'
> 
> /gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31/bin/mkdir: cannot 
> create directory ‘/etc/init.d’: Permission denied

I guess it's related to fe60ef998f537e0e71b (guix-install.sh: Install
SysV init script.)

bug#39950: flatpack packages can't open external applications

[Marius Bakke]

Damien Cassou  writes:

> Hi,
>
> when I install a flatpak package under Guix System, this package works
> but can't open external applications. This is a problem for some
> applications, e.g., Blender will never open your web browser.
>
> How to reproduce:
>
> $ guix install flatpak
>
> $ flatpak --user remote-add --if-not-exists flathub 
> https://flathub.org/repo/flathub.flatpakrepo
>
> $ flatpak --user install flathub org.blender.Blender
>
> $ flatpak --user run org.blender.Blender
>
> In Blender, click on the Help menu in the menu bar and choose "User
> communities". This is supposed to open a web browser but no browser will
> pop up.
>
> When in bash, I can use xdg-open to open a web page without problem.

To my knowledge, Flatpak applications run in isolated containers and
thus have no visibility to the host system by default.  Maybe there are
some command-line arguments you can add to give it access to what it
needs to open a browser?

It seems to me there is little Guix can do about it without breaking the
containerization features of Flatpak.  WDYT?


signature.asc
Description: PGP signature

bug#39869: python-orator build fails

[Marius Bakke]

This was a surprisingly deep rabbit hole that ended pretty
unsatisfactory with commit 51d42caa94515f43d677bdd76d53bf8bb8c7bc4e.

According to a comment in the package definition, the tests were never
supposed to run, so in the end they were just disabled.

I discovered a pattern that I hadn't seen yet in the Python ecosystem:
orator and many of its dependencies are no longer using setup.py.
Instead they have a file called pyproject.toml and calls out to a tool
called "poetry" to create distribution tarballs, run tests, etc; and it
apparently also creates a setup.py for the PyPI distribution.

I did not study poetry enough to figure out how it works, but we might
need a poetry-build-system or some such if the trend continues.  Mainly
because all packages using it seem to be stripping tests from the PyPI
release!  :-/


signature.asc
Description: PGP signature

bug#40079: emacs-elpy-1.31.0: failed to build

[Ricardo Wurmus]

Marius Bakke  writes:

> sirgazil via Bug reports for GNU Guix  writes:
>
>> I couldn't upgrade the packages in my user profile because "emacs-elpy" 
>> check phase fails. 
>>
>>
>> ## Steps to reproduce
>>
>> 1. guix pull
>> 2. guix build emacs-elpy
>>
>>
>> ## Unexpected result
>>
>>
>> The output of the check phase:
>>
>> ---
>> starting phase `check'
>>
>> Can’t guess python-indent-offset, using defaults: 4
>
> This seems to stem from the update of 'python-black' in
> 5f603fab23e7df7e7b76566b3add24b65e92f807.  Reverting that commit makes
> this package build.
>
> @Ricardo: Any objections to reverting the commit?

I’d rather not revert but add an older variant of python-black for elpy.

-- 
Ricardo

bug#40079: emacs-elpy-1.31.0: failed to build

[Maxim Cournoyer]

Ricardo Wurmus  writes:

> Marius Bakke  writes:
>
>> sirgazil via Bug reports for GNU Guix  writes:
>>
>>> I couldn't upgrade the packages in my user profile because "emacs-elpy" 
>>> check phase fails. 
>>>
>>>
>>> ## Steps to reproduce
>>>
>>> 1. guix pull
>>> 2. guix build emacs-elpy
>>>
>>>
>>> ## Unexpected result
>>>
>>>
>>> The output of the check phase:
>>>
>>> ---
>>> starting phase `check'
>>>
>>> Can’t guess python-indent-offset, using defaults: 4
>>
>> This seems to stem from the update of 'python-black' in
>> 5f603fab23e7df7e7b76566b3add24b65e92f807.  Reverting that commit makes
>> this package build.
>>
>> @Ricardo: Any objections to reverting the commit?
>
> I’d rather not revert but add an older variant of python-black for elpy.

Perhaps the issue would vanish if we move to Elpy 1.32?  I had started
packaging it, but hit some issues.

Maxim

bug#40079: emacs-elpy-1.31.0: failed to build

[Marius Bakke]

Maxim Cournoyer  writes:

> Ricardo Wurmus  writes:
>
>> Marius Bakke  writes:
>>
>>> sirgazil via Bug reports for GNU Guix  writes:
>>>
 I couldn't upgrade the packages in my user profile because "emacs-elpy" 
 check phase fails. 


 ## Steps to reproduce

 1. guix pull
 2. guix build emacs-elpy


 ## Unexpected result


 The output of the check phase:

 ---
 starting phase `check'

 Can’t guess python-indent-offset, using defaults: 4
>>>
>>> This seems to stem from the update of 'python-black' in
>>> 5f603fab23e7df7e7b76566b3add24b65e92f807.  Reverting that commit makes
>>> this package build.
>>>
>>> @Ricardo: Any objections to reverting the commit?
>>
>> I’d rather not revert but add an older variant of python-black for elpy.
>
> Perhaps the issue would vanish if we move to Elpy 1.32?  I had started
> packaging it, but hit some issues.

In any case I'm sure sirgazil is not the only user of this package, so
we should try and find a resolution quickly.

As a side note, this bug report could have been easily prevented by
building the few packages listed by 'guix refresh -l python{,2}-black'
before pushing!  Not to single out Ricardo here (I forget this too
occasionally), but I expect contributors to do this in general and think
we should keep a low threshold for reverting breaking commits.


signature.asc
Description: PGP signature

bug#39425: On , package source links are broken.

[Ludovic Courtès]

Hi!

Alex ter Weele  skribis:

> For example,  links
> to
> ,
> which 404s.
>
> Relevant discussion from #guix:
> .

This should be fixed by f2b24f01f42c1bad3ddffd140194de1aec38a5f8.

The change of behavior was presumably caused by
09238d618a511de80de189ff3ff18bfa0f280bb9, which removed a layer of
‘canonicalize-path’, which in turn prevented relative file name
canonicalization in ‘package-field-location’ to work:

--8<---cut here---start->8---
scheme@(guix-user)> (search-path %load-path "gnu/packages/base.scm")
$1 = 
"/gnu/store/sy9sh0m6nam63iny9xcsrmn2q7pp4sik-guix-module-union/share/guile/site/3.0/gnu/packages/base.scm"
scheme@(guix-user)> (call-with-input-file $1 port-filename)
$2 = 
"/gnu/store/sy9sh0m6nam63iny9xcsrmn2q7pp4sik-guix-module-union/share/guile/site/3.0/gnu/packages/base.scm"
scheme@(guix-user)> (fluid-set! %file-port-name-canonicalization 'relative)
scheme@(guix-user)> (call-with-input-file $1 port-filename)
$3 = 
"/gnu/store/sy9sh0m6nam63iny9xcsrmn2q7pp4sik-guix-module-union/share/guile/site/3.0/gnu/packages/base.scm"
scheme@(guix-user)> %load-path
$4 = 
("/gnu/store/sy9sh0m6nam63iny9xcsrmn2q7pp4sik-guix-module-union/share/guile/site/3.0"
 "/home/ludo/.guix-profile/share/guile/site/3.0" 
"/run/current-system/profile/share/guile/site/2.2" 
"/home/ludo/.guix-profile/share/guile/site/3.0" 
"/run/current-system/profile/share/guile/site/2.2" 
"/home/ludo/.guix-profile/share/guile/site/3.0" 
"/run/current-system/profile/share/guile/site/2.2" 
"/gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/share/guile/3.0" 
"/gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/share/guile/site/3.0"
 
"/gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/share/guile/site" 
"/gnu/store/0awhym5h0m890n0wq87y0dxznh14rk88-guile-next-3.0.1/share/guile")
scheme@(guix-user)> (canonicalize-path $3)
$5 = 
"/gnu/store/1xyinzzh924fpn79mmc279n7hzwzsn8l-guix-5e78a87bb-modules/share/guile/site/3.0/gnu/packages/base.scm"
--8<---cut here---end--->8---

Since ‘scm_i_relativize_path’ in Guile starts by calling
‘canonicalize-path’, it would then search for
/gnu/store/1xyin…-guix-5e78a87bb-modules in ‘%load-path’, but it’s not
there as such.

Anyway, the web site should be fixed on the next update, within an hour.

Thanks,
Ludo’.

bug#40153: The guix package fails to build attempting to install something directly under /etc

[Ludovic Courtès]

Hi,

Leo Famulari  skribis:

> On Fri, Mar 20, 2020 at 02:48:46PM -0400, Maxim Cournoyer wrote:
>> Repro:
>> 
>> ./pre-inst-env guix build -e '((@@ (gnu packages package-management) 
>> current-guix))'
>> 
>> /gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31/bin/mkdir: cannot 
>> create directory ‘/etc/init.d’: Permission denied
>
> I guess it's related to fe60ef998f537e0e71b (guix-install.sh: Install
> SysV init script.)

Indeed.  Fixed in fe4a37276b871e29a7397b0aa940aab2b842ce77.

Thanks!

Ludo’.

bug#40158: mount point is not created if mount? is #f

[maxim . cournoyer]

Consider the following file system record:

(file-system
  (device "some-server:/mnt/scratch/yocto-sstate")"
  (mount-point "/mnt/scratch/yocto-sstate")
  (create-mount-point? #t)
  (type "nfs")
  (mount? #f)
  (options "soft")
  (flags '(no-exec)))

Even though a user would think the mount point would be created, it is
not, I'm guessing because mount? is #f.

Maxim

bug#39869: python-orator build fails

[Maxim Cournoyer]

Hey Marius!

Marius Bakke  writes:

> This was a surprisingly deep rabbit hole that ended pretty
> unsatisfactory with commit 51d42caa94515f43d677bdd76d53bf8bb8c7bc4e.
>
> According to a comment in the package definition, the tests were never
> supposed to run, so in the end they were just disabled.
>
> I discovered a pattern that I hadn't seen yet in the Python ecosystem:
> orator and many of its dependencies are no longer using setup.py.
> Instead they have a file called pyproject.toml and calls out to a tool
> called "poetry" to create distribution tarballs, run tests, etc; and it
> apparently also creates a setup.py for the PyPI distribution.

Interesting!

> I did not study poetry enough to figure out how it works, but we might
> need a poetry-build-system or some such if the trend continues.  Mainly
> because all packages using it seem to be stripping tests from the PyPI
> release!  :-/

Yeah.  Or make the python-build-system smart at detecting many
situations (as we discussed on IRC today such as guessing how to run the
test suite).

Thanks for fixing it!

Maxim

bug#40159: python-language-server-0.31.7 fails to build

[ryan]

View build log at 
'/var/log/guix/drvs/3m/x0662f42mrhvsvyahlj8ajyykq9hax-python-language-server-0.31.7.drv.bz2'.


The build log listed above ended with:

...
running "python setup.py" with command "test" and parameters ()
running test
Searching for jedi<0.16,>=0.14.1
Reading https://pypi.org/simple/jedi/
Download error on https://pypi.org/simple/jedi/: [Errno -2] Name or 
service not known -- Some packages may not be found!

Couldn't retrieve index page for 'jedi'
Scanning index of all packages (this may take a while)
Reading https://pypi.org/simple/
Download error on https://pypi.org/simple/: [Errno -2] Name or service 
not known -- Some packages may not be found!

No local packages or working download links found for jedi<0.16,>=0.14.1
error: Could not find suitable distribution for 
Requirement.parse('jedi<0.16,>=0.14.1')
command "python" "-c" "import setuptools, 
tokenize;__file__='setup.py';f=getattr(tokenize, 'open', 
open)(__file__);code=f.read().replace('\\r\\n', 
'\\n');f.close();exec(compile(code, __file__, 'exec'))" "test" failed 
with status 1