From Nicolas.Perrenoud at united-security-providers.ch  Thu Feb  4 19:23:43 2016
From: Nicolas.Perrenoud at united-security-providers.ch (Perrenoud, Nicolas)
Date: Thu, 4 Feb 2016 18:23:43 +0000
Subject: pld-linux/openssl: Updated c_rehash shell script
Message-ID: <F12416C32E57D048BBE26B9CE1822B150BC6D4F4@uspEXCH02.u-s-p.local>

Hi all

I've created a patch for the c_rehash script shipped with OpenSSL in PLD Linux. It updates the script to support additional file types, as the original perl script used in OpenSSL 1.0.2

The pull request can be found here: https://github.com/pld-linux/openssl/pull/1

I'd be glad if this could be reviewed.

Best regards
Nicolas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5519 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20160204/fa9f81b5/attachment.bin>

From glen at pld-linux.org  Thu Feb  4 22:28:39 2016
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Thu, 4 Feb 2016 23:28:39 +0200
Subject: pld-linux/openssl: Updated c_rehash shell script
In-Reply-To: <F12416C32E57D048BBE26B9CE1822B150BC6D4F4@uspEXCH02.u-s-p.local>
References: <F12416C32E57D048BBE26B9CE1822B150BC6D4F4@uspEXCH02.u-s-p.local>
Message-ID: <56B3C287.20308@pld-linux.org>

looks  good, merged!

On 04.02.2016 20:23, Perrenoud, Nicolas wrote:
> Hi all
>
> I've created a patch for the c_rehash script shipped with OpenSSL in PLD Linux. It updates the script to support additional file types, as the original perl script used in OpenSSL 1.0.2
>
> The pull request can be found here: https://github.com/pld-linux/openssl/pull/1
>
> I'd be glad if this could be reviewed.
>
> Best regards
> Nicolas



-- 
glen



From Nicolas.Perrenoud at united-security-providers.ch  Fri Feb  5 08:08:46 2016
From: Nicolas.Perrenoud at united-security-providers.ch (Perrenoud, Nicolas)
Date: Fri, 5 Feb 2016 07:08:46 +0000
Subject: AW: pld-linux/openssl: Updated c_rehash shell script
In-Reply-To: <56B3C287.20308@pld-linux.org>
References: <F12416C32E57D048BBE26B9CE1822B150BC6D4F4@uspEXCH02.u-s-p.local>
 <56B3C287.20308@pld-linux.org>
Message-ID: <F12416C32E57D048BBE26B9CE1822B150BC6D531@uspEXCH02.u-s-p.local>

Thanks a lot!

Since I'm quite new here, can you tell me how/when this change finds it's way into http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/openssl/openssl-c_rehash.sh ?

I'm asking this because the Gentoo Linux Package https://packages.gentoo.org/packages/app-misc/c_rehash depends on that script from this CVS repo and I'll be needing this change in Gentoo.

Best regards
Nicolas

-----Urspr?ngliche Nachricht-----
Von: pld-devel-en-bounces at lists.pld-linux.org [mailto:pld-devel-en-bounces at lists.pld-linux.org] Im Auftrag von Elan Ruusam?e
Gesendet: Donnerstag, 4. Februar 2016 22:29
An: PLD: Developers list (English) <pld-devel-en at lists.pld-linux.org>
Betreff: Re: pld-linux/openssl: Updated c_rehash shell script

looks  good, merged!

On 04.02.2016 20:23, Perrenoud, Nicolas wrote:
> Hi all
>
> I've created a patch for the c_rehash script shipped with OpenSSL in PLD Linux. It updates the script to support additional file types, as the original perl script used in OpenSSL 1.0.2
>
> The pull request can be found here: https://github.com/pld-linux/openssl/pull/1
>
> I'd be glad if this could be reviewed.
>
> Best regards
> Nicolas



-- 
glen

_______________________________________________
pld-devel-en mailing list
pld-devel-en at lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5519 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20160205/665bc630/attachment.bin>

From arekm at maven.pl  Fri Feb  5 08:15:36 2016
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Fri, 5 Feb 2016 08:15:36 +0100
Subject: AW: pld-linux/openssl: Updated c_rehash shell script
In-Reply-To: <F12416C32E57D048BBE26B9CE1822B150BC6D531@uspEXCH02.u-s-p.local>
References: <F12416C32E57D048BBE26B9CE1822B150BC6D4F4@uspEXCH02.u-s-p.local>
 <56B3C287.20308@pld-linux.org>
 <F12416C32E57D048BBE26B9CE1822B150BC6D531@uspEXCH02.u-s-p.local>
Message-ID: <201602050815.36532.arekm@maven.pl>

On Friday 05 of February 2016, Perrenoud, Nicolas wrote:
> Thanks a lot!
> 
> Since I'm quite new here, can you tell me how/when this change finds it's
> way into
> http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/openssl/openssl-c_reh
> ash.sh ?

http://git.pld-linux.org/gitweb.cgi?p=packages/openssl.git;a=summary

cvs is historic repository

> Best regards
> Nicolas

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


From Nicolas.Perrenoud at united-security-providers.ch  Fri Feb  5 08:49:22 2016
From: Nicolas.Perrenoud at united-security-providers.ch (Perrenoud, Nicolas)
Date: Fri, 5 Feb 2016 07:49:22 +0000
Subject: AW: AW: pld-linux/openssl: Updated c_rehash shell script
In-Reply-To: <201602050815.36532.arekm@maven.pl>
References: <F12416C32E57D048BBE26B9CE1822B150BC6D4F4@uspEXCH02.u-s-p.local>
 <56B3C287.20308@pld-linux.org>
 <F12416C32E57D048BBE26B9CE1822B150BC6D531@uspEXCH02.u-s-p.local>
 <201602050815.36532.arekm@maven.pl>
