bug#25177: Test failures don't cause some Python packages to fail

[Marius Bakke]

Leo Famulari  writes:

> On Tue, Dec 13, 2016 at 09:21:44PM +0100, Marius Bakke wrote:
>> 
>> >>> Yikes, I had hoped to avoid addressing that Nix issue and the humongous
>> >>> "fix" for a while longer:
>> >>>
>> >>> https://github.com/NixOS/nixpkgs/pull/12552
>> >>
>> >> This puill-request is huge, but for setuptools, it comes down that they
>> >> updated from 18.2 to 19.4.
>> >
>> > Sounds like we're going down the same road. I've started a branch with
>> > the earlier patch and a few other fixes. Is it ok to overwrite the
>> > existing 'python-updates' branch on Savannah?
>> 
>> There are some commits in python-updates that haven't made its way into
>> any other branches. I created a new branch 'python-tests' for this fix.
>> 
>> Please build and fix as much as possible. I'd like to get this merged
>> ASAP. @Leo can you start this branch on Hydra?
>
> Several of the commit messages were truncated because of lines that
> began with '#:tests?'. The '#' character creates a comment.
>
> I fixed the commit messages with `git rebase`. This means that most of
> the commits are now signed by me. I didn't change the commits
> themselves.
>
> The evaluation is pending:
>
> https://hydra.gnu.org/jobset/gnu/python-tests

All failures from this run should be fixed, and then some. Can you
restart it?

@Hartmut, what was your command for building everything python? :-)


signature.asc
Description: PGP signature

bug#25205: Guix package is using the GuixSD logo instead of the Guix logo

[Luis Felipe López Acevedo]

Steps to reproduce
==

1. Go to https://www.gnu.org/software/guix/packages/g.html
2. Locate a guix package, and click on the "Expand" button


Unexpected behavior
===

The description shows the logotype of the Guix System Distribution.


Expected behavior
=

The description shows the logotype of the Guix package manager.


Additional information
==

