Processed: Re: Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

2019-03-27 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> retitle 924891 glibc: misc/tst-pkey fails due to cleared PKRU register after 
> signal in amd64 32-bit compat mode
Bug #924891 [src:glibc] glibc: FTBFS: tst-pkey fails for 32-bit processes on 
Xeon SP
Changed Bug title to 'glibc: misc/tst-pkey fails due to cleared PKRU register 
after signal in amd64 32-bit compat mode' from 'glibc: FTBFS: tst-pkey fails 
for 32-bit processes on Xeon SP'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
924891: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924891
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

2019-03-27 Thread Florian Weimer
retitle 924891 glibc: misc/tst-pkey fails due to cleared PKRU register after 
signal in amd64 32-bit compat mode 
thanks

* Lucas Nussbaum:

> On 27/03/19 at 08:48 +0100, Florian Weimer wrote:
>> > If that's useful, I can easily provide access to an AWS VM to debug this
>> > issue.
>> 
>> Oh, that would be quite helpful indeed.
>
> Can you send your SSH key? (I thought there was a way to get the SSH key
> for a DD, but I cannot find it anymore)
>
> Then you will be able to ssh to root@18.184.55.40.
> There's sbuild and schroot setup on the VM.
>
> When you are done, please 'poweroff' the machine, which will terminate
> it.

The issue reproduces outside the chroot, with the stretch userland.

What happens is that once we get out of the SIGUSR1 signal handler,
the PKRU register has value zero.  This happens around this code in
the test:

  /* Check that in a signal handler, there is no access.  */
  xsignal (SIGUSR1, _handler);
  xraise (SIGUSR1);
  xsignal (SIGUSR1, SIG_DFL);
  TEST_COMPARE (sigusr1_handler_ran, 1);

I checked the following (via a breakpoint in pkey_get; I don't think
GDB can read the PKRU register directly): Inside the SIGUSR1 signal
handler, PKRU has value 0x5554, as expected for this kernel, but
after the return, we get zero.  This is the first time a signal is
delivered on the main thread, so it's consistent with fairly broken
signal handling as far as the PKRU register is concerned.  I guess
clearing PKRU in this way might even constitute a minor security bug
(because the zero value means no restrictions).

This commit looks highly relevant:

commit a4455082dc6f0b5d51a23523f77600e8ede47c79
Author: Dave Hansen 
Date:   Wed Jun 8 10:25:33 2016 -0700

x86/signals: Add missing signal_compat code for x86 features

The 32-bit siginfo is a different binary format than the 64-bit
one.  So, when running 32-bit binaries on 64-bit kernels, we have
to convert the kernel's 64-bit version to a 32-bit version that
userspace can grok.

If the siginfo_t layout is incorrect (with regards to what the
hardware writes), I expect that we might end up copying back the wrong
PKRU value.

I'm not sure what to do here.  This really looks like a kernel bug.
Maybe we should just verify that this is fixed in the buster kernel
and move on?

Lucas, can you run your rebuild tests on newer kernels?



tzdata_2019a-0+deb9u1_source.changes ACCEPTED into proposed-updates->stable-new

2019-03-27 Thread Debian FTP Masters
Mapping stretch to stable.
Mapping stable to proposed-updates.

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 27 Mar 2019 21:34:20 +0100
Source: tzdata
Binary: tzdata
Architecture: source
Version: 2019a-0+deb9u1
Distribution: stretch
Urgency: medium
Maintainer: GNU Libc Maintainers 
Changed-By: Aurelien Jarno 
Description:
 tzdata - time zone and daylight-saving time data
Changes:
 tzdata (2019a-0+deb9u1) stretch; urgency=medium
 .
   * New upstream version, affecting the following past and future
 timestamps:
 - Palestine will not start DST until 2019-03-30, instead of 2019-03-23
   as previously predicted.
 - Metlakatla ended its observance of Pacific standard time, rejoining
   Alaska Time, on 2019-01-20 at 02:00.