Message-ID: <F12416C32E57D048BBE26B9CE1822B150BC6D558@uspEXCH02.u-s-p.local>

Thanks for your quick reply. I will see with the Gentoo guys so that the link in the c_rehash package is updated to use the Git repository instead.

-----Urspr?ngliche Nachricht-----
Von: Arkadiusz Mi?kiewicz [mailto:arekm at maven.pl] 
Gesendet: Freitag, 5. Februar 2016 08:16
An: pld-devel-en at lists.pld-linux.org
Cc: Perrenoud, Nicolas <Nicolas.Perrenoud at united-security-providers.ch>
Betreff: Re: AW: pld-linux/openssl: Updated c_rehash shell script

On Friday 05 of February 2016, Perrenoud, Nicolas wrote:
> Thanks a lot!
> 
> Since I'm quite new here, can you tell me how/when this change finds 
> it's way into 
> http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/openssl/openssl-c
> _reh
> ash.sh ?

http://git.pld-linux.org/gitweb.cgi?p=packages/openssl.git;a=summary

cvs is historic repository

> Best regards
> Nicolas

--
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5519 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20160205/90198933/attachment.bin>

From qboosh at pld-linux.org  Mon Feb  8 20:33:40 2016
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Mon, 8 Feb 2016 20:33:40 +0100
Subject: Fwd: ERRORS: libgsf.spec
Message-ID: <20160208193340.GA28416@mail>

