Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-05-06 Thread Adrian Bunk
On Mon, May 04, 2020 at 02:45:41PM -0400, Noah Meyerhans wrote:
>...
> I wonder if it'd make sense for libc to be a virtual package, with
> functionality provided by optimized builds and dependencies satisfied
> via Provides.  I don't know how well dpkg would cope with transitioning
> between providers, which seems like the riskiest side of this kind of
> thing.

What would happens if apt finds a dependency solution when installing or 
updating packages that involves switching to a libc package that does
not run on your device?
There are situations where changing the libc package would be the only
possible solution of the dependencies.

IMHO there are far too many ways how such a virtual package solution 
could brick devices.

> noah

cu
Adrian



Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-05-06 Thread Steve McIntyre
Hey Aurelien,

On Sun, May 03, 2020 at 11:53:35PM +0200, Aurelien Jarno wrote:
>
>One solution for this would be to ship the optimized library in the same
>package as the default library. Now this is not acceptable for embedded
>systems as they might not need that library and can't remove it. This is
>even more problematic if we need to add more optimized libraries. I guess
>this might be the case for arm64 as there are many new extensions in the
>pipe.

ACK. It's a problem to ship the different things in separate
packages. If it's really a problem for smaller systems to have all the
variants because of size, is there maybe another way to do things? How
about keeping the existing libc and have an extra package
("libc-optimised") with all the optimised versions *and* the basic
version, and have it provide/replace/conflict libc6?

(/me prepares to be ambarrassed as you point out the obvious flaw I'm
missing...)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect."
  -- Bruce Schneier



Bug#959874: locales: default date format for en_DK and other en_* should be improved

2020-05-06 Thread Aurelien Jarno
On 2020-05-06 13:52, Vincent Lefevre wrote:
> Package: locales
> Version: 2.30-5
> Severity: wishlist
> 
> I'm using LC_TIME=en_DK for the ISO 8601 date format, i.e. when
> written with digits. But the default date format seems to be the
> same one as LC_TIME=C and should be improved. This has currently
> been done only for US:

Please note that the en_US change is controversial and likely going to
be reverted. See https://sourceware.org/bugzilla/show_bug.cgi?id=25923

I guess the same argument will apply to other locales, ie that we should
change things that have been like that for decades.

> $ for i in $(locale -a | grep en_); do printf "%-20s" $i; LC_TIME=$i date; 
> done
> en_AG   Wed  6 May 13:46:50 CEST 2020
> en_AU   Wed  6 May 13:46:50 CEST 2020
> en_AU.utf8  Wed  6 May 13:46:50 CEST 2020
> en_BW   Wed May  6 13:46:50 CEST 2020
> en_BW.utf8  Wed May  6 13:46:50 CEST 2020
> en_CA   Wed May  6 13:46:50 CEST 2020
> en_CA.utf8  Wed May  6 13:46:50 CEST 2020
> en_DK   Wed May  6 13:46:50 CEST 2020
> en_DK.iso885915 Wed May  6 13:46:50 CEST 2020
> en_DK.utf8  Wed May  6 13:46:50 CEST 2020
> en_GB   Wed  6 May 13:46:50 CEST 2020
> en_GB.iso885915 Wed  6 May 13:46:50 CEST 2020
> en_GB.utf8  Wed  6 May 13:46:50 CEST 2020
> en_HK   Wed May  6 13:46:50 CEST 2020
> en_HK.utf8  Wed May  6 13:46:50 CEST 2020
> en_IE   Wed May  6 13:46:50 CEST 2020
> en_IE.utf8  Wed May  6 13:46:50 CEST 2020
> en_IE@euro  Wed May  6 13:46:50 CEST 2020
> en_IL   Wed May  6 13:46:50 CEST 2020
> en_IN   Wed May  6 13:46:50 CEST 2020
> en_NG   Wed May  6 13:46:50 CEST 2020
> en_NZ   Wed May  6 13:46:50 CEST 2020
> en_NZ.utf8  Wed May  6 13:46:50 CEST 2020
> en_PH   Wed May  6 13:46:50 CEST 2020
> en_PH.utf8  Wed May  6 13:46:50 CEST 2020
> en_SC.utf8  Wed  6 May 13:46:50 CEST 2020
> en_SG   Wed May  6 13:46:50 CEST 2020
> en_SG.utf8  Wed May  6 13:46:50 CEST 2020
> en_US   Wed 06 May 2020 01:46:50 PM CEST
> en_US.iso885915 Wed 06 May 2020 01:46:50 PM CEST
> en_US.utf8  Wed 06 May 2020 01:46:50 PM CEST
> en_ZA   Wed May  6 13:46:50 CEST 2020
> en_ZA.utf8  Wed May  6 13:46:50 CEST 2020
> en_ZM   Wed  6 May 13:46:50 CEST 2020
> en_ZW   Wed May  6 13:46:50 CEST 2020
> en_ZW.utf8  Wed May  6 13:46:50 CEST 2020
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages locales depends on:
> ii  debconf [debconf-2.0]  1.5.74
> ii  libc-bin   2.30-5
> ii  libc-l10n  2.30-5
> 
> locales recommends no packages.
> 
> locales suggests no packages.
> 
> -- debconf information:
> * locales/default_environment_locale: None
> * locales/locales_to_be_generated: All locales
> 
> -- 
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> 
> 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#959874: locales: default date format for en_DK and other en_* should be improved

