samba 4.15.2 symbol version mismatch

[Adam Osuchowski]

Samba 4.15.2-1 from th-test requires SAMBA_4.13.9 symbol


root@pldtest1:~# rpm -q samba
samba-4.15.2-1.x86_64
root@pldtest1:~# smbd
smbd: /usr/lib64/samba/libsamba-security-samba4.so: version `SAMBA_4.13.9' not 
found (required by /usr/lib64/libsmbldap.so.2)
smbd: /usr/lib64/samba/libreplace-samba4.so: version `SAMBA_4.13.9' not found 
(required by /usr/lib64/libsmbldap.so.2)
smbd: /usr/lib64/samba/libsmbd-shim-samba4.so: version `SAMBA_4.13.9' not found 
(required by /usr/lib64/libsmbldap.so.2)
smbd: /usr/lib64/samba/libsamba-debug-samba4.so: version `SAMBA_4.13.9' not 
found (required by /usr/lib64/libsmbldap.so.2)
root@pldtest1:~# winbindd 
winbindd: /usr/lib64/samba/libsamba-security-samba4.so: version `SAMBA_4.13.9' 
not found (required by /usr/lib64/libsmbldap.so.2)
winbindd: /usr/lib64/samba/libreplace-samba4.so: version `SAMBA_4.13.9' not 
found (required by /usr/lib64/libsmbldap.so.2)
winbindd: /usr/lib64/samba/libsmbd-shim-samba4.so: version `SAMBA_4.13.9' not 
found (required by /usr/lib64/libsmbldap.so.2)
winbindd: /usr/lib64/samba/libsamba-debug-samba4.so: version `SAMBA_4.13.9' not 
found (required by /usr/lib64/libsmbldap.so.2)
root@pldtest1:~# objdump -p /usr/lib64/libsmbldap.so.2 | grep -A6 'Version 
References'
Version References:
  required from libsamba-security-samba4.so:
0x07275469 0x00 13 SAMBA_4.13.9
  required from libreplace-samba4.so:
0x07275469 0x00 12 SAMBA_4.13.9
  required from libsmbd-shim-samba4.so:
0x07275469 0x00 11 SAMBA_4.13.9
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

xorg-font-font-adobe-75dpi package potential corruption

[Adam Osuchowski]

There is a problem with xorg-font-font-adobe-75dpi package during install:

root@pldtest:~# ipoldek install xorg-font-font-adobe-75dpi
Loading [pndir]th...
Loading [pndir]th...
30648 packages read
Processing dependencies...
There are 1 package to install:
A xorg-font-font-adobe-75dpi-1.0.3-2.noarch
This operation will use 5.4MB of disk space.
xorg-font-font-adobe-75dpi-1.0.3-2.noarch.rpm: digests OK
Need to get 5.3MB of archives.
xorg-font-font-adobe-75dpi-1.0.3-2.noarch.rpm: digests OK
xorg-font-font-adobe-75dpi-1.0.3-2.noarch.rpm: digests signatures OK
Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 0...
Verifying...  # [100%]
Preparing...  # [100%]
Updating / installing...
   1:xorg-font-font-adobe-75dpi-1.0.3-# [100%]
error: unpacking of archive failed: cpio: Bad magic
error: xorg-font-font-adobe-75dpi-1.0.3-2.noarch: install failed
There were errors

But rpm2cpio and cpio report no errors:

root@pldtest:~# ipoldek get xorg-font-font-adobe-75dpi
Loading [pndir]th...
Loading [pndir]th...
30648 packages read
th::xorg-font-font-adobe-75dpi-1.0.3-2.noarch.rpm [5.3M (5.3M/s)]   

xorg-font-font-adobe-75dpi-1.0.3-2.noarch.rpm: digests OK
root@pldtest:~# rpm2cpio xorg-font-font-adobe-75dpi-1.0.3-2.noarch.rpm | cpio 
-t > /dev/null 
11402 blocks
root@pldtest:~# echo $?
0

Could somebody look at this? Similiar package xorg-font-font-adobe-100dpi
built at the same time causes no problems.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: openssl again makes php5.3 crash

[Adam Osuchowski]

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.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: openssl 1.1.1 rebuild - need for help

[Adam Osuchowski]