Checksums-Sha1:
 853b259f05422d2205fd5f683f0f05948954849e 2029 tzdata_2019a-0+deb9u1.dsc
 29cdb003e84a597a0253433401601e67865faa08 378961 tzdata_2019a.orig.tar.gz
 21a81a59e2f6c30061a8b305501f5ea21e8f5283 101712 
tzdata_2019a-0+deb9u1.debian.tar.xz
 a01194360eb8bd1aa20ef12b51665d4b62d58a22 5507 
tzdata_2019a-0+deb9u1_source.buildinfo
Checksums-Sha256:
 a4a40761510436e037bead94747441ef871987607737d47d703f73bbfbced796 2029 
tzdata_2019a-0+deb9u1.dsc
 90366ddf4aa03e37a16cd49255af77f801822310b213f195e2206ead48c59772 378961 
tzdata_2019a.orig.tar.gz
 b0e0a67122cb464901afa4a910d21da0bca86ef799875e54ba4cf3d5c54a5c92 101712 
tzdata_2019a-0+deb9u1.debian.tar.xz
 de602203adec962755d330d964fd1cdbc33fbe922fb4bb65d1e2ad3bcb2fd7b1 5507 
tzdata_2019a-0+deb9u1_source.buildinfo
Files:
 915ecdb0eb5ad74220bcb329185df67e 2029 localization required 
tzdata_2019a-0+deb9u1.dsc
 288f7b1e43018c633da108f13b27cf91 378961 localization required 
tzdata_2019a.orig.tar.gz
 6d6cb9e96cf29525f527855f86269844 101712 localization required 
tzdata_2019a-0+deb9u1.debian.tar.xz
 daf5742987ffb87794c5e5e484b7a68b 5507 localization required 
tzdata_2019a-0+deb9u1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAlyb4uAACgkQE4jA+Jno
M2uc3g//ezAudC1IolkykARvsjFsDcr7qkCE7XuXvSgYsjU0rpSYIYoWdkUdIyj6
6gD0IMjLtEBEagMvj3u0dIuqvMcpT7LV9hMYd/3+d1g2CH99/Bg3TXjQCt6gJPkn
E+gzOGriuW6lvcgYOjfb9ee1tBwiUiPlEzHC85yWjZAM5UWnpxAQ9XqJXAgOznK8
K8MnhP6MJPgAp/j04NYzugfU6ZzPUzPUEGaeSykswR2MgIUEo+ssxNFthHRhaH2R
QLZZ60UQObv/yj56T5PNnLtRav7PRf1r2pmutxxh6qUGMSZLbnC+NLlt1tH7oeHM
3wCO2whhRfM6jvJMkMUGrBtu7TuuXMlUuG932t1F+RRcwnATuURdiOEXb591Env6
hLRyLSBeVbHc1Rdl7ZwbU+Ki2FetG5WXDh9iK2Vo5hsUQZCQ5H++qqy9FcR8wV1i
ao7NJRmQLDUyVEwpjh8zOFH9WZTpeVCQhIZJZwxft+L57rGmc2yVQETedUZ/qJGc
uQlyMc+1ZFwAvjno4nONHF5c4m5/ywlhQ/QlaDQRc/E2xKLLKEldsk4aio4fAMpg
FdM7Cd3wOGdIN41AuPT7Vg5Ov3WBrA1HxsT7mduXey7XvLptnJd01heJL6/2vezN
4b9XJRi5swG0A+0tEj13remKebuUxP0BonJrSpcR/c101WnoyPs=
=SzoB
-END PGP SIGNATURE-


Thank you for your contribution to Debian.



Processing of tzdata_2019a-0+deb9u1_source.changes

2019-03-27 Thread Debian FTP Masters
tzdata_2019a-0+deb9u1_source.changes uploaded successfully to localhost
along with the files:
  tzdata_2019a-0+deb9u1.dsc
  tzdata_2019a.orig.tar.gz
  tzdata_2019a-0+deb9u1.debian.tar.xz
  tzdata_2019a-0+deb9u1_source.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)



Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