It seems that df contains broken, zero-length file
(http://distfiles.pld-linux.org/distfiles/by-md5/a/3/a3e9622b31ab88422d519da72e6f0fa4/libgsf-1.14.35.tar.xz)

Could sb remove/refetch this file?


----- Forwarded message from PLD th-src builder <builder-th-src at pld-linux.org> -----

From: PLD th-src builder <builder-th-src at pld-linux.org>
X-PLD-Builder: th-src
To: qboosh at pld-linux.org
Date: Mon, 08 Feb 2016 18:16:14 +0000
Subject: ERRORS: libgsf.spec

Request by: qboosh at pld-linux.org

libgsf.spec (HEAD): FAILED

--- libgsf.spec:HEAD:
Build-Time: user:1.19s sys:0.43s real:8.09s (faults io:176 non-io:93287)



*** buildlog for libgsf.spec
request from: qboosh
started at: Mon Feb  8 19:16:06 2016
building SRPM using: cd rpm/packages; nice -n 0 ./builder -nu -nm --nodeps --http --define '_pld_builder 1' -bs  -r HEAD  -Tp auto/th/ -tt   libgsf.spec 2>&1

Cloning into 'libgsf'...
>From git://git.pld-linux.org/packages/libgsf
 * [new ref]         refs/notes/commits -> refs/notes/commits
5b50cce353fba2131697b22dc791f4f1d57dc8a1
Already on 'master'
Your branch is up-to-date with 'origin/master'.
Already up-to-date.

No conditional flags passed

from available:
--with   :	
--without:	 apidocs static_libs

Available branches: AC-branch master
Searching for tag auto/th/libgsf-1.14.35-1...
Searching for tag auto/th/libgsf-1_14_35-1...
--2016-02-08 18:16:13--  http://distfiles.pld-linux.org/distfiles/by-md5/a/3/a3e9622b31ab88422d519da72e6f0fa4/libgsf-1.14.35.tar.xz
Resolving distfiles.pld-linux.org... 193.239.45.41
Connecting to distfiles.pld-linux.org|193.239.45.41|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [application/octet-stream]
Saving to: 'libgsf-1.14.35.tar.xz'

     0K                                                        0.00 =0s

2016-02-08 18:16:13 (0.00 B/s) - 'libgsf-1.14.35.tar.xz' saved [0/0]

--2016-02-08 18:16:13--  http://attic-distfiles.pld-linux.org/distfiles/Attic/by-md5/a/3/a3e9622b31ab88422d519da72e6f0fa4/libgsf-1.14.35.tar.xz
Resolving attic-distfiles.pld-linux.org... 193.239.45.41
Connecting to attic-distfiles.pld-linux.org|193.239.45.41|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2016-02-08 18:16:13 ERROR 404: Not Found.

Error: some source, patch or icon files not stored in PLD repo. (http://ftp.gnome.org/pub/GNOME/sources/libgsf/1.14/libgsf-1.14.35.tar.xz)
exit status 1024
error: No files produced.
error: Macro %_builddir has empty body
error: Macro %_builddir has empty body
Fetching(Source0): http://ftp.gnome.org/pub/GNOME/sources/libgsf/1.14/libgsf-1.14.35.tar.xz
error: Fetching Source0 failed: Unknown or unexpected error
error: Missing Source0: libgsf-1.14.35.tar.xz: No such file or directory
Executing(--clean): /bin/sh -e /home/users/builder/tmp/rpm-tmp.39974
+ umask 022
+ cd /home/users/builder/rpm/BUILD
Begin-PLD-Builder-Info
Build-Time: user:1.19s sys:0.43s real:8.09s (faults io:176 non-io:93287)

End-PLD-Builder-Info


----- End forwarded message -----

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


From glen at pld-linux.org  Tue Feb 16 12:45:15 2016
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 16 Feb 2016 13:45:15 +0200
Subject: bash-completion packages
Message-ID: <56C30BCB.2030505@pld-linux.org>

so,

i've heard the complains about pointless bash-completion subpackages.

let's make the changes:
- add directories to filesystem packages
- drop the subpackages packages

note: requires: bash-completion >= 2.0 should be changed to conflicts: 
bash-completion < 2.0 to support the optional versioned dependency

anyone against? or having some other ideas?

-- 
glen



From glen at pld-linux.org  Wed Feb 17 09:12:22 2016
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Wed, 17 Feb 2016 10:12:22 +0200
Subject: cve-2015-7547-glibc-getaddrinfo-stack
Message-ID: <56C42B66.9000001@pld-linux.org>

https://googleonlinesecurity.blogspot.com.ee/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

-- 
glen



From glen at delfi.ee  Fri Feb 19 10:35:29 2016
From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Fri, 19 Feb 2016 11:35:29 +0200
Subject: pulse audio switching
Message-ID: <56C6E1E1.8010607@delfi.ee>

so i rebooted...

and now mpd (using alsa backend) switches sound profiles every 5 
seconds, to some SPEAKERS, BIG HALL, etc profiles

this is super annoying! any ideas?

i already downgraded pulseaudio 7.1 -> 7.0, what next?


-- 
glen



From jajcus at jajcus.net  Sat Feb 20 18:00:22 2016
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sat, 20 Feb 2016 18:00:22 +0100
Subject: Vulkan (new 3D graphics driver API) packages
Message-ID: <56C89BA6.1050702@jajcus.net>

Hi,

Last week Khronos Group released the Vulkan-1.0 specification and some
basic Vulkan software (SDK). First drivers and apps has also been
released.

Vulkan is the new 3D Graphics API which is hoped to be much better than
OpenGL.

Unfortunately the released SDK is complete mess. The 'official package'
is a self-extracting archive, compiled from multiple source repositories
and containing some deb packages. It is not suitable for PLD packaging.
Instead, I have packaged code from the individual GitHub repositories.
Those are also mess: unreasonable names, no proper versioning or release
tags, binaries would install in quite random locations, if at all?

That is why package naming and versioning is a bit of guess work now. We
should probably sync it with upstream, when they clean up the mess a
bit.

I have packaged the 'Vulkan-LoaderAndValidationLayers' with its
dependencies and the experimental Mesa driver for Intel GPUs.

The packages:

vulkan-loader.spec:

     vulkan-loader (that is package name of the DEB pkg in the official
SDK) ? the main API entry point ? libvulkan.so plus directories for the
ICDs (drivers) and layers (optional middleware)

     vulkan-loader-utils ? currently only 'vulkaninfo'

     vulkan-layers ? validation layers

     vulkan-devel ? Vulkan header files + exaples (demo code)

     vulkan-loader-demos - precompiled demos (won't run outside of the
source directory, ackaged in -devel, though)

This is built from the latest tag on the repository and uses the Vulkan
SDK version number.

Mesa-vulkan-icd-intel.spec:

     Mesa-vulkan-icd-intel ? Vulkan driver for intel GPUs

This is built from a snapshot of the 'vulkan' branch of Mesa GIT
repository. Will be built from Mesa spec, when mainstreamed.

The driver should work for Skylake GPUs and support for earlier chips
(like Haswell based HD4600) is incomplete and known to be buggy. Thats
why little more than 'vulkaninfo' works for me. Only
https://github.com/krh/vkcube would display anything for me, but only
when forced to link against our loader and the intel driver library (the
latter should never be needed).

The newest nVidia GPU Linux drivers include Vulkan support ? someone
with that GPU should try package that too. There is even a chance that
someone would be able to play The Talos Principle on Vulkan with that.

AMD is late, as always?

Jacek


From glen at pld-linux.org  Mon Feb 22 23:23:12 2016
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 23 Feb 2016 00:23:12 +0200
Subject: popt warning
Message-ID: <56CB8A50.30405@pld-linux.org>

sometimes i see such message when building packages:

warning: existing POPT configuration file 
"/usr/lib/rpm/rpmpopt:/usr/lib/rpm/%{_target}/rpmpopt:/etc/rpm/rpmpopt.*:/etc/rpm/rpm
popt:/etc/rpm/%{_target}/rpmpopt:~/.rpmpopt" considered INSECURE -- not 
loaded

not always, i.e building same package i sometimes see this and sometimes 
do not.
rpm-5.4.15-31.x86_64

any ideas what this is about?
and it appeared rather recently...

-- 
glen



From glen at delfi.ee  Tue Feb 23 10:18:56 2016
From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 23 Feb 2016 11:18:56 +0200
Subject: pulse audio switching
In-Reply-To: <56C6E1E1.8010607@delfi.ee>
References: <56C6E1E1.8010607@delfi.ee>
Message-ID: <56CC2400.4030206@delfi.ee>

the poor sound quality was caused by having two outputs enabled both 
routed to same output :)

On 19.02.2016 11:35, Elan Ruusam?e wrote:
> so i rebooted...
>
> and now mpd (using alsa backend) switches sound profiles every 5 
> seconds, to some SPEAKERS, BIG HALL, etc profiles
>
> this is super annoying! any ideas?
>
> i already downgraded pulseaudio 7.1 -> 7.0, what next?
>
>


-- 
glen



From n3npq at mac.com  Tue Feb 23 18:42:18 2016
From: n3npq at mac.com (Jeff Johnson)
Date: Tue, 23 Feb 2016 12:42:18 -0500
Subject: popt warning
In-Reply-To: <56CB8A50.30405@pld-linux.org>
References: <56CB8A50.30405@pld-linux.org>
Message-ID: <EA679464-A214-46E7-8FF7-DBA3B561BA31@mac.com>


On Feb 22, 2016, at 5:23 PM, Elan Ruusam?e wrote:

> sometimes i see such message when building packages:
> 
> warning: existing POPT configuration file "/usr/lib/rpm/rpmpopt:/usr/lib/rpm/%{_target}/rpmpopt:/etc/rpm/rpmpopt.*:/etc/rpm/rpm
> popt:/etc/rpm/%{_target}/rpmpopt:~/.rpmpopt" considered INSECURE -- not loaded
> 
> not always, i.e building same package i sometimes see this and sometimes do not.
> rpm-5.4.15-31.x86_64
> 
> any ideas what this is about?

The intent is/was to have poptSaneFile() check permissions on files being read
(non-zero is an error). The mechanism is dependent on adding a leading '@'
to a file path.

int poptSaneFile(const char * fn)
{
    struct stat sb;
    uid_t uid = getuid();

    if (stat(fn, &sb) == -1)
        return 1;
    if ((uid_t)sb.st_uid != uid)
        return 0;
    if (!S_ISREG(sb.st_mode))
        return 0;
    if (sb.st_mode & (S_IWGRP|S_IWOTH))
        return 0;
    return 1;
}

There may be other returns (from failure to read a file) in poptReadFile() that may trigger the message.


> and it appeared rather recently...
> 

hth

73 de Jeff



From glen at pld-linux.org  Tue Feb 23 18:58:00 2016
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 23 Feb 2016 19:58:00 +0200
Subject: popt warning
In-Reply-To: <EA679464-A214-46E7-8FF7-DBA3B561BA31@mac.com>
References: <56CB8A50.30405@pld-linux.org>
 <EA679464-A214-46E7-8FF7-DBA3B561BA31@mac.com>
Message-ID: <56CC9DA8.6080504@pld-linux.org>

On 23.02.2016 19:42, Jeff Johnson wrote:
> On Feb 22, 2016, at 5:23 PM, Elan Ruusam?e wrote:
>
>> sometimes i see such message when building packages:
>>
>> warning: existing POPT configuration file "/usr/lib/rpm/rpmpopt:/usr/lib/rpm/%{_target}/rpmpopt:/etc/rpm/rpmpopt.*:/etc/rpm/rpm
>> popt:/etc/rpm/%{_target}/rpmpopt:~/.rpmpopt" considered INSECURE -- not loaded
>>
>> not always, i.e building same package i sometimes see this and sometimes do not.
>> rpm-5.4.15-31.x86_64
>>
>> any ideas what this is about?
> The intent is/was to have poptSaneFile() check permissions on files being read
> (non-zero is an error). The mechanism is dependent on adding a leading '@'
> to a file path.
>
> int poptSaneFile(const char * fn)
> {
>      struct stat sb;
>      uid_t uid = getuid();
>
>      if (stat(fn, &sb) == -1)
>          return 1;
>      if ((uid_t)sb.st_uid != uid)
>          return 0;
>      if (!S_ISREG(sb.st_mode))
>          return 0;
>      if (sb.st_mode & (S_IWGRP|S_IWOTH))
>          return 0;
>      return 1;
> }
>
> There may be other returns (from failure to read a file) in poptReadFile() that may trigger the message.

so, any of those files should be group or other writable to produce the 
warning...


? for a in $(rpm -E 
/usr/lib/rpm/rpmpopt:/usr/lib/rpm/%{_target}/rpmpopt:/etc/rpm/rpmpopt.*:/etc/rpm/rpmpopt:/etc/rpm/%{_target}/rpmpopt:~/.rpmpopt|tr 
':' ' '); do ls -ld $a; done
-rw-r--r-- 1 root root 20977 29. nov   14:30 /usr/lib/rpm/rpmpopt
ls: cannot access '/usr/lib/rpm/x86_64-linux/rpmpopt': No such file or 
directory
ls: cannot access '/etc/rpm/rpmpopt.*': No such file or directory
ls: cannot access '/etc/rpm/rpmpopt': No such file or directory
ls: cannot access '/etc/rpm/x86_64-linux/rpmpopt': No such file or directory
ls: cannot access '~/.rpmpopt': No such file or directory

?



-- 
glen



From n3npq at mac.com  Tue Feb 23 19:24:12 2016
From: n3npq at mac.com (Jeff Johnson)
Date: Tue, 23 Feb 2016 13:24:12 -0500
Subject: popt warning
In-Reply-To: <56CC9DA8.6080504@pld-linux.org>
References: <56CB8A50.30405@pld-linux.org>
 <EA679464-A214-46E7-8FF7-DBA3B561BA31@mac.com>
 <56CC9DA8.6080504@pld-linux.org>
Message-ID: <72ACB5C7-3536-4556-874D-CE0166AA9073@mac.com>


On Feb 23, 2016, at 12:58 PM, Elan Ruusam?e wrote:

> On 23.02.2016 19:42, Jeff Johnson wrote:
>> On Feb 22, 2016, at 5:23 PM, Elan Ruusam?e wrote:
>> 
>>> sometimes i see such message when building packages:
>>> 
>>> warning: existing POPT configuration file "/usr/lib/rpm/rpmpopt:/usr/lib/rpm/%{_target}/rpmpopt:/etc/rpm/rpmpopt.*:/etc/rpm/rpm
>>> popt:/etc/rpm/%{_target}/rpmpopt:~/.rpmpopt" considered INSECURE -- not loaded
>>> 
>>> not always, i.e building same package i sometimes see this and sometimes do not.
>>> rpm-5.4.15-31.x86_64
>>> 
>>> any ideas what this is about?
>> The intent is/was to have poptSaneFile() check permissions on files being read
>> (non-zero is an error). The mechanism is dependent on adding a leading '@'
>> to a file path.
>> 
>> int poptSaneFile(const char * fn)
>> {
>>     struct stat sb;
>>     uid_t uid = getuid();
>> 
>>     if (stat(fn, &sb) == -1)
>>         return 1;
>>     if ((uid_t)sb.st_uid != uid)
>>         return 0;
>>     if (!S_ISREG(sb.st_mode))
>>         return 0;
>>     if (sb.st_mode & (S_IWGRP|S_IWOTH))
>>         return 0;
>>     return 1;
>> }
>> 
>> There may be other returns (from failure to read a file) in poptReadFile() that may trigger the message.
> 
> so, any of those files should be group or other writable to produce the warning...
> 

Yes but ... the poptSaneFile() mechanism is "opt in", turned on with an '@' prefix on a file path.

> 
> ? for a in $(rpm -E /usr/lib/rpm/rpmpopt:/usr/lib/rpm/%{_target}/rpmpopt:/etc/rpm/rpmpopt.*:/etc/rpm/rpmpopt:/etc/rpm/%{_target}/rpmpopt:~/.rpmpopt|tr ':' ' '); do ls -ld $a; done
> -rw-r--r-- 1 root root 20977 29. nov   14:30 /usr/lib/rpm/rpmpopt
> ls: cannot access '/usr/lib/rpm/x86_64-linux/rpmpopt': No such file or directory
> ls: cannot access '/etc/rpm/rpmpopt.*': No such file or directory
> ls: cannot access '/etc/rpm/rpmpopt': No such file or directory
> ls: cannot access '/etc/rpm/x86_64-linux/rpmpopt': No such file or directory
> ls: cannot access '~/.rpmpopt': No such file or directory
> 
> ?
> 

Not the right test: all files except the first mentioned as config files are permitted to be missing.

Something else is going on if this is recent behavior. All of this code in popt/rpm
was written a long time ago.

The non-reproducibility, and the claim that this is a recently changed behavior, also indicate
that something else is happening.

Are you running in a chroot with files that are being removed?

Is there a signal being sent that is interrupting one of these system calls (in poptReadFile)

    if ((nb = lseek(fdno, 0, SEEK_END)) == (off_t)-1
     || lseek(fdno, 0, SEEK_SET) == (off_t)-1
     || (b = (char*) calloc(sizeof(*b), (size_t)nb + 1)) == NULL
     || read(fdno, (char *)b, (size_t)nb) != (ssize_t)nb)
    {
        int oerrno = errno;
        (void) close(fdno);
        errno = oerrno;
        goto exit;
    }
    if (close(fdno) == -1)
        goto exit;

hth

73 de Jeff



> 
> 
> -- 
> glen
> 
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



From arekm at maven.pl  Tue Feb 23 19:25:36 2016
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Tue, 23 Feb 2016 19:25:36 +0100
Subject: [packages/git-core] noarch packages
In-Reply-To: <6743dd7eda7fdf45a0e70c079ac80440814754e9_refs_heads_master@pld-linux.org>
References: <ad39aec1a27ea283c19a4c450fa18d37ab0a7d28_refs_heads_master@pld-linux.org>
 <6743dd7eda7fdf45a0e70c079ac80440814754e9_refs_heads_master@pld-linux.org>
Message-ID: <201602231925.36427.arekm@maven.pl>

On Tuesday 23 of February 2016, glen wrote:
> commit 6743dd7eda7fdf45a0e70c079ac80440814754e9
> Author: Elan Ruusam?e <glen at delfi.ee>
> Date:   Tue Feb 23 14:34:41 2016 +0200
> 
>     noarch packages
> 
>  git-core.spec | 42 ++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 38 insertions(+), 4 deletions(-)
> ---
> diff --git a/git-core.spec b/git-core.spec
> index ef53117..ad97d6b 100644
> --- a/git-core.spec
> +++ b/git-core.spec
> @@ -14,7 +14,7 @@ Summary:	Distributed version control system focused on
> speed, effectivity and us Summary(pl.UTF-8):	Rozproszony system ?ledzenia
> tre?ci skupiony na szybko?ci, wydajno?ci i u?yteczno?ci Name:		git-core
>  Version:	2.7.1
> -Release:	2
> +Release:	3
>  License:	GPL v2


That breaks git-core-slug


 git pld
git: 'pld' is not a git command. See 'git --help'.

Did you mean this?
        pull


because it doesn't look at lib64/git-core anymore

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


From glen at pld-linux.org  Tue Feb 23 20:21:13 2016
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 23 Feb 2016 21:21:13 +0200
Subject: popt warning
In-Reply-To: <72ACB5C7-3536-4556-874D-CE0166AA9073@mac.com>
References: <56CB8A50.30405@pld-linux.org>
 <EA679464-A214-46E7-8FF7-DBA3B561BA31@mac.com>
 <56CC9DA8.6080504@pld-linux.org>
 <72ACB5C7-3536-4556-874D-CE0166AA9073@mac.com>
Message-ID: <56CCB129.1030602@pld-linux.org>

On 23.02.2016 20:24, Jeff Johnson wrote:
> On Feb 23, 2016, at 12:58 PM, Elan Ruusam?e wrote:
>
>> On 23.02.2016 19:42, Jeff Johnson wrote:
>>> On Feb 22, 2016, at 5:23 PM, Elan Ruusam?e wrote:
>>>
>>>> sometimes i see such message when building packages:
>>>>
>>>> warning: existing POPT configuration file "/usr/lib/rpm/rpmpopt:/usr/lib/rpm/%{_target}/rpmpopt:/etc/rpm/rpmpopt.*:/etc/rpm/rpm
>>>> popt:/etc/rpm/%{_target}/rpmpopt:~/.rpmpopt" considered INSECURE -- not loaded
>>>>
>>>> not always, i.e building same package i sometimes see this and sometimes do not.
>>>> rpm-5.4.15-31.x86_64
>>>>
>>>> any ideas what this is about?
>>> The intent is/was to have poptSaneFile() check permissions on files being read
>>> (non-zero is an error). The mechanism is dependent on adding a leading '@'
>>> to a file path.
>>>
>>> int poptSaneFile(const char * fn)
>>> {
>>>      struct stat sb;
>>>      uid_t uid = getuid();
>>>
>>>      if (stat(fn, &sb) == -1)
>>>          return 1;
>>>      if ((uid_t)sb.st_uid != uid)
>>>          return 0;
>>>      if (!S_ISREG(sb.st_mode))
>>>          return 0;
>>>      if (sb.st_mode & (S_IWGRP|S_IWOTH))
>>>          return 0;
>>>      return 1;
>>> }
>>>
>>> There may be other returns (from failure to read a file) in poptReadFile() that may trigger the message.
>> so, any of those files should be group or other writable to produce the warning...
>>
> Yes but ... the poptSaneFile() mechanism is "opt in", turned on with an '@' prefix on a file path.
>
>> ? for a in $(rpm -E /usr/lib/rpm/rpmpopt:/usr/lib/rpm/%{_target}/rpmpopt:/etc/rpm/rpmpopt.*:/etc/rpm/rpmpopt:/etc/rpm/%{_target}/rpmpopt:~/.rpmpopt|tr ':' ' '); do ls -ld $a; done
>> -rw-r--r-- 1 root root 20977 29. nov   14:30 /usr/lib/rpm/rpmpopt
>> ls: cannot access '/usr/lib/rpm/x86_64-linux/rpmpopt': No such file or directory
>> ls: cannot access '/etc/rpm/rpmpopt.*': No such file or directory
>> ls: cannot access '/etc/rpm/rpmpopt': No such file or directory
>> ls: cannot access '/etc/rpm/x86_64-linux/rpmpopt': No such file or directory
>> ls: cannot access '~/.rpmpopt': No such file or directory
>>
>> ?
>>
> Not the right test: all files except the first mentioned as config files are permitted to be missing.
i just tried to show, that there's only one file (from system), none of 
the "user" files even exist.

> Something else is going on if this is recent behavior. All of this code in popt/rpm
> was written a long time ago.
>
> The non-reproducibility, and the claim that this is a recently changed behavior, also indicate
> that something else is happening.
>
> Are you running in a chroot with files that are being removed?

no. i'm running in vserver as non-root user. it may qualify as chroot, 
but not sure about files being removed part.

>
> Is there a signal being sent that is interrupting one of these system calls (in poptReadFile)

i first noticed it in a code that was invoked from in bash prompt:

rpm --define "_specdir $PWD" --specfile $specfile -q --qf '%{VERSION}\n' 
| head -n1

but later i noticed rpm/rpmbuild (invoked from pld builder script) the 
same message was displayed.


i don't  think anything else happened on system when i ran into this, 
but i can't be sure and it's not happening right now to debug anything 
further.

>      if ((nb = lseek(fdno, 0, SEEK_END)) == (off_t)-1
>       || lseek(fdno, 0, SEEK_SET) == (off_t)-1
>       || (b = (char*) calloc(sizeof(*b), (size_t)nb + 1)) == NULL
>       || read(fdno, (char *)b, (size_t)nb) != (ssize_t)nb)
>      {
>          int oerrno = errno;
>          (void) close(fdno);
>          errno = oerrno;
>          goto exit;
>      }
>      if (close(fdno) == -1)
>          goto exit;



From glen at pld-linux.org  Tue Feb 23 20:28:53 2016
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=)
Date: Tue, 23 Feb 2016 21:28:53 +0200
Subject: [packages/git-core] noarch packages
In-Reply-To: <201602232013.13396.arekm@maven.pl>
References: <ad39aec1a27ea283c19a4c450fa18d37ab0a7d28_refs_heads_master@pld-linux.org>
 <201602231925.36427.arekm@maven.pl> <56CCAD33.7010100@pld-linux.org>
 <201602232013.13396.arekm@maven.pl>
