Bug#820743: [Pkg-postgresql-public] Bug#820743: [hurd-i386] postgresql-common / postgresql-9.5 fails to install during pspp build
Just for clarification ... As correctly mentioned, the PostgreSQL server cannot run on the Hurd. However this does not mean that the PSPP postgres client option cannot or should not be enabled on the Hurd. It simply means that the regression test for that option cannot run. My recollection was that in Debian the option was enabled, but the test specifically disabled. J' On Tue, Apr 12, 2016 at 06:16:40PM +0200, Friedrich Beckmann wrote: Hi Christoph, thanks for the info. We had disabled the optional postgresql on hurd-i386 in the previous pspp release. Is it maybe an idea to include this test case in the regression in postgresql? That would stop the release of the non-functional postgresql on hurd-i386, no? Friedrich > Am 12.04.2016 um 17:39 schrieb Christoph Berg: > > Re: Friedrich Beckmann 2016-04-12 <3ad966ac-2984-4449-94ba-addfe00d9...@gmx.de> >> Package: postgresql-9.5 >> Version: 9.5.2-1 >> >> During test installation on buildd for pspp, the pspp build fails on hurd-i386 during the setup >> of the postgresql. When I disable postgresql, then pspp builds and works. >> >> This is specific to the hurd-i386 architecture. The pspp package builds on other architectures. >> >> Friedrich >> >> The full log: https://buildd.debian.org/status/fetch.php?pkg=pspp=hurd-i386=0.10.1-2=1460387447 > > Hi Friedrich, > > the problem is in the hurd kernel that doesn't implement semaphores. > The interesting initdb error is this: > > creating template1 database in /?PKGBUILDDIR?/build/src/test/regress/./tmp_check/data/base/1 ... FATAL: could not create semaphores: Function not implemented > DETAIL: Failed system call was semget(1, 17, 03600). > > We have the weird situation where the server compiles successfully > including semget(), but isn't able to get executed because the > the kernel doesn't implement the feature. > > I've talked to the hurd people, and Richard Braun was confirming that > inter-process semaphores are not implemented yet. > > What we can do from the PostgreSQL side is to replace the current sysv > semaphores (semget) by POSIX semaphores (sem_init) which don't work > either, but have a much greater chance of getting implemented in the > future. So some day, it will just work, but until then, PostgreSQL > will unfortunately not really be available on that platform. > > Christoph ___ pspp-dev mailing list pspp-...@gnu.org https://lists.gnu.org/mailman/listinfo/pspp-dev -- Avoid eavesdropping. Send strong encryted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. signature.asc Description: Digital signature
Bug#820743: [Pkg-postgresql-public] Bug#820743: [hurd-i386] postgresql-common / postgresql-9.5 fails to install during pspp build
Hi Christoph, thanks for the info. We had disabled the optional postgresql on hurd-i386 in the previous pspp release. Is it maybe an idea to include this test case in the regression in postgresql? That would stop the release of the non-functional postgresql on hurd-i386, no? Friedrich > Am 12.04.2016 um 17:39 schrieb Christoph Berg: > > Re: Friedrich Beckmann 2016-04-12 > <3ad966ac-2984-4449-94ba-addfe00d9...@gmx.de> >> Package: postgresql-9.5 >> Version: 9.5.2-1 >> >> During test installation on buildd for pspp, the pspp build fails on >> hurd-i386 during the setup >> of the postgresql. When I disable postgresql, then pspp builds and works. >> >> This is specific to the hurd-i386 architecture. The pspp package builds on >> other architectures. >> >> Friedrich >> >> The full log: >> https://buildd.debian.org/status/fetch.php?pkg=pspp=hurd-i386=0.10.1-2=1460387447 > > Hi Friedrich, > > the problem is in the hurd kernel that doesn't implement semaphores. > The interesting initdb error is this: > > creating template1 database in > /«PKGBUILDDIR»/build/src/test/regress/./tmp_check/data/base/1 ... FATAL: > could not create semaphores: Function not implemented > DETAIL: Failed system call was semget(1, 17, 03600). > > We have the weird situation where the server compiles successfully > including semget(), but isn't able to get executed because the > the kernel doesn't implement the feature. > > I've talked to the hurd people, and Richard Braun was confirming that > inter-process semaphores are not implemented yet. > > What we can do from the PostgreSQL side is to replace the current sysv > semaphores (semget) by POSIX semaphores (sem_init) which don't work > either, but have a much greater chance of getting implemented in the > future. So some day, it will just work, but until then, PostgreSQL > will unfortunately not really be available on that platform. > > Christoph
Bug#820743: [Pkg-postgresql-public] Bug#820743: [hurd-i386] postgresql-common / postgresql-9.5 fails to install during pspp build
Re: Friedrich Beckmann 2016-04-12 <3ad966ac-2984-4449-94ba-addfe00d9...@gmx.de> > Package: postgresql-9.5 > Version: 9.5.2-1 > > During test installation on buildd for pspp, the pspp build fails on > hurd-i386 during the setup > of the postgresql. When I disable postgresql, then pspp builds and works. > > This is specific to the hurd-i386 architecture. The pspp package builds on > other architectures. > > Friedrich > > The full log: > https://buildd.debian.org/status/fetch.php?pkg=pspp=hurd-i386=0.10.1-2=1460387447 Hi Friedrich, the problem is in the hurd kernel that doesn't implement semaphores. The interesting initdb error is this: creating template1 database in /«PKGBUILDDIR»/build/src/test/regress/./tmp_check/data/base/1 ... FATAL: could not create semaphores: Function not implemented DETAIL: Failed system call was semget(1, 17, 03600). We have the weird situation where the server compiles successfully including semget(), but isn't able to get executed because the the kernel doesn't implement the feature. I've talked to the hurd people, and Richard Braun was confirming that inter-process semaphores are not implemented yet. What we can do from the PostgreSQL side is to replace the current sysv semaphores (semget) by POSIX semaphores (sem_init) which don't work either, but have a much greater chance of getting implemented in the future. So some day, it will just work, but until then, PostgreSQL will unfortunately not really be available on that platform. Christoph