Re: Tag Version 2.0.1 ?

[Friedrich Beckmann]

Thanks!

Re: Stable Release: pspp-2.0.1-1.dmg, released on March 21st 2024.

[Friedrich Beckmann]

arch" : "x86_64",
>"base" : 4498030592,
>"size" : 98304,
>"uuid" : "62535c78-da0c-3e89-86c9-f4f27ce1e9b1",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/gettext\/lib\/libintl.8.dylib",
>"name" : "libintl.8.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4501258240,
>"size" : 114688,
>"uuid" : "2e6aa821-305a-30c6-a528-bf5553ea200e",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/fribidi\/lib\/libfribidi.0.dylib",
>"name" : "libfribidi.0.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4535279616,
>"size" : 573440,
>"uuid" : "278da4ca-d7ef-3f7e-bf43-3f9629959acb",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/pcre2\/lib\/libpcre2-8.0.dylib",
>"name" : "libpcre2-8.0.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4536639488,
>"size" : 540672,
>"uuid" : "80411e27-44e5-3f57-bc04-ee5b316fb362",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/freetype\/lib\/libfreetype.6.dylib",
>"name" : "libfreetype.6.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4501483520,
>"size" : 98304,
>"uuid" : "f9dcf421-2272-3e64-bf25-12498a043364",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/graphite2\/lib\/libgraphite2.3.dylib",
>"name" : "libgraphite2.3.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4502011904,
>"size" : 147456,
>"uuid" : "4c7e7da0-63c7-3c40-9218-841181ffb4be",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/libpng\/lib\/libpng16.16.dylib",
>"name" : "libpng16.16.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4538417152,
>"size" : 212992,
>"uuid" : "ec607bb4-eef2-354f-8bfa-c74fe5e78bb0",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/fontconfig\/lib\/libfontconfig.1.dylib",
>"name" : "libfontconfig.1.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 454002,
>"size" : 868352,
>"uuid" : "d84e92a5-1309-3842-9b0a-4a7790ed7da2",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/libx11\/lib\/libX11.6.dylib",
>"name" : "libX11.6.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4538130432,
>"size" : 49152,
>"uuid" : "c114b453-9a16-3a55-ad6d-70ce37dd082a",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/libxext\/lib\/libXext.6.dylib",
>"name" : "libXext.6.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4488589312,
>"size" : 32768,
>"uuid" : "ae2f5af3-360a-3b33-8984-dc1005f41ba3",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/libxrender\/lib\/libXrender.1.dylib",
>"name" : "libXrender.1.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4539052032,
>"size" : 81920,
>"uuid" : "faff04db-24a6-304c-83b3-3c99b8d19222",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/libxcb\/lib\/libxcb.1.dylib",
>"name" : "libxcb.1.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4497133568,
>"size" : 32768,
>"uuid" : "ab151bcc-b6ba-3848-bc68-f1a78f7f82eb",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/libxcb\/lib\/libxcb-render.0.dylib",
>"name" : "libxcb-render.0.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4495224832,
>"size" : 16384,
>"uuid" : "293d6d0f-2a81-3243-9733-0e57a9e53d54",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/libxcb\/lib\/libxcb-shm.0.dylib",
>"name" : "libxcb-shm.0.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4541882368,
>"size" : 475136,
>"uuid" : "e13cd6df-5ae9-3f1a-87ae-dbc2da117f45",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/pixman\/lib\/libpixman-1.0.dylib",
>"name" : "libpixman-1.0.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4501819392,
>"size" : 16384,
>"uuid" : "291d0325-a1b5-3e83-987d-efff72b07082",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/glib\/lib\/libgmodule-2.0.0.dylib",
>"name" : "libgmodule-2.0.0.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4544368640,
>"size" : 409600,
>"uuid" : "5249e185-5eb7-3101-b4f4-6daf615bcd1b",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/libepoxy\/lib\/libepoxy.0.dylib",
>"name" : "libepoxy.0.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4546465792,
>"size" : 573440,
>"uuid" : "296adbe9-03f2-31b3-934b-35a0090cced0",
>"path" : 
> "\/Applications\/pspp.app\/Contents\/Resources\/opt\/jpeg-turbo\/lib\/libjpeg.8.dylib",
>"name" : "libjpeg.8.dylib"
>  },
>  {
>"source" : "P",
>"arch" : "arm64",
>"base" : 140703124193280,
>"size" : 196608,
>"uuid" : "3ba12577-21cf-3270-ac4e-4a558236468e",
>"path" : "\/usr\/libexec\/rosetta\/runtime",
>"name" : "runtime"
>  },
>  {
>"source" : "P",
>"arch" : "arm64",
>"base" : 4476284928,
>"size" : 344064,
>"uuid" : "79539977-1142-3b0b-9ecc-fac485d91d33",
>"path" : "\/Library\/Apple\/*\/libRosettaRuntime",
>"name" : "libRosettaRuntime"
>  },
>  {
>"source" : "P",
>"arch" : "x86_64",
>"base" : 4339924992,
>"size" : 1048576,
>"uuid" : "23af3066-b6df-329e-a48c-526fc67fb677",
>"path" : "\/Applications\/pspp.app\/Contents\/Resources\/bin\/psppire",
>"name" : "psppire"
>  },
>  {
>"size" : 0,
>"source" : "A",
>"base" : 0,
>"uuid" : "----"
>  }
> ],
>  "sharedCache" : {
>  "base" : 140703568314368,
>  "size" : 21474836480,
>  "uuid" : "7fa563c2-7726-366b-b2f5-1c64013c6b55"
> },
>  "vmSummary" : "ReadOnly portion of Libraries: Total=457.5M resident=0K(0%) 
> swapped_out_or_unallocated=457.5M(100%)\nWritable regions: Total=164.8M 
> written=0K(0%) resident=0K(0%) swapped_out=0K(0%) 
> unallocated=164.8M(100%)\n\nVIRTUAL   REGION 
> \nREGION TYPESIZECOUNT (non-coalesced) 
> \n=== ===  === \nRosetta Arena
>  4096K2 \nRosetta Generic   1048K  259 
> \nRosetta IndirectBranch  32K1 \nRosetta JIT  
> 128.0M1 \nRosetta Return Stack20K2 
> \nRosetta Thread Context  20K2 \nStack
>  8176K1 \nStack Guard   56.0M1 
> \nVM_ALLOCATE   19.0M7 \nVM_ALLOCATE (reserved)   
>   416K   38 reserved VM address space 
> (unallocated)\n__DATA16.9M  338 
> \n__DATA_CONST  15.6M  234 \n__DATA_DIRTY 
>   650K  102 \n__FONT_DATA23521 
> \n__LINKEDIT   184.1M   46 \n__OBJC_RO
>  71.1M1 \n__OBJC_RW 2170K1 
> \n__TEXT   273.4M  365 \ndyld private memory  
>  4360K4 \nmapped file7.3G  584 
> \n=== ===  === \nTOTAL
>   8.1G 1990 \nTOTAL, minus reserved VM space 8.1G 1990 
> \n",
>  "legacyInfo" : {
>  "threadTriggered" : {
> 
>  }
> },
>  "logWritingSignature" : "05cc7b94e2c9417bf3b6195c5c1ed13b2fb9e9de",
>  "trialInfo" : {
>  "rollouts" : [
>{
>  "rolloutId" : "64c025b28b7f0e739e4fbe58",
>  "factorPackIds" : {
> 
>  },
>  "deploymentId" : 24019
>},
>{
>  "rolloutId" : "5fb4245a1bbfe8005e33a1e1",
>  "factorPackIds" : {
> 
>  },
>  "deploymentId" : 24021
>}
>  ],
>  "experiments" : [
>{
>  "treatmentId" : "a3f9ec09-b145-49f3-8142-da4a1f338456",
>  "experimentId" : "65f21aa774b6f500a45abd7d",
>  "deploymentId" : 40001
>}
>  ]
> },
>  "reportNotes" : [
>  "PC register does not match crashing frame (0x0 vs 0x102CEBA78)"
> ]
> }
> 
> Model: Mac14,12, BootROM 10151.81.1, proc 12:8:4 processors, 32 GB, SMC
> Graphics: Apple M2 Pro, Apple M2 Pro, Built-In
> Display: Studio Display, 5120 x 2880 Retina, Main, MirrorOff, Online
> Memory Module: LPDDR5, Hynix
> AirPort: spairport_wireless_card_type_wifi (0x14E4, 0x4388), wl0: Dec 15 2023 
> 23:28:06 version 23.10.765.20.41.51.129 FWID 01-2829d3f6
> Bluetooth: Version (null), 0 services, 0 devices, 0 incoming serial ports
> Network Service: Ethernet, Ethernet, en0
> PCI Card: pci8086,15f0, USB eXtensible Host Controller, Thunderbolt@3,0,0
> USB Device: USB31Bus
> USB Device: 4-Port USB 3.0 Hub
> USB Device: 4-Port USB 2.0 Hub
> USB Device: Apple Watch Magnetic Charging Cable
> USB Device: USB31Bus
> USB Device: USB31Bus
> USB Device: USB31Bus
> USB Device: Backup+  Desk
> USB Device: USB31Bus
> USB Device: Keyboard Hub
> USB Device: Apple Optical USB Mouse
> USB Device: Apple Keyboard
> USB Device: Expansion Desk
> USB Device: USB31Bus
> USB Device: USB3 Gen2 Hub
> USB Device: USB2 Hub
> USB Device: Studio Display
> Thunderbolt Bus: Mac mini, Apple Inc.
> Thunderbolt Device: Studio Display, Apple Inc., 1, 67.1
> Thunderbolt Bus: Mac mini, Apple Inc.
> Thunderbolt Bus: Mac mini, Apple Inc.
> Thunderbolt Bus: Mac mini, Apple Inc.
> 
> 
> 
> 
> 
>> On Mar 24, 2024, at 12:11 PM, Friedrich Beckmann 
>>  wrote:
>> 
>> CAUTION: This email originated from outside of the University. Do not click 
>> links or open attachments unless you recognize the sender and know the 
>> content is safe.
>> 
>> 
>> Thanks for the report! Could you open the report that you can view before it 
>> is send to Apple, copy it, and send it to us? Does the previous version
>> 
>> https://www.hs-augsburg.de/~beckmanf/pspp/pspp-2.0.0-1.dmg
>> 
>> open and work? I have Monterey on my Macbook Pro 2015 and there I can open 
>> it.
>> 
>> 
>>> Am 24.03.2024 um 17:17 schrieb Heredia, Roberto R :
>>> 
>>> Hello,
>>> 
>>> Stable Release: pspp-2.0.1-1.dmg, released on March 21st 2024  does not 
>>> open on (see attached screnshot):
>>> 
>>> Apple M2 Pro
>>> 
>>> Sonoma 14.3.1
>>> 
>>> 
>>> 
>>> 
>>> Thanks!
>>> 
>>> R
>> 
> 

Re: Stable Release: pspp-2.0.1-1.dmg, released on March 21st 2024.

[Friedrich Beckmann]

Thanks for the report! Could you open the report that you can view before it is 
send to Apple, copy it, and send it to us? Does the previous version

https://www.hs-augsburg.de/~beckmanf/pspp/pspp-2.0.0-1.dmg

open and work? I have Monterey on my Macbook Pro 2015 and there I can open it.


> Am 24.03.2024 um 17:17 schrieb Heredia, Roberto R :
> 
> Hello,
> 
> Stable Release: pspp-2.0.1-1.dmg, released on March 21st 2024  does not open 
> on (see attached screnshot):
> 
> Apple M2 Pro
> 
> Sonoma 14.3.1
> 
> 
> 
> 
> Thanks!
> 
> R

Tag Version 2.0.1 ?

[Friedrich Beckmann]

Hi Ben,

could you tag the released version 2.0.1 in git?

Cheers

Fritz

benpfaff.org is down

[Friedrich Beckmann]

Hi Ben,

your webserver https://benpfaff.org is down since two days...

Cheers

Fritz

Re: benpfaff.org down?

[Friedrich Beckmann]

Works again.

Thanks!

> Am 24.01.2024 um 17:12 schrieb Ben Pfaff :
> 
> Thanks for the report. Apache had been stopped about 4 days ago. I
> don't know why. I restarted it.
> 
> On Wed, Jan 24, 2024 at 5:30 AM Friedrich Beckmann
>  wrote:
>> 
>> Hi Ben,
>> 
>> is your (web)server down? I cannot contact https://benpfaff.org via https. 
>> Ping works.
>> 
>> Cheers
>> 
>> Fritz
> 

benpfaff.org down?

[Friedrich Beckmann]

Hi Ben,

is your (web)server down? I cannot contact https://benpfaff.org via https. Ping 
works.

Cheers

Fritz

Thanks for your Catalan translation!

[Friedrich Beckmann]

Dear Francesc,

thanks for your pspp catalan translation!

https://translationproject.org/domain/pspp.html