Source files for Guix and GuixSD logos are available in the artwork 
repository (see https://savannah.gnu.org/git/?group=guix).



--
Luis Felipe López Acevedo
http://sirgazil.bitbucket.org/

bug#25206: utox 0.9.8 icon is a white box

[ng0]

The statusbar/taskbar icon of utox is a white square.

Affected are at least the environments Gnome and awesome.
In awesome there is a glitch where you can see that the icon
which is being used is actually very big, and I assume the same
happens for Gnome.
All icons are installed. I will upgrade utox (new release came
out 2 days ago) and see if it addresses this bug.


ng0@wasp /gnu/store/mqvck3frgaijs64mw0ffz3fr02vq6akq-utox-0.9.8$ tree
.
├── bin
│   └── utox
└── share
├── applications
│   └── utox.desktop
├── icons
│   └── hicolor
│   ├── 128x128
│   │   └── apps
│   │   └── utox.png
│   ├── 14x14
│   │   └── apps
│   │   └── utox.png
│   ├── 16x16
│   │   └── apps
│   │   └── utox.png
│   ├── 192x192
│   │   └── apps
│   │   └── utox.png
│   ├── 22x22
│   │   └── apps
│   │   └── utox.png
│   ├── 24x24
│   │   └── apps
│   │   └── utox.png
│   ├── 256x256
│   │   └── apps
│   │   └── utox.png
│   ├── 32x32
│   │   └── apps
│   │   └── utox.png
│   ├── 36x36
│   │   └── apps
│   │   └── utox.png
│   ├── 48x48
│   │   └── apps
│   │   └── utox.png
│   ├── 512x512
│   │   └── apps
│   │   └── utox.png
│   ├── 64x64
│   │   └── apps
│   │   └── utox.png
│   ├── 72x72
│   │   └── apps
│   │   └── utox.png
│   ├── 96x96
│   │   └── apps
│   │   └── utox.png
│   └── scalable
│   └── apps
│   └── utox.svg
└── man
└── man1
└── utox.1.gz


-- 
♥Ⓐ  ng0  | ng0.chaosnet.org

bug#25200: guix lint throws gnutls error

[Ludovic Courtès]

Hi Maxim!

Maxim Cournoyer  skribis:

> I'm using an up-to-date Guix (running directly from the Git tree) and
> recently started getting the following gnutls errors when attempting to
> run "guix lint some-package". This happens for any package.
>
> The complete error traceback returned on the console looks like:
>
>  guix lint icecat
> gnu/packages/gnuzilla.scm:304:2: icecat-45.5.1-gnu1: file names of patches 
> should start with the package name

[...]

> In guix/scripts/lint.scm:
>  786: 4 [check-vulnerabilities #]
>  781: 3 [# #]
> In unknown file:
>?: 2 [force # ()>>]
> In guix/scripts/lint.scm:
>  770: 1 [#]
> In ice-9/boot-9.scm:
>  160: 0 [catch srfi-34 # 
> ...]
>
> ice-9/boot-9.scm:160:17: In procedure catch:
> ice-9/boot-9.scm:160:17: Throw to key `gnutls-error' with args 
> `(# 
> set-certificate-credentials-x509-trust-file!)'.

What is the value of SSL_CERT_DIR?  Could it be that the directory it
points to contains dangling symlinks?

The logic for this is in (guix build download); search for “x509”.

Thanks for your report!

Ludo’.

bug#25205: Guix package is using the GuixSD logo instead of the Guix logo

[Ludovic Courtès]

Hello Felipe!

Luis Felipe López Acevedo  skribis:

> Steps to reproduce
> ==
>
> 1. Go to https://www.gnu.org/software/guix/packages/g.html
> 2. Locate a guix package, and click on the "Expand" button
>
>
> Unexpected behavior
> ===
>
> The description shows the logotype of the Guix System Distribution.

The list of GNU package logos is maintained separately, in the “GNU
womb” project at .  So in
general such reports should go to bug-w...@gnu.org.

However, I would argue that the original Guix logotype is mostly
superseded by the other one.  I’ve come to the conclusion that it’s
confusion to have two logos, and that the GuixSD one is cute anyway.
:-)

WDYT?

Thanks!

Ludo’.

bug#25205: Guix package is using the GuixSD logo instead of the Guix logo

[Christopher Allan Webber]

Ludovic Courtès writes:

> Hello Felipe!
>
> Luis Felipe López Acevedo  skribis:
>
>> Steps to reproduce
>> ==
>>
>> 1. Go to https://www.gnu.org/software/guix/packages/g.html
>> 2. Locate a guix package, and click on the "Expand" button
>>
>>
>> Unexpected behavior
>> ===
>>
>> The description shows the logotype of the Guix System Distribution.
>
> The list of GNU package logos is maintained separately, in the “GNU
> womb” project at .  So in
> general such reports should go to bug-w...@gnu.org.
>
> However, I would argue that the original Guix logotype is mostly
> superseded by the other one.  I’ve come to the conclusion that it’s
> confusion to have two logos, and that the GuixSD one is cute anyway.
> :-)
>
> WDYT?

I strongly support this.

bug#25205: Guix package is using the GuixSD logo instead of the Guix logo

[Mathieu Lirzin]

Hi,

l...@gnu.org (Ludovic Courtès) writes:

> Luis Felipe López Acevedo  skribis:
>
>> Steps to reproduce
>> ==
>>
>> 1. Go to https://www.gnu.org/software/guix/packages/g.html
>> 2. Locate a guix package, and click on the "Expand" button
>>
>>
>> Unexpected behavior
>> ===
>>
>> The description shows the logotype of the Guix System Distribution.
>
> The list of GNU package logos is maintained separately, in the “GNU
> womb” project at .  So in
> general such reports should go to bug-w...@gnu.org.
>
> However, I would argue that the original Guix logotype is mostly
> superseded by the other one.  I’ve come to the conclusion that it’s
> confusion to have two logos, and that the GuixSD one is cute anyway.
> :-)

As long as Guix and GuixSD are not synonymous, I would argue that mixing
the two logos increases confusion, whether it looks pretty or not.
Especially since the logos include their name.

If the choice of using GuixSD logo when designing Guix is about
esthetics, maybe we could use the same symbol for both logos.  Maybe
with a slightly different color that would help distinguish them?

What do people think?

-- 
Mathieu Lirzin

bug#25213: Character encoding issue causing broken symlinks for profile generation

[Christopher Baines]

The profile generation/union code generates broken symlinks. I've 
reproduced this on 2 different machines (both Debian running Guix).


To reproduce, run:

  guix environment --pure --container --ad-hoc nss-certs findutils 
coreutils


[env]# find $GUIX_ENVIRONMENT/etc/ssl/certs -xtype l -exec head {} \;

head: cannot open 
'/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/Certinomis_-_Autorit??_Racine:2.1.1.pem' 
for reading: No such file or directory
head: cannot open 
'/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem' 
for reading: No such file or directory
head: cannot open 
'/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/T??RKTRUST_Elektronik_Sertifika_Hizmet_Sa??lay??c??s??_H6:2.6.125.161.242.101.236.138.pem' 
for reading: No such file or directory
head: cannot open 
'/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/AC_Ra??z_Certic??mara_S.A.:2.15.7.126.82.147.123.224.21.227.87.240.105.140.203.236.12.pem' 
for reading: No such file or directory
head: cannot open 
'/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/T??B??TAK_UEKAE_K??k_Sertifika_Hizmet_Sa??lay??c??s??_-_S??r??m_3:2.1.17.pem' 
for reading: No such file or directory
head: cannot open 
'/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/T??RKTRUST_Elektronik_Sertifika_Hizmet_Sa??lay??c??s??_H5:2.7.0.142.23.254.36.32.129.pem' 
for reading: No such file or directory


Note the ?? in the names, which are the points where the names are 
incorrect.


This will cause errors like Throw to key `gnutls-error' with args 
`(# when using Guix.

bug#25177: Test failures don't cause some Python packages to fail

[Leo Famulari]

On Thu, Dec 15, 2016 at 10:26:45AM +0100, Marius Bakke wrote:
> All failures from this run should be fixed, and then some. Can you
> restart it?

Done, thanks for working on this!


signature.asc
Description: PGP signature

bug#25200: guix lint throws gnutls error

[Christopher Baines]

On 15/12/16 16:15, Ludovic Courtès wrote:
> Hi Maxim!
> 
> Maxim Cournoyer  skribis:
> 
>> I'm using an up-to-date Guix (running directly from the Git tree) and
>> recently started getting the following gnutls errors when attempting to
>> run "guix lint some-package". This happens for any package.
>>
>> The complete error traceback returned on the console looks like:
>>
>>  guix lint icecat
>> gnu/packages/gnuzilla.scm:304:2: icecat-45.5.1-gnu1: file names of patches 
>> should start with the package name
> 
> [...]
> 
>> In guix/scripts/lint.scm:
>>  786: 4 [check-vulnerabilities #]
>>  781: 3 [# #]
>> In unknown file:
>>?: 2 [force #> ()>>]
>> In guix/scripts/lint.scm:
>>  770: 1 [#]
>> In ice-9/boot-9.scm:
>>  160: 0 [catch srfi-34 #> ()> ...]
>>
>> ice-9/boot-9.scm:160:17: In procedure catch:
>> ice-9/boot-9.scm:160:17: Throw to key `gnutls-error' with args 
>> `(# 
>> set-certificate-credentials-x509-trust-file!)'.

I hit this on Wednesday, I think its a problem in the profile generation
code, related to character encoding, and possibly to do with locales.

It was triggered by the recent nss-certs update, but I don't think that
has anything to do with it, apart from introducing some files with names
including non-ascii characters.

I've filed bug#25213 about this which includes instructions to reproduce it.



signature.asc
Description: OpenPGP digital signature

bug#25213: Character encoding issue causing broken symlinks for profile generation

[Leo Famulari]

On Thu, Dec 15, 2016 at 09:23:56PM +, Christopher Baines wrote:
> The profile generation/union code generates broken symlinks. I've reproduced
> this on 2 different machines (both Debian running Guix).

Thanks for the report!

> To reproduce, run:
> 
>   guix environment --pure --container --ad-hoc nss-certs findutils coreutils
> 
> [env]# find $GUIX_ENVIRONMENT/etc/ssl/certs -xtype l -exec head {} \;
> 
> head: cannot open 
> '/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/Certinomis_-_Autorit??_Racine:2.1.1.pem'
> for reading: No such file or directory
> head: cannot open 
> '/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny:2.6.73.65.44.228.0.16.pem'
> for reading: No such file or directory
> head: cannot open 
> '/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/T??RKTRUST_Elektronik_Sertifika_Hizmet_Sa??lay??c??s??_H6:2.6.125.161.242.101.236.138.pem'
> for reading: No such file or directory
> head: cannot open 
> '/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/AC_Ra??z_Certic??mara_S.A.:2.15.7.126.82.147.123.224.21.227.87.240.105.140.203.236.12.pem'
> for reading: No such file or directory
> head: cannot open 
> '/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/T??B??TAK_UEKAE_K??k_Sertifika_Hizmet_Sa??lay??c??s??_-_S??r??m_3:2.1.17.pem'
> for reading: No such file or directory
> head: cannot open 
> '/gnu/store/g41lycan2cq74qfs6acsxmxk4c4ra0pd-profile/etc/ssl/certs/T??RKTRUST_Elektronik_Sertifika_Hizmet_Sa??lay??c??s??_H5:2.7.0.142.23.254.36.32.129.pem'
> for reading: No such file or directory
> 
> Note the ?? in the names, which are the points where the names are
> incorrect.

The interesting thing is that the links appear to be broken in some
cases and not others:

[env]# ls -l 
'/gnu/store/xxiqkmck8g8n6ic4jbxq84m1028vhrdj-profile/etc/ssl/certs/AC_Ra??z_Certic??mara_S.A.:2.15.7.126.82.147.123.224.21.227.87.240.105.140.203.236.12.pem'
lrwxrwxrwx 3 65534 65534 164 Jan  1  1970 
'/gnu/store/xxiqkmck8g8n6ic4jbxq84m1028vhrdj-profile/etc/ssl/certs/AC_Ra??z_Certic??mara_S.A.:2.15.7.126.82.147.123.224.21.227.87.240.105.140.203.236.12.pem'
 -> 
'/gnu/store/c7kr9pdni867k2778pykh16sw003kl1s-nss-certs-3.27.2/etc/ssl/certs/AC_Ra??z_Certic??mara_S.A.:2.15.7.126.82.147.123.224.21.227.87.240.105.140.203.236.12.pem'

bug#25205: Guix package is using the GuixSD logo instead of the Guix logo

[Chris Marusich]

Mathieu Lirzin  writes:

>> However, I would argue that the original Guix logotype is mostly
>> superseded by the other one.  I’ve come to the conclusion that it’s
>> confusion to have two logos, and that the GuixSD one is cute anyway.
>> :-)
>
> As long as Guix and GuixSD are not synonymous, I would argue that mixing
> the two logos increases confusion, whether it looks pretty or not.
> Especially since the logos include their name.
>
>
> What do people think?

Please understand that this is just my own opinion.

I think branding matters.  And I think using one icon for the "Guix" and
"GuixSD" logos is better branding than two very different-looking icons.
Having two icons does not make the difference clearer.  If anything, I
feel that it is MORE confusing because it fails to emphasize the common
component: Guix.

Consider Nix.  They use only one icon [1] on the websites for Nix [2]
and NixOS [3].  When you see it, you know the brand is Nix.  Nix and
NixOS are closely related to one another, so it's natural to share the
icon.  What's the difference?  A logo won't tell you; you need to read
the manual to learn that.  But you know it's Nix, regardless of how it's
being used.

I think GNU Guix should use one logo to strengthen its branding.  The
golden GNU [4] is better than the other one [5], so that's what I'd use.

> If the choice of using GuixSD logo when designing Guix is about
> esthetics, maybe we could use the same symbol for both logos.  Maybe
> with a slightly different color that would help distinguish them?

Since the words "Guix" and "GuixSD" are already different, I don't think
they need to come in a different color.  I do like the off-color "SD" in
the "GuixSD" logo, though, since it emphasizes that it's still Guix.

[1] https://nixos.org/logo/nixos-logo-only-hires.png
[2] https://nixos.org/nix/
[3] https://nixos.org/
[4] http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/plain/logo/GuixSD.svg
[5] 
http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/plain/logo/guix-logo.svg

-- 
Chris


signature.asc
Description: PGP signature