From jajcus at jajcus.net  Fri Feb  1 09:01:50 2019
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Fri, 1 Feb 2019 09:01:50 +0100
Subject: python3 only packages
In-Reply-To: <bfd81b87-03f3-d1fc-682c-3e1444df6aed@delfi.ee>
References: <bfd81b87-03f3-d1fc-682c-3e1444df6aed@delfi.ee>
Message-ID: <530b847b-4260-822b-fb4d-b842efab1c53@jajcus.net>

On 31/01/2019 21.34, Elan Ruusam?e wrote:
> what should be .spec named?
> 
> 
> python3-foo.spec?
> 
> python-foo.spec?

I think using python-foo.spec for the source and build only python3-foo
package from that is the most consistent way.

E.g. what if python4 appears? What if a package loses python2 support,
rename the spec?  Otherwise what source package name is depends not on
the package contents, but on its history, which doesn't feel right.

Jacek


From glen at pld-linux.org  Fri Feb  1 15:41:55 2019
From: glen at pld-linux.org (glen)
Date: Fri, 1 Feb 2019 16:41:55 +0200
Subject: openssl again makes php5.3 crash
In-Reply-To: <e98937f4-0efb-ab23-998c-dd39920497e7@maven.pl>
References: <5eed7172-31e9-5829-a9d4-68a5e2856170@delfi.ee>
 <6592143e-63cb-4997-55e9-a64a3ee8b367@pld-linux.org>
 <7638da2f-75fa-4bd1-b7eb-fbcbc40db600@maven.pl>
 <CAHiWvWFhDBBwdfut26HtSEKeFFWGf5m7dbMSjOAXEwdj1Tvk2g@mail.gmail.com>
 <e98937f4-0efb-ab23-998c-dd39920497e7@maven.pl>
Message-ID: <53f6ae6e-f14f-abdc-8c87-54fe32cc34fe@pld-linux.org>

(somewhy arekm wrote privately to me only).

anyway, the rel 44 (from th-test) still fails:

[root at 2e971bacdb48 app]# echo '{}'> composer.json
[root at 2e971bacdb48 app]# composer install; echo $?
Loading composer repositories with package information
139
[root at 2e971bacdb48 app]# rpm -q php53-common
php53-common-5.3.29-44.x86_64
[root at 2e971bacdb48 app]#

On 1/23/19 11:54 PM, Arkadiusz Mi?kiewicz wrote:
> On 23/01/2019 22:00, Elan Ruusam?e wrote:
>> yes. it worked, with?openssl 1.1 crashes
> php 5.4 doesn't crash.
>
> backported ext/openssl to 5.3 crashes.
>
> Fun.
>
>> On Wed, 23 Jan 2019 at 21:28, Arkadiusz Mi?kiewicz <arekm at maven.pl
>> <mailto:arekm at maven.pl>> wrote:
>>
>>      On 21/12/2018 12:51, glen wrote:
>>      > can you please look?
>>
>>      Did this work with older openssl?
>>
>>      Because this bug is somehow related to
>>      https://bugs.php.net/bug.php?id=61930
>>
>>
>>      Simplified reproducer:
>>
>>      > <?php
>>      >
>>      >
>>      > $url = 'https://repo.packagist.org/packages.json';
>>      >
>>      > function getCertificateFingerprint($certificate)
>>      > {
>>      >? ?$publickey = openssl_get_publickey($certificate);
>>      >? ?$pubkeydetails = openssl_pkey_get_details($publickey);
>>      > }
>>      >
>>      > $options = array();
>>      >
>>      > $defaultParams = array (
>>      >? ?'options' =>
>>      >? ?array (
>>      >? ? ?'ssl' =>
>>      >? ? ?array (
>>      >? ? ? ?'capture_peer_cert' => true,
>>      >? ? ? ?'verify_peer' => false,
>>      >? ? ?),
>>      >? ?),
>>      > );
>>      >
>>      > $context = stream_context_create($options, $defaultParams);
>>      >
>>      > if (false === $handle = @fopen($url, 'rb', false, $context)) {
>>      >? ?return;
>>      > }
>>      >
>>      > fclose($handle);
>>      > $handle = null;
>>      >
>>      > $params = stream_context_get_params($context);
>>      >
>>      >
>>      getCertificateFingerprint($params['options']['ssl']['peer_certificate']);
>>
>>
>>      >
>>      >
>>      > On 12/11/18 12:53 PM, Elan Ruusam?e wrote:
>>      >>
>>      >> $ docker run --privileged --rm -it
>>      registry.gitlab.com/pld-linux/pld
>>      <http://registry.gitlab.com/pld-linux/pld> sh
>>      >>
>>      >> [@42300ff78c63 /]# poldek -u --noask composer gdb --ignore=*php4*
>>      >> --ignore=*php52*
>>      >>
>>      >> [@42300ff78c63 /]# poldek -n th-debuginfo -u php53-debuginfo
>>      >> openssl-debuginfo
>>      >>
>>      >> [@42300ff78c63 /]# cd /tmp
>>      >>
>>      >> [@42300ff78c63 /tmp]# echo '{}' > composer.json
>>      >>
>>      >>
>>      >> [@42300ff78c63 /tmp]# composer install
>>      >> Do not run Composer as root/super user! See
>>      >> https://getcomposer.org/root for details
>>      >> Loading composer repositories with package information
>>      >> Segmentation fault
>>      >>
>>      >> [@42300ff78c63 /tmp]# composer config -g -- disable-tls true
>>      >> Do not run Composer as root/super user! See
>>      >> https://getcomposer.org/root for details
>>      >> [@42300ff78c63 /tmp]# composer install
>>      >> You are running Composer with SSL/TLS protection disabled.
>>      >> Do not run Composer as root/super user! See
>>      >> https://getcomposer.org/root for details
>>      >> Loading composer repositories with package information
>>      >> Updating dependencies (including require-dev)
>>      >> Nothing to install or update
>>      >> Generating autoload files
>>      >> [@42300ff78c63 /tmp]#
>>      >>
>>      >> [@236200a329d5 r]# rpm -q php53-common openssl
>>      >> php53-common-5.3.29-43.x86_64
>>      >> openssl-1.1.1a-1.x86_64
>>      >> [@236200a329d5 r]#
>>      >>
>>      >>
>>      >>
>>      >>
>>      >> [@42300ff78c63 /tmp]# composer config -g -- disable-tls false
>>      >> You are running Composer with SSL/TLS protection disabled.
>>      >> Do not run Composer as root/super user! See
>>      >> https://getcomposer.org/root for details
>>      >> [@42300ff78c63 /tmp]# gdb --args php /usr/bin/composer install
>>      >> GNU gdb (GDB) 8.2-2 (PLD Linux)
>>      >> Copyright (C) 2018 Free Software Foundation, Inc.
>>      >> License GPLv3+: GNU GPL version 3 or later
>>      >> <http://gnu.org/licenses/gpl.html>
>>      >> This is free software: you are free to change and redistribute it.
>>      >> There is NO WARRANTY, to the extent permitted by law.
>>      >> Type "show copying" and "show warranty" for details.
>>      >> This GDB was configured as "x86_64-pld-linux".
>>      >> Type "show configuration" for configuration details.
>>      >> For bug reporting instructions, please see:
>>      >> <http://www.gnu.org/software/gdb/bugs/>.
>>      >> Find the GDB manual and other documentation resources online at:
>>      >> ??? <http://www.gnu.org/software/gdb/documentation/>.
>>      >>
>>      >> For help, type "help".
>>      >> Type "apropos word" to search for commands related to "word"...
>>      >> Reading symbols from php...Reading symbols from
>>      >> /usr/lib/debug/usr/bin/php53.debug...done.
>>      >> done.
>>      >> (gdb) r
>>      >> Starting program: /usr/bin/php /usr/bin/composer install
>>      >> [Thread debugging using libthread_db enabled]
>>      >> Using host libthread_db library "/lib64/libthread_db.so.1".
>>      >> [Detaching after fork from child process 333]
>>      >> [Detaching after fork from child process 334]
>>      >> [Detaching after fork from child process 335]
>>      >> [Detaching after fork from child process 336]
>>      >> [Detaching after fork from child process 337]
>>      >> [Detaching after fork from child process 338]
>>      >> [Detaching after fork from child process 339]
>>      >> Do not run Composer as root/super user! See
>>      >> https://getcomposer.org/root for details
>>      >> [Detaching after fork from child process 340]
>>      >> Loading composer repositories with package information
>>      >>
>>      >> Program received signal SIGSEGV, Segmentation fault.
>>      >> 0x00007ffff7e66731 in _zval_ptr_dtor (zval_ptr=0x7ffff6853f9000) at
>>      >> /usr/src/debug/php-5.3.29/Zend/zend_execute_API.c:434
>>      >> 434??? ??? zval *zv = *zval_ptr;
>>      >> (gdb) bt
>>      >> #0? 0x00007ffff7e66731 in _zval_ptr_dtor (zval_ptr=0x7ffff6853f9000)
>>      >> at /usr/src/debug/php-5.3.29/Zend/zend_execute_API.c:434
>>      >> #1? 0x00007ffff7ec0f85 in zend_leave_helper_SPEC
>>      >> (execute_data=execute_data at entry=0x7ffff6853eb0) at
>>      >> /usr/src/debug/php-5.3.29/Zend/zend_vm_execute.h:160
>>      >> #2? 0x00007ffff7ec148a in ZEND_RETURN_SPEC_VAR_HANDLER
>>      >> (execute_data=0x7ffff6853eb0) at
>>      >> /usr/src/debug/php-5.3.29/Zend/zend_vm_execute.h:8255
>>      >> #3? 0x00007ffff7e99e61 in execute (op_array=0x131dec8) at
>>      >> /usr/src/debug/php-5.3.29/Zend/zend_vm_execute.h:107
>>      >> #4? 0x00007ffff7e76597 in zend_execute_scripts (type=type at entry=8,
>>      >> retval=retval at entry=0x0, file_count=file_count at entry=3) at
>>      >> /usr/src/debug/php-5.3.29/Zend/zend.c:1259
>>      >> #5? 0x00007ffff7e23d38 in php_execute_script
>>      >> (primary_file=primary_file at entry=0x7fffffffd090) at
>>      >> /usr/src/debug/php-5.3.29/main/main.c:2316
>>      >> #6? 0x0000000000404939 in main (argc=3, argv=0x7fffffffe458) at
>>      >> /usr/src/debug/php-5.3.29/sapi/cli/php_cli.c:1189
>>      >> (gdb)