Arkadiusz Miśkiewicz wrote:
> openssl 1.1.1 rebuild, if anyone wants to help here is TODO list:
>
> http://ep09.pld-linux.org/~pldth/qa.php?q=main-ready-test
>
> Examples on how to fix things are at packages/*/openssl.patch mostly. Also 
> patches sometimes in debian, archlinux or upstream git of projects.

I think, first of all we should to ensure that openssl 1.0.2 and 1.1.1 are
parallel installable, for instance by make openssl102 package. It would
allow old and new versions of the openssl API available and, thanks to it,
help in quiet migration.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/rc-scripts] - up to 0.4.17

[Adam Osuchowski]

Arkadiusz Miśkiewicz wrote:
> On 04/09/2018 17:33, adwol wrote:
>
>> @@ -260,7 +252,6 @@ done
>> %files
>>   %defattr(644,root,root,755)
>> -%doc ChangeLog
>>   %doc doc/*.txt doc/template.init
>>   %doc sysconfig/interfaces/data/chat-ppp*
>>   %doc sysconfig/interfaces/ifc*
>
> Where did ChangeLog go? make dist should create it (see DEVELOPMENT file at 
> the end)

Fixed. BTW, ChangeLog in 0.4.16 ended at 2015-11-26 09:21:44, 9 commits
before 0.4.16 commit, so it was already outdated in previous version.
Does anyone look at it?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: manual pages file names conflict in openssl 1.1 and heimdal 7.5

[Adam Osuchowski]

Jan Rękorajski wrote:
> That is the right solution in this case.
> I added that prefix for DES_* man pages in heimdal.

Ok, thanks, but this is not DES_* man pages issue only. I put them only
as example. I commited fix for others, too.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

manual pages file names conflict in openssl 1.1 and heimdal 7.5

[Adam Osuchowski]

File names of manual pages for functions in openssl 1.1 conflict with
its equivalents in heimdal 7.5. Example:

file /usr/share/man/man3/DES_cbc_cksum.3 from install of 
openssl-devel-1.1.0h-1.x86_64 conflicts with file from package 
heimdal-devel-7.5.0-2.x86_64
file /usr/share/man/man3/DES_cfb64_encrypt.3 from install of 
openssl-devel-1.1.0h-1.x86_64 conflicts with file from package 
heimdal-devel-7.5.0-2.x86_64
file /usr/share/man/man3/DES_ecb3_encrypt.3 from install of 
openssl-devel-1.1.0h-1.x86_64 conflicts with file from package 
heimdal-devel-7.5.0-2.x86_64
file /usr/share/man/man3/DES_ecb_encrypt.3 from install of 
openssl-devel-1.1.0h-1.x86_64 conflicts with file from package 
heimdal-devel-7.5.0-2.x86_64
file /usr/share/man/man3/DES_ede3_cbc_encrypt.3 from install of 
openssl-devel-1.1.0h-1.x86_64 conflicts with file from package 
heimdal-devel-7.5.0-2.x86_64
file /usr/share/man/man3/DES_is_weak_key.3 from install of 
openssl-devel-1.1.0h-1.x86_64 conflicts with file from package 
heimdal-devel-7.5.0-2.x86_64
file /usr/share/man/man3/DES_key_sched.3 from install of 
openssl-devel-1.1.0h-1.x86_64 conflicts with file from package 
heimdal-devel-7.5.0-2.x86_64
file /usr/share/man/man3/DES_pcbc_encrypt.3 from install of 
openssl-devel-1.1.0h-1.x86_64 conflicts with file from package 
heimdal-devel-7.5.0-2.x86_64
file /usr/share/man/man3/DES_set_key.3 from install of 
openssl-devel-1.1.0h-1.x86_64 conflicts with file from package 
heimdal-devel-7.5.0-2.x86_64
file /usr/share/man/man3/DES_set_key_checked.3 from install of 
openssl-devel-1.1.0h-1.x86_64 conflicts with file from package 
heimdal-devel-7.5.0-2.x86_64

As it turns out, heimdal defines these functions with hc_ prefix and such
symbols exist in heimdal libraries, while names without hc_ prefix are made
through #define:

$ grep '^#define DES_.*_encrypt' /usr/include/hcrypto/des.h 
#define DES_cbc_encrypt hc_DES_cbc_encrypt
#define DES_cfb64_encrypt hc_DES_cfb64_encrypt
#define DES_ecb3_encrypt hc_DES_ecb3_encrypt
#define DES_ecb_encrypt hc_DES_ecb_encrypt
#define DES_ede3_cbc_encrypt hc_DES_ede3_cbc_encrypt
#define DES_encrypt hc_DES_encrypt
#define DES_pcbc_encrypt hc_DES_pcbc_encrypt
$ nm -D /lib64/libhcrypto.so.4 | grep 'DES_.*_encrypt'
00018930 T hc_DES_cbc_encrypt
000194b0 T hc_DES_cfb64_encrypt
00018fd0 T hc_DES_ecb3_encrypt
000188b0 T hc_DES_ecb_encrypt
00019060 T hc_DES_ede3_cbc_encrypt
00018c80 T hc_DES_pcbc_encrypt

What should be done in such a case, to make parallel installation of
openssl-devel-1.1 and heimdal-devel possible? I thought about adding
hc_ prefix to all heimdal man pages file names but maybe someone has
idea for better solution.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/bind] - compact root.hint with root zone NSes only taken from another source; there is no need for such hu

[Adam Osuchowski]

Arkadiusz Miśkiewicz wrote:
> On Monday 23 of July 2018, adwol wrote:
> > commit 065091cf865bc6f8b14417f31729c7a77f641b98
> > Author: Adam Osuchowski 
> > Date:   Mon Jul 23 10:39:28 2018 +0200
> > 
> > - compact root.hint with root zone NSes only taken from another source;
> > there is no need for such huge hint file
> 
> dnssec records are not needed?

No, they aren't. Root KSK keys, which are anchor of chain of trust, are
stored in bind.keys file bundled with bind.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Broken openssl man pages

[Adam Osuchowski]

$ rpm -q openssl-tools
openssl-tools-1.0.2n-1.x86_64
$ man 1 openssl-x509
man: /usr/share/man/man1/openssl-x509.1 is self referencing
No manual entry for openssl-x509 in section 1
$ man openssl-s_client
man: /usr/share/man/man1/openssl-s_client.1 is self referencing
No manual entry for openssl-s_client
$ man openssl-pkcs7
man: /usr/share/man/man1/openssl-pkcs7.1 is self referencing
No manual entry for openssl-pkcs7

___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: 64-bit binaries in /usr/lib

[Adam Osuchowski]

Elan Ruusamäe wrote:
> every package probably has reason, given examples it would be easier to 
> explain.

$ rpm -qf `find {/usr,}/lib -type f -perm -0100 | xargs file | grep 'ELF 64-bit 
LSB executable' | cut -f1 -d:` | sort -u
ConsoleKit-0.4.6-3.x86_64
cups-filters-1.8.3-3.x86_64
git-core-2.10.0-1.x86_64
git-core-svn-2.10.0-1.x86_64
libinput-1.4.1-1.x86_64
nagios-plugin-check_load-2.1.3-1.x86_64
nagios-plugins-2.1.3-1.x86_64
polkit-0.113-3.x86_64
rpm-5.4.15-37.x86_64
rpm-build-5.4.15-37.x86_64
rpm-utils-5.4.15-37.x86_64
sysstat-11.2.0-3.x86_64
udisks-1.0.5-3.x86_64

In particular, git-core kept its binaries in /usr/lib64 formerly but it
was changed to /usr/lib. nagios-common contains both of them:

$ rpm -qf /usr/lib{,64}/nagios/plugins 
nagios-common-4.0.8-5.x86_64
nagios-common-4.0.8-5.x86_64

cups and rpm keep /usr/lib all the time.

> it may be deliberately packaged like this in pld, or just because 
> upstream uses such packaging (and it's not "fixed" in pld)

It is rather PLD issue.

> but the (--libdir) /usr/lib vs /usr/lib64 (and /usr/libx32) are for 
> libraries (libfoo.so.1), so you could parallel install libfoo.so.1(ix84) 
> and libfoo.so.1(x86-64).

That is, shared libraries on x86-64 arch should be placed in {/usr,}/lib64
and binaries (not intended to run directly by user), scripts and other 
private package files in {/usr,}/lib. Do I understand it correctly?

> there's also --libexecdir which is %{_libdir} in pld, but 
> %{_prefix}/libexec in other distros, and that path is used to provide 
> private binaries for application (not intended to be used from $PATH), that 
> is the most common case how binaries end up in /usr/lib* trees.
>
> i personally also think --libexecdir should be %{_prefix}/libexec. it would 
> make configurations simpler, don't need to patch for %{_libdir} everywhere.

I know but now it is totally removed and no package use it:

# ipoldek 'search -f /usr/libexec/*'
Loading [pndir]th...
Loading [pndir]th...
26078 packages read
Loading [rpmdbcache]/var/lib/rpm...
3352 packages loaded
Searching packages..done.
No package matches '/usr/libexec/*'

Besides, FSB admits of using /usr/lib insted of /usr/libexec.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

64-bit binaries in /usr/lib

[Adam Osuchowski]

Simple question: why have some packages their arch-dependent executables
placed in /usr/lib directory on x86-64 architecture? What principle
determines that these binaries are forced to be in /usr/lib instead of
/usr/lib64?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/GeoIP-db-IPASNum] updated to 2016.06.06

[Adam Osuchowski]

glen wrote:
> commit dbd877a6d696b54bd4ba3feb7a7c62034235792d
> Author: Elan Ruusamäe 
> Date:   Wed Jun 8 01:04:09 2016 +0300
> 
> updated to 2016.06.06
> 
>  GeoIP-db-IPASNum.spec | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> ---
> diff --git a/GeoIP-db-IPASNum.spec b/GeoIP-db-IPASNum.spec
> index e6b2ec6..047716a 100644
> --- a/GeoIP-db-IPASNum.spec
> +++ b/GeoIP-db-IPASNum.spec
> @@ -2,12 +2,12 @@ Summary:GeoLite IPASNum - IP to AS number translation 
> database for GeoIP
>  Summary(pl.UTF-8):   GeoLite IPASNum - baza danych tłumaczeń adresów IP na 
> numery AS dla GeoIP
>  Name:GeoIP-db-IPASNum
>  # Updated every month:
> -Version: 2016.06.07
> +Version: 2016.06.06
>  Release: 1
>  License: CC 3.0 BY-SA
>  Group:   Applications/Databases
>  Source0: 
> http://download.maxmind.com/download/geoip/database/asnum/GeoIPASNum.dat.gz?/GeoIPASNum-%{version}.dat.gz
> -# Source0-md5:   0a384c96479df8616116da9f12bcd471
> +# Source0-md5:   2c31a48670d00dde926587ec0ccff964

Could you explain where did you get this source from and why did you
commit older version?


builder@pld:~/rpm/packages$ builder -g -nd GeoIP-db-IPASNum
Cloning into 'GeoIP-db-IPASNum'...
remote: Counting objects: 379, done.
remote: Compressing objects: 100% (237/237), done.
remote: Total 379 (delta 139), reused 53 (delta 32)
Receiving objects: 100% (379/379), 40.21 KiB | 0 bytes/s, done.
Resolving deltas: 100% (139/139), done.
Checking connectivity... done.
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.
>From git://git.pld-linux.org/packages/GeoIP-db-IPASNum
 * [new ref] refs/notes/commits -> refs/notes/commits
MD5 sum mismatch. Use -U to refetch sources,
or -5 to update md5 sums, if you're sure files are correct.
Error: some source, patch or icon files not stored in PLD repo. 
(http://download.maxmind.com/download/geoip/database/asnum/GeoIPASNum.dat.gz?/GeoIPASNum-2016.06.06.dat.gz)
builder@pld:~/rpm/packages/GeoIP-db-IPASNum$ md5sum GeoIPASNum-2016.06.06.dat.gz
0a384c96479df8616116da9f12bcd471  GeoIPASNum-2016.06.06.dat.gz
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

ruby-mail conflicts

[Adam Osuchowski]

poldek:/all-avail> freshen ruby-mail
Processing dependencies...
ruby-mail-2.5.4-3.noarch obsoleted by ruby-mail-2.6.4-1.noarch
error: ruby-mail-2.6.4-1.noarch (cap ruby-mail = 2.6.4-1) conflicts with 
installed ruby-rails-3.2.19-3.noarch (ruby-mail >= 2.6)
There are 1 package to install, 1 to remove:
I ruby-mail-2.6.4-1.noarch
R ruby-mail-2.5.4-3.noarch
This operation will use 809.7KB of disk space.
Need to get 226.0KB of archives (226.0KB to download).

error: 1 conflicts
There were errors


Is ruby-mail package obsoleted by ruby-rails? If so, why didn't old
version be removed?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

kwin crashes when calibre is spawned

[Adam Osuchowski]

Under KDE4 on x86-64, when calibre is started, kwin crashes:


Program received signal SIGSEGV, Segmentation fault.
XVisualIDFromVisual (visual=0x0) at Misc.c:60
60  return visual->visualid;
(gdb) bt
#0  XVisualIDFromVisual (visual=0x0) at Misc.c:60
#1  0x7faa274daca3 in KWin::Client::embedClient (this=this@entry=0x157aa40, 
w=w@entry=31457284, attr=...) at 
/usr/src/debug/kde-workspace-4.11.22/kwin/manage.cpp:647
#2  0x7faa274db7c5 in KWin::Client::manage (this=this@entry=0x157aa40, 
w=w@entry=31457284, isMapped=isMapped@entry=false) at 
/usr/src/debug/kde-workspace-4.11.22/kwin/manage.cpp:67
#3  0x7faa27499f0d in KWin::Workspace::createClient 
(this=this@entry=0x14c8070, w=31457284, is_mapped=is_mapped@entry=false) at 
/usr/src/debug/kde-workspace-4.11.22/kwin/workspace.cpp:475
#4  0x7faa274cc847 in KWin::Workspace::workspaceEvent (this=0x14c8070, 
e=e@entry=0x7fffd01df0f0) at 
/usr/src/debug/kde-workspace-4.11.22/kwin/events.cpp:229
#5  0x7faa274bfbb0 in KWin::Application::x11EventFilter 
(this=0x7fffd01df4d0, e=0x7fffd01df0f0) at 
/usr/src/debug/kde-workspace-4.11.22/kwin/main.cpp:422
#6  0x7faa20627fa6 in ?? () from /usr/lib64/libQtGui.so.4
#7  0x7faa206387a2 in QApplication::x11ProcessEvent(_XEvent*) () from 
/usr/lib64/libQtGui.so.4
#8  0x7faa20662a57 in ?? () from /usr/lib64/libQtGui.so.4
#9  0x7faa21486ce1 in 
QEventLoop::processEvents(QFlags) () from 
/usr/lib64/libQtCore.so.4
#10 0x7faa21487055 in 
QEventLoop::exec(QFlags) () from 
/usr/lib64/libQtCore.so.4
#11 0x7faa2148ca1d in QCoreApplication::exec() () from 
/usr/lib64/libQtCore.so.4
#12 0x7faa274c096f in kdemain (argc=3, argv=0x7fffd01df628) at 
/usr/src/debug/kde-workspace-4.11.22/kwin/main.cpp:597
#13 0x7faa270bf800 in __libc_start_main () from /lib64/libc.so.6
#14 0x004007a9 in _start () at ../sysdeps/x86_64/start.S:118


The issue is recurrent every time. Could anybody confirm it? Is it
common PLD problem or is it connected with my environment?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: openssl, SSL2, KDE

[Adam Osuchowski]

Elan Ruusamäe wrote:
> i don't know, doesn't that make openssl version vulnerable to DROWN attack?

If I understood security advisory correctly 
(http://openssl.org/news/secadv/20160301.txt),
there should be no problems with 1.0.2g unless client/server uses SSLv2
or SSLv2 ciphersuites (that are deprecated, anyway).

> should we now build with sslv2 version enabled again? (it will be so after 
> your 2a82d451c777176ff64a6ba685f6daa046967f07)
> or disable the bcond as most of the tree soon rebuilt without sslv2 symbols?

I personally need SSLv2/SSLv3 support mainly for testing purposes.
I don't use SSLv2/SSLv3 in production environments but there are real
needs to own SSLv2/SSLv3 client/server and use it from time to time.

Alternative solution is to produce separate openssl package
(e.g. openssl-ssl23) with other filenames and sonames. Maybe it is
feasible, easily.

On the other hand, if client/server has disabled depracated SSL versions
explicity, everything should be ok (until next openssl bug...).
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: consolekit

[Adam Osuchowski]

Elan Ruusamäe wrote:
> i would remove that hack, but i don't have anything to test with. don't 
> know why you couldn't just provide .so.1 for legacy package, as new one 
> uses .so.3 anyway and can be parallel installed?

Ok, I fiexd upower-pm-utils to allow coexistence of upower-libs and
upower-pm-utils-libs. It is probably clean, now.

There is one issue left: /usr/lib*/girepository-1.0/UPowerGlib-1.0.typelib
file. I have no idea if this file is wanted and in what package it should
be placed.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: consolekit

