Bug#1059923: marked as done (spread-sheet-widget_0.10-1_s390x-buildd.changes REJECTED)

[Friedrich Beckmann]

I disabled that the upstream changelog file is distributed in the debian 
package. The
spread-sheet-widget provides two binary packages

libspread-sheet-widget and
libspread-sheet-widget-dev

and both usually have the same changelog.gz which is derived from ChangeLog in 
the
source directory. I noticed the 1970 date when I build this via pbuilder but the
date was correct when I build via „debuild“.

So I guess this might be a bug in the dh_installchangelog module. For now I just
removed the upstream changelog.

Thank you for your help!

Bug#1051243: texlive-binaries -8 version fixed the problem

[Friedrich Beckmann]

The problem is gone with the -8 release of texlive-binaries.

Thanks!!!

Bug#1051243: texlive-binaries needs rebuild due to update of zlib to 1.3

[Friedrich Beckmann]

I did a rebuild of texlive-binaries from source. Then I installed the created 
packages. The build environment contains zlib1g-dev 1.3-dfsg2.

Then "apt install texlive-plain-generic“ will work.

So texlive needs a rebuild due to the zlib version update as texlive seems to 
remember which version of zlib was used during build.

Bug#1051243: PANIC: unprotected error in call to Lua API (zlib library version does not match - header: 1.2.13, library: 1.3)

[Friedrich Beckmann]

The previous error messages showed that the locale was not configured. I 
configured the locale
but the problem persists but now with an additional PANIC:

 /tmp/fmtutil.kYG8CZ8c

No pages of output.
Transcript written on pdfetex.log.
fmtutil [INFO]: log file copied to: /var/lib/texmf/web2c/pdftex/pdfetex.log
fmtutil [INFO]: /var/lib/texmf/web2c/pdftex/pdfetex.fmt installed.
fmtutil [INFO]: --- remaking dvilualatex with luatex
fmtutil: running `luatex -ini   -jobname=dvilualatex -progname=dvilualatex 
dvilualatex.ini' ...
PANIC: unprotected error in call to Lua API (zlib library version does not 
match - header: 1.2.13, library: 1.3)
Aborted
fmtutil [ERROR]: running `luatex -ini   -jobname=luatex -progname=luatex 
luatex.ini 

Bug#1051243: This affects the build of the pspp package

[Friedrich Beckmann]

Hi all,

i noticed a failure in our CI pipeline for pspp probably due to this bug. The 
problem occurs when I try to install "apt install texlive-plain-generic“. The 
install fails with


….
Processing triggers for tex-common (6.18) …
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time... 
fmtutil failed. Output has been stored in
/tmp/fmtutil.S3jngCrK
Please include this file if you report a bug.

dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 tex-common
E: Sub-process /usr/bin/dpkg returned an error code (1)
….


In /tmp/fmtutil.S3jngCrk the following error messages are shown:


 /tmp/fmtutil.S3jngCrk 