Message-ID: <56CCB2F5.6000000@pld-linux.org>

On 23.02.2016 21:13, Arkadiusz Mi?kiewicz wrote:
> On Tuesday 23 of February 2016, Elan Ruusam?e wrote:
>> >On 23.02.2016 20:25, Arkadiusz Mi?kiewicz wrote:
>> > >
>> > >That breaks git-core-slug
>> > >
>> > >   git pld
>> > >
>> > >git: 'pld' is not a git command. See 'git --help'.
>> > >
>> > >Did you mean this?
>> > >
>> > >          pull
>> > >
>> > >because it doesn't look at lib64/git-core anymore
>> >
>> >how you managed to install it? there's dependency error preventing the
>> >upgrade!
>> >
>> >
>> >  1.
>> >
>> >
>> >
>> >     error:[git-bridgesvn.spec
>> >    
>> ><http://git.pld-linux.org/gitweb.cgi?p=packages/git-bridgesvn.git;f=git-br
>> >idgesvn.spec;h=HEAD;a=shortlog>] git-bridgesvn-0.1-0.20120109.2.x86_64: req
>> >/usr/lib64/git-core not found 2. error:[git-core-slug.spec
>> >    
>> ><http://git.pld-linux.org/gitweb.cgi?p=packages/git-core-slug.git;f=git-co
>> >re-slug.spec;h=HEAD;a=shortlog>] git-core-slug-0.13.4-13.x86_64: req
>> >/usr/lib64/git-core not found
> downgraded and now:

>
> poldek:/all-avail> !rpm -qf /usr/lib64/git-core
> git-core-2.7.1-2.x86_64
> poldek:/all-avail> greedy-upgrade git*
> Processing dependencies...
> git-core-2.7.1-2.x86_64 obsoleted by git-core-2.7.1-3.x86_64
> git-core-svn-2.7.1-2.x86_64 obsoleted by git-core-svn-2.7.1-3.x86_64
> git-core-cvs-2.7.1-2.x86_64 obsoleted by git-core-cvs-2.7.1-3.noarch
> git-core-email-2.7.1-2.x86_64 obsoleted by git-core-email-2.7.1-3.x86_64
> git-core-gitk-2.7.1-2.x86_64 obsoleted by git-core-gitk-2.7.1-3.noarch
> git-core-gui-2.7.1-2.x86_64 obsoleted by git-core-gui-2.7.1-3.noarch
> git-core-2.7.1-3.x86_64 marks perl-Git-2.7.1-3.x86_64 (cap perl-Git = 2.7.1-3)
>   perl-Git-2.7.1-2.x86_64 obsoleted by perl-Git-2.7.1-3.x86_64
> There are 7 packages to install (1 marked by dependencies), 7 to remove:
> I git-core-2.7.1-3.x86_64  git-core-cvs-2.7.1-3.noarch  git-core-
> email-2.7.1-3.x86_64  git-core-gitk-2.7.1-3.noarch  git-core-
> gui-2.7.1-3.noarch
> I git-core-svn-2.7.1-3.x86_64
> D perl-Git-2.7.1-3.x86_64
> R git-core-2.7.1-2.x86_64  git-core-cvs-2.7.1-2.x86_64  git-core-
> email-2.7.1-2.x86_64  git-core-gitk-2.7.1-2.x86_64  git-core-
> gui-2.7.1-2.x86_64
> R git-core-svn-2.7.1-2.x86_64  perl-Git-2.7.1-2.x86_64
> This operation will free 12.2KB of disk space.
> Need to get 4.6MB of archives (4.5MB to download).
>
> Retrieving [1/6] th-test::git-core-2.7.1-3.x86_64.rpm...
> .............................. 100.0% [3.2M (1.0M/s)]
> Retrieving [2/6] th-test::git-core-email-2.7.1-3.x86_64.rpm...
> .............................. 100.0% [462.1K (462.1K/s)]
> Retrieving [3/6] th-test::git-core-svn-2.7.1-3.x86_64.rpm...
> .............................. 100.0% [466.8K (466.8K/s)]
> Retrieving [4/6] th-test::git-core-cvs-2.7.1-3.noarch.rpm...
> .............................. 100.0% [71.2K (71.2K/s)]
> Retrieving [5/6] th-test::git-core-gitk-2.7.1-3.noarch.rpm...
> .............................. 100.0% [129.5K (129.5K/s)]
> Retrieving [6/6] th-test::git-core-gui-2.7.1-3.noarch.rpm...
> .............................. 100.0% [203.4K (203.4K/s)]
> Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps
> 1...
> Preparing...                ########################################### [100%]
>     1:perl-Git               ########################################### [ 14%]
>     2:git-core-svn           ########################################### [ 29%]
>     3:git-core               ########################################### [ 43%]
>     4:git-core-cvs           ########################################### [ 57%]
>     5:git-core-email         ########################################### [ 71%]
>     6:git-core-gitk          ########################################### [ 86%]
>     7:git-core-gui           ########################################### [100%]
> poldek:/all-avail> !rpm -qf /usr/lib64/git-core
> file /usr/lib64/git-core is not owned by any package
> poldek:/all-avail> !rpm -qf /usr/lib64/git-core/git-pld
> git-core-slug-0.13.4-13.x86_64

