bug#35332: ruby-public-suffix bundles Mozilla's Public Suffix List

[Chris Marusich]

Chris Marusich  writes:

> We should replace the bundled version with a Guix-packaged version of
> the list.

The following patch series introduces a Guix package for the Public
Suffix List, named public-suffix-list:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35333

Once it's been merged, we can probably just use public-suffix-list to
replace the bundled list.

There may also be other packages that bundle this list.  We should find
them and un-bundle them.

-- 
Chris


signature.asc
Description: PGP signature

bug#35332: ruby-public-suffix bundles Mozilla's Public Suffix List

[Chris Marusich]

Hi,

The Guix package ruby-public-suffix bundles Mozilla's Public Suffix
List.  We should replace the bundled version with a Guix-packaged
version of the list.

The bundled list is here:

  https://github.com/weppos/publicsuffix-ruby/blob/master/data/list.txt

-- 
Chris


signature.asc
Description: PGP signature

bug#35319: Guix System installer text direction wrong for RTL languages

[Ludovic Courtès]

"pelzflorian (Florian Pelz)"  skribis:

> The
>
> https://salsa.debian.org/mckinstry/newt/blob/debian/master/debian/README.Debian
>
> says:
>
> Debian's version of newt include Bidirectional text support not yet present
> upstream, including an API addition "newtCheckboxSetWidth". Please only use
> this within Debian until it is supported upstream.
>
> There is a
>
> https://salsa.debian.org/mckinstry/newt/blob/debian/master/debian/patches/bidi.patch

Thanks for researching it.  We may be unable to fix it for 1.0 but we
should definitely address it.

Ludo’.

bug#35319: Guix System installer text direction wrong for RTL languages

[pelzflorian (Florian Pelz)]

On Fri, Apr 19, 2019 at 05:26:35PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)"  skribis:
> 
> > On Wed, Apr 17, 2019 at 12:06:31PM +0200, Ludovic Courtès wrote:
> >> I made changes to the installer so it’s almost ready as far as I’m
> >> concerned.  It now displays language and territory names in the right
> >> language.
> >> 
> >
> > Language names for Arabic, Farsi, Hebrew are shown Left-to-Right (LTR)
> > instead of Right-to-Left, e.g. العربية is displayed wrongly as ‭العربية‬.
> 
> Ouch, good point!  I have no idea what it takes to display RTL languages
> properly.  AFAIK ‘gettext’ simply returns a string, so I guess it’s up
> to the UI toolkit (Newt?) to do the right thing?
> 

Debian has a similar bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917909

The

https://salsa.debian.org/mckinstry/newt/blob/debian/master/debian/README.Debian

says:

Debian's version of newt include Bidirectional text support not yet present
upstream, including an API addition "newtCheckboxSetWidth". Please only use
this within Debian until it is supported upstream.

There is a

https://salsa.debian.org/mckinstry/newt/blob/debian/master/debian/patches/bidi.patch

However, I do not know how to use this.

Regards,
Florian

bug#35324: SDDM shows black screen instead of login prompt

[Diego Nicola Barbato]

Hello Guix,

As already mentioned on IRC SDDM does not work for me.

This is what I tried:

$ qemu-system-x86_64 -enable-kvm -snapshot -m 6G $(guix system vm-image 
--image-size=24G config.scm)

After booting I get a black screen instead of a greeter.  I have
attached the config.scm, Xorg.log, and sddm.log.

This is on Guix System (commit: 5069bae) on x86_64.

Regards,

Diego



config.scm
Description: Binary data


Xorg.0.log
Description: Binary data


sddm.log
Description: Binary data

bug#35319: Guix System installer text direction wrong for RTL languages

[Ludovic Courtès]

"pelzflorian (Florian Pelz)"  skribis:

> On Wed, Apr 17, 2019 at 12:06:31PM +0200, Ludovic Courtès wrote:
>> I made changes to the installer so it’s almost ready as far as I’m
>> concerned.  It now displays language and territory names in the right
>> language.
>> 
>
> Language names for Arabic, Farsi, Hebrew are shown Left-to-Right (LTR)
> instead of Right-to-Left, e.g. العربية is displayed wrongly as ‭العربية‬.

Ouch, good point!  I have no idea what it takes to display RTL languages
properly.  AFAIK ‘gettext’ simply returns a string, so I guess it’s up
to the UI toolkit (Newt?) to do the right thing?

Ludo’.