...
No pages of output.
Transcript written on latex.log.
fmtutil [INFO]: log file copied to: /var/lib/texmf/web2c/pdftex/latex.log
fmtutil [INFO]: /var/lib/texmf/web2c/pdftex/latex.fmt installed.
fmtutil [ERROR]: running `luatex -ini   -jobname=luatex -progname=luatex 
luatex.ini 

Bug#1030827: FTBFS on armhf

[Friedrich Beckmann]

Dear Niko,

thanks for figuring out the problem! I will disable the perl-module
for the moment.

Thanks!

Friedrich

> Am 10.02.2023 um 20:53 schrieb Niko Tyni :
> 
> Control: severity -1 serious
> Justification: fails to build from source
> 
> On Tue, Feb 07, 2023 at 03:47:46PM -0500, Sergio Durigan Junior wrote:
>> Source: pspp
>> Severity: important
>> Version: 1.6.2-1
> 
>> pspp is currently FTBFSing on armhf due to several Perl-related tests
>> failing with:
>> 
>> --8<---cut here---start->8---
>> +PSPP.c: loadable library and perl binaries are mismatched (got first 
>> handshake key 0xa500080, needed 0xa400080)
>> --8<---cut here---end--->8---
>> 
>> You can see the build log by inspecting reproducible-build's page:
>> 
>>  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/pspp.html
> 
> Hi, this is about 64-bit time_t, which became supported in glibc 2.34.
> 
>  https://sources.debian.org/src/glibc/2.34-7/NEWS/#L171
> 
>  * Add support for 64-bit time_t on configurations like x86 where time_t
>is traditionally 32-bit.  Although time_t still defaults to 32-bit on
>these configurations, this default may change in future versions.
>This is enabled with the _TIME_BITS preprocessor macro set to 64 and is
>only supported when LFS (_FILE_OFFSET_BITS=64) is also enabled.  It is
>only enabled for Linux and the full support requires a minimum kernel
>version of 5.1.
> 
> Perl itself is built with 32-bit time_t on Debian 32-bit architectures
> (like armhf and i386), but the pspp configure script probes and enables
> 64-bit time_t:
> 
>  checking for 64-bit time_t with _TIME_BITS=64... yes
> 
> This ends up in config.h and changes the size of the Perl interpreter
> structure around for example
> 
>  https://sources.debian.org/src/perl/5.36.0-7/intrpvar.h/#L506
> 
> making the resulting compiled Perl module binary incompatible with
> /usr/bin/perl .
> 
> I expect that configuring explicitly with --disable-year2038 would
> be a quick fix.
> 
> Longer term, we might want to start building Perl with a 64-bit time_t,
> but that's clearly stuff for the next development cycle (bookworm + 1).
> 
> BTW, would it make sense to install the PSPP Perl module in the pspp
> binary package (or a separate libpspp-perl or whatever?) Currently
> it looks like you're building it just for running the tests but then
> throwing the result away.
> 
> Hope this helps, and thanks for your work on Debian.
> -- 
> Niko Tyni   nt...@debian.org

Bug#1004070: linux-image-4.19.0-18-amd64: kernel crashes when accessing files via nfs

[Friedrich Beckmann]

Hi Salvatore,

thanks for asking! If I remember correctly later kernels did not work at the 
time when I tested this. But have not tried more recent 4.19.x kernel. At the 
moment I do not have that much time but I will share the results here once I 
test that.

Regards

Friedrich

> Am 21.01.2023 um 20:47 schrieb Salvatore Bonaccorso :
> 
> Control: tags -1 + moreinfo
> 
> Hi Friedrich,
> 
> On Thu, Jan 20, 2022 at 11:08:35AM +0100, Friedrich Beckmann wrote:
>> Package: src:linux
>> Version: 4.19.208-1
>> Severity: important
>> 
>> Dear Maintainer,
>> 
>> after dist-upgrading to debian 10 the kernel crashes when accessing
>> files on nfs mounted filesystems. The bug can be reproduced by writing
>> between 100 and 1000 files á 50MByte to the mounted filesystem. The system
>> crashes completely, i.e. you cannot ping and ssh is dead. I have
>> to powercycle via ipmi to come back.
>> 
>> The bug is not there when I boot the previous 4.9.0-16-amd64 kernel.
>> 
>> This is a headless system with 4 nvidia gpus running with the proprietary
>> nvidia driver version 470.82.01. I do not think that this is related as
>> the bug happens even when nothing is happening on the gpus. The bios is from 
>> 2015 but I
>> load the intel-microcode.
>> 
>> Looking upstream, maybe this bug is related to
>> 
>> Bug 203827 - NFS v4.1 and v4.2 still unstable - 
>> https://bugzilla.kernel.org/show_bug.cgi?id=203827
>> Bug 200145 - kernel: FS-Cache: Duplicate cookie detected - 
>> https://bugzilla.kernel.org/show_bug.cgi?id=200145
>> 
>> Regards
>> 
>> Friedrich
>> 
>> I can reproduce the bug with the following script:
>> 
>> === killer script
>> #! /bin/bash -xe
>> cnt=1
>> for (( ; ; ))
>> do
>>echo "Run: $cnt"
>>((cnt++))
>>dd if=/dev/urandom of=~/sf bs=1M count=50
>>   rm ~/sf  
>> done
>> ===
>> 
>> 
>> == kern.log
>> Jan 20 09:51:50 breakout kernel: [  133.957968] FS-Cache: Duplicate cookie 
>> detected
>> Jan 20 09:51:50 breakout kernel: [  133.959815] FS-Cache: O-cookie 
>> c=0d1e4bca [p=6521ae05 fl=212 nc=0 na=0]
>> Jan 20 09:51:50 breakout kernel: [  133.961667] FS-Cache: O-cookie d=
>>   (null) n=  (null)
>> Jan 20 09:51:50 breakout kernel: [  133.963553] FS-Cache: O-key=[16] 
>> '0400010002000801c0a8505a'
>> Jan 20 09:51:50 breakout kernel: [  133.965407] FS-Cache: N-cookie 
>> c=883b7c78 [p=6521ae05 fl=2 nc=0 na=1]
>> Jan 20 09:51:50 breakout kernel: [  133.967273] FS-Cache: N-cookie 
>> d=dc94612b n=2d9b546b
>> Jan 20 09:51:50 breakout kernel: [  133.968059] FS-Cache: N-key=[16] 
>> '0400010002000801c0a8505a'
>> Jan 20 09:51:58 breakout kernel: [  141.528246] FS-Cache: Duplicate cookie 
>> detected
>> Jan 20 09:51:58 breakout kernel: [  141.529925] FS-Cache: O-cookie 
>> c=ab5caa2d [p=6521ae05 fl=212 nc=0 na=0]
>> Jan 20 09:51:58 breakout kernel: [  141.531542] FS-Cache: O-cookie d=
>>   (null) n=  (null)
>> Jan 20 09:51:58 breakout kernel: [  141.533136] FS-Cache: O-key=[16] 
>> '0400010002000801c0a8505a'
>> Jan 20 09:51:58 breakout kernel: [  141.534743] FS-Cache: N-cookie 
>> c=65656ae5 [p=6521ae05 fl=2 nc=0 na=1]
>> Jan 20 09:51:58 breakout kernel: [  141.536340] FS-Cache: N-cookie 
>> d=dc94612b n=49e94c35
>> Jan 20 09:51:58 breakout kernel: [  141.537919] FS-Cache: N-key=[16] 
>> '0400010002000801c0a8505a'
>> Jan 20 09:52:27 breakout kernel: [  170.456631] general protection fault: 
>>  [#1] SMP PTI
>> Jan 20 09:52:27 breakout kernel: [  170.458602] CPU: 5 PID: 13651 Comm: dd 
>> Tainted: P   OE 4.19.0-18-amd64 #1 Debian 4.19.208-1
>> Jan 20 09:52:27 breakout kernel: [  170.460511] Hardware name: Supermicro 
>> SYS-7048GR-TR/X10DRG-Q, BIOS 2.0 12/31/2015
>> Jan 20 09:52:27 breakout kernel: [  170.462416] RIP: 
>> 0010:__kmalloc+0xaa/0x220
>> Jan 20 09:52:27 breakout kernel: [  170.464307] Code: 08 65 4c 03 05 cf 2e 
>> fe 78 49 83 78 10 00 49 8b 28 0f 84 0c 01 00 00 48 85 ed 0f 84 03 01 00 00 
>> 41 8b 47 20 49 8b 3f 48 01 e8 <48> 8b 18 48 89 c1 49 33 9f 38 01 00 00 48 89 
>> e8 48 0f c9 48 31 cb
>> Jan 20 09:52:27 breakout kernel: [  170.466332] RSP: 0018:9dfda84cf5b8 
>> EFLAGS: 00010282
>> Jan 20 09:52:27 breakout kernel: [  170.468343] RAX: bf0892e61936d294 RBX: 
>>  RCX: 2a674397
>> Jan 20

Bug#1004070: Acknowledgement (linux-image-4.19.0-18-amd64: kernel crashes when accessing files via nfs)

[Friedrich Beckmann]

I filed a reference to this bug in upstream in the mentioned upstream bugs.

Bug#1004070: linux-image-4.19.0-18-amd64: kernel crashes when accessing files via nfs

[Friedrich Beckmann]

Package: src:linux
Version: 4.19.208-1
Severity: important

Dear Maintainer,

after dist-upgrading to debian 10 the kernel crashes when accessing
files on nfs mounted filesystems. The bug can be reproduced by writing
between 100 and 1000 files á 50MByte to the mounted filesystem. The system
crashes completely, i.e. you cannot ping and ssh is dead. I have
to powercycle via ipmi to come back.

The bug is not there when I boot the previous 4.9.0-16-amd64 kernel.

This is a headless system with 4 nvidia gpus running with the proprietary
nvidia driver version 470.82.01. I do not think that this is related as
the bug happens even when nothing is happening on the gpus. The bios is from 
2015 but I
load the intel-microcode.

Looking upstream, maybe this bug is related to

Bug 203827 - NFS v4.1 and v4.2 still unstable - 
https://bugzilla.kernel.org/show_bug.cgi?id=203827
Bug 200145 - kernel: FS-Cache: Duplicate cookie detected - 
https://bugzilla.kernel.org/show_bug.cgi?id=200145

Regards

Friedrich

I can reproduce the bug with the following script:

=== killer script
#! /bin/bash -xe
cnt=1
for (( ; ; ))
do
echo "Run: $cnt"
((cnt++))
dd if=/dev/urandom of=~/sf bs=1M count=50
   rm ~/sf  
done
===


== kern.log
Jan 20 09:51:50 breakout kernel: [  133.957968] FS-Cache: Duplicate cookie 
detected
Jan 20 09:51:50 breakout kernel: [  133.959815] FS-Cache: O-cookie 
c=0d1e4bca [p=6521ae05 fl=212 nc=0 na=0]
Jan 20 09:51:50 breakout kernel: [  133.961667] FS-Cache: O-cookie d=  
(null) n=  (null)
Jan 20 09:51:50 breakout kernel: [  133.963553] FS-Cache: O-key=[16] 
'0400010002000801c0a8505a'
Jan 20 09:51:50 breakout kernel: [  133.965407] FS-Cache: N-cookie 
c=883b7c78 [p=6521ae05 fl=2 nc=0 na=1]
Jan 20 09:51:50 breakout kernel: [  133.967273] FS-Cache: N-cookie 
d=dc94612b n=2d9b546b
Jan 20 09:51:50 breakout kernel: [  133.968059] FS-Cache: N-key=[16] 
'0400010002000801c0a8505a'
Jan 20 09:51:58 breakout kernel: [  141.528246] FS-Cache: Duplicate cookie 
detected
Jan 20 09:51:58 breakout kernel: [  141.529925] FS-Cache: O-cookie 
c=ab5caa2d [p=6521ae05 fl=212 nc=0 na=0]
Jan 20 09:51:58 breakout kernel: [  141.531542] FS-Cache: O-cookie d=  
(null) n=  (null)
Jan 20 09:51:58 breakout kernel: [  141.533136] FS-Cache: O-key=[16] 
'0400010002000801c0a8505a'
Jan 20 09:51:58 breakout kernel: [  141.534743] FS-Cache: N-cookie 
c=65656ae5 [p=6521ae05 fl=2 nc=0 na=1]
Jan 20 09:51:58 breakout kernel: [  141.536340] FS-Cache: N-cookie 
d=dc94612b n=49e94c35
Jan 20 09:51:58 breakout kernel: [  141.537919] FS-Cache: N-key=[16] 
'0400010002000801c0a8505a'
Jan 20 09:52:27 breakout kernel: [  170.456631] general protection fault:  
[#1] SMP PTI
Jan 20 09:52:27 breakout kernel: [  170.458602] CPU: 5 PID: 13651 Comm: dd 
Tainted: P   OE 4.19.0-18-amd64 #1 Debian 4.19.208-1
Jan 20 09:52:27 breakout kernel: [  170.460511] Hardware name: Supermicro 
SYS-7048GR-TR/X10DRG-Q, BIOS 2.0 12/31/2015
Jan 20 09:52:27 breakout kernel: [  170.462416] RIP: 0010:__kmalloc+0xaa/0x220
Jan 20 09:52:27 breakout kernel: [  170.464307] Code: 08 65 4c 03 05 cf 2e fe 
78 49 83 78 10 00 49 8b 28 0f 84 0c 01 00 00 48 85 ed 0f 84 03 01 00 00 41 8b 
47 20 49 8b 3f 48 01 e8 <48> 8b 18 48 89 c1 49 33 9f 38 01 00 00 48 89 e8 48 0f 
c9 48 31 cb
Jan 20 09:52:27 breakout kernel: [  170.466332] RSP: 0018:9dfda84cf5b8 
EFLAGS: 00010282
Jan 20 09:52:27 breakout kernel: [  170.468343] RAX: bf0892e61936d294 RBX: 
 RCX: 2a674397
Jan 20 09:52:27 breakout kernel: [  170.470390] RDX: b080 RSI: 
006000c0 RDI: 00025540
Jan 20 09:52:27 breakout kernel: [  170.472401] RBP: bf0892e61936d294 R08: 
8cbaff965540 R09: 8cbaff407300
Jan 20 09:52:27 breakout kernel: [  170.474421] R10: 8cbaf2bed684 R11: 
8cbae401a940 R12: 006000c0
Jan 20 09:52:27 breakout kernel: [  170.476444] R13: 0029 R14: 
8cbaff407780 R15: 8cbaff407780
Jan 20 09:52:27 breakout kernel: [  170.478471] FS:  7f0afeeeb580() 
GS:8cbaff94() knlGS:
Jan 20 09:52:27 breakout kernel: [  170.480520] CS:  0010 DS:  ES:  
CR0: 80050033
Jan 20 09:52:27 breakout kernel: [  170.482546] CR2: 7f0afe9ee000 CR3: 
001025e86003 CR4: 003606e0
Jan 20 09:52:27 breakout kernel: [  170.484586] DR0:  DR1: 
 DR2: 
Jan 20 09:52:27 breakout kernel: [  170.486614] DR3:  DR6: 
fffe0ff0 DR7: 0400
Jan 20 09:52:27 breakout kernel: [  170.488640] Call Trace:
Jan 20 09:52:27 breakout kernel: [  170.490698]  ? 
nfs4_init_uniform_client_string+0x50/0x140 [nfsv4]
Jan 20 09:52:27 breakout kernel: [  170.492744]  
nfs4_init_uniform_client_string+0x50/0x140 [nfsv4]
Jan 20 09:52:27 breakout kernel: [  170.494784]  

Bug#1002473: Debian Bug pspp

[Friedrich Beckmann]

Control: Tags -1 fixed-upstream

I cannot reproduce the bug in the current git version. So it should be fixed 
with the next upcoming release which we plan in the next couple of weeks.

Bug#1002473: Bugreport debian

[Friedrich Beckmann]

Control: Tags -1 confirmed

Hi Florine,

thanks for your bug report. I can see the same behaviour here on MacOS.

Regards

Friedrich

Bug#995788: [src:spread-sheet-widget] Updating the spread-sheet-widget Uploaders list

[Friedrich Beckmann]

I guess we will do a new release of pspp together with a new release of the 
spread-sheet-widget in sooner future.

Bug#963220: ELPA: pspp-mode.el installed in package pspp 1.2.0-5 via dh_elpa cannot be installed

[Friedrich Beckmann]

Hi Nicholas,

thanks for looking into the problem!

> Am 20.06.2020 um 22:22 schrieb Nicholas D Steeves :
> 
> Control: tag -1 moreinfo
> 
> Hi,
> 
> Lev, I've CCed you with a question at the bottom (the question is #3).
> 
> Friedrich Beckmann  writes:
> 
>> Package: dh-elpa
>> Version: 2.0.3
>> 
>> Hi,
>> 
>> i run some tests on debian testing. I installed the recently build
>> pspp 1.2.0-5 package which uses dh-elpa to install pspp-mode.el
>> for emacs.
> 
> Installed with dpkg/apt?

Installed with apt.

> 
>> In the current emacs version in testing 1:26.3+1-2
>> I cannot install the package. When I run 
>> 
>> M-x package-list-packages
>> 
>> I see:
>>  ...
>>  zones  2019.7.13 available  Zones of text - like multiple 
>> regions
>>  ztree  1.0.5 available  Text mode directory tree
>>  poker  0.2   installed  Texas hold 'em poker
>>  psgml  1.3.4 installed  SGML-editing mode with parsing 
>> support
>>  dh-elpa2.0.4 external   package.el style packages for 
>> Debian
>>  pspp-mode  1.0   external   Major mode for editing PSPP 
>> files
> 
>* if you click on pspp-mode I think you'll find
>  Status: External in 
> ‘/usr/share/emacs/site-lisp/elpa-src/pspp-mode-1.0/pspp-mode.el’

I see:
 Status: External in ‘/usr/share/emacs/site-lisp/elpa/pspp-mode-1.0/’ 
(unsigned).

>* "Status: External" means it has been installed.
>* What does M-x locate-library psp-mode return?

M-x locate-library pspp-mode returns:

Library is file /usr/share/emacs/site-lisp/pspp/pspp-mode.el

>> There are only the dh-elpa and the pspp-mode package listed as „external“. 
>> When
>> I type „i“ to install pspp-mode, then this does not work.
> 
> Haven't you already installed it with 'apt install pspp‘?

Yes, I have and I expected that I can activate the pspp-mode simply
with "M-x pspp-mode“, but that is not possible. I have to do

M-x load-library pspp-mode.el (loading from 
/usr/share/emacs/site-lisp/pspp/pspp-mode.el)

and then I can do

M-x pspp-mode

to switch the mode. As far as I remember the only requirement for that
would be to have just the pspp-mode.el file in that path, no?

>> This works for the „available“ packages. So listing works, the info is
>> shown but I cannot use the package. It seems that nobody else uses
>> dh-elpa right?
> 
> Plenty of people use dh-elpa :-)  At this point it's unclear what you're
> reporting.  Maybe it's one of these?:
> 
> 1. pspp regression after converting to dh-elpa
>   * normal bug, against in pspp package

Maybe I use dh-elpa in wrong way in the pspp debian package setup.
I remember that it worked some time ago but today it does not.

> 2. request to install Debian packages from the 'package-list-packages'
>   interface.
>   * wishlist bug in src:emacs (in a desktop-general sense) to add
> Debian package management to packages.el

No, I expect that I can activate the pspp-mode right after installation
of the pspp package via apt.

> 3. request for information about how to install elpa-foo packages using
>   apt from inside emacs.  Lev, I seem to remember that you maintain one
>   or two packages that can do this.

No, I do not want to run apt from within emacs.

> 4. something else

As far as I remember the dh-elpa procedure worked some time ago but now
it is at least unexpected behaviour. I expect that I can use the
pspp-mode after the installation of the pspp package directly. But
this does not happen. Maybe I use the dh-elpa package in a wrong way
during the preparation of the pspp debian package. Maybe I use
emacs in a wrong way. Maybe emacs is broken with external packages.
The pspp debian package is here:

https://salsa.debian.org/science-team/pspp/-/tree/master/debian

Thanks for your detailed questions! I hope I could clarify the
things. It would really help if somebody with more experience with
emacs and dh-elpa could have a look at this. 

> Cheers,
> Nicholas

Bug#963220: ELPA: pspp-mode.el installed in package pspp 1.2.0-5 via dh_elpa cannot be installed

[Friedrich Beckmann]

Package: dh-elpa
Version: 2.0.3

Hi,

i run some tests on debian testing. I installed the recently build
pspp 1.2.0-5 package which uses dh-elpa to install pspp-mode.el
for emacs. In the current emacs version in testing 1:26.3+1-2
I cannot install the package. When I run 

M-x package-list-packages

I see:
  ...
  zones  2019.7.13 available  Zones of text - like multiple 
regions
  ztree  1.0.5 available  Text mode directory tree
  poker  0.2   installed  Texas hold 'em poker
  psgml  1.3.4 installed  SGML-editing mode with parsing 
support
  dh-elpa2.0.4 external   package.el style packages for 
Debian
  pspp-mode  1.0   external   Major mode for editing PSPP files
  ada-mode   4.0   built-in   major-mode for editing Ada sources
  ...

There are only the dh-elpa and the pspp-mode package listed as „external“. When
I type „i“ to install pspp-mode, then this does not work. This works for the
„available“ packages. So listing works, the info is shown but I cannot use the
package. It seems that nobody else uses dh-elpa right?

Friedrich

Bug#942609: pspp: Debian / Ubuntu - Compiler settings for ppc64el architecture

[Friedrich Beckmann]

Hi Steve,

thanks for the bug report and your patch. From my point of view this is a bug 
in the compiler if the test suite does not pass on the ppc64el architecture 
with -O3 optimization settings on Ubuntu. However, the problem seems still to 
be there when 1.2.0-4 was compiled on 22nd of May: 

https://launchpad.net/ubuntu/+source/pspp

pspp still fails on ppc64el and riscv64 on ubuntu without the patch, i.e. with 
-O3, while it works on Debian:

https://buildd.debian.org/status/package.php?p=pspp

I think I will include your patch.

Friedrich

Bug#932951: Updated 1.2.0-4 package in NEW queue

[Friedrich Beckmann]

I made a new package version 1.2.0-4 which removes the
texlive-generic-recommended dependency. The package is currently in the
NEW/unstable queue. Thanks for all your work here.

Friedrich

Bug#916902: Taking over pspp into Debian Science team maintenance (Was: pspp: CVE-2018-20230)

[Friedrich Beckmann]

Hi Andreas,

i created the account beckmanf-guest at salsa.

Regards

Friedrich

> Am 23.04.2019 um 13:18 schrieb Andreas Tille :
> 
> Hi Friedrich,
> 
> thanks for the quick confirmation.
> I've injected the packaging into
> 
>   https://salsa.debian.org/science-team/pspp
> 
> and added Ben Pfaff to the Debian Science team.  Please create a login
> on Salsa yourself to enable you becoming a member of the team and thus
> getting commit permissions.
> 
> Kind regards
> 
>Andreas.
> 
> On Tue, Apr 23, 2019 at 11:17:23AM +0200, Friedrich Beckmann wrote:
>> Hi Andreas,
>> 
>> thanks for your offer to add the bugfix! You are of course welcome to do so.
>> You can also create a project for the debian parts of pspp in salsa.
>> 
>> Regards
>> 
>> Friedrich
>> 
>>> Am 23.04.2019 um 08:44 schrieb Andreas Tille :
>>> 
>>> Hi Friedrich,
>>> 
>>> I stumbled upon #916902 in my Buster bug squashing effort.  I'm willing
>>> to apply and upload the suggested fix[1], but I feel our both time
>>> better spent if the changes are done in a repository on Salsa.  Since
>>> the package perfectly fits into Debian Science scope I'd volunteer to
>>> move the package to Debian Science.
>>> 
>>> In case I will not hear from you I in the next five days asume you agree
>>> with this.
>>> 
>>> Kind regards
>>> 
>>> Andreas.
>>> 
>>> 
>>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916902#32
>>> 
>>> --
>>> http://fam-tille.de
>> 
>> 
> 
> -- 
> http://fam-tille.de

Bug#916902: Taking over pspp into Debian Science team maintenance (Was: pspp: CVE-2018-20230)

[Friedrich Beckmann]

Hi Andreas,

thanks for your offer to add the bugfix! You are of course welcome to do so.
You can also create a project for the debian parts of pspp in salsa.

Regards

Friedrich

> Am 23.04.2019 um 08:44 schrieb Andreas Tille :
>
> Hi Friedrich,
>
> I stumbled upon #916902 in my Buster bug squashing effort.  I'm willing
> to apply and upload the suggested fix[1], but I feel our both time
> better spent if the changes are done in a repository on Salsa.  Since
> the package perfectly fits into Debian Science scope I'd volunteer to
> move the package to Debian Science.
>
> In case I will not hear from you I in the next five days asume you agree
> with this.
>
> Kind regards
>
>  Andreas.
>
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916902#32
>
> --
> http://fam-tille.de

Bug#913118: libspread-sheet-widget package required for pspp

[Friedrich Beckmann]

Hi folks,

the pspp package 0.10.1 has been removed from debian today due to a build 
failure in the regression:

https://tracker.debian.org/pkg/pspp

The new pspp 1.2.0 release is already waiting in mentors

https://mentors.debian.net/package/pspp

but that release needs the libspread-sheet-widget which is a new package 
waiting since 8 days:

https://ftp-master.debian.org/new/spread-sheet-widget_0.3-1.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913118

If there is anything missing - please let me know.

Friedrich

Bug#913118: ITP: libspread-sheet-widget -- gtk3 widget for spread sheet like tabular data required for pspp

[Friedrich Beckmann]

Package: wnpp
Severity: wishlist
Owner: Friedrich Beckmann 

* Package name  : libspread-sheet-widget
  Version   : 0.3
  Upstream Author   : John Darrington 
* URL   : https://savannah.gnu.org/projects/ssw
* License   : GPL-3
  Programming Lang  : C
  Description   : gtk3 widget for data like a spread sheet  

The next 1.2.0 release of pspp requires a new gtk3 spread sheet
widget which is provided as a standalone library to use for
others. The widget allows to display and modify data in a spread
sheet like manner.

Friedrich Beckmann

Bug#909857: fixed upstream

[Friedrich Beckmann]

tags 909857 + fixed-upstream
thanks

This is fixed upstream in

https://savannah.gnu.org/bugs/?52072 

Bug#872987: pspp 1.0.0-1 FTBFS on mips64el architecture on debian

[Friedrich Beckmann]

Package: pspp
Version: 1.0.0-1

pspp 1.0.0-1 fails the regression test with 6 failed tests for the architecture 
mips64el
on debian. All other architectures pass.

See: https://buildd.debian.org/status/package.php?p=pspp=unstable

The previous version 0.10.2-2 passed the regression on mips64el. I suspect that 
the
failures are due to the switch from gcc6 to gcc7 and/or the switch in the gnulib
version or the recent changes in sys-file-reader due to 64bit and endianess.
0.10.2-2 failed to compile with gcc7 due to the old gnulib version.

See: https://buildd.debian.org/status/logs.php?pkg=pspp=mips64el

The failed tests are:

67: value labelsFAILED 
(sys-file-reader.at:428)
138: bad variable name in long string value labelFAILED 
(sys-file-reader.at:3513)
160: write and read long string value labels and missing values FAILED 
(sys-file.at:91)
172: system file character encoding  FAILED (sys-file.at:467)
1152: Perl write variable parameters  FAILED 
(perl-module.at:236)
1160: Perl Pspp.t FAILED 
(perl-module.at:677)

The detailed log shows:

## -- ##
## Detailed failed tests. ##
## -- ##

# -*- compilation -*-
67. sys-file-reader.at:308: testing value labels ...
./sys-file-reader.at:422: sack --$variant sys-file.sack > sys-file.sav
./sys-file-reader.at:427: pspp -o pspp.csv sys-file.sps
./sys-file-reader.at:428: cat pspp.csv
--- -   2017-08-21 12:23:32.674887492 +
+++ /<>/tests/testsuite.dir/at-groups/67/stdout2017-08-21 
12:23:32.662266407 +
@@ -67,23 +67,8 @@
 
 Value,Label
 JKLMNOPQ,value label for `JKLMNOPQ'",13