-- 
glen



From glen at pld-linux.org  Tue Feb  5 12:22:32 2019
From: glen at pld-linux.org (glen)
Date: Tue, 5 Feb 2019 13:22:32 +0200
Subject: Fwd: Re: [packages/dehydrated] - run always via sudo as
 root:dehydrated to allow dehydrated group to read certificates and keys,
In-Reply-To: <f6a09d0a-72ae-df9e-c9ae-1f14b73ee7ac@delfi.ee>
References: <f6a09d0a-72ae-df9e-c9ae-1f14b73ee7ac@delfi.ee>
Message-ID: <fe162853-3abf-0902-9879-ee9b0154dd61@pld-linux.org>

cc: list

-------- Forwarded Message --------

Subject: 	Re: [packages/dehydrated] - run always via sudo as 
root:dehydrated to allow dehydrated group to read certificates and keys,
Date: 	Fri, 21 Dec 2018 22:35:54 +0200
From: 	Elan Ruusam?e <glen@>
To: 	hawk at pld-linux.org



provides user and group missing

https://github.com/pld-linux/dehydrated/commit/e91f3230f38cc6642d9d0853ab0990f8ecec8d9c


From glen at pld-linux.org  Tue Feb  5 17:43:01 2019
From: glen at pld-linux.org (glen)
Date: Tue, 5 Feb 2019 18:43:01 +0200
Subject: openssl again makes php5.3 crash
In-Reply-To: <53f6ae6e-f14f-abdc-8c87-54fe32cc34fe@pld-linux.org>
References: <5eed7172-31e9-5829-a9d4-68a5e2856170@delfi.ee>
 <6592143e-63cb-4997-55e9-a64a3ee8b367@pld-linux.org>
 <7638da2f-75fa-4bd1-b7eb-fbcbc40db600@maven.pl>
 <CAHiWvWFhDBBwdfut26HtSEKeFFWGf5m7dbMSjOAXEwdj1Tvk2g@mail.gmail.com>
 <e98937f4-0efb-ab23-998c-dd39920497e7@maven.pl>
 <53f6ae6e-f14f-abdc-8c87-54fe32cc34fe@pld-linux.org>
Message-ID: <4b551fc9-9c0d-ee1d-8ac7-860aa0347723@pld-linux.org>

friendly ping!