[Adam Osuchowski]

Elan Ruusamäe wrote:
> after polkit problem gets solved, i was struggling to with upower package 
> should i use:
>
> upower-libs-0.99.3-2 or upower-pm-utils-libs-0.9.23-1

I fork upower-pm-utils package from upower over a year ago because of
problems with suspending/hibernating. Dbus methods Suspend(), Hibernate(),
CanSuspend() and CanHibernate() have been removed, so
org.freedesktop.PowerManagement dbus service, which use them, stops working.
The last version of upower which works well with non-systemd environments
is 0.9.23.

> btw, upower-pm-utils-libs-0.9.23-1 fakes .so.3 symlink, but i don't get why
> it kind of breaks things deliberately. i even saw some symbol error from 
> mate-power-manager tool (don't have log right now)
>
> so... why?

I don't remember why. It was made a year ago. I don't insist that this
symlink has to stay. If you consider it needless and will be working as
before, remove it.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: consolekit

[Adam Osuchowski]

Elan Ruusamäe wrote:
> Nov  2 20:05:20 rotten-fruit console-kit-daemon[5590]: WARNING: Couldn't 
> read /proc/24047936/environ: Failed to open file '/proc/24047936/environ': 
> No such file or directory
>
> anyone seeing this with non-systemd desktop?
> i'm using lightdm for xinit manager

Yes, I've seen something similar few weeks ago. Check if last polkit
commit (0.113-2, git only, not in repo) with my patch, helps.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/ntp] - fix compile error