-str9ж,"Format: A9
-
-Value,Label
-RSTUVWXYZ,value label for `RSTUVWXYZ'",14
-str12,"Format: A12
-
-Value,Label
-0123456789ab,value label for `0123456789ab'
-cdefghijklmn,value label for `cdefghijklmn'",15
-str16,"Format: A16
-
-Value,Label
-EFGHIJKLMNOPQRST,value label for `EFGHIJKLMNOPQRST'
-UVWXYZ0123456789,value label for `UVWXYZ0123456789' with Cyrillic letters: 
`фхц'
-opqrstuvwxyzABCD,value label for `opqrstuvwxyzABCD'",16
-str17,"Format: A17
-
-Value,Label
-abcdefghijklmnopq,value label for `abcdefghijklmnopq'",17
+str9ж,Format: A9,14
+str12,Format: A12,15
+str16,Format: A16,16
+str17,Format: A17,17
 
67. sys-file-reader.at:308: 67. value labels (sys-file-reader.at:308): FAILED 
(sys-file-reader.at:428)

# -*- compilation -*-
138. sys-file-reader.at:3468: testing bad variable name in long string value 
label ...
./sys-file-reader.at:3510: sack --$variant sys-file.sack > sys-file.sav
./sys-file-reader.at:3513: pspp -O format=csv sys-file.sps
--- -   2017-08-21 12:24:28.997836833 +
+++ /<>/tests/testsuite.dir/at-groups/138/stdout   2017-08-21 
12:24:28.986496047 +
@@ -6,5 +6,3 @@
 
 "warning: `sys-file.sav' near offset 0x1d4: Ignoring long string value label 0 