Cheers

Fritz

Release 2.0.0 - Debian / Windows / MacOS

[Friedrich Beckmann]

Hi folks,

i made a new debian pspp 2.0.0-3 release and it seems to build now:

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

There are some problems with the regression for tests using the interactive 
mode on
s390x, powerpc and ppc64 architectures:

https://savannah.gnu.org/bugs/?65125
https://savannah.gnu.org/bugs/?65123

I disabled test 1564 and 1602 on debian and then the build seems to
pass on all platforms. I made a new debian spread-sheet-widget 0.10-3 release.

https://buildd.debian.org/status/package.php?p=spread-sheet-widget

I also copied the windows installer from the CI builder to a new stable release
directory and updated the webpage such that the new stable 2.0.0 release is 
found there.

https://www.gnu.org/software/pspp/get.html

I updated the MacOS homebrew pspp tap https://github.com/fredowski/homebrew-pspp
and the MacOS stable bundle: https://www.hs-augsburg.de/homes/beckmanf/pspp/
MacOS builds also use the 0.10 spread-sheet-widget.

Cheers

Fritz

Thanks for your Ukrainian pspp translation!

[Friedrich Beckmann]

Hi Yuri,

thanks for your Ukrainian translation of pspp!

Friedrich

Re: MacOS: iconv library behaves differently starting from MacOS 14 Somona - skip test "convert invalid UTF-8 to ISO-8859-1“

[Friedrich Beckmann]

Hi Ben,

thanks for the idea. I reverted the skipped test and added your
suggested patch. Can you produce a new source build such that this
can be tested via the brew flow?

Fritz