[Adam Osuchowski]

Elan Ruusamäe wrote:
 such stdlib changes can be actually written with puts:

 puts(Unity.XFAILMessage);
 or sometimes:
 fputs(Unity.XFAILMessage, stderr);

As you wish...
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/ntp] - fix compile error

[Adam Osuchowski]

Jakub Bogusz wrote:
 puts adds newline, so puts(str) is equivalent of printf(%s\n, str),
 but printf(str).
 
 You can replace printf(str) with fputs(str, stdout).
 (fputs doesn't add newline)

Everybody will be satisfied with fputs() or there is antoher proposal?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/sqlite3] drop pointless year macro

[Adam Osuchowski]

glen wrote:
 commit 9ff1c54dc27e48a465cfd09860bd031e6923c26a
 Author: Elan Ruusamäe g...@delfi.ee
 Date:   Thu Feb 26 22:08:01 2015 +0200
 
 drop pointless year macro
 
  sqlite3.spec | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)
 ---
 diff --git a/sqlite3.spec b/sqlite3.spec
 index 0e3842c..63fe775 100644
 --- a/sqlite3.spec
 +++ b/sqlite3.spec
 @@ -20,12 +20,9 @@
  %undefinewith_tests
  %endif
  
 -%define  version_year2015
  #define  version_num %(echo %{version} |  awk -F. 
 '{printf(%d%02d%02d%02d, $1, $2, $3, $4)}')
  %define  version_num 3080803
 -%define  _ulibdir/usr/lib
  %define  tclver  8.6