On 2/1/19 4:41 PM, glen wrote:
> (somewhy arekm wrote privately to me only).
>
> anyway, the rel 44 (from th-test) still fails:
>
> [root at 2e971bacdb48 app]# echo '{}'> composer.json
> [root at 2e971bacdb48 app]# composer install; echo $?
> Loading composer repositories with package information
> 139
> [root at 2e971bacdb48 app]# rpm -q php53-common
> php53-common-5.3.29-44.x86_64
> [root at 2e971bacdb48 app]#
>
> On 1/23/19 11:54 PM, Arkadiusz Mi?kiewicz wrote:
>> On 23/01/2019 22:00, Elan Ruusam?e wrote:
>>> yes. it worked, with?openssl 1.1 crashes
>> php 5.4 doesn't crash.
>>
>> backported ext/openssl to 5.3 crashes.
>>
>> Fun.
>>
>>> On Wed, 23 Jan 2019 at 21:28, Arkadiusz Mi?kiewicz <arekm at maven.pl
>>> <mailto:arekm at maven.pl>> wrote:
>>>
>>> ???? On 21/12/2018 12:51, glen wrote:
>>> ???? > can you please look?
>>>
>>> ???? Did this work with older openssl?
>>>
>>> ???? Because this bug is somehow related to
>>> ???? https://bugs.php.net/bug.php?id=61930
>>>
>>>
>>> ???? Simplified reproducer:
>>>
>>> ???? > <?php
>>> ???? >
>>> ???? >
>>> ???? > $url = 'https://repo.packagist.org/packages.json';
>>> ???? >
>>> ???? > function getCertificateFingerprint($certificate)
>>> ???? > {
>>> ???? >? ?$publickey = openssl_get_publickey($certificate);
>>> ???? >? ?$pubkeydetails = openssl_pkey_get_details($publickey);
>>> ???? > }
>>> ???? >
>>> ???? > $options = array();
>>> ???? >
>>> ???? > $defaultParams = array (
>>> ???? >? ?'options' =>
>>> ???? >? ?array (
>>> ???? >? ? ?'ssl' =>
>>> ???? >? ? ?array (
>>> ???? >? ? ? ?'capture_peer_cert' => true,
>>> ???? >? ? ? ?'verify_peer' => false,
>>> ???? >? ? ?),
>>> ???? >? ?),
>>> ???? > );
>>> ???? >
>>> ???? > $context = stream_context_create($options, $defaultParams);
>>> ???? >
>>> ???? > if (false === $handle = @fopen($url, 'rb', false, $context)) {
>>> ???? >? ?return;
>>> ???? > }
>>> ???? >
>>> ???? > fclose($handle);
>>> ???? > $handle = null;
>>> ???? >
>>> ???? > $params = stream_context_get_params($context);
>>> ???? >
>>> ???? >
>>> getCertificateFingerprint($params['options']['ssl']['peer_certificate']);
>>>
>>>
>>> ???? >
>>> ???? >
>>> ???? > On 12/11/18 12:53 PM, Elan Ruusam?e wrote:
>>> ???? >>
>>> ???? >> $ docker run --privileged --rm -it
>>> ???? registry.gitlab.com/pld-linux/pld
>>> ???? <http://registry.gitlab.com/pld-linux/pld> sh
>>> ???? >>
>>> ???? >> [@42300ff78c63 /]# poldek -u --noask composer gdb 
>>> --ignore=*php4*
>>> ???? >> --ignore=*php52*
>>> ???? >>
>>> ???? >> [@42300ff78c63 /]# poldek -n th-debuginfo -u php53-debuginfo
>>> ???? >> openssl-debuginfo
>>> ???? >>
>>> ???? >> [@42300ff78c63 /]# cd /tmp
>>> ???? >>
>>> ???? >> [@42300ff78c63 /tmp]# echo '{}' > composer.json
>>> ???? >>
>>> ???? >>
>>> ???? >> [@42300ff78c63 /tmp]# composer install
>>> ???? >> Do not run Composer as root/super user! See
>>> ???? >> https://getcomposer.org/root for details
>>> ???? >> Loading composer repositories with package information
>>> ???? >> Segmentation fault
>>> ???? >>
>>> ???? >> [@42300ff78c63 /tmp]# composer config -g -- disable-tls true
>>> ???? >> Do not run Composer as root/super user! See
>>> ???? >> https://getcomposer.org/root for details
>>> ???? >> [@42300ff78c63 /tmp]# composer install
>>> ???? >> You are running Composer with SSL/TLS protection disabled.
>>> ???? >> Do not run Composer as root/super user! See
>>> ???? >> https://getcomposer.org/root for details
>>> ???? >> Loading composer repositories with package information
>>> ???? >> Updating dependencies (including require-dev)
>>> ???? >> Nothing to install or update
>>> ???? >> Generating autoload files
>>> ???? >> [@42300ff78c63 /tmp]#
>>> ???? >>
>>> ???? >> [@236200a329d5 r]# rpm -q php53-common openssl
>>> ???? >> php53-common-5.3.29-43.x86_64
>>> ???? >> openssl-1.1.1a-1.x86_64
>>> ???? >> [@236200a329d5 r]#
>>> ???? >>
>>> ???? >>
>>> ???? >>
>>> ???? >>
>>> ???? >> [@42300ff78c63 /tmp]# composer config -g -- disable-tls false
>>> ???? >> You are running Composer with SSL/TLS protection disabled.
>>> ???? >> Do not run Composer as root/super user! See
>>> ???? >> https://getcomposer.org/root for details
>>> ???? >> [@42300ff78c63 /tmp]# gdb --args php /usr/bin/composer install
>>> ???? >> GNU gdb (GDB) 8.2-2 (PLD Linux)
>>> ???? >> Copyright (C) 2018 Free Software Foundation, Inc.
>>> ???? >> License GPLv3+: GNU GPL version 3 or later
>>> ???? >> <http://gnu.org/licenses/gpl.html>
>>> ???? >> This is free software: you are free to change and 
>>> redistribute it.
>>> ???? >> There is NO WARRANTY, to the extent permitted by law.
>>> ???? >> Type "show copying" and "show warranty" for details.
>>> ???? >> This GDB was configured as "x86_64-pld-linux".
>>> ???? >> Type "show configuration" for configuration details.
>>> ???? >> For bug reporting instructions, please see:
>>> ???? >> <http://www.gnu.org/software/gdb/bugs/>.
>>> ???? >> Find the GDB manual and other documentation resources online 
>>> at:
>>> ???? >> <http://www.gnu.org/software/gdb/documentation/>.
>>> ???? >>
>>> ???? >> For help, type "help".
>>> ???? >> Type "apropos word" to search for commands related to "word"...
>>> ???? >> Reading symbols from php...Reading symbols from
>>> ???? >> /usr/lib/debug/usr/bin/php53.debug...done.
>>> ???? >> done.
>>> ???? >> (gdb) r
>>> ???? >> Starting program: /usr/bin/php /usr/bin/composer install
>>> ???? >> [Thread debugging using libthread_db enabled]
>>> ???? >> Using host libthread_db library "/lib64/libthread_db.so.1".
>>> ???? >> [Detaching after fork from child process 333]
>>> ???? >> [Detaching after fork from child process 334]
>>> ???? >> [Detaching after fork from child process 335]
>>> ???? >> [Detaching after fork from child process 336]
>>> ???? >> [Detaching after fork from child process 337]
>>> ???? >> [Detaching after fork from child process 338]
>>> ???? >> [Detaching after fork from child process 339]
>>> ???? >> Do not run Composer as root/super user! See
>>> ???? >> https://getcomposer.org/root for details
>>> ???? >> [Detaching after fork from child process 340]
>>> ???? >> Loading composer repositories with package information
>>> ???? >>
>>> ???? >> Program received signal SIGSEGV, Segmentation fault.
>>> ???? >> 0x00007ffff7e66731 in _zval_ptr_dtor 
>>> (zval_ptr=0x7ffff6853f9000) at
>>> ???? >> /usr/src/debug/php-5.3.29/Zend/zend_execute_API.c:434
>>> ???? >> 434??? ??? zval *zv = *zval_ptr;
>>> ???? >> (gdb) bt
>>> ???? >> #0? 0x00007ffff7e66731 in _zval_ptr_dtor 
>>> (zval_ptr=0x7ffff6853f9000)
>>> ???? >> at /usr/src/debug/php-5.3.29/Zend/zend_execute_API.c:434
>>> ???? >> #1? 0x00007ffff7ec0f85 in zend_leave_helper_SPEC
>>> ???? >> (execute_data=execute_data at entry=0x7ffff6853eb0) at
>>> ???? >> /usr/src/debug/php-5.3.29/Zend/zend_vm_execute.h:160
>>> ???? >> #2? 0x00007ffff7ec148a in ZEND_RETURN_SPEC_VAR_HANDLER
>>> ???? >> (execute_data=0x7ffff6853eb0) at
>>> ???? >> /usr/src/debug/php-5.3.29/Zend/zend_vm_execute.h:8255
>>> ???? >> #3? 0x00007ffff7e99e61 in execute (op_array=0x131dec8) at
>>> ???? >> /usr/src/debug/php-5.3.29/Zend/zend_vm_execute.h:107
>>> ???? >> #4? 0x00007ffff7e76597 in zend_execute_scripts 
>>> (type=type at entry=8,
>>> ???? >> retval=retval at entry=0x0, file_count=file_count at entry=3) at
>>> ???? >> /usr/src/debug/php-5.3.29/Zend/zend.c:1259
>>> ???? >> #5? 0x00007ffff7e23d38 in php_execute_script
>>> ???? >> (primary_file=primary_file at entry=0x7fffffffd090) at
>>> ???? >> /usr/src/debug/php-5.3.29/main/main.c:2316
>>> ???? >> #6? 0x0000000000404939 in main (argc=3, argv=0x7fffffffe458) at
>>> ???? >> /usr/src/debug/php-5.3.29/sapi/cli/php_cli.c:1189
>>> ???? >> (gdb)
>
-- 
glen



From arekm at maven.pl  Tue Feb  5 20:18:52 2019
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Tue, 5 Feb 2019 20:18:52 +0100
Subject: openssl again makes php5.3 crash
In-Reply-To: <4b551fc9-9c0d-ee1d-8ac7-860aa0347723@pld-linux.org>
References: <5eed7172-31e9-5829-a9d4-68a5e2856170@delfi.ee>
 <6592143e-63cb-4997-55e9-a64a3ee8b367@pld-linux.org>
 <7638da2f-75fa-4bd1-b7eb-fbcbc40db600@maven.pl>
 <CAHiWvWFhDBBwdfut26HtSEKeFFWGf5m7dbMSjOAXEwdj1Tvk2g@mail.gmail.com>
 <e98937f4-0efb-ab23-998c-dd39920497e7@maven.pl>
 <53f6ae6e-f14f-abdc-8c87-54fe32cc34fe@pld-linux.org>
 <4b551fc9-9c0d-ee1d-8ac7-860aa0347723@pld-linux.org>
Message-ID: <66f1a3d6-0c93-2be8-2301-472079d329c0@maven.pl>

On 05/02/2019 17:43, glen wrote:
> friendly ping!