> Am 04.11.2023 um 21:01 schrieb Ben Pfaff :
> 
> It looks to me like Mac OS is returning EOPNOTSUPP when it should
> return EILSEQ.  Would you mind trying the following patch?
> 
> diff --git a/src/libpspp/i18n.c b/src/libpspp/i18n.c
> index 5e9aa0d59c..7697ac614c 100644
> --- a/src/libpspp/i18n.c
> +++ b/src/libpspp/i18n.c
> @@ -214,6 +215,7 @@ try_recode (struct converter *cvtr, char fallbackchar,
> return out - 1 - out_;
> 
>   case EILSEQ:
> +  case EOPNOTSUPP:
> if (outbytes == 0)
>   return -E2BIG;
> if (!fallbackchar)
> 
> 
> On Sat, Nov 4, 2023 at 11:53 AM Friedrich Beckmann
>  wrote:
>> 
>> Hi Ben,
>> 
>> pspp uses the native iconv library from Apple on MacOS. Apple has changed 
>> that library from MacOS 13 to MacOS 14. As a result the returned error codes 
>> seem different. That is the reason why the test "convert invalid UTF-8 to 
>> ISO-8859-1“ fails on MacOS 14. The problem is discussed here:
>> 
>> https://github.com/fredowski/homebrew-pspp/issues/5#issuecomment-1793464558
>> 
>> I made a patch to disable that test on MacOS such that the regression will 
>> work again on MacOS 14. I hope until Apple fixes the iconv library.
>> 
>> Cheers
>> 
>> Fritz

MacOS: iconv library behaves differently starting from MacOS 14 Somona - skip test "convert invalid UTF-8 to ISO-8859-1“

[Friedrich Beckmann]

Hi Ben,

pspp uses the native iconv library from Apple on MacOS. Apple has changed that 
library from MacOS 13 to MacOS 14. As a result the returned error codes seem 
different. That is the reason why the test "convert invalid UTF-8 to 
ISO-8859-1“ fails on MacOS 14. The problem is discussed here:

https://github.com/fredowski/homebrew-pspp/issues/5#issuecomment-1793464558

I made a patch to disable that test on MacOS such that the regression will work 
again on MacOS 14. I hope until Apple fixes the iconv library. 

Cheers

Fritz

Re: ☠ Buildbot (GNU pspp CI): debian-sid-amd64 - failed compile (failure) (master)

[Friedrich Beckmann]

Nice! Unfortunately it still fails on the MacOS CI pipeline… 

https://github.com/fredowski/homebrew-pspp/actions/runs/6728288235

Could you maybe reintroduce that this test only runs on linux systems? It seems 
to be really hard…


> Am 02.11.2023 um 06:20 schrieb Ben Pfaff :
> 
> I think I got it. The buildbot output is almost clear, and the remaining 
> failure (https://caeis.etech.fh-augsburg.de/buildbot/#/builders/2/builds/506) 
> is an intermittent network failure, not a bug in PSPP. I requested a rebuild 
> for that one.
> 
> On Wed, Nov 1, 2023 at 6:43 PM Ben Pfaff  wrote:
> This test is painful. It seems to fail everywhere but my own machine. I am 
> trying yet another approach.
> 
> On Wed, Nov 1, 2023 at 12:57 PM Friedrich Beckmann 
>  wrote:
> Hi Ben,
> 
> i think your fix did not work out… The CI pipeline still fails:
> 
> https://caeis.etech.fh-augsburg.de/buildbot/#/console
> 
> The test "interactive output appears immediately“ fails with a timeout. 
> 
> Now also the MacOS homebrew latest fails. There without timeout, just a fail 
> for that test.
> 
> Cheers
> 
> Fritz
> 
> 
> > Am 01.11.2023 um 17:40 schrieb Ben Pfaff :
> > 
> > Weird bug.
> > 
> > I switched to another way to test the feature that broke in the testsuite 
> > here. It should be more portable, I hope.
> > 
> > On Tue, Oct 31, 2023 at 11:23 PM Friedrich Beckmann 
> >  wrote:
> > Hi Ben,
> > 
> > i guess something went wrong with one of the last commits:
> > 
> > https://caeis.etech.fh-augsburg.de/buildbot/#/console
> > 
> > Cheers
> > 
> > Fritz
> > 
> 

Re: ☠ Buildbot (GNU pspp CI): debian-sid-amd64 - failed compile (failure) (master)

[Friedrich Beckmann]

Hi Ben,

i think your fix did not work out… The CI pipeline still fails:

https://caeis.etech.fh-augsburg.de/buildbot/#/console

The test "interactive output appears immediately“ fails with a timeout. 

Now also the MacOS homebrew latest fails. There without timeout, just a fail 
for that test.

Cheers

Fritz


> Am 01.11.2023 um 17:40 schrieb Ben Pfaff :
> 
> Weird bug.
> 
> I switched to another way to test the feature that broke in the testsuite 
> here. It should be more portable, I hope.
> 
> On Tue, Oct 31, 2023 at 11:23 PM Friedrich Beckmann 
>  wrote:
> Hi Ben,
> 
> i guess something went wrong with one of the last commits:
> 
> https://caeis.etech.fh-augsburg.de/buildbot/#/console
> 
> Cheers
> 
> Fritz
> 

Fwd: ☠ Buildbot (GNU pspp CI): debian-sid-amd64 - failed compile (failure) (master)

[Friedrich Beckmann]

Hi Ben,

i guess something went wrong with one of the last commits:

https://caeis.etech.fh-augsburg.de/buildbot/#/console

Cheers

Fritz

Re: frustrations

[Friedrich Beckmann]

Hi Ben,

I love Crystal Lee. Please email me back how to fix the issue :-)

Cheers

Fritz

> Am 26.09.2023 um 17:15 schrieb Ben Pfaff :
> 
> I'm starting to get so frustrated with the bug reports we get for PSPP. About 
> 90% of them seem to be Windows-specific, and a lot of the users who report 
> them don't seem to be able to cogently describe how the problem arises, or 
> even what version of PSPP they're using. And, of course, since I don't use 
> Windows, there's not much chance that I can fix the problem or verify that 
> it's fixed. I don't know what to do about it.

Re: ☠ Buildbot (GNU pspp CI): debian-sid-i386 - failed compile (failure) (master)

[Friedrich Beckmann]

Works again...

> Am 04.06.2023 um 16:43 schrieb Ben Pfaff :
> 
> Thanks for reporting the problem. I pushed a likely fix.
> 
> On Sat, Jun 3, 2023 at 8:27 PM Friedrich Beckmann  <mailto:friedrich.beckm...@gmx.de>> wrote:
> Hi Ben,
> 
> the last commit broke the i386 regression.
> 
> https://caeis.etech.fh-augsburg.de/buildbot/#/console 
> <https://caeis.etech.fh-augsburg.de/buildbot/#/console>
> 
> Regards
> 
> Fritz
> 
> Anfang der weitergeleiteten Nachricht:
> 
>> Von: build...@pspp.org <mailto:build...@pspp.org>
>> Datum: 3. Juni 2023 um 19:41:48 MESZ
>> An: friedrich.beckm...@gmx.de <mailto:friedrich.beckm...@gmx.de>
>> Betreff: ☠ Buildbot (GNU pspp CI): debian-sid-i386 - failed compile 
>> (failure) (master)
>> 
>> 
>> A failed build has been detected on builder debian-sid-i386 
>> <https://caeis.etech.fh-augsburg.de/buildbot/#builders/4/builds/143> while 
>> building GNU pspp CI.
>> 
>> Information:
>> 
>> Build state: failed compile (failure)
>> Revision: 2ba8dc2955f8a4bcad4a265fd3354f4fd8f74564
>> Worker: hsa-worker
>> Build Reason: (unknown)
>> Blamelist: Ben Pfaff
>> Steps:
>> 
>> 0: worker_preparation ( success )
>> 1: git ( success ) (  
>> <https://caeis.etech.fh-augsburg.de/buildbot/#builders/4/builds/143/steps/1/logs/stdio>
>>  )
>> 2: build ( warnings ) (  
>> <https://caeis.etech.fh-augsburg.de/buildbot/#builders/4/builds/143/steps/2/logs/stdio>
>>   
>> <https://caeis.etech.fh-augsburg.de/buildbot/#builders/4/builds/143/steps/2/logs/warnings__29_>
>>  )
>> 3: make check ( failure ) (  
>> <https://caeis.etech.fh-augsburg.de/buildbot/#builders/4/builds/143/steps/3/logs/stdio>
>>   
>> <https://caeis.etech.fh-augsburg.de/buildbot/#builders/4/builds/143/steps/3/logs/warnings__1_>
>>  )
>> 4: Test Results ( success ) (  
>> <https://caeis.etech.fh-augsburg.de/buildbot/#builders/4/builds/143/steps/4/logs/stdio>
>>   
>> <https://caeis.etech.fh-augsburg.de/buildbot/#builders/4/builds/143/steps/4/logs/testsuite_log>
>>  )
>> 5: shell ( success ) (  
>> <https://caeis.etech.fh-augsburg.de/buildbot/#builders/4/builds/143/steps/5/logs/stdio>
>>  )
>> 6: shell_1 ( success ) (  
>> <https://caeis.etech.fh-augsburg.de/buildbot/#builders/4/builds/143/steps/6/logs/stdio>
>>  )

Fwd: ☠ Buildbot (GNU pspp CI): debian-sid-i386 - failed compile (failure) (master)

[Friedrich Beckmann]

Hi Ben,the last commit broke the i386 regression.https://caeis.etech.fh-augsburg.de/buildbot/#/consoleRegardsFritzAnfang der weitergeleiteten Nachricht:Von: build...@pspp.orgDatum: 3. Juni 2023 um 19:41:48 MESZAn: friedrich.beckm...@gmx.deBetreff: ☠ Buildbot (GNU pspp CI): debian-sid-i386 - failed compile (failure) (master)A failed build has been detected on builder
debian-sid-i386
while building GNU pspp CI.
Information:

Build state: failed compile (failure)
Revision: 2ba8dc2955f8a4bcad4a265fd3354f4fd8f74564
Worker: hsa-worker
Build Reason: (unknown)
Blamelist: Ben Pfaff 

Steps:



0: worker_preparation ( success )



1: git ( success )
(

)



2: build ( warnings )
(


)



3: make check ( failure )
(


)



4: Test Results ( success )
(


)



5: shell ( success )
(

)



6: shell_1 ( success )
(

)

Trigger new source build?

[Friedrich Beckmann]

Hi Ben,

can you trigger a new source build? I made two commits to make
the build and the regression work again for older compilers and MacOS.

Cheers

Fritz

Windows CI pipeline is working again

[Friedrich Beckmann]

I fixed the CI pipeline for the windows build. The build including the 
2.0.0-pre is available here:

https://caeis.etech.fh-augsburg.de/downloads/windows/pspp-win-daily

Re: Some entries in pspp-2.0.0-pre1.nl.po

[Friedrich Beckmann]

Hi Jaap,

sorry - I did not read this email before I sent the other one.

Again: Thanks for the translation and the hints!

Friedrich

> Am 13.05.2023 um 08:44 schrieb PSPP Vertaler :
> 
> Dear reader,
> 
> while translating new entries in pspp-2.0.0-pre1.nl.po to Dutch, I came 
> across a couple of entries of which I wonder whether they're correct. They're 
> included below.
> Can I have a CC of the answer, please? Then I can correct the translations, 
> if necessary.
> 
> Regards, Jaap Verhage.
> 
> ==
> 
> ID 527: The PRESORTED subcommand state that the input data is presorted.
> - "state" is plural while "subcommand" is single;
> - "state" should be "supposes"?
> 
> ID 1438: This recoding output value has width %d.
> - "recoding" should be "recoded"?
> 
> ID 135: Identifier `%s' is not valid in encoding `%s'.used for this 
> dictionary.
> - "." following "`%s'" should not be there?
> 
> ID 441: Syntax error expecting number in (%g,%g) for %s.
> - shouldn't the "(" (left parenthesis) be a "[" (left square bracket)?
> 
> ==

Re: I386 build fails

[Friedrich Beckmann]

https://caeis.etech.fh-augsburg.de/buildbot/#/console


> Am 24.04.2023 um 07:21 schrieb Friedrich Beckmann :
> 
> 
> Hi Ben,
> 
> the i386 build fails on the ci.
> 
> Regards
> 
> Fritz

I386 build fails

[Friedrich Beckmann]

Hi Ben,

the i386 build fails on the ci.

Regards

Fritz

Re: Debian and Ubuntu regression is working again on 32bit systems (i386 and armhf) - perl module disabled

[Friedrich Beckmann]

Hi Ben,

it depends on the version of perl you use. The problem started when I updated 
the virtual machine in the ci setup.
 
Fritz

> Am 17.02.2023 um 17:07 schrieb Ben Pfaff :
> 
> I don't understand Perl much at all. I think that we'll need help if we want 
> it to work again.
> It does seem to work for me (at least, it passes the tests here).
> 
> On Fri, Feb 17, 2023 at 12:47 AM Friedrich Beckmann 
> mailto:friedrich.beckm...@gmx.de>> wrote:
> I made the debian 1.6.2-2 release where I disabled the perl module. The 
> regression now works agains for i386 and armhf such that pspp will not be 
> removed from debian and ubuntu.
> 
> https://buildd.debian.org/status/package.php?p=pspp 
> <https://buildd.debian.org/status/package.php?p=pspp>
> 
> https://launchpad.net/ubuntu/+source/pspp 
> <https://launchpad.net/ubuntu/+source/pspp>
> 
> Fritz
> 
> 
> 
> 
> 

Debian and Ubuntu regression is working again on 32bit systems (i386 and armhf) - perl module disabled

[Friedrich Beckmann]

I made the debian 1.6.2-2 release where I disabled the perl module. The 
regression now works agains for i386 and armhf such that pspp will not be 
removed from debian and ubuntu.

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

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

Fritz

Re: 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

Last commits break build on debian buster

[Friedrich Beckmann]

Hi Ben,

is it possible that you introduced something that will not compile on buster 
anymore?

https://caeis.etech.fh-augsburg.de/buildbot/#/console

Fritz

Re: GIMP vs. rsvg-convert for building PSPP

[Friedrich Beckmann]

Hi Ben,

the only thing I remember what to consider was that the resulting image file 
has correct transparent settings for the background. When I tried an 
alternative ages ago the resulting bitmap files did not have a transparent 
background.

Cheers

Fritz

> Am 22.07.2022 um 20:48 schrieb Ben Pfaff :
> 
> PSPP currently uses GIMP to generate PNGs from SVGs. GIMP is
> heavyweight, slow, and commonly not installed on developer systems, so
> we run it from Smake as pre-configuration.
> 
> There's a newer program called rsvg-convert that is much more commonly
> available these days. It is lightweight, fast, and more commonly
> installed (it is a binary that comes with the rsvg library, which is
> itself widely used). It produces good-quality output. I think that we
> could switch to it from GIMP, run it at build time instead of as part
> of Smake, and thereby improve the build process.
> 
> Does anyone have comments on this?
> 

Re: ☠ Buildbot (GNU pspp CI): debian-buster-amd64 - failed compile (failure) compile (failure) '/home/buildbot/pspp-buildbot/get_test_results.sh debian-buster-amd64-build' (failure) (master)

[Friedrich Beckmann]

Hi Ben,

yes true - somebody using g_memdup2 in new code would need this glibfix.h. No 
problem if you want to change the fix. Maybe we can also just wait until newer 
glib is available in our oldest target distribution and then we can remove this 
altogether.

Fritz

> Am 11.07.2022 um 18:30 schrieb Ben Pfaff :
> 
> I'm glad you fixed it. I'm not so happy with the details of the fix because 
> it requires developers to realize that they need the fix and include a 
> special header for it. That kind of thing leads to repeated problems over 
> time.
> 
> I think that the attached commit would have fixed the problem without the 
> need for developers to know to include a header.
> 
> On Sun, Jul 10, 2022 at 2:54 PM Friedrich Beckmann 
>  wrote:
> The fix did not work on debian. I pushed a different fix.
> 
> > Am 09.07.2022 um 17:39 schrieb Ben Pfaff :
> >
> > I think I fixed this. I started a build.
> >
> 
> <0001-gui-Make-sure-header-wrapper-gets-used-for-widgets-n.patch>

Re: ☠ Buildbot (GNU pspp CI): debian-buster-amd64 - failed compile (failure) compile (failure) '/home/buildbot/pspp-buildbot/get_test_results.sh debian-buster-amd64-build' (failure) (master)

[Friedrich Beckmann]

The fix did not work on debian. I pushed a different fix.

> Am 09.07.2022 um 17:39 schrieb Ben Pfaff :
>
> I think I fixed this. I started a build.
>

Fwd: ☠ Buildbot (GNU pspp CI): debian-buster-amd64 - failed compile (failure) compile (failure) '/home/buildbot/pspp-buildbot/get_test_results.sh debian-buster-amd64-build' (failure) (master)

[Friedrich Beckmann]

Hi Ben,

the introduction of g_memdup2 breaks the compilation on debian buster because 
this was introduced in a later glib2 version.

https://discourse.gnome.org/t/port-your-module-from-g-memdup-to-g-memdup2-now/5538

Buster has glib 2.58.3 while we need now 2.67.3. Maybe we should note this in 
the minimum requirements. Also Debian bullseye has 2.66.8 and will probably 
fail to build.

Regards

Fritz

Anfang der weitergeleiteten Nachricht:

> Von: build...@pspp.org
> Datum: 9. Juli 2022 um 06:48:45 MESZ
> An: friedrich.beckm...@gmx.de
> Betreff: ☠ Buildbot (GNU pspp CI): debian-buster-amd64 - failed compile 
> (failure) compile (failure) '/home/buildbot/pspp-buildbot/get_test_results.sh 
> debian-buster-amd64-build' (failure) (master)
> 
> 
> A failed build has been detected on builder debian-buster-amd64 while 
> building GNU pspp CI.
> 
> Information:
> 
> Build state: failed compile (failure) compile (failure) 
> '/home/buildbot/pspp-buildbot/get_test_results.sh debian-buster-amd64-build' 
> (failure)
> Revision: 93261332cde187e1392b6935234b2b1d8b9a1d51
> Worker: hsa-worker
> Build Reason: (unknown)
> Blamelist: Ben Pfaff
> Steps:
> 
> 0: worker_preparation ( success )
> 1: git ( success ) (  )
> 2: compile ( failure ) (   )
> 3: make check ( failure ) (  )
> 4: Test Results ( failure ) (   )
> 5: shell ( success ) (  )
> 6: shell_1 ( success ) (  )

Re: pspp-1.6.2 released [stable]

[Friedrich Beckmann]

Hi Ben,

can you trigger a new nightly build with the 1.6.2 release version as the 
windows builder builds from your nightly builds?

Regards

Fritz

> Am 02.07.2022 um 06:07 schrieb Ben Pfaff :
> 
> I'm very pleased to announce the release of a new version of GNU PSPP.
> PSPP is a program for statistical analysis of sampled data.  It is a
> free replacement for the proprietary program SPSS.
> 
> Here are the compressed sources and a GPG detached signature[*]:
>  https://ftp.gnu.org/gnu/pspp/pspp-1.6.2.tar.gz
>  https://ftp.gnu.org/gnu/pspp/pspp-1.6.2.tar.gz.sig
> 
> Use a mirror for higher download bandwidth:
>  http://www.gnu.org/order/ftp.html
> 
> [*] Use a .sig file to verify that the corresponding file (without the
> .sig suffix) is intact.  First, be sure to download both the .sig file
> and the corresponding tarball.  Then, run a command like this:
> 
>  gpg --verify pspp-1.6.2.tar.gz.sig
> 
> If that command fails because you don't have the required public key,
> then run this command to import it:
> 
>  gpg --keyserver keys.gnupg.net --recv-keys 
> C2D1AB061656AAC54B5E975485199DE8C6648E90
> 
> or obtain the project members' keys directly from Savannah:
> 
>  wget -q -O- 
> 'https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=pspp&download=1'
>  | gpg --import -
> 
> Either way, afterward, rerun the 'gpg --verify' command.
> 
> Changes from 1.6.1 to 1.6.2:
> 
> * Bug fixes.
> 
> 

Re: Pspp icon name in gui

[Friedrich Beckmann]

O.k. - I did not find them...

> Without the fix, when I minimize the PSPPIRE window and then hit the
> key that shows all the minimized window icons at the bottom of my
> screen (in the default GNOME window manager), I see a generic icon for
> PSPPIRE. With the fix, the PSPPIRE icon shows. So I think this is
> good.
>

Re: Pspp icon name in gui

[Friedrich Beckmann]

In the source for example here:

https://git.savannah.gnu.org/cgit/pspp.git/tree/src/ui/gui/psppire-window.c#n397

But I do not see this icon anywhere in the gui. Maybe this is used with other 
window managers?

> Am 30.06.2022 um 06:12 schrieb Ben Pfaff :
> 
> 
> Where does this icon name show up? I hadn't noticed anything odd, but maybe I 
> can fix it if I can see it myself.
> 
>> On Wed, Jun 29, 2022, 9:01 PM Friedrich Beckmann  
>> wrote:
>> Hi John,
>> 
>> the pspp icon name was changed to org.gnu.pspp. The gui code sets the window 
>> icon at various places to pspp. I could not figure out where this icon is 
>> used in the window manager. Do you see an effect somewhere? 
>> 
>> Regards
>> 
>> Fritz
>> 

Pspp icon name in gui

[Friedrich Beckmann]

Hi John,

the pspp icon name was changed to org.gnu.pspp. The gui code sets the window 
icon at various places to pspp. I could not figure out where this icon is used 
in the window manager. Do you see an effect somewhere? 

Regards

Fritz

Re: pspp-1.6.1 released [stable]

[Friedrich Beckmann]

Hi Ben,

shall we do a 1.6.2 release to include the icon fix?

Fritz

> Am 24.06.2022 um 18:57 schrieb Ben Pfaff :
> 
> I'm very pleased to announce the release of a new version of GNU PSPP.
> PSPP is a program for statistical analysis of sampled data.  It is a
> free replacement for the proprietary program SPSS.
> 
> Here are the compressed sources and a GPG detached signature[*]:
>  https://ftp.gnu.org/gnu/pspp/pspp-1.6.1.tar.gz
>  https://ftp.gnu.org/gnu/pspp/pspp-1.6.1.tar.gz.sig
> 
> Use a mirror for higher download bandwidth:
>  http://www.gnu.org/order/ftp.html
> 
> [*] Use a .sig file to verify that the corresponding file (without the
> .sig suffix) is intact.  First, be sure to download both the .sig file
> and the corresponding tarball.  Then, run a command like this:
> 
>  gpg --verify pspp-1.6.1.tar.gz.sig
> 
> If that command fails because you don't have the required public key,
> then run this command to import it:
> 
>  gpg --keyserver keys.gnupg.net --recv-keys 
> C2D1AB061656AAC54B5E975485199DE8C6648E90
> 
> or obtain the project members' keys directly from Savannah:
> 
>  wget -q -O- 
> 'https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=pspp&download=1'
>  | gpg --import -
> 
> Either way, afterward, rerun the 'gpg --verify' command.
> 
> Changes from 1.6.0 to 1.6.1:
> 
> * The SET command now supports LEADZERO for controlling output of a
>   leading zero in F, COMMA, and DOT format.
> 
> * Bug fixes and translation updates.
> 
> 

Thank you for your translations for the pspp 1.6.0 release!

[Friedrich Beckmann]

Dear Translators,

thank you very much for your translations for the pspp 1.6.0 release! I have 
just merged the translations with this commit:

https://git.savannah.gnu.org/cgit/pspp.git/commit/?id=fd9f8f66a9dd948d25e1da1838e0db96f47a784f

Regards

Friedrich

Re: pspp-1.5.5

[Friedrich Beckmann]

1.5.5-1 building on debian:

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

> Am 11.04.2022 um 01:48 schrieb Ben Pfaff :
>
> I just put out PSPP 1.5.5. It has bug fixes and translation updates since
> the recent 1.5.4 release.
>
> I'm going to try to fix https://savannah.gnu.org/bugs/?61809 before
> releasing 1.6.0.
>

Re: pspp-1.5.4

[Friedrich Beckmann]

Hi Ben,

i just changed the metainfo file and added the 1.5.4 release

https://git.savannah.gnu.org/cgit/pspp.git/commit/?id=cbfb46348d9fd638e02be86914e23e4ddfffd6aa

I think it would be nice if you could add the release information including the 
date
in the metainfo before you do a release. Otherwise the released tarball does 
not include
the release information.

Cheers

Fritz

> Am 01.04.2022 um 05:08 schrieb Ben Pfaff :
> 
> I put out a release of PSPP 1.5.4 at alpha.gnu.org and sent it to the
> translation project to get new translations. I think it's about time
> to release 1.6.0 (but please let me know if you think there are bugs
> we should fix first).
> 

spread-sheet-widget 0.8-1 is in debian unstable

[Friedrich Beckmann]

Hi John,

i made an upload of the spread-sheet-widget 0.8 to debian unstable

https://buildd.debian.org/status/package.php?p=spread-sheet-widget

Cheers

Fritz

Matrix multiplication / exponentiation

[Friedrich Beckmann]

I found the following during translation:

https://git.savannah.gnu.org/cgit/pspp.git/tree/src/language/stats/matrix.c#n3386

Shouldn’t that be exponentiation instead of multiplication?

Fritz

Re: pspp-1.5.4

[Friedrich Beckmann]

Hi Ben,

thanks for the release. I had a look at the bugtracker and I think these bugs

Saving as .odt / csv in 1.5.3 results empty documants / sheets. - 
https://savannah.gnu.org/bugs/?61549 

Import dialog: Preview shows correct data but import results in empty data view 
(Text Delimeter) - https://savannah.gnu.org/bugs/?61809

saved to spv, then cannot extract to odt - https://savannah.gnu.org/bugs/?62082

Results for ASRESID in CROSSTABS incorrect. 1.4.1 - 
https://savannah.gnu.org/bugs/?60982

might be worth looking at before doing a 1.6 release.

Cheers

Fritz


> Am 01.04.2022 um 05:08 schrieb Ben Pfaff :
> 
> I put out a release of PSPP 1.5.4 at alpha.gnu.org and sent it to the
> translation project to get new translations. I think it's about time
> to release 1.6.0 (but please let me know if you think there are bugs
> we should fix first).
> 

Re: Your automagic screenshots!

[Friedrich Beckmann]

I answered her in the mailing list to export from excel to csv and to import 
from csv to pspp. That seemed to be sufficient. I was more wondering how to 
engage people who probably are not in the position to install the build 
environment to render the documentation. 

Friedrich 

> Am 23.03.2022 um 04:59 schrieb Ben Pfaff :
> 
> Maybe we should add instructions for conversion to the FAQ or the
> manual. The batch mode instructions look helpful to me.
> 

Your automagic screenshots!

[Friedrich Beckmann]

Hi John,

i just had a look at your automagic screenshots that you take for the 
documentation. Very nice. This Nina who asked on the mailing list

https://lists.gnu.org/archive/html/pspp-users/2022-03/msg00031.html 


how to import from Excel mentioned that it would be nice to have a description 
for this in the manual. I wanted to propose her that she could
make such a manual which would currently mean to write the texi code which 
would require to have a build system running to see the rendered pages. 
Automagic screenshots would be even more advanced.

Did you ever propose users just to make some kind of handcrafted tutorial or 
documentation, provide it in pdf under some CC license and we would publish it 
on the gnu website?

Cheers

Fritz

Re: Makefile.am - nerd question

[Friedrich Beckmann]

> Am 21.03.2022 um 17:15 schrieb Ben Pfaff :
> 
> I'm having a little trouble understanding exactly what you're saying.
> Let's be precise. I think there are three versions of the line at
> issue:
> #1: The version before my recent change.
> #2: The version after my recent change.
> #3: The version we would have if we removed the line entirely.
> 
> I found that #1 didn't work for me with my autobuilder and that #2
> did. I haven't tried #3.
> Which versions work for you?

I tried #3 and it worked. Did not try the dist target, but BUILT_SOURCES is a 
dependency of distdir by default. In order to build the binaries directly as it 
was done in the windows build, the dependency is too late in the list of 
dependencies, i.e. after the object files such that the compiler already tries 
to compile the c files before the headers are build. So I was wondering why the 
line is there. It works if do just „make“ but it does not work if you do „make 
src/ui/terminal/pspp“ - neither with #2 nor #3. 

I just thought that there is an easy explanation for this line that I just dont 
see.

Fritz

Re: Nightly distribution build - switched off nightly?

[Friedrich Beckmann]

Thanks!

The Buildbot has detected a restored build on builder win-cross while building 
GNU pspp CI.
Full details are available at:
   https://caeis.etech.fh-augsburg.de/buildbot/#builders/7/builds/297


> Am 20.03.2022 um 17:25 schrieb Ben Pfaff :
> 
> I trigger the "nightly" builds manually these days. I try to run them
> once a day but sometimes I forget or I don't turn on my computer that
> day.
> 
> I started one now.
> 
> On Sun, Mar 20, 2022 at 12:14 AM Friedrich Beckmann
>  wrote:
>> 
>> Hi Ben,
>> 
>> I added some bugfixes to make the Windows build work again. The windows 
>> builds are based on your nightly distribution builds:
>> 
>> https://pspp.benpfaff.org/~blp/pspp-master/
>> 
>> However the „nightly“ seems to be switched off… The last build is from 17th 
>> of March.
>> 
>> https://caeis.etech.fh-augsburg.de/buildbot/#/console
>> 
>> Cheers
>> 
>> Fritz

Makefile.am - nerd question

[Friedrich Beckmann]

Hi Ben,

regarding this line in Makefile.am

https://git.savannah.gnu.org/cgit/pspp.git/tree/Makefile.am#n155

that you changed in your commit

https://git.savannah.gnu.org/cgit/pspp.git/commit/?id=75c0aef55a6135a0398d520519e79df2b3a21e0e
 . 

I removed that line alltogether and I could not find a difference. That line is 
not sufficient to build the gnulib headers before compiling the c files as the 
dependency is too late in the dependency list. When I remove it and touch the 
headers, then a rebuild is still started. I tried to understand the purpose but 
I could not find one.

Fritz

Nightly distribution build - switched off nightly?

[Friedrich Beckmann]

Hi Ben,

I added some bugfixes to make the Windows build work again. The windows builds 
are based on your nightly distribution builds:

https://pspp.benpfaff.org/~blp/pspp-master/

However the „nightly“ seems to be switched off… The last build is from 17th of 
March.

https://caeis.etech.fh-augsburg.de/buildbot/#/console

Cheers

Fritz

Re: PSPP and Log4j

[Friedrich Beckmann]

Hi Therese,

thanks for questions regarding pspp and log4j. Could you maybe tell us about 
your use of pspp, i.e. for what kind of data do you use pspp and what kind of 
analysis are you doing?

Thanks

Friedrich

> Am 03.01.2022 um 08:29 schrieb  
> :
> 
> Hello,
>  
> I work with managing your system PSPP and hope that I have come to the right 
> place.
> Given the recent situation regarding the vulnerability risk around Log4J, I 
> would be grateful if you could answer the following questions:
>   
> Does the product contain the Log4J framework?
>   • Is your product vulnerable to CVE-2021-44228?
>   • How do you intend to handle the vulnerability?
>   • How should we act as a customer?
>   • IF there is no immediate solution WHEN this and WHAT do we do in the 
> meantime?
>  
>  
> Med vänlig hälsning
> Therese Horn
> Projektledare | IT Projekt och kvalitet
> +46470588605 | +46767207948
> therese.h...@kronoberg.se
> www.regionkronoberg.se
>  
> 

Reintroduced the windows installer link on the download page - Added a buildbot badge

[Friedrich Beckmann]

I have reintroduced the windows installer link to the nightly windows installer 
builds on the buildbot on the gnu pspp website.

See: https://www.gnu.org/software/pspp/get.html

I also added the nice buildbot badge! I have a direct link to the nightly build 
of today because that one at least did not crash when I ran the installer on a 
windows 11 machine. It would be better to have a windows installer based on a 
released version but I guess the windows build does not work in the last 1.4.1 
release.

Cheers

Fritz

Re: Windows cross compile build

[Friedrich Beckmann]

Hi John,

I tested the pspp-64bit-install.exe installer from here

https://caeis.etech.fh-augsburg.de/downloads/windows/pspp-win-daily/1.5.3-g8d023f/
 
<https://caeis.etech.fh-augsburg.de/downloads/windows/pspp-win-daily/1.5.3-g8d023f/>

on Windows 11 and it did not crash. The examples and the html help are working.

As you already guessed the problem was the mingw64-configure/make which does not
work as expected. I now build also the dependencies with your script on debian 
bullseye.
How did you survive to even jump into the nsis windoze installer stuff?...

Cheers

Fritz

> Am 29.12.2021 um 23:42 schrieb John Darrington  <mailto:j...@darrington.wattle.id.au>>:
> 
> I think Harry had a similar problem, and from what I remember I concluded
> that the  mingw64-  scripts which Opensuse shipped were trying to be too
> clever for their own good.
> 
> What they do is they force ALL builds to ALWAYS build for mingw64 - which
> is not what we want.   For reasons I won't discuss now, cross building
> PSPP first requires a native build.  The mingw64-configure/make stuff
> messes this up.
> 
> I presume you have executed the script Windows/build-dependencies?
> 
> I suggest you build the way the build-dependencies script recommends,
> by passing the --host= and other arguments.
> 
> J'
> 
> On Wed, Dec 29, 2021 at 10:18:34PM +0100, Friedrich Beckmann wrote:
> Hi John,
> 
> I try to get the CI/CD chain back to live. I tried to build the windows 
> cross build on opensuse by using the the latest source package from Ben which 
> is 1.5.3-g8d023f. Inside the source tree I created a build directory „fritz“. 
> From there I started "mingw64-configure“ and then „mingw64-make“. The 
> configure stage was successfull but the make ended with
> 
> libtool: link: /usr/bin/x86_64-w64-mingw32-ranlib .libs/libgl.a
> libtool: link: ( cd ".libs" && rm -f "libgl.la <http://libgl.la/>" && ln 
> -s "../libgl.la <http://libgl.la/>" "libgl.la <http://libgl.la/>" )
> make[6]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz/native/gl'
> make[5]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz/native/gl'
> make[4]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz/native/gl'
> make[3]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz/native'
> (cd native && flock --verbose ./native-lock make src/ui/terminal/pspp)
> flock: getting lock took 0.16 seconds
> flock: executing make
> make[3]: Entering directory '/home/pspp/pspp-1.5.3-g8d023f/fritz/native'
> make[3]: *** No rule to make target 'src/ui/terminal/pspp'.  Stop.
> make[3]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz/native'
> make[2]: *** [Makefile:14330: native/src/ui/terminal/pspp] Error 2
> make[2]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz'
> make[1]: *** [Makefile:12371: all-recursive] Error 1
> make[1]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz'
> make: *** [Makefile:6490: all] Error 2
> (sandbox) pspp@windows:~/pspp-1.5.3-g8d023f/fritz$ mingw64-configure 
> 
> Do you maybe have an example how to do the windows cross build?
> 
> Regards
> 
> Fritz
> 
> 
> 

Windows build back on buildbot - nightly pspp windows installers available for download

[Friedrich Beckmann]

Hi,

i have reintroduced the nightly windows builds on the buildbot by using John's 
new windows cross compiling strategy. The builder is called „win-cross“ on the 
buildbot:

https://caeis.etech.fh-augsburg.de/buildbot/#/builders

The building system is based on debian bullseye amd64. The setup of the build 
machine including the installed packages is described here:

https://github.com/fredowski/pspp-buildbot/blob/master/create_win_vm.sh

The build is done with Ben’s nightly pspp distribution. The build script is 
here:

https://github.com/fredowski/pspp-buildbot/blob/master/win/buildpspp-win.sh

The build includes the generation of all the build dependencies with John’s 
fabulous script. The installers are then copied to the download area and are 
available for download here:

https://caeis.etech.fh-augsburg.de/downloads/windows/pspp-win-daily/1.5.3-g8d023f/

I have not tested the windows installers. So if anybody with a windows machine 
is out there - maybe you could test the pspp windows version.

Cheers

Fritz

Windows cross compile build

[Friedrich Beckmann]

Hi John,

I try to get the CI/CD chain back to live. I tried to build the windows cross 
build on opensuse by using the the latest source package from Ben which is 
1.5.3-g8d023f. Inside the source tree I created a build directory „fritz“. From 
there I started "mingw64-configure“ and then „mingw64-make“. The configure 
stage was successfull but the make ended with

libtool: link: /usr/bin/x86_64-w64-mingw32-ranlib .libs/libgl.a
libtool: link: ( cd ".libs" && rm -f "libgl.la" && ln -s "../libgl.la" 
"libgl.la" )
make[6]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz/native/gl'
make[5]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz/native/gl'
make[4]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz/native/gl'
make[3]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz/native'
(cd native && flock --verbose ./native-lock make src/ui/terminal/pspp)
flock: getting lock took 0.16 seconds
flock: executing make
make[3]: Entering directory '/home/pspp/pspp-1.5.3-g8d023f/fritz/native'
make[3]: *** No rule to make target 'src/ui/terminal/pspp'.  Stop.
make[3]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz/native'
make[2]: *** [Makefile:14330: native/src/ui/terminal/pspp] Error 2
make[2]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz'
make[1]: *** [Makefile:12371: all-recursive] Error 1
make[1]: Leaving directory '/home/pspp/pspp-1.5.3-g8d023f/fritz'
make: *** [Makefile:6490: all] Error 2
(sandbox) pspp@windows:~/pspp-1.5.3-g8d023f/fritz$ mingw64-configure 

Do you maybe have an example how to do the windows cross build?

Regards

Fritz

Re: Daily tar buggy

[Friedrich Beckmann]

Hi Ben,

the opensuse and the macOS homebrew build both use your latest.tgz . Your last 
creation of the source tgz did not work

https://benpfaff.org/~blp/pspp-master/latest/source/

It is not a problem of the source in the git repo.

Regards 

Fritz

> Am 22.12.2021 um 19:06 schrieb Ben Pfaff :
> 
> Did it get cleared up? It looks mostly green to me for the current top
> commit "Convert all Perl build tools to Python and remove Perl build
> dependency". I see some red under opensuse, but I'm not sure how to
> interpret the results there.
> 
>> On Tue, Dec 21, 2021 at 10:12 PM Friedrich Beckmann
>>  wrote:
>> 
>> Hi Ben,
>> 
>> your Daily Package seems corrupted.
>> 
>> https://caeis.etech.fh-augsburg.de/buildbot/#/console
>> 
>> Herzliche Grüße
>> 
>> Fritz

Daily tar buggy

[Friedrich Beckmann]

Hi Ben,

your Daily Package seems corrupted.

https://caeis.etech.fh-augsburg.de/buildbot/#/console

Herzliche Grüße 

Fritz

Builds are failing on buildbot

[Friedrich Beckmann]

Hi,

the builds are failing on the buildbot after the introduction of the matrix 
command. See:

https://caeis.etech.fh-augsburg.de/buildbot/#/console

Cheers

Fritz

Fwd: Buildbot success in GNU pspp CI on debian-sid-i386

[Friedrich Beckmann]

The buildbot says it is fixed...

> Anfang der weitergeleiteten Nachricht:
> 
> Von: build...@pspp.org
> Betreff: Buildbot success in GNU pspp CI on debian-sid-i386
> Datum: 6. Dezember 2021 um 18:52:47 MEZ
> An: friedrich.beckm...@gmx.de
> 
> The Buildbot has detected a restored build on builder debian-sid-i386 while 
> building GNU pspp CI.
> Full details are available at:
>http://caeis.etech.fh-augsburg.de:8010/#builders/5/builds/167
> 
> Buildbot URL: http://caeis.etech.fh-augsburg.de:8010/
> 
> Worker for this Build: hsa-worker
> 
> Build Reason: 
> Blamelist: Ben Pfaff , John Darrington 
> 
> 
> Build succeeded!
> 
> Sincerely,
> -The Buildbot
> 

Fwd: Buildbot failure in GNU pspp CI on debian-sid-i386

[Friedrich Beckmann]

Hi,

the pspp build fails for the i386 build. At least the regression claims that.

Cheers

Fritz

> Anfang der weitergeleiteten Nachricht:
> 
> Von: build...@pspp.org
> Betreff: Buildbot failure in GNU pspp CI on debian-sid-i386
> Datum: 6. Dezember 2021 um 07:13:07 MEZ
> An: friedrich.beckm...@gmx.de
> 
> http://caeis.etech.fh-augsburg.de:8010/#builders/5/builds/166 
> 

Re: Script to cross build pspp for windows

[Friedrich Beckmann]

Hi John,

thanks jumping into the dark world of windoze... I am currently quite busy. 
Thats why I could not spend time on this topic - but I guess it is really worth 
to do this because many users use this.

Fritz

> Am 19.03.2021 um 20:49 schrieb John Darrington :
> 
> For those who are interested in cross building for windows, attached
> is a script which downloads all the dependencies, compiles and links
> a working pspp binaries.
> 
> It takes about 15 mins on my machine.  The only caveat is that the
> meson provided by Debian is not recent enough.  You must get the
> one from Debian backports.
> 
> It doesn't come with a fancy self contained installer like windows
> people often expect.  I tried using Harry's pspp.nsi file but it
> wouldn't work for me (I'm not sure why).  Also there are a few things
> (like icons) missing.
> 
> Perhaps someone who knows a bit more about Windows might be interested
> in finishing the job.
> 
> J'
> 