No, it isn't pointless! The values of url and other tags should be universal
as much as possible. In case of version updating, the year in url may change
and nobody wants to wonder if any part of any tag should be updated in
connection with it. Macros is designed for such cases and clearly points
what should to pay attention to.

If %version_year is pointless, the %version_num is pointless too and should
be removed alike. Please keep coherent.

Think logically about changes you apply before you do it and don't
determine and change anything basing on your private judgements and point
of view only. Your are not the one-man oracle! Once again, your behaviour,
manners and collaborative skills leave a lot to be desired.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/grep] - move from GREP_OPTIONS environmental variable to alias due to its obsolescence

[Adam Osuchowski]

Jacek Konieczny wrote:
 Such a shell script for any interactive shell started, just because one
 or two PLD users have uncommented the /etc/env.d/GREP_OPTIONS we might
 have wrongly introduced long time ago?

There are no difference between putting grep's options into alias and
into $GREP_OPTIONS since grep automatically interprets this variable.
They both have same security and other impacts. If grep developers hadn't
decided to obsolete support for this variable, it would remain in PLD's
/etc/env.d for long time without anybody care.

 I don't think it is worth it.

Surely, nothing is worth for someone who doesn't use it...

 Keeping backward compatibility for any strange feature we might have
 once thought it was a good idea would only make more and more mess in
 our distribution. I would say: let's break compatibility whenever we can
 get things simpler/safer/more functional this way and the compatibility
 cost is not too big. If the system won't boot because of the change,
 then it might be a good idea to introduce backward-compatibility hack.
 This is not such a case.