so, looks like poldek/rpm bug, it should bail out with dir-dep error:

# rpm -q git-core git-core-slug
git-core-2.6.4-1.x86_64
git-core-slug-0.13.4-13.x86_64
# poldek -n th-test --up -u git-core --ignore=git-core-slug -t
Processing dependencies...
git-core-2.6.4-1.x86_64 obsoleted by git-core-2.7.1-3.x86_64
   greedy upgrade git-core-svn-2.6.4-1.x86_64 to 2.7.1-3.x86_64 
(unresolved git-core = 2.6.4-1)
    git-core-svn-2.6.4-1.x86_64 obsoleted by git-core-svn-2.7.1-3.x86_64
   greedy upgrade git-core-cvs-2.6.4-1.x86_64 to 2.7.1-3.noarch 
(unresolved git-core = 2.6.4-1)
    git-core-cvs-2.6.4-1.x86_64 obsoleted by git-core-cvs-2.7.1-3.noarch
   greedy upgrade gnome-keyring-git-core-2.6.4-1.x86_64 to 
2.7.1-3.x86_64 (unresolved git-core = 2.6.4-1)
    gnome-keyring-git-core-2.6.4-1.x86_64 obsoleted by 
gnome-keyring-git-core-2.7.1-3.x86_64
   greedy upgrade bash-completion-git-2.6.4-1.noarch to 2.7.1-3.noarch 