for variable str14, with width 14, that has bad value width 9."
 
-warning: `sys-file.sav' near offset 0x259: Duplicate value label for 
`abcdefghijklmn' on str14.
-
138. sys-file-reader.at:3468: 138. bad variable name in long string value label 
(sys-file-reader.at:3468): FAILED (sys-file-reader.at:3513)

# -*- compilation -*-
160. sys-file.at:62: testing write and read long string value labels and 
missing values ...
./sys-file.at:90: pspp -o pspp.csv sysfile.sps
./sys-file.at:91: cat pspp.csv
--- -   2017-08-21 12:24:42.428694787 +
+++ /<>/tests/testsuite.dir/at-groups/160/stdout   2017-08-21 
12:24:42.414550801 +
@@ -1,18 +1,8 @@
 Variable,Description,Position
 s1,"Format: A9
-Missing Values: ""0   ""
-
-Value,Label
-abc  ,First value label
-abcdefgh ,Second value label
-abcdefghi,Third value label",1
+Missing Values: ""0   """,1
 s2,"Format: A9
-Missing Values: ""12  ""; ""123 ""
-
-Value,Label
-0,Fourth value label
-01234567 ,Fifth value label
-012345678,Sixth value label",2
+Missing Values: ""12  ""; ""123 """,2
 s3,"Format: A9
 Missing Values: ""1234""; ""12345   ""; ""12345678""",3
 
160. sys-file.at:62: 160. write and read long string value labels and missing 
values (sys-file.at:62): FAILED (sys-file.at:91)

# -*- compilation -*-
172. sys-file.at:433: testing system file character encoding ...
./sys-file.at:434: i18n-test supports_encodings windows-1252
./sys-file.at:459: pspp -O format=csv save.sps
./sys-file.at:466: pspp -o pspp.csv get.sps
./sys-file.at:467: sed 's/(Entered [^)]*)/(Entered )/' pspp.csv
--- -   2017-08-21 12:24:47.250095314 +
+++ /<>/tests/testsuite.dir/at-groups/172/stdout   2017-08-21 
12:24:47.230570439 +
@@ -19,10 +19,7 @@
 Attribute,Value
 Atatürk,Düsseldorf Gewürztraminer",1
 roué,"Label: Provençal soupçon
-Format: A9
-
-Value,Label
-abcdefghi,sauté précis",2
+Format: A9",2
 croûton,Format: A1000,3
 
 Table: Custom data file attributes.
172. sys-file.at:433: 172. 

Bug#866890: pspp - cve-2017-10791 - cve-2017-10792

[Friedrich Beckmann]

Hi Ben,

my understanding is that they bring up two different problems.

For

https://bugzilla.redhat.com/show_bug.cgi?id=1467004 (Hash Function)

the argument is that shift operations and overflows are undefined or
implementation dependent for signed integers as used in the hash function.

https://www.securecoding.cert.org/confluence/display/c/INT13-C.+Use+bitwise+operators+only+on+unsigned+operands

Shifting a negative number is „bad“ by that definition and that is what they 
checked.

But when looking at the code, isn’t there a problem when a pointer is cast to 
integer
on 64 Bit platforms because the pointer is 64 Bit and the integer is 32 Bit in 
hash_pointer? Wouldn’t we
want to have a hash based on the 64 Bit as for hash_double?

For https://bugzilla.redhat.com/show_bug.cgi?id=1467005 (crash on csv 
conversion)

they managed to generate a file which results in a crash when analyzed. 
Although pspp
stills gives an error message that something is wrong in the file… 

Friedrich


> Am 04.07.2017 um 15:27 schrieb Ben Pfaff <b...@cs.stanford.edu>:
> 
> The attribution of the problem to the hash function is probably wrong,
> since that function is purely combinatorial logic, but the report as a
> whole is right because the attachment in the bug report at
> https://bugzilla.redhat.com/show_bug.cgi?id=1467004 does cause
> pspp-convert to assert-fail.
> 
> I'm looking into it.
> 
> On Mon, Jul 03, 2017 at 08:50:56PM +0200, John Darrington wrote:
>> I suspect this report is mistaken.  But this bit is Ben's code, so I'll let 
>> him comment on
>> that.
>> 
>> J'
>> 
>> On Mon, Jul 03, 2017 at 07:22:57AM +0200, Friedrich Beckmann wrote:
>> Dear owl337 team,
>> 
>> thanks for looking at pspp and finding the security problems
>> 
>> https://security-tracker.debian.org/tracker/CVE-2017-10791
>> 
>> and
>> 
>> https://security-tracker.debian.org/tracker/CVE-2017-10792
>> 
>> in pspp! Your reports are quite detailed. Could you describe how you 
>> found the problems, i.e. do
>> you have some information about collAFL?
>> 
>> Regards
>> 
>> Friedrich
>> 
>> 
>> 
>> ___
>> pspp-dev mailing list
>> pspp-...@gnu.org
>> https://lists.gnu.org/mailman/listinfo/pspp-dev
>> 
>> -- 
>> Avoid eavesdropping.  Send strong encrypted email.
>> PGP Public key ID: 1024D/2DE827B3 
>> fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
>> See http://sks-keyservers.net or any PGP keyserver for public key.
>> 
> 
> 

Bug#866890: pspp - cve-2017-10791 - cve-2017-10792

[Friedrich Beckmann]

Hi John,


> Am 04.07.2017 um 07:10 schrieb John Darrington <j...@darrington.wattle.id.au>:
> 
> On Mon, Jul 03, 2017 at 11:37:30PM +0200, Friedrich Beckmann wrote:
> Hi John,
> 
> today I looked a little bit at the hash function. I think the problem is 
> that compared to
> the referenced code the x parameter is type int instead of unsigned int. 
> Googling around the
> overflow behavior of signed and the shift right of signed is not defined 
> in the c standard
> although ???many?" implementations assume 2th complement signed 
> implementation. Both is well
> defined for unsigned int operations.
> 
> Ahh.  Perhaps you're right.  But I cannot see that this would cause a crash, 
> so I suspect that's
> another problem.

They compiled with a compiler switch -fsanitized=undefined. I assume that this 
produces the crash.

> I changed the parameter type from int to unsigned int and I cannot see a 
> problem in the regression.
> 
> What problems did you encounter before your change (if any)?

I encountered no problems. At first I assumed that they use some form of static 
code analysis. Then I tried
to run our regression with the above mentioned switch but on MacOS I 
encountered some compile problems.

In my view the behavior in our code might produce a bad hash as it deviates 
from the original code as the right
shift is different for int and unsigned int. But I cannot see how this produces 
a security vulnerability.

Friedrich



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#866890: pspp - cve-2017-10791 - cve-2017-10792

[Friedrich Beckmann]

Hi John,

today I looked a little bit at the hash function. I think the problem is that 
compared to
the referenced code the x parameter is type int instead of unsigned int. 
Googling around the
overflow behavior of signed and the shift right of signed is not defined in the 
c standard
although „many?" implementations assume 2th complement signed implementation. 
Both is well
defined for unsigned int operations.

I changed the parameter type from int to unsigned int and I cannot see a 
problem in the regression.

But looking at the code I wondered if this hash function also works on 64 Bit 
architectures. The
reference only talks about uint32_t.

Regards

Friedrich


> Am 03.07.2017 um 20:50 schrieb John Darrington <j...@darrington.wattle.id.au>:
> 
> I suspect this report is mistaken.  But this bit is Ben's code, so I'll let 
> him comment on
> that.
> 
> J'
> 
> On Mon, Jul 03, 2017 at 07:22:57AM +0200, Friedrich Beckmann wrote:
> Dear owl337 team,
> 
> thanks for looking at pspp and finding the security problems
> 
> https://security-tracker.debian.org/tracker/CVE-2017-10791
> 
> and
> 
> https://security-tracker.debian.org/tracker/CVE-2017-10792
> 
> in pspp! Your reports are quite detailed. Could you describe how you 
> found the problems, i.e. do
> you have some information about collAFL?
> 
> Regards
> 
> Friedrich
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#866890: pspp - cve-2017-10791 - cve-2017-10792

[Friedrich Beckmann]

Dear owl337 team,

thanks for looking at pspp and finding the security problems

https://security-tracker.debian.org/tracker/CVE-2017-10791

and

https://security-tracker.debian.org/tracker/CVE-2017-10792

in pspp! Your reports are quite detailed. Could you describe how you found the 
problems, i.e. do
you have some information about collAFL?

Regards

Friedrich

Bug#853623: pspp fails to build on debian with gcc-7

[Friedrich Beckmann]

Hi,

i could reproduce the problem in the current upstream version. The reason is an 
old
version of gnulib that we use. I guess we will fix this upstream and make a new 
release.

Friedrich

Bug#850457: pspp 0.10.2-1 FTBS randomly

[Friedrich Beckmann]

> Am 03.06.2017 um 14:10 schrieb John Darrington :
> 
> I presume this error is one that has just recently arisen?  and so far as I'm 
> aware, no uploads
> of pspp have recently occured in Debian (am I right Frederich?)   If so, then 
> I suggest that recent
> changes to other entities are investigated.
> 

pspp-0.10.2-1 is in testing since Oktober 2016. It was build again postgresql 
9.6.0-1
In march it was rebuild against postgresql 9.6.2-1 (PIE rebuild)

A first report of the postgresql related problems was from Santiago in January 
2017
with postgresql 9.6.1-2. The new report from Lucas on i386 is with postgresql 
9.6.3-3

Friedrich



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#850457: pspp 0.10.2-1 FTBS randomly

[Friedrich Beckmann]

Hi Lucas,

I guess the regression failure for postgresql here

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

and for pspp here

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

which also fails when starting the psql server has probably the same reason
in the build environment. The error message in pspp indicates
a problem with the locale settings.

I could switch off the check of stderr in that specific test case
as John proposed which will make pspp pass again. Maybe some
investigation if this is related to the build system would be
more advisable.

Christoph cannot reproduce the postgresql regression failure
on his build system. I cannot reproduce the pspp failure
on my build system.

Note that Santiago found the problem as a random failure in stretch. He
put several buildlogs here:

https://people.debian.org/~sanvila/build-logs/pspp/

Lucas found the problem on stretch for i386 to be reproducable.

As Christoph already asked: Could you maybe check the locale
settings on your build system?

Regards

Friedrich

Bug#850457: PSPP build failure related to PSQL problem?

[Friedrich Beckmann]

Hi,

maybe the pspp regression failure is related to bug #863928 in PSQL where the 
regression fails when the database is initialized. This is exactly what we do 
in the failing test 247 in pspp.

Friedrich

Bug#850457: pspp 0.10.2-1 FTBS randomly

[Friedrich Beckmann]

Dear Adrian, dear Lucas,

thanks for your reports. Maybe you can help me with the analysis as I have 
problems to reproduce it
here locally. 

As already reported in the bug log

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

I think the problem is due to locale settings in the environment. The
critical message is:

+locale: Cannot set LC_MESSAGES to default locale: No such file or directory

in test 247 (which starts a PSQL server). The problem happens when the psql 
server starts.

It seems strange to me that this happens randomly. 

Regards

Friedrich

Bug#850457: pspp: FTBFS randomly (testsuite: 247 failed)

[Friedrich Beckmann]

Control: tags -1 unreproducable

Hi Santiago,

thanks for your bug report. I tried to reproduce the build problem
that you describe but I was not able to do so. Looking at your build logs
I can see that it is always test 247 that fails. Test 247 starts a postgresql
database server and then tries to read data from this database.

Looking at your log file the critical section is here:

= Snippet from Santiagos failure log 
##  ##
## Summary of the failures. ##
##  ##
Failed tests:
GNU PSPP 0.10.2 test suite test groups:

 NUM: FILE-NAME:LINE TEST-GROUP-NAME
  KEYWORDS

 247: get-data-psql.at:124 GET DATA /TYPE=PSQL

## -- ##
## Detailed failed tests. ##
## -- ##

# -*- compilation -*-
247. get-data-psql.at:124: testing GET DATA /TYPE=PSQL ...
./get-data-psql.at:125: initdb -A trust
--- /dev/null   2017-01-05 19:44:44.56400 +
+++ /<>/tests/testsuite.dir/at-groups/247/stderr   2017-01-06 
02:09:40.476955912 +
@@ -0,0 +1 @@
+locale: Cannot set LC_MESSAGES to default locale: No such file or directory
stdout:
The files belonging to this database system will be owned by user "buildd".
This user must also own the server process.

The database cluster will be initialized with locale "C".
The default database encoding has accordingly been set to "SQL_ASCII".
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory /<>/tests/testsuite.dir/0247/cluster ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

Success. You can now start the database server using:

pg_ctl -D /<>/tests/testsuite.dir/0247/cluster -l logfile start

247. get-data-psql.at:124: 247. GET DATA /TYPE=PSQL (get-data-psql.at:124): 
FAILED (get-data-psql.at:125)

== End of snippet =

My clue is that the problem is related to the line

+locale: Cannot set LC_MESSAGES to default locale: No such file or directory

so it would be a hint that there is some problem on your build
system with the locale mechanism. 

If I build the pspp package from source as you did with

dpkg-buildpackage -B

and then run test 247 with verbose output it looks like this:

 Snippet from Friedrich ===
fritz@debian:~/pspp/debian/pspp-0.10.2$ XTERM_LOCALE='' /bin/bash 
'./tests/testsuite' 247 -v -C tests 
AUTOTEST_PATH=tests/data:tests/language/lexer:tests/libpspp:tests/output:src/ui/terminal:utilities
 RUNNER='' -j1
## --- ##
## GNU PSPP 0.10.2 test suite. ##
## --- ##
247. get-data-psql.at:124: testing GET DATA /TYPE=PSQL ...
./get-data-psql.at:125: initdb -A trust
stdout:
The files belonging to this database system will be owned by user "fritz".
This user must also own the server process.

The database cluster will be initialized with locale "C".
The default database encoding has accordingly been set to "SQL_ASCII".
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory 
/home/fritz/pspp/debian/pspp-0.10.2/tests/testsuite.dir/0247/cluster ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

Success. You can now start the database server using:

pg_ctl -D 
/home/fritz/pspp/debian/pspp-0.10.2/tests/testsuite.dir/0247/cluster -l logfile 
start

./get-data-psql.at:125: pg_ctl start -w -o "-k $socket_dir -h ''"
stdout:
waiting for server to startLOG:  database system was shut down at 
2017-01-08 10:50:11 CET
LOG:  MultiXact member wraparound protections are now enabled
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
 done
server started
./get-data-psql.at:125: createdb -h "$socket_dir" -p $PG_PORT $PG_DBASE
stderr:
stdout:
./get-data-psql.at:125: psql -h "$socket_dir" -p $PG_PORT $PG_DBASE < 
populate.sql
stdout:
CREATE TABLE
CREATE TABLE
INSERT 0 1000
CREATE TABLE
INSERT 0 1
INSERT 0 1
INSERT 0 1
./get-data-psql.at:128: cat > ordinary-query.sps < empty-result.sps < large-result.sps < 1).
LIST.

TEMPORARY.
N OF CASES 6.
LIST.

SORT CASES BY x (D).

TEMPORARY.
N OF CASES 6.
LIST.
EOF

./get-data-psql.at:217: pspp -o pspp.csv large-result.sps
./get-data-psql.at:218: cat pspp.csv
./get-data-psql.at:250: psql -h "$socket_dir" -p $PG_PORT $PG_DBASE < 
all-null-string.sql
stdout:
CREATE TABLE
INSERT 0 1
INSERT 0 1
./get-data-psql.at:253: cat > get-data.sps < Am 06.01.2017 um 

Bug#820743: [Pkg-postgresql-public] Bug#820743: [hurd-i386] postgresql-common / postgresql-9.5 fails to install during pspp build

[Friedrich Beckmann]

Hi Christoph,

thanks for the info. We had disabled the optional postgresql on hurd-i386 in 
the previous pspp release.

Is it maybe an idea to include this test case in the regression in postgresql? 
That would stop the
release of the non-functional postgresql on hurd-i386, no?

Friedrich

> Am 12.04.2016 um 17:39 schrieb Christoph Berg <m...@debian.org>:
> 
> Re: Friedrich Beckmann 2016-04-12 
> <3ad966ac-2984-4449-94ba-addfe00d9...@gmx.de>
>> Package: postgresql-9.5
>> Version: 9.5.2-1
>> 
>> During test installation on buildd for pspp, the pspp build fails on 
>> hurd-i386 during the setup
>> of the postgresql. When I disable postgresql, then pspp builds and works. 
>> 
>> This is specific to the hurd-i386 architecture. The pspp package builds on 
>> other architectures.
>> 
>> Friedrich
>> 
>> The full log: 
>> https://buildd.debian.org/status/fetch.php?pkg=pspp=hurd-i386=0.10.1-2=1460387447
> 
> Hi Friedrich,
> 
> the problem is in the hurd kernel that doesn't implement semaphores.
> The interesting initdb error is this:
> 
> creating template1 database in 
> /«PKGBUILDDIR»/build/src/test/regress/./tmp_check/data/base/1 ... FATAL:  
> could not create semaphores: Function not implemented
> DETAIL:  Failed system call was semget(1, 17, 03600).
> 
> We have the weird situation where the server compiles successfully
> including semget(), but isn't able to get executed because the
> the kernel doesn't implement the feature.
> 
> I've talked to the hurd people, and Richard Braun was confirming that
> inter-process semaphores are not implemented yet.
> 
> What we can do from the PostgreSQL side is to replace the current sysv
> semaphores (semget) by POSIX semaphores (sem_init) which don't work
> either, but have a much greater chance of getting implemented in the
> future. So some day, it will just work, but until then, PostgreSQL
> will unfortunately not really be available on that platform.
> 
> Christoph

Bug#820743: [hurd-i386] postgresql-common / postgresql-9.5 fails to install during pspp build

[Friedrich Beckmann]

Package: postgresql-9.5
Version: 9.5.2-1

During test installation on buildd for pspp, the pspp build fails on hurd-i386 
during the setup
of the postgresql. When I disable postgresql, then pspp builds and works. 

This is specific to the hurd-i386 architecture. The pspp package builds on 
other architectures.

Friedrich

The full log: 
https://buildd.debian.org/status/fetch.php?pkg=pspp=hurd-i386=0.10.1-2=1460387447


== Extract from log file ===

Setting up openssl (1.0.2g-1) ...
Setting up postgresql-client-common (173) ...
Setting up postgresql-client-9.5 (9.5.2-1) ...
update-alternatives: using /usr/share/postgresql/9.5/man/man1/psql.1.gz to 
provide /usr/share/man/man1/psql.1.gz (psql.1.gz) in auto mode
Setting up ssl-cert (1.0.37) ...
Setting up postgresql-common (173) ...
Adding user postgres to group ssl-cert

Creating config file /etc/postgresql-common/createcluster.conf with new version
Building PostgreSQL dictionaries from installed myspell/hunspell packages...
Removing obsolete dictionary files:
All runlevel operations denied by policy
invoke-rc.d: policy-rc.d denied execution of start.
Setting up postgresql-9.5 (9.5.2-1) ...
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/(?

Bug#759102: automake version 15 includes the bugfix

[Friedrich Beckmann]

automake version 15 includes the bugfix. Today automake release 14 is in the 
automake package of debian unstable.

Friedrich

Bug#790105: Cannot grab the lower right corner of a window to resize the window.

[Friedrich Beckmann]

Package: gnome
Version: 3.14+3
Severity: important
Tags: fixed-upstream, sid

I cannot resize the windows because I cannot grab the lower right corner of the 
window. This problem
is known in upstream:

https://bugzilla.gnome.org/show_bug.cgi?id=746598

and it is already fixed upstream. The link to the patch is in the upstream bug 
report. I reproduced this in unstable
in a virtual machine (VMware). I did not test the upstream patch.

Friedrich


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763603: pspp: startup notification does not work

[Friedrich Beckmann]

The problem is currently only visible for me in KDE. I guess in GNOME the 
default behavior is that the
startupnotificaton is off, while in KDE it is on. 

I think the way to handle the problem could be to fix the problem upstream and 
wait for 
the new release.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763603: startup notification

[Friedrich Beckmann]

I added a bug description and a patch upstream:

https://savannah.gnu.org/patch/index.php?8549


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763603: pspp: startup notification does not work

[Friedrich Beckmann]

Hi Ronny,

thanks for the bug description. I am a little bit confused by your version 
information. Where
did you get that package from? There is currently pspp 0.8.4-1 only in unstable 
but I do not know
about any backport.

https://packages.debian.org/search?suite=allkeywords=pspp

Friedrich

Am 01.10.2014 um 11:35 schrieb Ronny Standtke ronny.stand...@fhnw.ch:

 Package: pspp
 Version: 0.8.4-1~bpo70+1
 Severity: minor
 
 When starting pspp from the KDE start menu the startup
 notification (bouncing mouse cursor) does not stop after
 PSPP finished loading.
 
 I tried to fix the issue by specifying a StartupWMClass in
 the desktop file but it didn't help. The only solution I found
 was to disable the startup notification (see attached patch).
 pspp.desktop.diff

Bug#763603: pspp: startup notification does not work

[Friedrich Beckmann]

Control: tags -1 + confirmed patch
Control: found -1 0.8.3-6 

Hi Ronny,

i tried to reproduce the problem with the 
pspp testing 0.8.3-6 release and I see it bouncing…

Friedrich


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763603: pspp: startup notification does not work

[Friedrich Beckmann]

Hi Ronny,

yes, that is what I mean: I see it bouncing and bouncing and bouncing… : -)

Friedrich


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#720865: Merged with 758088

[Friedrich Beckmann]

The problem with the perl build was due to problem upstream which is described 
here:

http://savannah.gnu.org/patch/index.php?8508

The patch has been introduced in upstream pspp here:

http://git.savannah.gnu.org/cgit/pspp.git/commit/?id=9f3aceccf7a1f7c08312be6cb34aa688bd958677

The debian package introduces a patch for the file perl-module/t/pspp.t 
(test1039fix.patch). The same problem is described
in the merged bug 758088: 

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758088


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#760841: pspp: [kfreebsd] random testsuite failures

[Friedrich Beckmann]

Thank you for trying the build, adding the bug description to the bugtracker 
and analyzing the problem!

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

Friedrich 

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#759102: Parallel build does not work due to problem with automake texi-vers.am

[Friedrich Beckmann]

Package: pspp
Version: 0.8.3-4
Control: fixed-upstream, fixed

The parallel build with make all html pdf does not work due to a bug in 
automake. The problem is described in 
pspp upstream here:

https://savannah.gnu.org/bugs/?43029

and in automake upstream here: 

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18301 

The problem is fixed in automake upstream. See

http://git.savannah.gnu.org/cgit/automake.git/commit/?id=74cdef7897da220bf062957ff9699815681441ef
 

Currently there is a workaround in the pspp debian package 
debian/patches/texi-vers.patch. This patch 
can be removed when the fixed automake version is in debian.

Friedrich


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758539: Use dh-autoreconf to update autotools files

[Friedrich Beckmann]

The problem has been fixed upstream with this patch: 

http://git.savannah.gnu.org/cgit/pspp.git/commit/?id=b7dc0fed8f8e0053cd8a1dc715c74f4133a6a415

Friedrich

Bug#758539: Fwd: Bug#758539: pspp: Use dh-autoreconf to update autotools files

[Friedrich Beckmann]

Anfang der weitergeleiteten Nachricht:

 Von: Breno Leitao bren...@br.ibm.com
 Betreff: Aw: Bug#758539: pspp: Use dh-autoreconf to update autotools files
 Datum: 24. August 2014 18:35:56 MESZ
 An: Friedrich Beckmann friedrich.beckm...@gmx.de
 
 Hi Fiedrich,
 
 Yes, now pspp built finally on ppc64el.
 Thank you so much!
 
 Breno
 
 On 08/24/2014 07:49 AM, Friedrich Beckmann wrote:
 Hi Breno,
 
 does the updated package work for you now? 
 
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758539
 
 Regards
 
 Friedrich
 
 Am 18.08.2014 um 18:22 schrieb Breno Leitao bren...@br.ibm.com
 mailto:bren...@br.ibm.com:

Bug#758539: pspp: Use dh-autoreconf to update autotools files

[Friedrich Beckmann]

I guess I found the reason why autoreconf does not work. I filed a bug in 
upstream:

https://savannah.gnu.org/patch/index.php?8518

I prepare a new package version which uses autoconf.

Friedrich


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#747699: #747699 [n| | ] [pspp] pspp is not updated in the repository

[Friedrich Beckmann]

We have updated the debian package to pspp upstream version 0.8.3. 

Friedrich

Bug#758088: pspp failed to run test on mips64el

[Friedrich Beckmann]

Dear YunQiang Su,

you are refering to version 0.7.9. It might be that the problem you report is 
the same as 
that one described here:

http://savannah.gnu.org/patch/index.php?8508

The patch has been introduced in upstream pspp here:

http://git.savannah.gnu.org/cgit/pspp.git/commit/?id=9f3aceccf7a1f7c08312be6cb34aa688bd958677

Regards

Friedrich 

Am 14.08.2014 um 09:41 schrieb YunQiang Su wzss...@gmail.com:

 Package: pspp
 Version: 0.7.9+git20120620-1.2
 
 --- -   2033-12-08 08:27:16.958411009 +0800
 +++ /tmp/pspp/pspp-0.7.9+git20120620/tests/testsuite.dir/at-groups/951/stdout
  2033-12-08 08:27:16.940752178 +0800
 @@ -1,15 +1,15 @@
 Variable 0 is string, label is A Short String Variable
 Value Labels:
  = threes
 - = ones
  = twos
 + = ones
 Variable 1 is longstring, label is A Long String Variable
 Value Labels:
 Variable 2 is numeric, label is A Numeric Variable
 Value Labels:
 1 = Unity
 -3 = Thripality
 2 = Duality
 +3 = Thripality
 Variable 3 is date, label is A Date Variable
 Value Labels:
 Variable 4 is dollar, label is A Dollar Variable
 951. perl-module.at:335: 951. Perl read system file
 (perl-module.at:335): FAILED (perl-module.at:370)
 
 # -*- compilation -*-
 957. perl-module.at:703: testing Perl Pspp.t ...
 ./perl-module.at:706: perl -MText::Diff -e '' || exit 77
 ./perl-module.at:707: LD_LIBRARY_PATH=$abs_top_builddir/src/.libs \
   DYLD_LIBRARY_PATH=$abs_top_builddir/src/.libs \
   $PERL -I$abs_top_builddir/perl-module/blib/arch \
 -I$abs_top_builddir/perl-module/blib/lib
 $abs_top_builddir/perl-module/t/Pspp.t
 
 
 --- -   2033-12-08 08:27:26.272479944 +0800
 +++ /tmp/pspp/pspp-0.7.9+git20120620/tests/testsuite.dir/at-groups/957/stdout
  2033-12-08 08:27:26.257159156 +0800
 @@ -23,7 +23,7 @@
 ok 22 - Value label for long string
 ok 23 - Check output 2
 ok 24 - Dictionary survives sysfile
 -ok 25 - Basic reader operation
 +not ok 25 - Basic reader operation
 ok 26 - Streaming of files
 Formatted string is 11-SEP-2001 08:20
 ok 27 - format_value function
 @@ -35,6 +35,6 @@
 ok 33 - Missing Value Positive
 ok 34 - Missing Value Positive SYS
 ok 35 - Missing Value Positive Num
 -ok 36 - Custom Attributes
 +not ok 36 - Custom Attributes
 ok 37 - Case count
 
 
 
 -- 
 YunQiang Su
 testsuite.log.xz