Ok, so why there are still other aliases defined in /etc/shrc.d? For example:

$ grep alias /etc/shrc.d/*.sh
[...]
/etc/shrc.d/colorls.sh:alias ls=ls --color=$COLOR_MODE
/etc/shrc.d/pinfo.sh:   alias info=pinfo
/etc/shrc.d/pinfo.sh:   alias man=pinfo -m
/etc/shrc.d/which.sh:alias which='alias | /usr/bin/which --tty-only 
--read-alias --show-dot --show-tilde'
[...]

They also make more mess, they also get things more complicated and less
secure and they also could be the cause of quarrel. Why such ls is good
and grep is bad? Let's break compatibility and remove them all. These,
who want to use them, will define them in their own shell configs.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/grep] - move from GREP_OPTIONS environmental variable to alias due to its obsolescence

[Adam Osuchowski]

Elan Ruusamäe wrote:
 a reference to such obsolescence ?

Did you try to run grep 2.21 with GREP_OPTIONS set even once?
Please try it and search sources for message you will see,
before asking such a question.

 this definately is not the same thing as it was before! restore previous 
 behaviour by *not* enforcing such options!

Any evidences, examples? It is very close to GREP_OPTIONS. The alternative
is to patch sources and disable this warning, but it is not good way
to solve this issue. Please stop yelling and suggest better solution.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Recommended Ciphersuite

[Adam Osuchowski]

Jan Rękorajski wrote:
 Our current ciphers list is:
 
 ALL:!ADH:!EXP:!LOW:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
 
 instead of putting there random list of ciphers we can achieve the same
 effect just by disabling the weak ones, like this:
 
 ALL:!ADH:!EXPORT!LOW:!SSLv2:!DES:!3DES:!aNULL:!eNULL:!MD5:!PSK:!SEED:+HIGH:+MEDIUM
 
 Looks better IMO.

Maybe looks better but that Mozilla ciphersuites list fixes specific order
of prioritization. Better ciphers (in their opinion) are scored higher
(e.g. AES128 is preferred to AES256), whereas your general ciphers
specification string fixes only set of ciphers and leaves detailed
ordering decision to SSL/TLS software (mainly openssl library).

Try to diff outputs of `openssl ciphers -v' for Mozilla developed string
and this general one. Order will be definitely different. So, they are
not identical, what does not mean that any of them is better at all.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm5 package verification and md5sum of config files

[Adam Osuchowski]

Jan Rękorajski wrote:
 Quick question, does passing '--nohmacs' option give the same effect as
 your patch to lib/verify.c? In that case we could just make it default
 and add '--hmacs' option.

No. --nohmacs option disables checking hmac entirely even for truly
modified files (with hmac verify flag set). For example, I have modified
my /etc/bashrc file:

# rpm -q --qf '[%{filemd5s}  %{filenames}\n]' bash | grep /etc/bashrc ; md5sum 
/etc/bashrc
95bd580c005792a58362fec41c14615a  /etc/bashrc
82e47e6fbf2fa5b0d9401e8b989ffb72  /etc/bashrc

so `rpm -V' should show this file was modified (and this file only), but:

# rpm -V bash
..5.  c /etc/bashrc
..5.  c /etc/skel/.bash_logout
..5.  c /etc/skel/.bash_profile
..5.  c /etc/skel/.bashrc
# rpm -V --nohmacs bash
#
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm5 package verification and md5sum of config files

[Adam Osuchowski]

Jan Rękorajski wrote:
 I'm afraid your patch doesn't work for me, I'm still getting bad md5
 for config files:
 
 $ rpm -V wget
 ..5.  c /etc/wgetrc
 
 Am I missing something?

Ok, I made investigation one more time and probably know what happened.

The patch I sent is against build/files.c file which is part of rpmbuild
and fixes the problem by changing verify flags (placed in package file)
during package building. Only fresh built (by fixed rpmbuild) package
would be verified correctly even on buggy rpm. I forgot to tell about it
because I tested various scenarios and they all mixed up.

So, once again: patch for build/files.c fixes package building process
only and would work if all packages in repo were been rebuilt (I don't
think RM will accede to this).

In attachment, there is another patch, just for verification process.
It disables use of hmac during digest calculation entirely. Since in
rpm package files there are included plain md5sums, hmac support is
useless. I personally don't know what advantages does hmac digest have
over plain digest in case of files integrity verification against package
database (especially as the hmac key is constant and hardcoded in rpm
sources).

So, to sum up: there are two ways to fix problem of reporting false
md5sum differences during packages verification:
* first, fix the building process and remain with hmac digests, but *ALL*
  packages in repo should be rebuilt,
* second, fix the verification process only, drop hmac support and do it
  the good old way.

IMHO, first method is more elegant but is more difficult and it's not
worth it.
--- rpm-5.4.10.orig/lib/verify.c2012-07-06 17:39:16.0 +0200
+++ rpm-5.4.10/lib/verify.c 2012-10-21 19:35:08.610708732 +0200
@@ -261,11 +261,7 @@
unsigned char * fdigest = (unsigned char *)
memset(alloca(vf-dlen), 0, vf-dlen);
size_t fsize = 0;
-#define_mask   (RPMVERIFY_FDIGEST|RPMVERIFY_HMAC)
-   unsigned dflags = (vf-vflags  _mask) == RPMVERIFY_HMAC
-   ? 0x2 : 0x0;
-#undef _mask
-   int rc = dodigest(vf-dalgo, vf-fn, fdigest, dflags, fsize);
+   int rc = dodigest(vf-dalgo, vf-fn, fdigest, 0, fsize);
sb.st_size = fsize;
if (rc) {
VF_SET(res, READFAIL);
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm5 package verification and md5sum of config files

[Adam Osuchowski]

Jan Rękorajski wrote:
 Adam, which bug is fixed by your 1-liner?

The original one: rpm shows bad md5 digest of files marked as
`%verify(no md5)' (config files) although they are not modified.

Second case (--nomd5 shows that all files are modified) was only
a proof that there may be a general bug in rpm5 verification, so
probably it is needed to neatly recheck the source code.

FYI, I don't claim that my 1-liner is the best solution for first case.
I only find it helps. Maybe there is more suitable one.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm5 package verification and md5sum of config files

[Adam Osuchowski]

Jan Rękorajski wrote:
 I'm afraid your patch doesn't work for me, I'm still getting bad md5
 for config files:
 
 $ rpm -V wget
 ..5.  c /etc/wgetrc
 
 Am I missing something?

Hmmm, I don't know. Maybe I changed something else during debugging and
forgot about it. Give me some time, I will check it once again.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm5 package verification and md5sum of config files

[Adam Osuchowski]

Jeffrey Johnson wrote:
 FYI: the --nomd5 option changed to --nofdigests like 4-5y ago.
 If there is still legacy compatibility for --nomd5, then its time
 to rip it out imho: I see no reason to maintain myriad
 confusing alternative invocations for changes made years ago.

What's the difference... With --nofdigests bahaviour is the same.

 What are you showing me?

I'm showing you invalid output of rpm. Tell me sincerely, is it normal
that rpm with option --nomd5/--nofdigests shows that ALL files in
package are modified even though they aren't?

 I can't tell what rpm version, and
 I have no comparison to be able to tell what you consider
 a bug from the above display. I have no idea what/how
 rpm is patched in PLD, assuming that is the OS being used.

I wrote version I checked in my first mail, but I can repeat:
rpm-5.4.10-18 from PLD distro (I report it on pld-devel mailing list,
so it should be obvious). Anyway, it doesn't matter because vanilla
rpm5 behaves in the same way.

 I also cannot tell what the output SHOULD look like
 without knowing more details.

Run rpm4 and you can see it yourself. Hint: there should be empty
output, because no files were modified, so `rpm -V' should print
nothing.

BTW, why there is no information in documentation about --nohmacs
option which tell rpm to not show this faked information?

 You are entirely entitled to hold whatever point of view and
 opinion you wish.

Should I understand you think that situation I report is quite normal
and rpm5 will always show that md5 digest of file is changed even if
content is not modified? Interesting...

 But if you are seriously interested in a change in RPM, then post
 a bug (launchpad/rpm preferred) with sufficient information to analyze,
 not just POV/opinion.

I don't have time and don't feel like creating launchpad account, so
I report here.

The problem is: rpm5 keeps md5 digests of files in its database, but
when veryfing files marked in specfile like this (in PLD most of config
files have this mark):

%verify(not md5)

it compares these md5 digests with hmac-md5 of current files on disk
what of course leads to differences (rpmvfVerify() in lib/verify.c:265).
Changing this to:

%verify(not hmac)

helps, but I think it is not good solution. Rather, there should be
consistency in digest types (plain vs. hmac): since md5 digests are
stored in database, -V should check md5 not hmac-md5. So, I propose
change like in my mail attachment (btw, I really don't have any idea
what this line is for).

Make what do you want with this knowledge. I only would like rpm5 works
not worse than rpm4 and I hope you now understand where the problem lies.
--- rpm-5.4.10.orig/build/files.c   2012-10-15 23:29:13.601832730 +0200
+++ rpm-5.4.10/build/files.c2012-10-15 23:29:50.264308164 +0200
@@ -393,7 +393,6 @@
if (strcmp(p, vfa-attribute))
/*@innercontinue@*/ continue;
verifyFlags |= vfa-flag;
-   verifyFlags = ~RPMVERIFY_FDIGEST;
/*@innerbreak@*/ break;
}
if (vfa-attribute)
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