Re: Remove links to Windows builds?

[Friedrich Beckmann]

Hi Michel,

you can see the build scripts for Windows from the buildbot here:

https://github.com/fredowski/pspp-buildbot

The problem is the cross build which has problems with the documentation 
because that requires the native pspp to produce some parts of the 
documentation. That are more or less the scripts from Harry. 

Friedrich

> Am 14.03.2021 um 21:21 schrieb Michel Boaventura :
> 
> Hey all,
> 
> I'm making progress compiling PSPP for windows but came out with a error 
> which seems to be a bug:
> 
> ../src/ui/gui/psppire-import-spreadsheet.c:34:45: error: unknown type name 
> 'uint'; did you mean 'u_int'?
> set_column_header_label (GtkWidget *button, uint i, gpointer user_data)
>^~~~
>u_int
> 
> 
> Changing this uint to uint32_t everything seems to work.
> 
> On 21/03/11 12:34PM, Michel Boaventura wrote:
>> Hey all,
>> 
>> Resending this message since I've accidentaly sent it to just Ben encrypted 
>> with his key.
>> 
>> Every semester I teach a basic PSPP course to around 100 students, 90% of 
>> which use Windows. They all download
>> PSPP from Harry's https://sourceforge.net/projects/pspp4windows/. What kind 
>> of errors are people reporting,
>> because I think I'm missing those emails.
>> 
>> I'm more then happy to try to tackle those. Although I don't use Windows 
>> myself it's a (sadly) highly used OS
>> here on Brazil, mainly from Human Science students.
>> 
>> Cheers,
>> 
>> On 21/03/10 09:31AM, Ben Pfaff wrote:
>>> I'm starting to believe that we should remove the links to the Windows
>>> builds entirely, because people are reporting bugs that we can't fix.
>>> 
>>> What do you think?
>>> 
>> 
>> --
>> Michel Boaventura
> 
> 
> 
> --
> Michel Boaventura