2020-05-06 Thread Vincent Lefevre
Package: locales
Version: 2.30-5
Severity: wishlist

I'm using LC_TIME=en_DK for the ISO 8601 date format, i.e. when
written with digits. But the default date format seems to be the
same one as LC_TIME=C and should be improved. This has currently
been done only for US:

$ for i in $(locale -a | grep en_); do printf "%-20s" $i; LC_TIME=$i date; done
en_AG   Wed  6 May 13:46:50 CEST 2020
en_AU   Wed  6 May 13:46:50 CEST 2020
en_AU.utf8  Wed  6 May 13:46:50 CEST 2020
en_BW   Wed May  6 13:46:50 CEST 2020
en_BW.utf8  Wed May  6 13:46:50 CEST 2020
en_CA   Wed May  6 13:46:50 CEST 2020
en_CA.utf8  Wed May  6 13:46:50 CEST 2020
en_DK   Wed May  6 13:46:50 CEST 2020
en_DK.iso885915 Wed May  6 13:46:50 CEST 2020
en_DK.utf8  Wed May  6 13:46:50 CEST 2020
en_GB   Wed  6 May 13:46:50 CEST 2020
en_GB.iso885915 Wed  6 May 13:46:50 CEST 2020
en_GB.utf8  Wed  6 May 13:46:50 CEST 2020
en_HK   Wed May  6 13:46:50 CEST 2020
en_HK.utf8  Wed May  6 13:46:50 CEST 2020
en_IE   Wed May  6 13:46:50 CEST 2020
en_IE.utf8  Wed May  6 13:46:50 CEST 2020
en_IE@euro  Wed May  6 13:46:50 CEST 2020
en_IL   Wed May  6 13:46:50 CEST 2020
en_IN   Wed May  6 13:46:50 CEST 2020
en_NG   Wed May  6 13:46:50 CEST 2020
en_NZ   Wed May  6 13:46:50 CEST 2020
en_NZ.utf8  Wed May  6 13:46:50 CEST 2020
en_PH   Wed May  6 13:46:50 CEST 2020
en_PH.utf8  Wed May  6 13:46:50 CEST 2020
en_SC.utf8  Wed  6 May 13:46:50 CEST 2020
en_SG   Wed May  6 13:46:50 CEST 2020
en_SG.utf8  Wed May  6 13:46:50 CEST 2020
en_US   Wed 06 May 2020 01:46:50 PM CEST
en_US.iso885915 Wed 06 May 2020 01:46:50 PM CEST
en_US.utf8  Wed 06 May 2020 01:46:50 PM CEST
en_ZA   Wed May  6 13:46:50 CEST 2020
en_ZA.utf8  Wed May  6 13:46:50 CEST 2020
en_ZM   Wed  6 May 13:46:50 CEST 2020
en_ZW   Wed May  6 13:46:50 CEST 2020
en_ZW.utf8  Wed May  6 13:46:50 CEST 2020

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libc-bin   2.30-5
ii  libc-l10n  2.30-5

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/default_environment_locale: None
* locales/locales_to_be_generated: All locales

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-05-06 Thread Aurelien Jarno
On 2020-05-06 13:56, Steve McIntyre wrote:
> Hey Aurelien,
> 
> On Sun, May 03, 2020 at 11:53:35PM +0200, Aurelien Jarno wrote:
> >
> >One solution for this would be to ship the optimized library in the same
> >package as the default library. Now this is not acceptable for embedded
> >systems as they might not need that library and can't remove it. This is
> >even more problematic if we need to add more optimized libraries. I guess
> >this might be the case for arm64 as there are many new extensions in the
> >pipe.
> 
> ACK. It's a problem to ship the different things in separate
> packages. If it's really a problem for smaller systems to have all the
> variants because of size, is there maybe another way to do things? How
> about keeping the existing libc and have an extra package
> ("libc-optimised") with all the optimised versions *and* the basic
> version, and have it provide/replace/conflict libc6?
> 
> (/me prepares to be ambarrassed as you point out the obvious flaw I'm
> missing...)