rpm5 package verification and md5sum of config files

[Adam Osuchowski]

Package verification by rpm-5.4.10-18 always shows config files as modified
(md5sum changed) even though they are not modified.

For example:

root@pld:~# rpm -q --qf '[%{filemd5s}  %{filenames}\n]' systemd-units | grep 
/etc/systemd/system-preset/default.preset ; md5sum 
/etc/systemd/system-preset/default.preset
e6e4f6387a5dd8161fcb48c51ce85197  /etc/systemd/system-preset/default.preset
e6e4f6387a5dd8161fcb48c51ce85197  /etc/systemd/system-preset/default.preset
root@pld:~# rpm -V systemd-units
..5.  c /etc/systemd/system-preset/default.preset
root@pld:~# rpm -q --qf '[%{filemd5s}  %{filenames}\n]' wget | grep /etc/wgetrc 
; md5sum /etc/wgetrc
0dbf720f5c9d29cbad8356f758a6a889  /etc/wgetrc
0dbf720f5c9d29cbad8356f758a6a889  /etc/wgetrc
root@pld:~# rpm -V wget
..5.  c /etc/wgetrc

It occurs probably for every package with configuration file(s).

BTW, is there any argument for rpm5 to not show changes of configuration
files during -V verification like with rpm4?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm5 package verification and md5sum of config files

[Adam Osuchowski]

Jeffrey Johnson wrote:
 The comparison is against the file on disk (and includes check of mtime)
   md5sum /etc/wgetrc
 (or whatever digest you are using: the '5' is mostly hysterical these days)

Ok, I know that comparison is against the file on disk but that's what
it's all about. Why rpm -V shows differences in files md5 sums (no matter
how hysterical md5 is, it is better than nothing) since these md5 sums in
rpm database are exactly the same as md5 sums of files on disk? Even if I
specify --nomd5 option, rpm tells that all files has changed md5 sums:

root@pld:~# rpm -V --nomd5 wget
..5.  c /etc/wgetrc
..5.  d /usr/share/doc/wget-1.14/NEWS.gz
..5./usr/share/locale/hr/LC_MESSAGES/wget.mo
..5./usr/share/locale/nl/LC_MESSAGES/wget.mo
..5./usr/bin/rmold
..5.  d /usr/share/doc/wget-1.14/README.gz
..5./usr/share/locale/cs/LC_MESSAGES/wget.mo
[...]

From my point of view it is a bug. rpm4 behaviour is more logical in
this situation.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en