bug#35311: Python 2 test failures: test_httplib test_urllib2_localnet

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> 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:
>>
>> I confirm that this has been preventing ‘core-updates’ evaluations from
>> happening for a while (apparently
>> circa dd7ce8643a28f5d633c5f3124de6be897cd5065f):
>>
>>   https://berlin.guixsd.org/jobset/core-updates-core-updates
>>
>> Ludo’.
>
> Hello, I pushed commit e337061b3a on core-updates, which fixes this.

Awesome, thank you!

The build farm is busy building this right now.  :-)

Ludo’.

bug#35311: Python 2 test failures: test_httplib test_urllib2_localnet

[Maxim Cournoyer]

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:
>
> I confirm that this has been preventing ‘core-updates’ evaluations from
> happening for a while (apparently
> circa dd7ce8643a28f5d633c5f3124de6be897cd5065f):
>
>   https://berlin.guixsd.org/jobset/core-updates-core-updates
>
> Ludo’.

Hello, I pushed commit e337061b3a on core-updates, which fixes this.

Closing.

Maxim

bug#35283: ISO images are not reproducible

[Thomas Schmitt]

Hi,

> Files added by ‘grub-mkrescue’ are “out of our control” so we would need
> to patch ‘grub-mkrescue’ to honor SOURCE_DATE_EPOCH, for example.

Google shows that patches have been proposed. But they seem not to
have made it into the source.

Vladimir Serbinko's answer here
  https://lists.gnu.org/archive/html/grub-devel/2015-12/msg00046.html
might be the reason. I understand that he demands uniqueness of UUIDs.

But that's not really a problem with reproducible ISOs. If pseudo-random
UUIDs depend deterministically on SOURCE_DATE_EPOCH, then collisions are
only to expect between ISOs made with the same seconds value.
This can also happen if non-reproducible ISOs are made while their
systems' clocks show the same time by mere incident.

So one should use SOURCE_DATE_EPOCH values with best possible entropy.
Not one humanly invented lucky number for all ISOs of a distro.

If ever two identical ISOs are offered to GRUB at boot time, it needs
some imagination to construct a problem if GRUB operates on the one
which was not used by the EFI firmware to start GRUB.


So when a reproducible ISO is made for the first time, its SOURCE_DATE_EPOCH
should be taken from "date +%s" and recorded for further runs.
The ISO will bear it as "Creation Time", like "2019021612165300".
The last two digits "00" are centiseconds and should be ignored even
if not "00".
If decoding that time back to seconds-since-1970 is cumbersome, one may
store the seconds value in a data file in the input tree of the ISO
before packing up by a xorriso run with SOURCE_DATE_EPOCH having that
value.


> after rereading the Xorriso manual, it seemed to me that if we
> set SOURCE_DATE_EPOCH and pass:
>   -volume_date all_file_dates set_to_mtime
> then all the files would have the mtime specified by SOURCE_DATE_EPOCH,
> which would solve the problem.

This is the support for ignoring atime and ctime changes of input files
but respecting their mtime changes.

If you want a fixed time for all three timestamps in all files, do:

  -volume_date all_file_dates ="$SOURCE_DATE_EPOCH"

The "=" announces seconds-since-1970 as time format. See -alter_date.

Note that in this proposal $SOURCE_DATE_EPOCH is evaluated by the shell,
not by xorriso. Depending on the way how xorriso is started, you need to
insert the actual number.


Have a nice day :)

Thomas

bug#35283: ISO images are not reproducible

[Ludovic Courtès]

Hi,

(Moving discussion to , which is
specifically about ISO image reproducibility issues.)

"Thomas Schmitt"  skribis:

> Florian Pelz wrote:
>>  The content is different at the beginning of the ISO image
>> (maybe padding or timestamps in the file system)
>
> That's to expect if not environment SOURCE_DATE_EPOCH is set and exported.
>
> SOURCE_DATE_EPOCH belongs to the specs of reproducible-builds.org. It
> is supposed to be either undefined or to contain a decimal number which
> tells the seconds since january 1st 1970. If it contains a number, then
> it is used for all timestamps and as seed of pseudo-random numbers like
> MBR id or GPT UUIDs.
>
> If all files and directories have the same names and the same content,
> then xorriso runs with the same arguments and the same SOURCE_DATE_EPOCH
> value are supposed to create byte-identical result ISOs.