2019-03-27 Thread Lucas Nussbaum
On 27/03/19 at 22:00 +0100, Lucas Nussbaum wrote:
> On 27/03/19 at 08:48 +0100, Florian Weimer wrote:
> > > If that's useful, I can easily provide access to an AWS VM to debug this
> > > issue.
> > 
> > Oh, that would be quite helpful indeed.
> 
> Can you send your SSH key? (I thought there was a way to get the SSH key
> for a DD, but I cannot find it anymore)

I found a way. You have access.

> Then you will be able to ssh to root@18.184.55.40.
> There's sbuild and schroot setup on the VM.
> 
> When you are done, please 'poweroff' the machine, which will terminate
> it.
> 
> Lucas



Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

2019-03-27 Thread Lucas Nussbaum
On 27/03/19 at 08:48 +0100, Florian Weimer wrote:
> > If that's useful, I can easily provide access to an AWS VM to debug this
> > issue.
> 
> Oh, that would be quite helpful indeed.

Can you send your SSH key? (I thought there was a way to get the SSH key
for a DD, but I cannot find it anymore)

Then you will be able to ssh to root@18.184.55.40.
There's sbuild and schroot setup on the VM.

When you are done, please 'poweroff' the machine, which will terminate
it.

Lucas



[Git][glibc-team/tzdata] Pushed new tag debian/2019a-0+deb9u1

2019-03-27 Thread Aurelien Jarno


Aurelien Jarno pushed new tag debian/2019a-0+deb9u1 at GNU Libc Maintainers / 
tzdata

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/tree/debian/2019a-0+deb9u1
You're receiving this email because of your account on salsa.debian.org.



[Git][glibc-team/tzdata][stretch] 2 commits: New upstream version, affecting the following past and future timestamps:

2019-03-27 Thread Aurelien Jarno


Aurelien Jarno pushed to branch stretch at GNU Libc Maintainers / tzdata


Commits:
06d94d60 by Aurelien Jarno at 2019-03-27T20:34:12Z
New upstream version, affecting the following past and future timestamps:

* New upstream version, affecting the following past and future
  timestamps:
  - Palestine will not start DST until 2019-03-30, instead of 2019-03-23
as previously predicted.
  - Metlakatla ended its observance of Pacific standard time, rejoining
Alaska Time, on 2019-01-20 at 02:00.

- - - - -
aaea5de0 by Aurelien Jarno at 2019-03-27T20:34:26Z
releasing package tzdata version 2019a-0+deb9u1

- - - - -


1 changed file:

- debian/changelog


View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/compare/d39cfe4198620b6848a3427b803fedfe3ca72bd9...aaea5de0249851dcd19398273e85611979df2dcd

-- 
View it on GitLab: 
https://salsa.debian.org/glibc-team/tzdata/compare/d39cfe4198620b6848a3427b803fedfe3ca72bd9...aaea5de0249851dcd19398273e85611979df2dcd
You're receiving this email because of your account on salsa.debian.org.



Processed: retitle 924891 to glibc: FTBFS: tst-pkey fails for 32-bit processes on Xeon SP

2019-03-27 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> retitle 924891 glibc: FTBFS: tst-pkey fails for 32-bit processes on Xeon SP
Bug #924891 [src:glibc] glibc: FTBFS: 
/<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10:
 fatal error: ndbm.h: No such file or directory
Changed Bug title to 'glibc: FTBFS: tst-pkey fails for 32-bit processes on Xeon 
SP' from 'glibc: FTBFS: 
/<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10:
 fatal error: ndbm.h: No such file or directory'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
924891: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924891
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Coworking a Milano. Spazi raddoppiati e prezzi super scontati. Ti restano solo pochi giorni per approfittarne!!!

2019-03-27 Thread BonolaOffice.com
Compili QUI il modulo online e verra' ricontattato da un nostro operatore.
Oppure segnali questo NUOVO SERVIZIO ad un suo collega
Smart Working