Re: Remove links to Windows builds?

[Friedrich Beckmann]

Hi Ben,

I don’t think so. I guess that the majority of users use the windows version. 
Some issues like the Windows7 64Bit issue pop up some times. I think it is 
better to inform the users that windows cannot be build currently and that 
there are some known issues. So they have to wait. Anyway the released version 
works for most I guess.

Fritz

> Am 10.03.2021 um 18:31 schrieb Ben Pfaff :
> 
> I'm starting to believe that we should remove the links to the Windows
> builds entirely, because people are reporting bugs that we can't fix.
> 
> What do you think?
> 

Re: CI - builds are failing...

[Friedrich Beckmann]

The buildbot is happy again:

http://caeis.etech.fh-augsburg.de:8010/#/console

> Am 07.01.2021 um 07:35 schrieb Ben Pfaff :
> 
> It's fixed now.
> 
> On Wed, Jan 6, 2021 at 10:19 PM Friedrich Beckmann
>  wrote:
>> 
>> CI - the builds are failing…
>> 
>> http://caeis.etech.fh-augsburg.de:8010/#/console
>> 
>> 

CI - builds are failing...

[Friedrich Beckmann]

CI - the builds are failing…

http://caeis.etech.fh-augsburg.de:8010/#/console 

Re: Buildbot success in GNU pspp CI on debian-buster-amd64

[Friedrich Beckmann]

Hi John,

it tried the cross build with the script from Harry based on opensuse and mingw 
in an out of source build but it ends with the following:

...
make[4]: Leaving directory 
'/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build/gl'
make[3]: Leaving directory 
'/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build/gl'
make[2]: Leaving directory 
'/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build/gl'
Making all in gl
make[2]: Entering directory 
'/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build/gl'
make  all-recursive
make[3]: Entering directory 
'/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build/gl'
make[4]: Entering directory 
'/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build/gl'
make[4]: Nothing to be done for 'all-am'.
make[4]: Leaving directory 
'/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build/gl'
make[3]: Leaving directory 
'/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build/gl'
make[2]: Leaving directory 
'/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build/gl'
Making all in po
make[2]: Entering directory 
'/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build/po'
make[2]: Leaving directory 
'/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build/po'
make[2]: Entering directory 
'/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build'
/usr/bin/mkdir -p native
(cd native && 
/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build/../configure 
--host=$build --without-gui)
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '1000' is supported by ustar format... yes
checking whether GID '100' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking whether make supports the include directive... yes (GNU style)
checking for gcc... i686-w64-mingw32-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... configure: error: in 
`/home/pspp/pspp-master-20210103/pspp-1.5.2-g21f20b/build/native':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details


Config log:


...
It was created by GNU PSPP configure 1.5.2-g21f20b, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ../configure --cache-file=mingw32-config.cache --host=i686-w64-mingw32 
--build=x86_64-suse-linux-gnu --target=i686-w64-mingw32 
--prefix=/usr/i686-w64-mingw32/sys-root/mingw 
--exec-prefix=/usr/i686-w64-mingw32/sys-root/mingw 
--bindir=/usr/i686-w64-mingw32/sys-root/mingw/bin 
--sbindir=/usr/i686-w64-mingw32/sys-root/mingw/sbin 
--sysconfdir=/usr/i686-w64-mingw32/sys-root/mingw/etc 
--datadir=/usr/i686-w64-mingw32/sys-root/mingw/share 
--includedir=/usr/i686-w64-mingw32/sys-root/mingw/include 
--libdir=/usr/i686-w64-mingw32/sys-root/mingw/lib 
--libexecdir=/usr/i686-w64-mingw32/sys-root/mingw/libexec 
--localstatedir=/usr/i686-w64-mingw32/sys-root/mingw/var 
--sharedstatedir=/usr/i686-w64-mingw32/sys-root/mingw/com 
--mandir=/usr/i686-w64-mingw32/sys-root/mingw/share/man 
--infodir=/usr/i686-w64-mingw32/sys-root/mingw/share/info --enable-relocatable 
PSPPIRE_LDFLAGS=/tmp/pspp.res --with-libpq
...


Maybe a configure option to completely disable the documentation generation 
could help 

Cheers

Fritz


> Am 03.01.2021 um 19:33 schrieb John Darrington :
> 
> Thanks Fritz,
> 
> The mingw build however seems to not work.  You need to reconfigure
> it to build out of source.  In-source cross building is no longer
> supported since a few weeks.
> 
> J'
> 
> On Sun, Jan 03, 2021 at 10:31:48AM +0100, Friedrich Beckmann wrote:
> CI - the builds are back…
> 
> 
> 
>> Anfang der weitergeleiteten Nachricht:
>> 
>> Von: build...@pspp.org
>> Betreff: Buildbot success in GNU pspp CI on debian-buster-amd64
>> Datum: 3. Januar 2021 um 09:11:14 MEZ
>> An: friedrich.beckm...@gmx.de
>> 
>> The Buildbot has detected a restored build on builder debian-buster-amd64 
>> while building GNU pspp CI.
>> Full details are available at:
>>   http://caeis.etech.fh-augsburg.de:8010/#builders/4/builds/215
>> 
>> Buildbot URL: http://caeis.etech.fh-augsburg.de:8010/
>> 
>> Worker for this Build: hsa-worker
>> 
>> Build Reason: 
>> Blamelist: Ben Pfaff , John Darrington 
>> 
>> 
>> Build succeeded!
>> 
>> Sincerely,
>> -The Buildbot
>> 
> 

Fwd: Buildbot success in GNU pspp CI on debian-buster-amd64

[Friedrich Beckmann]

CI - the builds are back…



> Anfang der weitergeleiteten Nachricht:
> 
> Von: build...@pspp.org
> Betreff: Buildbot success in GNU pspp CI on debian-buster-amd64
> Datum: 3. Januar 2021 um 09:11:14 MEZ
> An: friedrich.beckm...@gmx.de
> 
> The Buildbot has detected a restored build on builder debian-buster-amd64 
> while building GNU pspp CI.
> Full details are available at:
>http://caeis.etech.fh-augsburg.de:8010/#builders/4/builds/215
> 
> Buildbot URL: http://caeis.etech.fh-augsburg.de:8010/
> 
> Worker for this Build: hsa-worker
> 
> Build Reason: 
> Blamelist: Ben Pfaff , John Darrington 
> 
> 
> Build succeeded!
> 
> Sincerely,
> -The Buildbot
> 

CI - builds are failing

[Friedrich Beckmann]

the latest commits result in failing builds:

http://caeis.etech.fh-augsburg.de:8010/#/

Fritz

Re: pspp and rust...

[Friedrich Beckmann]

One could put some effort into working around this but it is more the story how 
many dependencies we depend on in the end if we start from scratch. I guess 
everything would work with an earlier version of librsvg which could be build 
without rust but then it ends up in fiddling with the dependencies of the brew 
packages.

> Am 20.12.2020 um 09:31 schrieb John Darrington :
> 
> Presumably librsvg can be cross compiled ?
> 
> J'
> 
> On Sun, Dec 20, 2020 at 09:04:18AM +0100, Friedrich Beckmann wrote:
> I just asked a friend to compile pspp on the new Macbook with the A1 
> processor using homebrew. I turned out that „rust“ fails to compile and he 
> asked if we need rust to run pspp. The story is that we need some icons from 
> the adwaita-icon-theme. adwaita-icon-theme needs librsvg. librsvg needs rust. 
> So yes - to have pspp with the gui we need rust.
> 
> Fritz
> 

Re: warning

[Friedrich Beckmann]

Hi Harry,

i think you can ignore both. I figured out that Copy and Paste will work with 
higher dpi when librsvg above 2.44 is used. Not that important.

Fritz

> Am 12.12.2020 um 11:28 schrieb Harry Thijssen :
> 
> Hi
> 
> When configuring I get the warning:
> 
> configure: WARNING: The following optional packages are not installed.
> You may wish to install them to obtain additional functionality:
>org.fsf.metainfo.xml will not be translated. Install gettext >=0.20 or 
> appstream.
> librsvg >= 2.44 required for high dpi Copy and Paste
> 
> The first seems nothing to worry about. The second could be more of a 
> problem. However I tried to install librsvg on the host and in mingw,  but 
> both seem not to solve the issue.  Is it something to worry about?  Anybody 
> an idea which packet is needed?
> 
> Stay save

Re: PSPP version

[Friedrich Beckmann]

Hi Harry,

yes, the last release is 1.4.1

Fritz

> Am 05.12.2020 um 22:55 schrieb Harry Thijssen :
> 
> Hi
> 
> I am a bit confused about the current version of PSPP. It seems to be 1.5.2. 
> But is never released according to the released tarballs. I know there were 
> some problems with the versions. 
> On https://savannah.gnu.org/projects/pspp/ the latest is 1.4.0
> On https://www.gnu.org/software/pspp/ the latest  is 1.4.1
> 
> Is it indeed 1.4.1 ?
> 
> Stay safe
> 

Re: cross building PSPP is not possible

[Friedrich Beckmann]

Hi Harry,

I also get failed builds for the windows cross build. The reason is here:

https://lists.gnu.org/archive/html/pspp-dev/2020-11/msg00011.html

John creates example results for the documentation with the build pspp 
executable. That does not work for the cross build because pspp.exe cannot be 
executed on the build host. The idea was to disable the build of the 
documentation with some configure option. I worked a little bit on that but 
without success so far. What I figured out is that it is not possible to put 
„info_TEXINFOS" in a conditional context - that is a restriction in automake. I 
then tried build the documentation in a hierarchical build but that requires 
some refactoring.

Fritz

> Am 05.12.2020 um 22:48 schrieb Harry Thijssen :
> 
> Hi
> 
> I still get this error: 
> 
> libtool: link: ( cd "src/.libs" && rm -f "libpspp-core.la" && ln -s 
> "../libpspp-core.la" "libpspp-core.la" )
> /bin/sh ./libtool  --tag=CC   --mode=link i686-w64-mingw32-gcc -Wall -Wextra 
> -Wwrite-strings -Wstrict-prototypes -Wpointer-arith -Wno-sign-compare 
> -Wmissing-prototypes -ggdb   `: /usr/i686-w64-mingw32/sys-root/mingw/bin` 
> -Wl,--exclude-libs=libintl.a -Wl,--exclude-libs=libiconv.a 
> -Wl,--no-keep-memory -o src/ui/terminal/pspp.exe  src/ui/terminal/libui.la 
> src/ui/libuicommon.la src/libpspp.la src/libpspp-core.la 
> -L/usr/i686-w64-mingw32/sys-root/mingw/lib -lpangocairo-1.0 -lpango-1.0 
> -lgobject-2.0 -lglib-2.0 -lintl -lcairo  -lreadline 
> -L/usr/i686-w64-mingw32/sys-root/mingw/lib -lgsl -lgslcblas -lm -liconv 
> -lreadline -lgslcblas -lz -lintl 
> libtool: link: i686-w64-mingw32-gcc -Wall -Wextra -Wwrite-strings 
> -Wstrict-prototypes -Wpointer-arith -Wno-sign-compare -Wmissing-prototypes 
> -ggdb -Wl,--exclude-libs=libintl.a -Wl,--exclude-libs=libiconv.a 
> -Wl,--no-keep-memory -o src/ui/terminal/.libs/pspp.exe  
> src/ui/terminal/.libs/libui.a src/ui/.libs/libuicommon.a src/.libs/libpspp.a 
> -L/usr/i686-w64-mingw32/sys-root/mingw/lib src/.libs/libpspp-core.a -lxml2 
> -lpq -ladvapi32 -lws2_32 -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 
> -lglib-2.0 -lcairo -lgsl 
> /usr/i686-w64-mingw32/sys-root/mingw/lib/libiconv.dll.a -lreadline -lgslcblas 
> -lz -lintl -L/usr/i686-w64-mingw32/sys-root/mingw/lib
> (cd ./examples \
>  && 
> /home/harry/pspp-master-20201205/pspp-1.5.2-ga06dd5/src/ui/terminal/pspp 
> ../doc/pspp-figures/aggregate.sps -o - -O format=spv) > 
> doc/pspp-figures/aggregate.spv.tmp
> /bin/sh: line 1: 
> /home/harry/pspp-master-20201205/pspp-1.5.2-ga06dd5/src/ui/terminal/pspp: No 
> such file or directory
> make[2]: *** [Makefile:14303: doc/pspp-figures/aggregate.spv] Error 127
> make[2]: Leaving directory 
> '/home/harry/pspp-master-20201205/pspp-1.5.2-ga06dd5'
> 
> Stay safe

Homepage: Obtain pspp - MacOS - Mention homebrew installation

[Friedrich Beckmann]

Hi John,

for the MacOS system we have three different ways to install pspp

a) The DMG bundle
b) Install via macports
c) Install via homebrew (=> https://brew.sh) 

a) and b) are already mentioned here:

https://www.gnu.org/software/pspp/get.html

Can you add the homebrew install on that MacOS paragraph? You can link to the 
„tap“

https://github.com/fredowski/homebrew-pspp

which provides the build scripts for the homebrew environment.

Of course you are free to use the „badges“ showing the build status for the 
variants which I have included on the page here:

https://www.hs-augsburg.de/~beckmanf/pspp/

Cheers

Fritz

Re: Windows Cross build fails because pspp executable is required during build

[Friedrich Beckmann]

I think that would be a perfect solution for the windows cross build.

Fritz

> Am 19.11.2020 um 10:35 schrieb John Darrington :
> 
> One thing we could do, is add a configure flag --without-documentation so
> that the person building can choose not generate any documents.
> 

Re: Windows Cross build fails because pspp executable is required during build

[Friedrich Beckmann]

Maybe it is possible that 

make
make install

will produce an info file without examples? Examples only with make doc or 
similar?

Another idea would be a make target which is crafted for the cross compile 
process without
the requirement of a pspp executable that runs on the build host. 

Fritz

> Am 17.11.2020 um 18:40 schrieb John Darrington :
> 
> On Tue, Nov 17, 2020 at 06:04:39PM +0100, Friedrich Beckmann wrote:
> Is it a big deal to produce the examples only for the doc target?
> 
> Our "doc" target is a convenience thing which is defined as
> 
> doc: $(INFO_DEPS) $(DVIS) $(PDFS) $(PSS) $(HTMLS) $(dist_docbook_DATA)
> 
> 
> Note that INFO_DEPS includes doc/pspp.info which since it is documentation
> needs the examples.  INFO_DEPS is a standard dependency of the all-am target
> which is set automatically by automake.
> 
> So I think your question boils down to "Can we omit pspp.info from the default
> target?"-   I suppose the answer to that question is "Yes we could".
> However it would fly in the face of the GNU conventions, which installs the
> info files when running "make install".
> 
> J'
> 
> 
> 

Re: Windows Cross build fails because pspp executable is required during build

[Friedrich Beckmann]

Is it a big deal to produce the examples only for the doc target?

> Am 17.11.2020 um 17:51 schrieb Ben Pfaff :
> 
> For the specific case of cross-building Windows on GNU/Linux, it could
> also work to install Wine. Many of the tests work OK that way, for
> example.
> 
> On Tue, Nov 17, 2020 at 5:02 AM John Darrington
>  wrote:
>> 
>> We're now using the pspp binary to generate its own documentation.  So
>> the documentation cannot work when cross building.  I can think of 3
>> things we could do:
>> 
>> 1.  Like Fritz suggests, ship the generated files in the tarball.
>> 2.  Don't generate any documentation when cross building.
>> 3.  For cross builds, also build a native binary and generate the
>>documentation using that.
>> 
>> All of these solutions have their own (de)merits.
>> 
>> J'
>> 
>> 
>> 
>> On Tue, Nov 17, 2020 at 07:20:22AM +0100, Friedrich Beckmann wrote:
>> Hi,
>> 
>> i completely forgot that the windows build is a cross build, i.e. 
>> pspp.exe can of course not be executed on the build machine. The current 
>> build process fails with
>> 
>> 
>> (cd ./examples \
>>  && 
>> /home/pspp/pspp-master-20201117/pspp-1.5.2-gc04cd4/src/ui/terminal/pspp.exe 
>> ../doc/examples/autorecode.sps -o - -O format=spv) > 
>> doc/examples/autorecode.spv.tmp
>> /bin/sh: line 1: 
>> /home/pspp/pspp-master-20201117/pspp-1.5.2-gc04cd4/src/ui/terminal/pspp.exe: 
>> cannot execute binary file: Fehler im Format der Programmdatei
>> make[2]: *** [Makefile:14217: doc/examples/autorecode.spv] Error 126
>> make[2]: Leaving directory 
>> '/home/pspp/pspp-master-20201117/pspp-1.5.2-gc04cd4'
>> make[1]: *** [Makefile:12303: all-recursive] Error 1
>> make[1]: Leaving directory 
>> '/home/pspp/pspp-master-20201117/pspp-1.5.2-gc04cd4'
>> make: *** [Makefile:6401: all] Error 2
>> Uncaught exception from user code:
>>system 'Mingw32-make'  failed: 512 at ./buildpspp4windows.pl line 
>> 568,  line 937.
>>main::ProcMake() called at ./buildpspp4windows.pl line 369
>>main::ProcGeneratePSPP("w32", "Debug") called at 
>> ./buildpspp4windows.pl line 124
>> program finished with exit code 2
>> elapsedTime=419.754343
>> 
>> ===
>> 
>> While executing a simple „make“
>> 
>> 
>> https://github.com/fredowski/pspp-buildbot/blob/master/win/buildpspp4windows.pl#L568
>> 
>> Any ideas how this can be avoided? Aren’t this examples for the 
>> documentation, i.e. could that be part of the doc target?
>> 
>> http://caeis.etech.fh-augsburg.de:8010/#/builders/7/builds/95
>> 
>> Fritz
>> 
>> 
>> 
>> 

Re: Windows Cross build fails because pspp executable is required during build

[Friedrich Beckmann]

Hi John,

we do 2. anyway. The problem is that the documentation is already build when 
going for a simple „make“. Instead it should only be invoked when doing „make 
doc“ or a similar task. Does this affect the html documentation also?

Fritz


> Am 17.11.2020 um 14:02 schrieb John Darrington :
> 
> We're now using the pspp binary to generate its own documentation.  So
> the documentation cannot work when cross building.  I can think of 3
> things we could do:
> 
> 1.  Like Fritz suggests, ship the generated files in the tarball.
> 2.  Don't generate any documentation when cross building.
> 3.  For cross builds, also build a native binary and generate the
>documentation using that.
> 
> All of these solutions have their own (de)merits.
> 
> J'
> 
> 
> 
> On Tue, Nov 17, 2020 at 07:20:22AM +0100, Friedrich Beckmann wrote:
> Hi,
> 
> i completely forgot that the windows build is a cross build, i.e. 
> pspp.exe can of course not be executed on the build machine. The current 
> build process fails with
> 
> 
> (cd ./examples \
>  && 
> /home/pspp/pspp-master-20201117/pspp-1.5.2-gc04cd4/src/ui/terminal/pspp.exe 
> ../doc/examples/autorecode.sps -o - -O format=spv) > 
> doc/examples/autorecode.spv.tmp
> /bin/sh: line 1: 
> /home/pspp/pspp-master-20201117/pspp-1.5.2-gc04cd4/src/ui/terminal/pspp.exe: 
> cannot execute binary file: Fehler im Format der Programmdatei
> make[2]: *** [Makefile:14217: doc/examples/autorecode.spv] Error 126
> make[2]: Leaving directory 
> '/home/pspp/pspp-master-20201117/pspp-1.5.2-gc04cd4'
> make[1]: *** [Makefile:12303: all-recursive] Error 1
> make[1]: Leaving directory 
> '/home/pspp/pspp-master-20201117/pspp-1.5.2-gc04cd4'
> make: *** [Makefile:6401: all] Error 2
> Uncaught exception from user code:
>   system 'Mingw32-make'  failed: 512 at ./buildpspp4windows.pl line 568, 
>  line 937.
>   main::ProcMake() called at ./buildpspp4windows.pl line 369
>   main::ProcGeneratePSPP("w32", "Debug") called at ./buildpspp4windows.pl 
> line 124
> program finished with exit code 2
> elapsedTime=419.754343
> 
> ===
> 
> While executing a simple „make“ 
> 
> 
> https://github.com/fredowski/pspp-buildbot/blob/master/win/buildpspp4windows.pl#L568
> 
> Any ideas how this can be avoided? Aren’t this examples for the 
> documentation, i.e. could that be part of the doc target?
> 
> http://caeis.etech.fh-augsburg.de:8010/#/builders/7/builds/95
> 
> Fritz 
> 
> 
> 

Windows Cross build fails because pspp executable is required during build

[Friedrich Beckmann]

Hi,

i completely forgot that the windows build is a cross build, i.e. pspp.exe can 
of course not be executed on the build machine. The current build process fails 
with


(cd ./examples \
 && 
/home/pspp/pspp-master-20201117/pspp-1.5.2-gc04cd4/src/ui/terminal/pspp.exe 
../doc/examples/autorecode.sps -o - -O format=spv) > 
doc/examples/autorecode.spv.tmp
/bin/sh: line 1: 
/home/pspp/pspp-master-20201117/pspp-1.5.2-gc04cd4/src/ui/terminal/pspp.exe: 
cannot execute binary file: Fehler im Format der Programmdatei
make[2]: *** [Makefile:14217: doc/examples/autorecode.spv] Error 126
make[2]: Leaving directory '/home/pspp/pspp-master-20201117/pspp-1.5.2-gc04cd4'
make[1]: *** [Makefile:12303: all-recursive] Error 1
make[1]: Leaving directory '/home/pspp/pspp-master-20201117/pspp-1.5.2-gc04cd4'
make: *** [Makefile:6401: all] Error 2
Uncaught exception from user code:
system 'Mingw32-make'  failed: 512 at ./buildpspp4windows.pl line 568, 
 line 937.
main::ProcMake() called at ./buildpspp4windows.pl line 369
main::ProcGeneratePSPP("w32", "Debug") called at ./buildpspp4windows.pl 
line 124
program finished with exit code 2
elapsedTime=419.754343

===

While executing a simple „make“ 

https://github.com/fredowski/pspp-buildbot/blob/master/win/buildpspp4windows.pl#L568

Any ideas how this can be avoided? Aren’t this examples for the documentation, 
i.e. could that be part of the doc target?

http://caeis.etech.fh-augsburg.de:8010/#/builders/7/builds/95

Fritz 

Re: make install-html fails

[Friedrich Beckmann]

thanks for the fix. MacOS is building again:

https://travis-ci.org/github/fredowski/osxbundler

Fritz

> Am 16.11.2020 um 18:18 schrieb John Darrington :
> 
> I pushed a fix for this.
> 
> On Mon, Nov 16, 2020 at 02:39:05PM +0100, Friedrich Beckmann wrote:
> Hi,
> 
> i see the following when doing „make install-html“ on debian. Any ideas?
> 
> Fritz
> 
> 
> fritz@debian:~/pspp/build$ make install-html
> Making install-html in gl
> make[1]: Verzeichnis „/home/fritz/pspp/build/gl“ wird betreten
> make[2]: Verzeichnis „/home/fritz/pspp/build/gl“ wird betreten
> make[2]: Für das Ziel „install-html-am“ ist nichts zu tun.
> make[2]: Verzeichnis „/home/fritz/pspp/build/gl“ wird verlassen
> make[1]: Verzeichnis „/home/fritz/pspp/build/gl“ wird verlassen
> Making install-html in po
> make[1]: Verzeichnis „/home/fritz/pspp/build/po“ wird betreten
> make[1]: Verzeichnis „/home/fritz/pspp/build/po“ wird verlassen
> make[1]: Verzeichnis „/home/fritz/pspp/build“ wird betreten
> make[1]: *** Keine Regel vorhanden, um das Ziel „html-local“, 
>   benötigt von „install-html-local“, zu erstellen.  Schluss.
> make[1]: Verzeichnis „/home/fritz/pspp/build“ wird verlassen
> make: *** [Makefile:12303: install-html-recursive] Fehler 1
> fritz@debian:~/pspp/build$ 
> 
> 

Re: svg2png speedup

[Friedrich Beckmann]

> On my system this sped up "make -f Smake -j128 icons" from 1.8 to 1.6
> seconds.  On other systems I guess it will make a bigger difference.

What kind of system was this again…? :-)

latest is missing in nightly build directory

[Friedrich Beckmann]

Hi Ben,

the „latest" link is missing in your build directory. Therefore 

http://pspp.benpfaff.org/~blp/pspp-master/latest/source/index.html

does not work but that is required for the windows build.

http://caeis.etech.fh-augsburg.de:8010/#/builders/7/builds/93

Fritz

make install-html fails

[Friedrich Beckmann]

Hi,

i see the following when doing „make install-html“ on debian. Any ideas?

Fritz


fritz@debian:~/pspp/build$ make install-html
Making install-html in gl
make[1]: Verzeichnis „/home/fritz/pspp/build/gl“ wird betreten
make[2]: Verzeichnis „/home/fritz/pspp/build/gl“ wird betreten
make[2]: Für das Ziel „install-html-am“ ist nichts zu tun.
make[2]: Verzeichnis „/home/fritz/pspp/build/gl“ wird verlassen
make[1]: Verzeichnis „/home/fritz/pspp/build/gl“ wird verlassen
Making install-html in po
make[1]: Verzeichnis „/home/fritz/pspp/build/po“ wird betreten
make[1]: Verzeichnis „/home/fritz/pspp/build/po“ wird verlassen
make[1]: Verzeichnis „/home/fritz/pspp/build“ wird betreten
make[1]: *** Keine Regel vorhanden, um das Ziel „html-local“, 
  benötigt von „install-html-local“, zu erstellen.  Schluss.
make[1]: Verzeichnis „/home/fritz/pspp/build“ wird verlassen
make: *** [Makefile:12303: install-html-recursive] Fehler 1
fritz@debian:~/pspp/build$ 

Regression fails with test 1205 "tex glyphs" on opensuse - debian is working / Windows cross build also fails

[Friedrich Beckmann]

Hi,

the regression fails on the opensuse platform with test 1205 „Tex glyphs“ on 
opensuse.

http://caeis.etech.fh-augsburg.de:8010/#/console

The logfile is available here:

http://caeis.etech.fh-augsburg.de:8010/api/v2/logs/4390/raw

The windows cross build also fails with

+++
make[2]: Leaving directory 
'/home/pspp/pspp-master-20201101/pspp-1.5.2-g14db37/po'
make[2]: Entering directory '/home/pspp/pspp-master-20201101/pspp-1.5.2-g14db37'
make[2]: *** No rule to make target 'src/ui/terminal/pspp', needed by 
'doc/examples/autorecode.spv'.  Stop.
make[2]: Leaving directory '/home/pspp/pspp-master-20201101/pspp-1.5.2-g14db37'
make[1]: *** [Makefile:12277: all-recursive] Error 1
+++

Any ideas?

Fritz

Regression is failing on buildbot

[Friedrich Beckmann]

Hi Ben, hi John,

the regression is failing after the introduction of „Add a Tex driver“ in test 
1206 „tex simple example“.

http://caeis.etech.fh-augsburg.de:8010/#/console

Fritz

Re: Nightly build failure for user manual since 12th of October

[Friedrich Beckmann]

The windows build from Harry retrieves the pdf directly from Bens Nightly build:

http://caeis.etech.fh-augsburg.de:8010/#/builders/7

So Harry does not try to generate the pdf. But the cross build fails if the pdf 
is not available at Bens place.

> Am 15.10.2020 um 19:38 schrieb John Darrington :
> 
> 41;344;0cOn Thu, Oct 15, 2020 at 09:18:35AM -0700, Ben Pfaff wrote:
> Hmm. It's worse than that, since now it's impossible to build a source
> distribution from Git without first building the PSPP binary.
> 
> That much is true.
> 
> And I think that cross-compiling from Git is impossible now?
> Since you can't build the manual unless you first build and run the 
> binary.
> 
> Yes and no.  One must first build a native binary, at least for the
> terminal version of PSPP, because that is used to generate the
> example outputs.  Once you've done that, then you can do a cross build.
> 
> However, it's going to get worse :/   because I have plans to auto generate
> screenshots for the manual.  These will depend upon a nativly built
> and installed PSPPIRE.  So when that happens, then yes, almost everything
> will have to be built, before the manual can be built.
> 
> I think I need to discard the idea of having separate "source" and 
> "binary"
> nightly builds.
> 
> In my opinion, it would still be useful to have a regular build-bot
> to check that cross-builds can be performed from the tarball, even if
> that tarball can only be generated after building a native binary.
> 
> 
> J'

Nightly build failure for user manual since 12th of October

[Friedrich Beckmann]

The nightly build fails since:

https://pspp.benpfaff.org/~blp/pspp-master/20201012050501/source/

due to build failure of the manual.

Re: Not Implemented Commands

[Friedrich Beckmann]

Except if I look for something. My assumption for the first hours is that I am 
too stupid to find it… 

> Am 12.10.2020 um 19:58 schrieb John Darrington :
> 
> In my opionion, we should delete Chapter 20 of the user manual  "Not 
> Implemented".
> 
> I think the manual is large enough explaining what PSPP can do, and there is
> little purpose listing things it can't.
> 
> Objections?
> 
> J'
> 

Re: Build failure with commit 8ce80361a582f

[Friedrich Beckmann]

I fixed it with commit

https://git.savannah.gnu.org/cgit/pspp.git/commit/?id=e50dabd2879fa0134bd726412c4229bdaf441c1a

I indeed installed spread-sheet-widget in some install directory. Now the build 
honours the
information from pkgconfig. 

> I'm guessing that you have libspread-sheet-widget installed somewhere unusual.
> 
> Can you try adding $(SPREAD_SHEET_WIDGET_CFLAGS) to
> 
> src_ui_gui_libwidgets_essential_la_CFLAGS in the file
> 
> src/ui/gui/automake.mk

Build failure with commit 8ce80361a582f

[Friedrich Beckmann]

Hi John,

the build fails on the buildbot:

http://caeis.etech.fh-augsburg.de:8010/#/console

with this commit:

https://git.savannah.gnu.org/cgit/pspp.git/commit/?id=8ce80361a582f88b22449b2d277873f7770155a0

See: http://caeis.etech.fh-augsburg.de:8010/#/builders/4/builds/90

Fritz

Re: buildpspp4windows

[Friedrich Beckmann]

Hi Harry,

> git clone git://git.code.sf.net/p/pspp4windows/build pspp4windows-build
> 
> Is  that workable for you?  If so, I think I will push the other stuff to. 
> Have to check this because on my nas there are also files with passwords. 

Yes, that works. The repository only contains „buildpspp4windows.pl“. I had 
recovered and guessed some more files which are in

https://github.com/fredowski/pspp-buildbot/tree/master/win

The files that I created in that „win“ directory and which I have not taken 
from your setup are 

„buildssw-win.sh“ and
"get-results-win.sh“ 

where „get-results-win.sh“ is pretty buildbot specific. It would be nice if as 
much as possible stuff, e.g. the „used-in-build“ files would be together in one 
git repository. I have three more files which are win specific:

https://github.com/fredowski/pspp-buildbot/blob/master/prepare_win.sh

which installs all the build environment except spread-sheet-widget ,

https://github.com/fredowski/pspp-buildbot/blob/master/create_win_vm.sh

which creates the lxc container but more or less only calls „prepare_win.sh“ and

https://github.com/fredowski/pspp-buildbot/blob/master/run_win.sh

which calls „build-ssw-win.sh“ and „buildpspp4windows.pl“ and does the actual 
build.

Maybe we can move the „prepare_win.sh“ script also to your repo. I think it is 
not
buildbot related - it should also work on a plain opensuse 15.2 installation.

Do I remember correctly that you use a virtualbox vm in your build setup? Maybe 
you can
have a look at lxc containers which I found very nice. Once the setup for user 
lxc containers
is done on the host machine, it is really easy to create the vm from a script 
(=> create_win_vm.sh).

https://github.com/fredowski/pspp-buildbot/blob/master/INSTALL.md
https://github.com/fredowski/pspp-buildbot/blob/master/README.md

> BTW. I saw your question about your latest patch. May procedures have the 
> possibility to uses patches. For this you need a directory
>"$BaseDir/win/pspp-patches"  Every .patch file in this directory will be 
> patched to the downloaded source.  So be careful to remove or rename them 
> after your test. 

Mmh. I do not remember any question about patches. I saw your patch support in 
„buildpspp4windows.pl“ but I have not used it as I did not find any patches.

Fritz

Re: Building --without-gui

[Friedrich Beckmann]

Hi Ben,

I have made the crossbuild with lxc containers. That works quite
nicely. The complete build environment is inside lxc:

https://github.com/fredowski/pspp-buildbot

Here is how to create the build environment in an lxc container

https://github.com/fredowski/pspp-buildbot/blob/master/create_win_vm.sh

The overall buildbot control including Harrys machine:

https://github.com/fredowski/pspp-buildbot/blob/master/master/master.cfg#L136

Harrys build script of the bundle:

https://github.com/fredowski/pspp-buildbot/blob/master/win/buildpspp4windows.pl

About installing user based lxc containers:

https://github.com/fredowski/pspp-buildbot/blob/master/INSTALL.md

Fritz

> Am 11.09.2020 um 07:32 schrieb Ben Pfaff :
> 
> I should be able to do that.
> 
> I'm currently working to get a nightly Windows build with binaries. I
> found using
> Docker a little frustrating, but now I think I've managed to get a cross-build
> working under Debian without Docker. Most of the tests pass, too.
> 
> Wine is kind of slow. I think it's because there's a single-threaded
> "wineserver"
> process bottlenecking my setup so that I only get 7 or 8 way parallelism, on
> average, out of the 128 physical processor threads.
> 
> At the same time, I'm still working on .spo files. I've found a new source of
> information, which is good because I was feeling somewhat stuck.
> 
> On Sun, Sep 6, 2020 at 2:59 AM John Darrington
>  wrote:
>> 
>> Now that you've got a lightning fast machine, would it be
>> possible to have your buildbot check some combination of
>> ./configure options   For example --without-gui  --without-cairo 
>> --without-perl-module etc.
>> 
>> I wouldn't necessarily expect "make dist" or "make distcheck" to work
>> when these options are applied, but "make check" should do.
>> 
>> J'
> 

Re: pspp 1.4.1 on debian - looks good but host test time limit fails on hurd-i386

[Friedrich Beckmann]

Ben - you write special code for Hurd. Amazing.

> Am 07.09.2020 um 23:20 schrieb Ben Pfaff :
>
> The bug is a mystery. I think the code should work. However, it
> doesn't, so I put in an alternate implementation for Hurd.
>
> On Mon, Sep 7, 2020 at 11:41 AM Ben Pfaff  wrote:
>>
>> Oh, it turned out that it just took a while for my SSH key change
>> to propagate. I do have access to that now. I'll see what's going on.
>>
>> On Sun, Sep 6, 2020 at 3:08 PM Friedrich Beckmann
>>  wrote:
>>>
>>>
>>>> Am 06.09.2020 um 22:22 schrieb Ben Pfaff :
>>>>
>>>> Do you know where I can find a hurd-i386 machine to test on?
>>>> The reason for this failure is not evident to me.
>>>>
>>>> It doesn't look like the GCC Compile Farm has a hurd machine,
>>>> and I can't figure out how to log into the one porterbox that
>>>> Debian has (it's not managed by the Debian admins like most
>>>> are).
>>>
>>> As I am not DD I had to ask for access always. The hurd I found is
>>> probably the one you also found:
>>>
>>> https://db.debian.org/machines.cgi?host=exodar
>>>
>>>
>>>

pspp: Small typo in polish name which breaks sed during build

[Friedrich Beckmann]

Cześć polish translation team,

thank you very much for all your translations! Could you maybe fix the following
small typo in the polish translation of the pspp project:

https://git.savannah.gnu.org/cgit/pspp.git/commit/?id=57a6e611f43bfb0ef492b28200de5071a79ce21e

which breaks the build of pspp on MacOS? If I fix this in the source code data 
it will always
be overwritten by the file from the translation project. The pspp project:

https://translationproject.org/domain/pspp.html

Thanks for your help!

Friedrich

Re: pspp 1.4.1 on debian - looks good but host test time limit fails on hurd-i386

[Friedrich Beckmann]

> Am 06.09.2020 um 22:22 schrieb Ben Pfaff :
>
> Do you know where I can find a hurd-i386 machine to test on?
> The reason for this failure is not evident to me.
>
> It doesn't look like the GCC Compile Farm has a hurd machine,
> and I can't figure out how to log into the one porterbox that
> Debian has (it's not managed by the Debian admins like most
> are).

As I am not DD I had to ask for access always. The hurd I found is
probably the one you also found:

https://db.debian.org/machines.cgi?host=exodar

Re: Release 1.4.1 is from master branch

[Friedrich Beckmann]

Ah - o.k. I also noticed that one might get lost a little bit not
to forget a commit.

> Am 06.09.2020 um 21:11 schrieb Ben Pfaff :
>
> Yes. I created branch-1.4 because we were talking about making the
> 1.4.1 release from a subset of commits on master. It is confusing to
> try to do this without a branch. Later, John suggested that we should
> actually put everything on master into the release, so instead I
> dropped the version number on master back to 1.4.1 and released
> from there. I admit that this is a very unusual thing to do, but it also
> seemed to me like a better choice than having a separate branch
> with all the same commits as the master branch. I hope that it does
> not cause any serious problems.
>
> Since then, I've deleted branch-1.4. I think that it was only going to
> be confusing to have it.
>
> On Sat, Sep 5, 2020 at 11:57 PM Friedrich Beckmann
>  wrote:
>>
>> Hi Ben,
>>
>> as far as I see it the 1.4.1 release is from master branch?
>>
>> Fritz

pspp 1.4.1 on debian - looks good but host test time limit fails on hurd-i386

[Friedrich Beckmann]

pspp 1.4.1 is on debian and looks good.
https://buildd.debian.org/status/package.php?p=pspp
There is one test failing on hurd-i386:
HOST - portable tests

769: HOST - one command  ok
770: HOST - two commands ok
771: HOST - time limit   FAILED (host.at:48)

Re: [Pspp-commits] [SCM] GNU PSPP branch, master, updated. v1.4.0-87-g31d82a2

[Friedrich Beckmann]

> Am 06.09.2020 um 09:22 schrieb John Darrington :
> 
> I'm also concerned about how ubiquitous "appstream" is.  Will people using 
> other distributions
> (Slackware, FreeBSD ...) be able to easily install it?

With the recent fix in the makefile the pspp.pot file is rebuild now also when 
building from the
distribution package - you see the last bug report when building without gui. 
Before that the
pspp.pot file was never rebuild when building from a distribution. We have

xgettext 0.19.8.1: Without patches crashes with the —-its option
xgettext 0.20: Works without the appstream package - no metainfo.its file 
required - builtin
appstream: Available on opensuse,ubuntu and debian - makes it work with 
distribution version 0.19.8.1
 
So either a distribution has gettext 0.20 or 0.19 (some patches?) with the 
metainfo file. Otherwise the
org.fsf.pspp.metainfo.xml file will not be translated.

I pushed a change that this is not a build requirement but just a warning 
during configure.

Re: [Pspp-commits] [SCM] GNU PSPP branch, master, updated. v1.4.0-87-g31d82a2

[Friedrich Beckmann]

Mmh. Do you find the metainfo.its file in /usr/share/gettext/its/metainfo.its 
after installing
the appstream package? As mentioned on opensuse this required to install 
AppStream-devel while
on debian and ubuntu this is the package appstream. 

> Am 06.09.2020 um 09:22 schrieb John Darrington :
> 
> On Sun, Sep 06, 2020 at 08:48:52AM +0200, Friedrich Beckmann wrote:
> I tried this on opensuse 15.2 which has the unpatched 0.19.8.1 version. 
> Which version
> do you use?
> 
> I tried it with 0.19.8.1 downloaded from ftp.gnu.org
> 
> I found that even after installing running "apt get appstream", this version 
> of xgettext
> couldn't find it.
> 
> I'm also concerned about how ubiquitous "appstream" is.  Will people using 
> other distributions
> (Slackware, FreeBSD ...) be able to easily install it?
> 
> J'
> 

Release 1.4.1 is from master branch

[Friedrich Beckmann]

Hi Ben,

as far as I see it the 1.4.1 release is from master branch?

Fritz

Re: [Pspp-commits] [SCM] GNU PSPP branch, master, updated. v1.4.0-87-g31d82a2

[Friedrich Beckmann]

I tried this on opensuse 15.2 which has the unpatched 0.19.8.1 version. Which 
version
do you use?

> Am 06.09.2020 um 08:21 schrieb John Darrington :
> 
> On Sat, Sep 05, 2020 at 05:32:46PM -0400, Friedrich Beckmann wrote:
> commit 31d82a2be4506259512ee4ed075eadb76750139f
> Author: Friedrich Beckmann 
> Date:   Sat Sep 5 17:24:17 2020 +0200
> 
> added appstream as a build requirement
> 
> appstream provides the metainfo.its file which is required for
> xgettext to extract the translation strings of the
> src/ui/gui/org.fsf.pspp.metainfo.xml.in file
> 
> The metainfo.its file is located in /usr/share/gettext/its on
> debian and on opensuse. It is provided by the packages
> 
> debian: appstream
> opensuse:   AppStream-devel
> 
> The test in  configure.ac is ineffective at detecting metainfo.its, if the 
> installed
> xgettext is the unpatched version of 0.19.8.1   -   it always reports that 
> appstream 0.12 is
> not installed.
> 
> Thus the purpose is defeated.

Re: TP: pspp -- msgfmt errors

[Friedrich Beckmann]

I figured out is that the relevant its file is already available also on 
opensuse 15.2. The file
is located at 

/usr/share/gettext/its/metainfo.its

The file is not provided by gettext but by the package „AppStream-devel" on 
opensuse. On debian it is provided by the appstream package. When this file is 
available no self designed its file is necessary, i.e. we can remove our own 
metainfo.its file. Then the „—-its“ option is not required and xgettext does 
not crash. I tested this on opensuse 15.2 and on debian. I pushed a fix for 
this including a configure time check for the correct behaviour of xgettext. 

Fritz

> Am 05.09.2020 um 12:34 schrieb John Darrington :
> 
> Ugg.  What a horrible situation.
> 
> We can't rely on distributions applying this patch.  And very few
> distributions ship gettext 0.20  - I don't know why not - it has
> been released since more than 12 months.
> 
> So I have pushed a kludge to work around this bug.
> 
> J'
> 
> On Sat, Sep 05, 2020 at 12:08:59PM +0300, opensuse.lietuviu.kalba wrote:
> 2020-09-05 12:06, John Darrington ra:
>> That is strange.  I am also using that version and I don't get this error.
>> 
>> Can you try to find out the conditions which provoke it?
> 
> 
> Friedrich Beckmann already wrote about this:
> 
> 2020-08-26 17:37
> 
> 2020-09-03 00:16
> 
> 
> A summary described here:
> 
> https://bugzilla.opensuse.org/show_bug.cgi?id=1176142

Re: Compiling PSPP from GIT

[Friedrich Beckmann]

Hi Mindaugas,

very nice! Maybe it is a bit confusing but you can try it yourself. When you 
open the gui
and open the help page, then your favourite browser should open and you see
the pspp web page. Now the point: If you do not install the html, then pspp will
fetch the help from the internet. Therefore you should always install the html. 
It is
not like the usual documentation that only few people read from the share 
location.
Or is the html now installed as default when you install pspp?

Friedrich

> Am 05.09.2020 um 20:57 schrieb opensuse.lietuviu.kalba 
> :
> 
> 2020-09-03 23:22, Friedrich Beckmann rašė:
>> You can create the html pages with „make html“ and then you have to install 
>> them. On debian that is the directory /usr/share/doc/pspp.
>> 
>> Friedrich
> 
> 
> Thanks for hint! Now PSPP 1.5.0 RPM has -doc and -devel-doc subpackages with 
> documentation.
> 
> --
> 
> Mindaugas
>