I guess that the provide/replace/conflict libc6 will just prevent
installation of foreign libc6 packages, basically making this optimized
package useless in the multiarch context.

OTOH, what is the drawback of having GCC defaulting to -moutline-atomics?
It will improve performance on many more packages than only glibc, and
is way easier to implement overall. It also means users has nothing to
do to get additional performances.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#959874: locales: default date format for en_DK and other en_* should be improved

2020-05-06 Thread Aurelien Jarno
On 2020-05-06 17:47, Vincent Lefevre wrote:
> On 2020-05-06 16:12:58 +0200, Aurelien Jarno wrote:
> > On 2020-05-06 13:52, Vincent Lefevre wrote:
> > > Package: locales
> > > Version: 2.30-5
> > > Severity: wishlist
> > > 
> > > I'm using LC_TIME=en_DK for the ISO 8601 date format, i.e. when
> > > written with digits. But the default date format seems to be the
> > > same one as LC_TIME=C and should be improved. This has currently
> > > been done only for US:
> > 
> > Please note that the en_US change is controversial and likely going to
> > be reverted. See https://sourceware.org/bugzilla/show_bug.cgi?id=25923
> 
> I'm not sure whether this is the same thing as this one focuses
> on day/month ordering, but there's the place of the year (which
> was actually the main thing I was thinking about).

Nope, this one indeed complains about the day/month ordering, but given
all the date part is going to be revert, the place of the year will also
be reverted.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#959874: locales: default date format for en_DK and other en_* should be improved

2020-05-06 Thread Vincent Lefevre
On 2020-05-06 16:12:58 +0200, Aurelien Jarno wrote:
> On 2020-05-06 13:52, Vincent Lefevre wrote:
> > Package: locales
> > Version: 2.30-5
> > Severity: wishlist
> > 
> > I'm using LC_TIME=en_DK for the ISO 8601 date format, i.e. when
> > written with digits. But the default date format seems to be the
> > same one as LC_TIME=C and should be improved. This has currently
> > been done only for US:
> 
> Please note that the en_US change is controversial and likely going to
> be reverted. See https://sourceware.org/bugzilla/show_bug.cgi?id=25923

I'm not sure whether this is the same thing as this one focuses
on day/month ordering, but there's the place of the year (which
was actually the main thing I was thinking about).

> I guess the same argument will apply to other locales, ie that we should
> change things that have been like that for decades.

Concerning the year, there's also a lack of consistency in Canada:

$ for i in $(locale -a | grep _CA); do printf "%-20s" $i; LC_TIME=$i date; done
en_CA   Wed May  6 17:42:39 CEST 2020
en_CA.utf8  Wed May  6 17:42:39 CEST 2020
fr_CA   mercredi 6 mai 2020, 17:42:39 (UTC+0200)
fr_CA.utf8  mercredi 6 mai 2020, 17:42:39 (UTC+0200)
ik_CA   Qit Sup  6 17:42:39 CEST 2020
iu_CA   ᐱ ᒪᐃ  6 17:42:39 CEST 2020
shs_CA  Ske Ell  6 17:42:39 CEST 2020

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)