Incremento di flessibilita' ed auto organizzazione del tempo con un conseguente 
miglioramento della qualita' della vita del lavoratore e del profitto aziendale

Nuova Modalita' Organizzativa

Pensa ai tuoi spazi come ad un Cloud. Scegli un ufficio per una persona o un 
intero team, per un giorno, una settimana, un mese o per quanti anni desideri 
modulandoli nel tempo in base alle esigenze aziendali.

Sale riunioni e Servizi

Utilizzabili per il solo tempo necessario. Attrezzate e personalizzate in 
funzione delle singole esigenze. Possibilita' di ampliare il proprio network 
incontrando nuovi potenziali clienti e partner condividendo opportunita' ed 
idee.

COME RAGGIUNGERCI
Tangenziale Ovest
Uscita Novara/Gallaratese Molino Dorino

Autostrada A4 Torino Venezia
Autostrada Milano Laghi
uscita Viale Certosa/Fiera Campionaria - Lampugnano

Metropolitana Milanese Linea 1 Rossa
Direzione Rho/Fiera - Fermata Bonola

Autobus linee di superficie
40 - 68 - 69 - 80 - 199 - 64 
Nota Importante:
BonolaOffice nel rispetto della privacy fa presente che se la comunicazione in 
oggetto dovesse risultare non gradita, ci scusiamo vivamente precisando in ogni 
caso che questa newsletter non e' riconducibile a spamming. Qualora non si 
desideri ricevere piu' questo tipo d'informazione clicchi qui .
body{ text-align: left; background: #00ECB9; font-family:arial; font-weight: 
100; } h1{ color: #396; font-weight: 100; font-size: 40px; margin: 40px 0px 
20px; } .imageIconFormContatti { position: absolute; width: 25px; left: 85%; 
top: 7px; } .etichettaCampoError{ display: block; background-color: #fcf8e3; 
border-color: #faebcc; color: #FF; float: left; width: 100%; margin-left: 
0px; padding: 10px 5px; clear:both; }  

Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

2019-03-27 Thread Florian Weimer
* Lucas Nussbaum:

> On 26/03/19 at 23:10 +0100, Aurelien Jarno wrote:
>> On 2019-03-22 17:30, Florian Weimer wrote:
>> > > About the archive rebuild: The rebuild was done on EC2 VM instances from
>> > > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
>> > > failed build was retried once to eliminate random failures.
>> > 
>> > I believe the actual test failure is tst-pkey.
>> > 
>> > Presumably, this rebuild was performed on some Xeon SP CPU.  Do you
>> > know which model?  Do you have any information about the kernel and
>> > hypervisor used?
>> > 
>> > 32-bit protection key support has had issues from time to time.
>> 
>> Do you have some more details about the issue? Is it a glibc or a kernel
>> problem?
>> 
>> If we can't fix the issue easily on the libc side, I guess the way to
>> fix that is to XFAIL that test on 32-bit x86. 
>
> If that's useful, I can easily provide access to an AWS VM to debug this
> issue.

Oh, that would be quite helpful indeed.



Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

2019-03-27 Thread Lucas Nussbaum
On 26/03/19 at 23:10 +0100, Aurelien Jarno wrote:
> On 2019-03-22 17:30, Florian Weimer wrote:
> > > About the archive rebuild: The rebuild was done on EC2 VM instances from
> > > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> > > failed build was retried once to eliminate random failures.
> > 
> > I believe the actual test failure is tst-pkey.
> > 
> > Presumably, this rebuild was performed on some Xeon SP CPU.  Do you
> > know which model?  Do you have any information about the kernel and
> > hypervisor used?
> > 
> > 32-bit protection key support has had issues from time to time.
> 
> Do you have some more details about the issue? Is it a glibc or a kernel
> problem?
> 
> If we can't fix the issue easily on the libc side, I guess the way to
> fix that is to XFAIL that test on 32-bit x86. 

If that's useful, I can easily provide access to an AWS VM to debug this
issue.

Lucas