(unresolved git-core = 2.6.4-1)
    bash-completion-git-2.6.4-1.noarch obsoleted by 
bash-completion-git-2.7.1-3.noarch
   greedy upgrade git-core-gitk-2.6.4-1.x86_64 to 2.7.1-3.noarch 
(unresolved git-core = 2.6.4-1)
    git-core-gitk-2.6.4-1.x86_64 obsoleted by git-core-gitk-2.7.1-3.noarch
   greedy upgrade git-core-gitweb-2.6.4-1.x86_64 to 2.7.1-3.noarch 
(unresolved git-core = 2.6.4-1)
    git-core-gitweb-2.6.4-1.x86_64 obsoleted by 
git-core-gitweb-2.7.1-3.noarch
git-core-2.7.1-3.x86_64 marks perl-Git-2.7.1-3.x86_64 (cap perl-Git = 
2.7.1-3)
  perl-Git-2.6.4-1.x86_64 obsoleted by perl-Git-2.7.1-3.x86_64
There are 8 packages to install (7 marked by dependencies), 8 to remove:
I git-core-2.7.1-3.x86_64
D bash-completion-git-2.7.1-3.noarch  git-core-cvs-2.7.1-3.noarch 
git-core-gitk-2.7.1-3.noarch
D git-core-gitweb-2.7.1-3.noarch  git-core-svn-2.7.1-3.x86_64 
gnome-keyring-git-core-2.7.1-3.x86_64
D perl-Git-2.7.1-3.x86_64
R bash-completion-git-2.6.4-1.noarch  git-core-2.6.4-1.x86_64 
git-core-cvs-2.6.4-1.x86_64  git-core-gitk-2.6.4-1.x86_64
R git-core-gitweb-2.6.4-1.x86_64  git-core-svn-2.6.4-1.x86_64 
gnome-keyring-git-core-2.6.4-1.x86_64
R perl-Git-2.6.4-1.x86_64
This operation will use 461.1KB of disk space.
Need to get 4.1MB of archives (4.1MB to download).