By mounting the ISO image, I found that some files didn’t have their
timestamp reset: some files in /var/guix (easily fixed), but more
importantly those added by GRUB in /boot and /System.

Files added by ‘grub-mkrescue’ are “out of our control” so we would need
to patch ‘grub-mkrescue’ to honor SOURCE_DATE_EPOCH, for example.

However, after rereading the Xorriso manual, it seemed to me that if we
set SOURCE_DATE_EPOCH and pass:

  -volume_date all_file_dates set_to_mtime

then all the files would have the mtime specified by SOURCE_DATE_EPOCH,
which would solve the problem.

I tried it, but that’s not what happened.  What am I missing, Thomas?

Thanks,
Ludo’.

bug#35319: Guix System installer text direction wrong for RTL languages

[pelzflorian (Florian Pelz)]

On Wed, Apr 17, 2019 at 12:06:31PM +0200, Ludovic Courtès wrote:
> I made changes to the installer so it’s almost ready as far as I’m
> concerned.  It now displays language and territory names in the right
> language.
> 

Language names for Arabic, Farsi, Hebrew are shown Left-to-Right (LTR)
instead of Right-to-Left, e.g. العربية is displayed wrongly as ‭العربية‬.

Regards,
Florian

bug#35311: Python 2 test failures: test_httplib test_urllib2_localnet

[Ludovic Courtès]

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:

I confirm that this has been preventing ‘core-updates’ evaluations from
happening for a while (apparently
circa dd7ce8643a28f5d633c5f3124de6be897cd5065f):

  https://berlin.guixsd.org/jobset/core-updates-core-updates

Ludo’.

bug#35296: gdm doesn't always start at boot

[Ludovic Courtès]

Hello,

(Please keep the bug Cc’d.)

Julien Lepiller  skribis:

> Le Tue, 16 Apr 2019 22:21:54 +0200,
> Ludovic Courtès  a écrit :

[...]

>> When GDM fails to show up,
>> does /var/lib/gdm/.local/share/xorg/Xorg*.log or
>> ~/.local/share/xorg/Xorg*.log show any hints?

> Attached is the xorg log file.

Thanks.

> [   155.937] (**) Option "fd" "25"
> [   155.937] (II) event3  - USB Optical Mouse: device removed
> [   155.937] (II) AIGLX: Suspending AIGLX clients for VT switch
> [   155.937] (II) systemd-logind: got pause for 13:67
> [   155.937] (II) systemd-logind: got pause for 13:66
> [   155.937] (II) systemd-logind: got pause for 13:70
> [   155.938] (II) systemd-logind: got pause for 13:68
> [   155.938] (II) systemd-logind: got pause for 13:65
> [   155.938] (II) systemd-logind: got pause for 226:0
> [   155.938] (II) systemd-logind: got pause for 13:69
> [   155.938] (II) systemd-logind: got pause for 13:72
> [   155.938] (II) systemd-logind: got pause for 13:64
> [ 12676.770] (EE) 
> Fatal server error:
> [ 12676.770] (EE) systemd-logind disappeared (stopped/restarted?)
> [ 12676.770] (EE) 
> [ 12676.770] (EE) 
> Please consult the The X.Org Foundation support 
>at http://wiki.x.org
>  for help. 

On my machine I have the “got pause” messages, but these are the last
messages and then everything works.

Does /var/log/messages show anything regarding elogind?  It could be
that the real problem lies with elogind, although that bit has been
reliable in my experience.

Thanks,
Ludo’.

bug#34498: Confusing msgid " Running value is ~s.~%"

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)"  skribis:

> On Thu, Apr 18, 2019 at 06:37:34PM +0200, Ludovic Courtès wrote:
>> Can you suggest a better comment?
>> 
>
> Maybe: ;; TRANSLATORS: 'running' is the name of a variable.

That’s not quite true though (it’s a slot in the  class,
technically.)

I agree that “running value” is a confusing phrase.  That’s why I wrote
that it’s a PID most of the time, hoping that this would clarify it.

> I thought #:running describes the manner in which the service is
> running.  Maybe I misunderstand.

Yeah, it’s really just a PID:

--8<---cut here---start->8---
$ sudo herd status nscd
Status of nscd:
  It is started.
  Running value is 446.
  It is enabled.
  Provides (nscd).
  Requires (user-processes).
  Conflicts with ().
  Will be respawned.
--8<---cut here---end--->8---

We’ve just received new translations, so let’s see if that looks good.

Thanks,
Ludo’.