I wasn't able to find the cause of this. Compared ext/openssl with 5.4
(which doesn't segfault) and can't find the problem.

Even backported ext/openssl from 5.4 to 5.3 still gets me segfaulting
php 5.3.

So I think the problem is solved outside ext/openssl.

Reproducer if anyone wants to look below.

I still plan to play with this more (because I'll be doing php 5.3
upgrades here in feb/march).

<?php


$url = 'https://repo.packagist.org/packages.json';

function getCertificateFingerprint($certificate)
{
  $publickey = openssl_get_publickey($certificate);
  $pubkeydetails = openssl_pkey_get_details($publickey);
}

$options = array();

$defaultParams = array (
  'options' =>
  array (
    'ssl' =>
    array (
      'capture_peer_cert' => true,
      'verify_peer' => false,
    ),
  ),
);

$context = stream_context_create($options, $defaultParams);

if (false === $handle = @fopen($url, 'rb', false, $context)) {
  return;
}

fclose($handle);
$handle = null;

$params = stream_context_get_params($context);

getCertificateFingerprint($params['options']['ssl']['peer_certificate']);


> 
> On 2/1/19 4:41 PM, glen wrote:
>> (somewhy arekm wrote privately to me only).
>>
>> anyway, the rel 44 (from th-test) still fails:
>>
>> [root at 2e971bacdb48 app]# echo '{}'> composer.json
>> [root at 2e971bacdb48 app]# composer install; echo $?
>> Loading composer repositories with package information
>> 139
>> [root at 2e971bacdb48 app]# rpm -q php53-common
>> php53-common-5.3.29-44.x86_64
>> [root at 2e971bacdb48 app]#
>>
>> On 1/23/19 11:54 PM, Arkadiusz Mi?kiewicz wrote:
>>> On 23/01/2019 22:00, Elan Ruusam?e wrote:
>>>> yes. it worked, with?openssl 1.1 crashes
>>> php 5.4 doesn't crash.
>>>
>>> backported ext/openssl to 5.3 crashes.
>>>
>>> Fun.
>>>
>>>> On Wed, 23 Jan 2019 at 21:28, Arkadiusz Mi?kiewicz <arekm at maven.pl
>>>> <mailto:arekm at maven.pl>> wrote:
>>>>
>>>> ???? On 21/12/2018 12:51, glen wrote:
>>>> ???? > can you please look?
>>>>
>>>> ???? Did this work with older openssl?
>>>>
>>>> ???? Because this bug is somehow related to
>>>> ???? https://bugs.php.net/bug.php?id=61930
>>>>
>>>>
>>>> ???? Simplified reproducer:
>>>>
>>>> ???? > <?php
>>>> ???? >
>>>> ???? >
>>>> ???? > $url = 'https://repo.packagist.org/packages.json';
>>>> ???? >
>>>> ???? > function getCertificateFingerprint($certificate)
>>>> ???? > {
>>>> ???? >? ?$publickey = openssl_get_publickey($certificate);
>>>> ???? >? ?$pubkeydetails = openssl_pkey_get_details($publickey);
>>>> ???? > }
>>>> ???? >
>>>> ???? > $options = array();
>>>> ???? >
>>>> ???? > $defaultParams = array (
>>>> ???? >? ?'options' =>
>>>> ???? >? ?array (
>>>> ???? >? ? ?'ssl' =>
>>>> ???? >? ? ?array (
>>>> ???? >? ? ? ?'capture_peer_cert' => true,
>>>> ???? >? ? ? ?'verify_peer' => false,
>>>> ???? >? ? ?),
>>>> ???? >? ?),
>>>> ???? > );
>>>> ???? >
>>>> ???? > $context = stream_context_create($options, $defaultParams);
>>>> ???? >
>>>> ???? > if (false === $handle = @fopen($url, 'rb', false, $context)) {
>>>> ???? >? ?return;
>>>> ???? > }
>>>> ???? >
>>>> ???? > fclose($handle);
>>>> ???? > $handle = null;
>>>> ???? >
>>>> ???? > $params = stream_context_get_params($context);
>>>> ???? >
>>>> ???? >
>>>> getCertificateFingerprint($params['options']['ssl']['peer_certificate']);
>>>>
>>>>
>>>>
>>>> ???? >
>>>> ???? >
>>>> ???? > On 12/11/18 12:53 PM, Elan Ruusam?e wrote:
>>>> ???? >>
>>>> ???? >> $ docker run --privileged --rm -it
>>>> ???? registry.gitlab.com/pld-linux/pld
>>>> ???? <http://registry.gitlab.com/pld-linux/pld> sh
>>>> ???? >>
>>>> ???? >> [@42300ff78c63 /]# poldek -u --noask composer gdb
>>>> --ignore=*php4*
>>>> ???? >> --ignore=*php52*
>>>> ???? >>
>>>> ???? >> [@42300ff78c63 /]# poldek -n th-debuginfo -u php53-debuginfo
>>>> ???? >> openssl-debuginfo
>>>> ???? >>
>>>> ???? >> [@42300ff78c63 /]# cd /tmp
>>>> ???? >>
>>>> ???? >> [@42300ff78c63 /tmp]# echo '{}' > composer.json
>>>> ???? >>
>>>> ???? >>
>>>> ???? >> [@42300ff78c63 /tmp]# composer install
>>>> ???? >> Do not run Composer as root/super user! See
>>>> ???? >> https://getcomposer.org/root for details
>>>> ???? >> Loading composer repositories with package information
>>>> ???? >> Segmentation fault
>>>> ???? >>
>>>> ???? >> [@42300ff78c63 /tmp]# composer config -g -- disable-tls true
>>>> ???? >> Do not run Composer as root/super user! See
>>>> ???? >> https://getcomposer.org/root for details
>>>> ???? >> [@42300ff78c63 /tmp]# composer install
>>>> ???? >> You are running Composer with SSL/TLS protection disabled.
>>>> ???? >> Do not run Composer as root/super user! See
>>>> ???? >> https://getcomposer.org/root for details
>>>> ???? >> Loading composer repositories with package information
>>>> ???? >> Updating dependencies (including require-dev)
>>>> ???? >> Nothing to install or update
>>>> ???? >> Generating autoload files
>>>> ???? >> [@42300ff78c63 /tmp]#
>>>> ???? >>
>>>> ???? >> [@236200a329d5 r]# rpm -q php53-common openssl
>>>> ???? >> php53-common-5.3.29-43.x86_64
>>>> ???? >> openssl-1.1.1a-1.x86_64
>>>> ???? >> [@236200a329d5 r]#
>>>> ???? >>
>>>> ???? >>
>>>> ???? >>
>>>> ???? >>
>>>> ???? >> [@42300ff78c63 /tmp]# composer config -g -- disable-tls false
>>>> ???? >> You are running Composer with SSL/TLS protection disabled.
>>>> ???? >> Do not run Composer as root/super user! See
>>>> ???? >> https://getcomposer.org/root for details
>>>> ???? >> [@42300ff78c63 /tmp]# gdb --args php /usr/bin/composer install
>>>> ???? >> GNU gdb (GDB) 8.2-2 (PLD Linux)
>>>> ???? >> Copyright (C) 2018 Free Software Foundation, Inc.
>>>> ???? >> License GPLv3+: GNU GPL version 3 or later
>>>> ???? >> <http://gnu.org/licenses/gpl.html>
>>>> ???? >> This is free software: you are free to change and
>>>> redistribute it.
>>>> ???? >> There is NO WARRANTY, to the extent permitted by law.
>>>> ???? >> Type "show copying" and "show warranty" for details.
>>>> ???? >> This GDB was configured as "x86_64-pld-linux".
>>>> ???? >> Type "show configuration" for configuration details.
>>>> ???? >> For bug reporting instructions, please see:
>>>> ???? >> <http://www.gnu.org/software/gdb/bugs/>.
>>>> ???? >> Find the GDB manual and other documentation resources online
>>>> at:
>>>> ???? >> <http://www.gnu.org/software/gdb/documentation/>.
>>>> ???? >>
>>>> ???? >> For help, type "help".
>>>> ???? >> Type "apropos word" to search for commands related to "word"...
>>>> ???? >> Reading symbols from php...Reading symbols from
>>>> ???? >> /usr/lib/debug/usr/bin/php53.debug...done.
>>>> ???? >> done.
>>>> ???? >> (gdb) r
>>>> ???? >> Starting program: /usr/bin/php /usr/bin/composer install
>>>> ???? >> [Thread debugging using libthread_db enabled]
>>>> ???? >> Using host libthread_db library "/lib64/libthread_db.so.1".
>>>> ???? >> [Detaching after fork from child process 333]
>>>> ???? >> [Detaching after fork from child process 334]
>>>> ???? >> [Detaching after fork from child process 335]
>>>> ???? >> [Detaching after fork from child process 336]
>>>> ???? >> [Detaching after fork from child process 337]
>>>> ???? >> [Detaching after fork from child process 338]
>>>> ???? >> [Detaching after fork from child process 339]
>>>> ???? >> Do not run Composer as root/super user! See
>>>> ???? >> https://getcomposer.org/root for details
>>>> ???? >> [Detaching after fork from child process 340]
>>>> ???? >> Loading composer repositories with package information
>>>> ???? >>
>>>> ???? >> Program received signal SIGSEGV, Segmentation fault.
>>>> ???? >> 0x00007ffff7e66731 in _zval_ptr_dtor
>>>> (zval_ptr=0x7ffff6853f9000) at
>>>> ???? >> /usr/src/debug/php-5.3.29/Zend/zend_execute_API.c:434
>>>> ???? >> 434??? ??? zval *zv = *zval_ptr;
>>>> ???? >> (gdb) bt
>>>> ???? >> #0? 0x00007ffff7e66731 in _zval_ptr_dtor
>>>> (zval_ptr=0x7ffff6853f9000)
>>>> ???? >> at /usr/src/debug/php-5.3.29/Zend/zend_execute_API.c:434
>>>> ???? >> #1? 0x00007ffff7ec0f85 in zend_leave_helper_SPEC
>>>> ???? >> (execute_data=execute_data at entry=0x7ffff6853eb0) at
>>>> ???? >> /usr/src/debug/php-5.3.29/Zend/zend_vm_execute.h:160
>>>> ???? >> #2? 0x00007ffff7ec148a in ZEND_RETURN_SPEC_VAR_HANDLER
>>>> ???? >> (execute_data=0x7ffff6853eb0) at
>>>> ???? >> /usr/src/debug/php-5.3.29/Zend/zend_vm_execute.h:8255
>>>> ???? >> #3? 0x00007ffff7e99e61 in execute (op_array=0x131dec8) at
>>>> ???? >> /usr/src/debug/php-5.3.29/Zend/zend_vm_execute.h:107
>>>> ???? >> #4? 0x00007ffff7e76597 in zend_execute_scripts
>>>> (type=type at entry=8,
>>>> ???? >> retval=retval at entry=0x0, file_count=file_count at entry=3) at
>>>> ???? >> /usr/src/debug/php-5.3.29/Zend/zend.c:1259
>>>> ???? >> #5? 0x00007ffff7e23d38 in php_execute_script
>>>> ???? >> (primary_file=primary_file at entry=0x7fffffffd090) at
>>>> ???? >> /usr/src/debug/php-5.3.29/main/main.c:2316
>>>> ???? >> #6? 0x0000000000404939 in main (argc=3, argv=0x7fffffffe458) at
>>>> ???? >> /usr/src/debug/php-5.3.29/sapi/cli/php_cli.c:1189
>>>> ???? >> (gdb)
>>


-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From adwol at zonk.pl  Wed Feb  6 00:02:14 2019
From: adwol at zonk.pl (Adam Osuchowski)
Date: Wed, 6 Feb 2019 00:02:14 +0100
Subject: openssl again makes php5.3 crash
In-Reply-To: <66f1a3d6-0c93-2be8-2301-472079d329c0@maven.pl>
References: <5eed7172-31e9-5829-a9d4-68a5e2856170@delfi.ee>
 <6592143e-63cb-4997-55e9-a64a3ee8b367@pld-linux.org>
 <7638da2f-75fa-4bd1-b7eb-fbcbc40db600@maven.pl>
 <CAHiWvWFhDBBwdfut26HtSEKeFFWGf5m7dbMSjOAXEwdj1Tvk2g@mail.gmail.com>
 <e98937f4-0efb-ab23-998c-dd39920497e7@maven.pl>
 <53f6ae6e-f14f-abdc-8c87-54fe32cc34fe@pld-linux.org>
 <4b551fc9-9c0d-ee1d-8ac7-860aa0347723@pld-linux.org>
 <66f1a3d6-0c93-2be8-2301-472079d329c0@maven.pl>
Message-ID: <20190205230214.6b8b4567@zonk.pl>

Arkadiusz Mi?kiewicz wrote:
> I wasn't able to find the cause of this. Compared ext/openssl with 5.4
> (which doesn't segfault) and can't find the problem.
> 
> Even backported ext/openssl from 5.4 to 5.3 still gets me segfaulting
> php 5.3.
> 
> So I think the problem is solved outside ext/openssl.
> 
> Reproducer if anyone wants to look below.

openssl.patch is broken. zval is struct not pointer, so type of local
variables should be 'zval *' not bare zval.

Fixed in repo as release 45.


From gotar at polanet.pl  Wed Feb  6 16:50:03 2019
From: gotar at polanet.pl (Tomasz Pala)
Date: Wed, 6 Feb 2019 16:50:03 +0100
Subject: is anyone using x32? was Re: [packages/librsvg] - updated
 dependencies; librsvg since 2.42 is partially in rust (what with th-x32?)
In-Reply-To: <cf74d0d0-9520-91d1-b7f1-72609d07651f@maven.pl>
References: <775f4438b11ae12c8700fcab3790c5a384605f95_refs_heads_master@pld-linux.org>
 <fc65f7f1cf360e29b7e44b9835dece9805ad9dbc_refs_heads_master@pld-linux.org>
 <20190130194442.GA4682@mail> <20190130200510.GB19467@tachikoma.lan>
 <cf74d0d0-9520-91d1-b7f1-72609d07651f@maven.pl>
Message-ID: <20190206155003.GA28042@polanet.pl>

On Thu, Jan 31, 2019 at 06:30:59 +0100, Arkadiusz Mi?kiewicz wrote:

>> 3. drop x32 possibly? https://lwn.net/Articles/774734/
> 
> Is anyone using x32 here? Speak up.

I am. In two containers only, but was planning to use one more widely;
now waiting for upstream decision.

-- 
Tomasz Pala <gotar at pld-linux.org>


From glen at pld-linux.org  Thu Feb  7 10:16:39 2019
From: glen at pld-linux.org (glen)
Date: Thu, 7 Feb 2019 11:16:39 +0200
Subject: /etc/issue.d
Message-ID: <4b2cfa1e-9006-2be8-93c2-364e40f434af@pld-linux.org>

https://github.com/pld-linux/util-linux/commit/1d44bc2b730b4461b6c3f09a602f4b7472e7b6e6

# - agetty: Documentation/releases/v2.32-ReleaseNotes:54:?? - add 
support for /etc/issue.d? [Karel Zak]
# 
https://github.com/karelzak/util-linux/commit/1fc82a1360305f696dc1be6105c9c56a9ea03f52#diff-d7efd2b3dbb10e54185f001dc21d43db

so, should the dir be added to setup and all issue* packages move their 
contents there (or duplicate?)

-- 
glen



From glen at pld-linux.org  Thu Feb 14 11:54:21 2019
From: glen at pld-linux.org (glen)
Date: Thu, 14 Feb 2019 12:54:21 +0200
Subject: [packages/syslog-ng] - add /etc/syslog-ng.d to config
In-Reply-To: <ffc0f4857cc2a66b4d7e7326219d2b49ea7976c9_refs_heads_master@pld-linux.org>
References: <02680757c3ce4fe6060dfcb8e565058d011fb631_refs_heads_master@pld-linux.org>
 <ffc0f4857cc2a66b4d7e7326219d2b49ea7976c9_refs_heads_master@pld-linux.org>
Message-ID: <edba1a4e-4f9a-e111-f8fc-cc5637f0318d@pld-linux.org>


On 2/14/19 9:38 AM, arekm wrote:
>   
> +%triggerun -- syslog-ng < 3.19.1
> +grep -q '/etc/syslog-ng.d/'/etc/syslog-ng/syslog-ng.conf || echo '@include "/etc/syslog-ng.d/"' >> /etc/syslog-ng/syslog-ng.conf
> +exit 0
> +


argh, again some project decides to do include dir support, but without 
actual without globing!!!

what's the directory scanning rule?

will it exclude backups from editors and package managers other cruft 
like VCS dirs/files?

ps: you should grep what you append, maybe someone has in comments 
matching "/etc/syslog-ng.d/"


-- 
glen



From jajcus at jajcus.net  Tue Feb 19 09:34:48 2019
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 19 Feb 2019 09:34:48 +0100
Subject: =?UTF-8?Q?Can_we_finally_switch_to_systemd_/run_directory=3f_/var/r?=
 =?UTF-8?B?dW4gc3Vja3PigKY=?=
Message-ID: <4fc07c63-986c-ac74-7865-bc55ce4e43da@jajcus.net>

Hi,


In PLD various systemd units and tmpfiles configs have been patched to
move from /run to the legacy /var/run for 'backward compatibility', even
though there are good reasons for using /run.

New systemd won't even work well with /var/run:

Feb 19 08:55:04 pbx systemd-tmpfiles[1100]:
[/usr/lib/tmpfiles.d/dbus.conf:1] Line references path below legacy
directory /var/run/, updating /var/run/dbus ? /run/dbus; please update
the tmpfiles.d/ drop-in file accordingly.
Feb 19 08:55:04 pbx systemd-tmpfiles[1100]:
[/usr/lib/tmpfiles.d/iproute2.conf:1] Line references path below legacy
directory /var/run/, updating /var/run/netns ? /run/netns; please update
the tmpfiles.d/ drop-in file accordingly.
Feb 19 08:55:04 pbx systemd-tmpfiles[1100]:
[/usr/lib/tmpfiles.d/ndisc6.conf:1] Line references path below legacy
directory /var/run/, updating /var/run/rdnssd ? /run/rdnssd; please
update the tmpfiles.d/ drop-in file accordingly.
Feb 19 08:55:04 pbx systemd-tmpfiles[1100]:
[/usr/lib/tmpfiles.d/openvpn.conf:1] Line references path below legacy
directory /var/run/, updating /var/run/openvpn ? /run/openvpn; please
update the tmpfiles.d/ drop-in file accordingly.
Feb 19 08:55:04 pbx systemd-tmpfiles[1100]:
[/usr/lib/tmpfiles.d/pam.conf:1] Line references path below legacy
directory /var/run/, updating /var/run/console ? /run/console; please
update the tmpfiles.d/ drop-in file accordingly.
Feb 19 08:55:04 pbx systemd-tmpfiles[1100]:
[/usr/lib/tmpfiles.d/pam.conf:2] Line references path below legacy
directory /var/run/, updating /var/run/sepermit ? /run/sepermit; please
update the tmpfiles.d/ drop-in file accordingly.
Feb 19 08:55:04 pbx systemd-tmpfiles[1100]:
[/usr/lib/tmpfiles.d/radvd.conf:1] Line references path below legacy
directory /var/run/, updating /var/run/radvd ? /run/radvd; please update

Feb 19 08:55:14 pbx systemd[1]: Failed to connect to API bus: No such
file or directory
Feb 19 08:55:14 pbx systemd[1]: Failed to connect to system bus: No such
file or directory
Feb 19 08:55:14 pbx systemd[1]: Failed to connect to API bus: No such
file or directory

?and various different errors.

/var/run being stored on a persistent file system has been causing
various trouble even before systemd had been a thing. Many services
wouldn't start after unclean shutdown because of pid or lock files
staying around etc.

The systemd preferred way to handle backward compatibility with the old
/var/run directory is to make /var/run a symlink to /run. I think it is
time to implement this in PLD and make rc-scripts mount tmpfs on /run
too. The bigger problem will be /var/run subdirectories? I have no good
idea how to make this work without systemd and tmpfiles or by
re-implementing tmpfiles in rc-scripts? I wish we could switch to
systemd all together finally.

Jacek


From jajcus at jajcus.net  Tue Feb 19 09:39:23 2019
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 19 Feb 2019 09:39:23 +0100
Subject: =?UTF-8?Q?Re=3a_Can_we_finally_switch_to_systemd_/run_directory=3f_?=
 =?UTF-8?Q?/var/run_sucks=e2=80=a6?=
In-Reply-To: <4fc07c63-986c-ac74-7865-bc55ce4e43da@jajcus.net>
References: <4fc07c63-986c-ac74-7865-bc55ce4e43da@jajcus.net>
Message-ID: <99601eb5-cbf1-e1c5-05e9-1a7023ce7aff@jajcus.net>

On 19/02/2019 09.34, Jacek Konieczny wrote:
> The systemd preferred way to handle backward compatibility with the old
> /var/run directory is to make /var/run a symlink to /run. 

Wrong? it is bind-mount of /run over /var/run, which is currently
disabled in PLD.

Maybe the way to go is to restore this and mark /var/run
%_netsharedpath in rpm macros?

Jacek


From jajcus at jajcus.net  Tue Feb 19 09:41:56 2019
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 19 Feb 2019 09:41:56 +0100
Subject: =?UTF-8?Q?Re=3a_Can_we_finally_switch_to_systemd_/run_directory=3f_?=
 =?UTF-8?Q?/var/run_sucks=e2=80=a6?=
In-Reply-To: <99601eb5-cbf1-e1c5-05e9-1a7023ce7aff@jajcus.net>
References: <4fc07c63-986c-ac74-7865-bc55ce4e43da@jajcus.net>
 <99601eb5-cbf1-e1c5-05e9-1a7023ce7aff@jajcus.net>
Message-ID: <aa4f6467-e5d9-fe4f-9a26-a97feabd92ac@jajcus.net>

On 19/02/2019 09.39, Jacek Konieczny wrote:
> On 19/02/2019 09.34, Jacek Konieczny wrote:
>> The systemd preferred way to handle backward compatibility with the old
>> /var/run directory is to make /var/run a symlink to /run. 
> 
> Wrong? it is bind-mount of /run over /var/run, which is currently
> disabled in PLD.

Forget this? it seems I am wrong again? I need to investigate it a bit
further?

Jacek


From glen at pld-linux.org  Tue Feb 19 15:23:25 2019
From: glen at pld-linux.org (glen)
Date: Tue, 19 Feb 2019 16:23:25 +0200
Subject: [packages/libidn2] Use lua in %post scripts to break dependency
 loop
In-Reply-To: <f4326ba5b51606cadceef812835037b081fb2c72_refs_heads_master@pld-linux.org>
References: <416e476374bdb08c967e3d6e55fca1920a6b1886_refs_heads_master@pld-linux.org>
 <f4326ba5b51606cadceef812835037b081fb2c72_refs_heads_master@pld-linux.org>
Message-ID: <79807d55-abcb-a729-dfbd-5f87c9c2b483@pld-linux.org>


On 2/19/19 2:16 PM, jajcus wrote:
> -%post
> -/sbin/ldconfig
> -[ ! -x /usr/sbin/fix-info-dir ] || /usr/sbin/fix-info-dir %{_infodir} >/dev/null 2>&1
> +%post	-p <lua>
> +os.execute("/sbin/ldconfig >/dev/null 2>&1")
> +os.execute("/usr/sbin/fix-info-dir %{_infodir} >/dev/null 2>&1")
>   
> -%postun
> -/sbin/ldconfig
> -[ ! -x /usr/sbin/fix-info-dir ] || /usr/sbin/fix-info-dir %{_infodir} >/dev/null 2>&1
> +%postun	-p <lua>
> +os.execute("/sbin/ldconfig >/dev/null 2>&1")
> +os.execute("/usr/sbin/fix-info-dir %{_infodir} >/dev/null 2>&1")
>   


the behaviour is not identical:

1. previous code did not hide ldconfig errors

2. previous code skipped invocation if /usr/sbin/fix-info-dir was missing


as you hopefully tested this, then os.execute does not trigger failure, 
but would be nice to see ldconfig errors, if any.


-- 
glen



From glen at pld-linux.org  Tue Feb 19 15:27:11 2019
From: glen at pld-linux.org (glen)
Date: Tue, 19 Feb 2019 16:27:11 +0200
Subject: =?UTF-8?Q?Re=3a_Can_we_finally_switch_to_systemd_/run_directory=3f_?=
 =?UTF-8?Q?/var/run_sucks=e2=80=a6?=
In-Reply-To: <99601eb5-cbf1-e1c5-05e9-1a7023ce7aff@jajcus.net>
References: <4fc07c63-986c-ac74-7865-bc55ce4e43da@jajcus.net>
 <99601eb5-cbf1-e1c5-05e9-1a7023ce7aff@jajcus.net>
Message-ID: <4d5d0167-acb1-4ca7-3f5a-53d219456465@pld-linux.org>


On 2/19/19 10:39 AM, Jacek Konieczny wrote:
> On 19/02/2019 09.34, Jacek Konieczny wrote:
>> The systemd preferred way to handle backward compatibility with the old
>> /var/run directory is to make /var/run a symlink to /run.
> Wrong? it is bind-mount of /run over /var/run, which is currently
> disabled in PLD.


yes, it's bind mounted. but i don't have much pld-systemd systems around 
to verify widely.


```

# mount|grep run
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,mode=755)

# rpm -q systemd
systemd-232-7.x86_64

```


non-systemd should do the same, but currently it does not:


```

# mount|grep run
run on /run type tmpfs (rw,relatime,mode=755)

# rpm -q rc-scripts
rc-scripts-0.4.18-1.x86_64

```

-- 
glen



From jajcus at jajcus.net  Tue Feb 19 15:37:12 2019
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 19 Feb 2019 15:37:12 +0100
Subject: [packages/libidn2] Use lua in %post scripts to break dependency
 loop
In-Reply-To: <79807d55-abcb-a729-dfbd-5f87c9c2b483@pld-linux.org>
References: <416e476374bdb08c967e3d6e55fca1920a6b1886_refs_heads_master@pld-linux.org>
 <f4326ba5b51606cadceef812835037b081fb2c72_refs_heads_master@pld-linux.org>
 <79807d55-abcb-a729-dfbd-5f87c9c2b483@pld-linux.org>
Message-ID: <13d0135f-7f6e-698b-cc00-bfda1beb7818@jajcus.net>

On 19/02/2019 15.23, glen wrote:
> the behaviour is not identical:
> 
> 1. previous code did not hide ldconfig errors

Which should not bother us. Even if ldconfig does not work we need this
installed if we want glibc installed properly

> 2. previous code skipped invocation if /usr/sbin/fix-info-dir was missing

Not needed here ? we can just ignore the errors.

> as you hopefully tested this, then os.execute does not trigger failure,

> but would be nice to see ldconfig errors, if any.

Maybe?

Anyway? that change was pointless, as a loop is still there, although
shorter (libidn2 -> glibc -> libidn2) and not easy to fix.

Adding external libidn2 dependency to glibc was a very bad idea and
should be reverted. glibc must not have any 'heavy' external
dependencies. And libidn2 is not even a single library, as it pulls
libunistring.


Jacek




From glen at pld-linux.org  Tue Feb 19 15:53:19 2019
From: glen at pld-linux.org (glen)
Date: Tue, 19 Feb 2019 16:53:19 +0200
Subject: [packages/libidn2] Use lua in %post scripts to break dependency
 loop
In-Reply-To: <13d0135f-7f6e-698b-cc00-bfda1beb7818@jajcus.net>
References: <416e476374bdb08c967e3d6e55fca1920a6b1886_refs_heads_master@pld-linux.org>
 <f4326ba5b51606cadceef812835037b081fb2c72_refs_heads_master@pld-linux.org>
 <79807d55-abcb-a729-dfbd-5f87c9c2b483@pld-linux.org>
 <13d0135f-7f6e-698b-cc00-bfda1beb7818@jajcus.net>
Message-ID: <637b3fde-1f0c-21db-e0a5-f87458f2ece9@pld-linux.org>

On 2/19/19 4:37 PM, Jacek Konieczny wrote:

> Adding external libidn2 dependency to glibc was a very bad idea and
> should be reverted. glibc must not have any 'heavy' external
> dependencies. And libidn2 is not even a single library, as it pulls
> libunistring.

perhaps pld should go alpine? use musl and busybox?

kill selinux, nls and other nonsense not useful in containers?


...i tend to see less value in pld nowadays, only to support some legacy 
applications.


-- 
glen



From arekm at maven.pl  Tue Feb 19 15:59:42 2019
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Tue, 19 Feb 2019 15:59:42 +0100
Subject: [packages/libidn2] Use lua in %post scripts to break dependency
 loop
In-Reply-To: <13d0135f-7f6e-698b-cc00-bfda1beb7818@jajcus.net>
References: <416e476374bdb08c967e3d6e55fca1920a6b1886_refs_heads_master@pld-linux.org>
 <f4326ba5b51606cadceef812835037b081fb2c72_refs_heads_master@pld-linux.org>
 <79807d55-abcb-a729-dfbd-5f87c9c2b483@pld-linux.org>
 <13d0135f-7f6e-698b-cc00-bfda1beb7818@jajcus.net>
Message-ID: <cb97ad53-ece3-7524-dab0-e50da4034ac8@maven.pl>

On 19/02/2019 15:37, Jacek Konieczny wrote:

> Adding external libidn2 dependency to glibc was a very bad idea and
> should be reverted. glibc must not have any 'heavy' external
> dependencies. 

That's why it is "Suggests" not "Requires".

-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From mike at altlinux.org  Tue Feb 19 16:30:11 2019
From: mike at altlinux.org (Michael Shigorin)
Date: Tue, 19 Feb 2019 18:30:11 +0300
Subject: Can we finally switch to =?utf-8?Q?sys?=
 =?utf-8?Q?temd_=2Frun_directory=3F_=2Fvar=2Frun_sucks=E2=80=A6?=
In-Reply-To: <4fc07c63-986c-ac74-7865-bc55ce4e43da@jajcus.net>
References: <4fc07c63-986c-ac74-7865-bc55ce4e43da@jajcus.net>
Message-ID: <20190219153011.GB3962@imap.altlinux.org>

On Tue, Feb 19, 2019 at 09:34:48AM +0100, Jacek Konieczny wrote:
> The bigger problem will be /var/run subdirectories? I have no
> good idea how to make this work without systemd and tmpfiles or
> by re-implementing tmpfiles in rc-scripts? 

You might want to have a look at
http://git.altlinux.org/gears/s/startup.git?p=startup.git;a=commit;h=e7558a4ecfe9084099c9c620614e646008f1f68d
and probably some later commits as well.

> I wish we could switch to systemd all together finally.

CVE-2019-6454 has some recent irony for you...

-- 
?---- WBR, Michael Shigorin / http://altlinux.org
??------ http://opennet.ru / http://anna-news.info


From glen at delfi.ee  Tue Feb 19 19:02:59 2019
From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 19 Feb 2019 20:02:59 +0200
Subject: [packages/libidn2] Use lua in %post scripts to break dependency
 loop
In-Reply-To: <cb97ad53-ece3-7524-dab0-e50da4034ac8@maven.pl>
References: <416e476374bdb08c967e3d6e55fca1920a6b1886_refs_heads_master@pld-linux.org>
 <f4326ba5b51606cadceef812835037b081fb2c72_refs_heads_master@pld-linux.org>
 <79807d55-abcb-a729-dfbd-5f87c9c2b483@pld-linux.org>
 <13d0135f-7f6e-698b-cc00-bfda1beb7818@jajcus.net>
 <cb97ad53-ece3-7524-dab0-e50da4034ac8@maven.pl>
Message-ID: <46cb8095-631f-ee16-5572-7c57694fb648@delfi.ee>

On 19/02/2019 16:59, Arkadiusz Mi?kiewicz wrote:

> On 19/02/2019 15:37, Jacek Konieczny wrote:
>
>> Adding external libidn2 dependency to glibc was a very bad idea and
>> should be reverted. glibc must not have any 'heavy' external
>> dependencies.
> That's why it is "Suggests" not "Requires".
>
it's rpm implementation detail, that it converts suggests to requires 
when dep solving, thus it is still creating dependency loops it can not 
solve.

jbj has been ranting about that several times in the lists.



From glen at pld-linux.org  Thu Feb 21 16:38:04 2019
From: glen at pld-linux.org (glen)
Date: Thu, 21 Feb 2019 17:38:04 +0200
Subject: [packages/linux-pstore] - initial
In-Reply-To: <89eac3bb7404b1fc35985399d804c376da4a535b_refs_heads_master@pld-linux.org>
References: <155075422854.1152.3367568468719568968@pld-linux.org>
 <89eac3bb7404b1fc35985399d804c376da4a535b_refs_heads_master@pld-linux.org>
Message-ID: <5d32e3b0-1d20-d9c8-cb69-9bcae7c1ad13@pld-linux.org>

On 2/21/19 3:03 PM, arekm wrote:

> +%post
> +if [ -d /sys/fs/pstore ]; then
> +	grep -qE "^none.*/sys/fs/pstore" %{_sysconfdir}/fstab || (echo -e "none\t\t/sys/fs/pstore\tpstore\tdefaults\t 0 0" >> %{_sysconfdir}/fstab && grep -q "/sys/fs/pstore" /proc/self/mounts || mount /sys/fs/pstore)
> +	exit 0
> +fi
> +


yuks.


i think this should go to "setup" package like rest of the fstab mounts


and mounting from %post does not seem good either.


so i propose:

1. add to setup the mount with noauto

2. update rc-scripts to mount it


this is the way afaik other fs are done.


-- 
glen



From arekm at maven.pl  Thu Feb 21 17:31:13 2019
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Thu, 21 Feb 2019 17:31:13 +0100
Subject: [packages/linux-pstore] - initial
In-Reply-To: <5d32e3b0-1d20-d9c8-cb69-9bcae7c1ad13@pld-linux.org>
References: <155075422854.1152.3367568468719568968@pld-linux.org>
 <89eac3bb7404b1fc35985399d804c376da4a535b_refs_heads_master@pld-linux.org>
 <5d32e3b0-1d20-d9c8-cb69-9bcae7c1ad13@pld-linux.org>
Message-ID: <e51af2c7-28f7-4815-bce1-55daa1853f9e@maven.pl>

On 21/02/2019 16:38, glen wrote:
> On 2/21/19 3:03 PM, arekm wrote:
> 
>> +%post
>> +if [ -d /sys/fs/pstore ]; then
>> +??? grep -qE "^none.*/sys/fs/pstore" %{_sysconfdir}/fstab || (echo -e
>> "none\t\t/sys/fs/pstore\tpstore\tdefaults\t 0 0" >>
>> %{_sysconfdir}/fstab && grep -q "/sys/fs/pstore" /proc/self/mounts ||
>> mount /sys/fs/pstore)
>> +??? exit 0
>> +fi
>> +
> 
> 
> yuks.
> 
> 
> i think this should go to "setup" package like rest of the fstab mounts
> 
> 
> and mounting from %post does not seem good either.
> 
> 
> so i propose:
> 
> 1. add to setup the mount with noauto

It is there but as auto

https://git.pld-linux.org/gitweb.cgi?p=projects/setup.git;a=commitdiff;h=7ee07b3cca899e6220914022676f2aab1efb46d9

(need to put it into actual setup.spec, too)

> 
> 2. update rc-scripts to mount it
> 
> 
> this is the way afaik other fs are done.


Initially I added mounting to python script itself. And I guess I go
that route (mount if not mounted) instead of %post.


-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From atler at pld-linux.org  Sun Feb 24 12:57:05 2019
From: atler at pld-linux.org (Jan Palus)
Date: Sun, 24 Feb 2019 12:57:05 +0100
Subject: Missing buildlogs
Message-ID: <20190224115705.yahoahtpiqmm3cp4@kalarepa>

Looks like starting with gcc build (https://srcbuilder.pld-linux.org/th/queue.html#184029)
buildlogs went missing. Can someone check?


From qboosh at pld-linux.org  Sun Feb 24 13:25:07 2019
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 24 Feb 2019 13:25:07 +0100
Subject: Missing buildlogs
In-Reply-To: <20190224115705.yahoahtpiqmm3cp4@kalarepa>
References: <20190224115705.yahoahtpiqmm3cp4@kalarepa>
Message-ID: <20190224122507.GA21362@mail>

On Sun, Feb 24, 2019 at 12:57:05PM +0100, Jan Palus wrote:
> Looks like starting with gcc build (https://srcbuilder.pld-linux.org/th/queue.html#184029)
> buildlogs went missing. Can someone check?

Probably because:

there were problems sending files from queue /home/users/builderth/pld-builder.new/spool/buildlogs:
problems:
[src: /home/users/builderth/pld-builder.new/spool/buildlogs/th-x86_64.a13106f0-19e0-4e4b-bb97-80a070419923.libatomic_ops.spec.log]

@ERROR: invalid uid ftp
rsync error: error starting client-server protocol (code 5) at main.c(1648) [sender=3.1.2]
[...]

(from the tons of emails I'm getting from builders...)


-- 
Jakub Bogusz    http://qboosh.pl/


From atler at pld-linux.org  Sun Feb 24 13:35:30 2019
From: atler at pld-linux.org (Jan Palus)
Date: Sun, 24 Feb 2019 13:35:30 +0100
Subject: Missing buildlogs
In-Reply-To: <20190224122507.GA21362@mail>
References: <20190224115705.yahoahtpiqmm3cp4@kalarepa>
 <20190224122507.GA21362@mail>
Message-ID: <20190224123530.43rq5nhbu7hssxg2@kalarepa>

On 24.02.2019 13:25, Jakub Bogusz wrote:
> On Sun, Feb 24, 2019 at 12:57:05PM +0100, Jan Palus wrote:
> > Looks like starting with gcc build (https://srcbuilder.pld-linux.org/th/queue.html#184029)
> > buildlogs went missing. Can someone check?
> 
> Probably because:
> 
> there were problems sending files from queue /home/users/builderth/pld-builder.new/spool/buildlogs:
> problems:
> [src: /home/users/builderth/pld-builder.new/spool/buildlogs/th-x86_64.a13106f0-19e0-4e4b-bb97-80a070419923.libatomic_ops.spec.log]
> 
> @ERROR: invalid uid ftp
> rsync error: error starting client-server protocol (code 5) at main.c(1648) [sender=3.1.2]
> [...]
> 
> (from the tons of emails I'm getting from builders...)

Right, thanks. Seems like at some point in time I got too overwhelmed by those
messages and created rule to get rid of them completely.


From arekm at maven.pl  Mon Feb 25 22:28:11 2019
From: arekm at maven.pl (=?UTF-8?Q?Arkadiusz_Mi=c5=9bkiewicz?=)
Date: Mon, 25 Feb 2019 22:28:11 +0100
Subject: Missing buildlogs
In-Reply-To: <20190224115705.yahoahtpiqmm3cp4@kalarepa>
References: <20190224115705.yahoahtpiqmm3cp4@kalarepa>
Message-ID: <dbbd1465-f629-bc07-1d44-c96f913db34b@maven.pl>

On 24/02/2019 12:57, Jan Palus wrote:
> Looks like starting with gcc build (https://srcbuilder.pld-linux.org/th/queue.html#184029)
> buildlogs went missing. Can someone check?

rsyncd required restart on glibc upgrade it seems. Fixed.


-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From glen at delfi.ee  Tue Feb 26 13:14:17 2019
From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 26 Feb 2019 14:14:17 +0200
Subject: Missing buildlogs
In-Reply-To: <dbbd1465-f629-bc07-1d44-c96f913db34b@maven.pl>
References: <20190224115705.yahoahtpiqmm3cp4@kalarepa>
 <dbbd1465-f629-bc07-1d44-c96f913db34b@maven.pl>
Message-ID: <ea159ded-fb4a-a1ce-d668-9564f9a1702b@delfi.ee>

On 25/02/2019 23:28, Arkadiusz Mi?kiewicz wrote:

> On 24/02/2019 12:57, Jan Palus wrote:
>> Looks like starting with gcc build (https://srcbuilder.pld-linux.org/th/queue.html#184029)
>> buildlogs went missing. Can someone check?
> rsyncd required restart on glibc upgrade it seems. Fixed.

perhaps add trigger to restart, like we have for crond

do you have any syslogs on the error?

and it was glibc upgrade from what to what version?




From baggins at pld-linux.org  Tue Feb 26 23:53:15 2019
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 26 Feb 2019 23:53:15 +0100
Subject: KDE4 and KDE3 going away
Message-ID: <20190226225315.GD19467@tachikoma.lan>

Until someone fixes build problems with kde packages that are currently broken
according to http://ep09.pld-linux.org/~pldth/main-ready-test.txt, I am
going to remove ALL kde4 and kde3 packages and everything that depends on
them.

YHBW, HTH, HAND.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From glen at delfi.ee  Wed Feb 27 14:47:52 2019
From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Wed, 27 Feb 2019 15:47:52 +0200
Subject: KDE4 and KDE3 going away
In-Reply-To: <20190226225315.GD19467@tachikoma.lan>
References: <20190226225315.GD19467@tachikoma.lan>
Message-ID: <63569501-0469-63c6-f276-92dcbc4902ee@delfi.ee>

let them rest well!

On 27/02/2019 00:53, Jan R?korajski wrote:
> Until someone fixes build problems with kde packages that are currently broken
> according to http://ep09.pld-linux.org/~pldth/main-ready-test.txt, I am
> going to remove ALL kde4 and kde3 packages and everything that depends on
> them.
>
> YHBW, HTH, HAND.
>