perhaps poldek/rpm can't handle arch change and dir change in same 
transaction?

ps: the dir change commit was
https://github.com/pld-linux/git-core/commit/6743dd7eda7fdf45a0e70c079ac80440814754e9

-- 
glen



From n3npq at mac.com  Tue Feb 23 21:03:18 2016
From: n3npq at mac.com (Jeff Johnson)
Date: Tue, 23 Feb 2016 15:03:18 -0500
Subject: popt warning
In-Reply-To: <56CCB129.1030602@pld-linux.org>
References: <56CB8A50.30405@pld-linux.org>
 <EA679464-A214-46E7-8FF7-DBA3B561BA31@mac.com>
 <56CC9DA8.6080504@pld-linux.org>
 <72ACB5C7-3536-4556-874D-CE0166AA9073@mac.com>
 <56CCB129.1030602@pld-linux.org>
Message-ID: <B48FFF98-8CE4-4580-9754-CAF52B9A6097@mac.com>


On Feb 23, 2016, at 2:21 PM, Elan Ruusam?e wrote:

> 
> i first noticed it in a code that was invoked from in bash prompt:
> 
> rpm --define "_specdir $PWD" --specfile $specfile -q --qf '%{VERSION}\n' | head -n1
> 
> but later i noticed rpm/rpmbuild (invoked from pld builder script) the same message was displayed.
> 
> 
> i don't  think anything else happened on system when i ran into this, but i can't be sure and it's not happening right now to debug anything further.
> 

Try running (in a loop if non-reproducible) with strace is about all I can suggest.

The behavior of rpm+popt will be dependent on other coincident system actions.

73 de Jeff



From jajcus at jajcus.net  Thu Feb 25 13:12:31 2016
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Thu, 25 Feb 2016 13:12:31 +0100
Subject: Vulkan 3D drivers test request
Message-ID: <56CEEFAF.5040000@jajcus.net>

Hi,

I have made the Vulkan packages and would like someone to test those on 
a different system and hardware.

To play with Vulkan you need:

1. the Vulkan loader
2. a Vulkan Installable Client Driver (ICD)
3. a Vulkan application


1. the Vulkan loader

It is available in the 'vulkan-loader' package

2. a Vulkan ICD

Currently we have four different Vulkan drivers:

a. Mesa-vulkan-icd-intel

The 'official' Intel Vulkan driver, developed as a part of the Mesa
project, but not yet merged to the main line.

It is supposed to support everything from Ivybridge (HD Graphics 4000) up
to Sky Lake (Iris Pro Graphics 580), but anything below Broadwell is
'unfinished'.

I have tested this one, but little more than 'vulkaninfo' worked for me
on HD Graphics 4600

b. vulkan-sdk-icd-intel

Another driver for Intel GPUs Developed by LunarG, as part of their
Vulkan SDK.

It is supposed to handle Intel Haswell, Ivy Bridge and Sandy Bridge
GPUs.

I have not tested it yet.

Both Intel drivers should work with regular intel xorg and kernel
drivers, but DRI3 must be enabled (support added to our
xorg-driver-video-intel only recently, available in th-test)

c. vulkan-sdk-icd-nulldrv

Dummy Vulkan driver. Does nothing, but can be queried with 'vulkaninfo'
and some Vulkan apps even won't crash with it.a

d. xorg-driver-video-nvidia on the Vulkan branch

Unfortunately this probably requires matching xorg (included) and kernel
driver.

3. Vulkan applications

a. 'vulkaninfo' from vulkan-sdk-tools

Like 'glxinfo' ? queries the Vulkan drivers for available hardware and
features.

b. 'vulkan-cube' and 'vulkan-tri' from vulkan-sdk-demos

Simple demos

c. Various Vulkan examples on GitHub

https://github.com/krh/vkcube
https://github.com/SaschaWillems/Vulkan
https://github.com/SaschaWillems/VulkanCapsViewer

d. serious games ;)

Seriously? there is one (using Serious Engine), which has Vulkan
support, on public beta branch:

http://steamcommunity.com/app/257510/discussions/0/412447613565426479/

Good luck and have fun!

Jacek