Re: migrating pld /var/run to /run (and related dirs)

[Jacek Konieczny]

On 2/8/20 6:52 PM, Tomasz Pala wrote:
> On Thu, Feb 06, 2020 at 19:20:26 +0100, Arkadiusz Miśkiewicz wrote:
> 
>> We need to finally do this while still keeping sysvinit compatibility
>> (using symlinks).
> 
> Why do we need to do this? Legacy SysVinit uses /var/run and works,
> while systemd systems are already handled well (tmpfiles etc.) in /run.

New systemd won't even boot properly when /run is a symlink. And many
system components rely on /run and /var/run contents to be the same,
especially when they are supposed to run on SysVinit and systemd systems
with the same default config.

> In other words: what problem are you going to solve and in which
> scenarios? IMHO the /etc/init.d/ scripts should be kept as they are.

That is why the /var/run -> /run symlink should be provided.

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

Re: firefox and builders...

[Jacek Konieczny]

On 03/06/2019 07.25, Jan Rękorajski wrote>
> I don't believe it's nodejs problem, I think it's builder
> security/networking problem.
But the security/networking restrictions are there for a reason. If we
allow build process to download anything it wants, then we could skip
shipping source packages at all.

Yes it sucks in today's world, especially when trying to build something
like Node or Java crap. Proper source packages are harder and harder to
find, even for C code (e.g. when code is available only on github and
includes submodules)…

Maybe we should rethink our policy…, but just removing the restrictions
because one package stopped to build doesn't seem a right way to do it.

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

git push: No space left on device

[Jacek Konieczny]

Hi,

Our repository seems to be misbehaving:

remote: fatal: write failure on standard output: No space left on device
remote: error: unable to write file GxPlugins.lv2.spec
remote: Emitting a message to the fedmsg bus.
remote: * Publishing information for 1 commits
remote: exim: insufficient disk space
remote: Error in hook  hooks/post-receive.python.d/slug_hook.py
remote: [Errno 28] No space left on device

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

Re: [packages/nginx] - rel 3; provide /etc/nginx/snippets dir for custom config chunks that are not included anywhere by

[Jacek Konieczny]

On 11/03/2019 23.24, Elan Ruusamäe wrote:
> why not /etc/nginx/conf.avail like rest of the debian/ubuntu world lives?

/etc/nginx/snippets is exactly how Debian does that.


# dpkg -S /etc/nginx/snippets ; echo ; grep NAME /etc/os-release
nginx-common: /etc/nginx/snippets

PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"

Jacek

> 
> 
> On 11/03/2019 16:50, arekm wrote:
>>
>> commit 924400caa957d83ab7d2899775b761d54567c86d
>> Author: Arkadiusz Miśkiewicz 
>> Date:   Mon Mar 11 15:50:38 2019 +0100
>>
>>  - rel 3; provide /etc/nginx/snippets dir for custom config chunks
>> that are not included anywhere by default (but can be included by admin)
>>
>>   nginx.spec | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>> ---
>> diff --git a/nginx.spec b/nginx.spec
>> index 8c7ddd4..e878939 100644
>> --- a/nginx.spec
>> +++ b/nginx.spec
>> @@ -44,7 +44,7 @@ Summary(pl.UTF-8):    Serwer HTTP i odwrotne proxy o
>> wysokiej wydajności
>>   # - mainline: production quality but API can change
>>   Name:    nginx
>>   Version:    1.15.9
>> -Release:    2
>> +Release:    3
>>   License:    BSD-like
>>   Group:    Networking/Daemons/HTTP
>>   Source0:    http://nginx.org/download/%{name}-%{version}.tar.gz
>> @@ -351,6 +351,7 @@ install -d $RPM_BUILD_ROOT/etc/rc.d/init.d \
>>   $RPM_BUILD_ROOT%{_localstatedir}/cache/%{name} \
>>   $RPM_BUILD_ROOT%{_localstatedir}/lock/subsys/%{name} \
>>  
>> $RPM_BUILD_ROOT{%{_sbindir},%{_sysconfdir}/{conf,modules,vhosts,webapps}.d}
>> \
>> +    $RPM_BUILD_ROOT%{_sysconfdir}/snippets \
>>   $RPM_BUILD_ROOT/etc/{logrotate.d,monit} \
>>   $RPM_BUILD_ROOT{%{systemdunitdir},/etc/systemd/system}
>>   @@ -456,6 +457,7 @@ fi
>>   %dir %attr(750,root,nginx) %{_sysconfdir}
>>   %dir %{_sysconfdir}/conf.d
>>   %dir %{_sysconfdir}/modules.d
>> +%dir %{_sysconfdir}/snippets
>>   %dir %{_sysconfdir}/vhosts.d
>>   %dir %{_sysconfdir}/webapps.d
>>   %attr(640,root,root) %{_sysconfdir}/mime.types
>> 
>>
>>  gitweb:
>>
>> http://git.pld-linux.org/gitweb.cgi/packages/nginx.git/commitdiff/924400caa957d83ab7d2899775b761d54567c86d
>>
>>
>> ___
>> pld-cvs-commit mailing list
>> pld-cvs-com...@lists.pld-linux.org
>> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

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

Re: Can we finally switch to systemd /run directory? /var/run sucks…

[Jacek Konieczny]

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

Re: Can we finally switch to systemd /run directory? /var/run sucks…

[Jacek Konieczny]

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

Can we finally switch to systemd /run directory? /var/run sucks…

[Jacek Konieczny]

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

Re: python3 only packages

[Jacek Konieczny]

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

Re: [packages/postgrey] - migrate configuration to /etc/postfix

[Jacek Konieczny]

On 25/01/2019 19.13, Arkadiusz Miśkiewicz wrote:
> On 25/01/2019 18:54, hawk wrote:
>> commit d545a6c3390ab2ebc284896499594a8d46ec94a1
>> Author: Marcin Krol 
>> Date:   Fri Jan 25 18:53:51 2019 +0100
>>
>> - migrate configuration to /etc/postfix
> 
> /etc/mail was a bad idea, so such migration in all MTAs and tools is
> welcome :)

yes! :-)


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

PLD New Rescue Th-2018 1.6

[Jacek Konieczny]

Hi,

I have just made the new release of PLD New Rescue boot disk image. It
is based on the latest Th snapshot and includes a few improvements since
the last PLD NR release, though nothing major.

https://github.com/Jajcus/pld-new-rescue/releases/tag/th2018-1.6

Please let me know if it works for you on various systems and use cases,
I did only some basic testing.

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

Re: Mesa 18.3.0, Meson, LLVM, RTTI and OpenCL

[Jacek Konieczny]

On 12/12/2018 16.06, Jakub Bogusz wrote:
> 
> THEY just changed the way of enabling rtti (from make variable to cmake
> define).
> As we had rtti in previous versions of llvm and it's needed by other
> packages (i.e. Mesa/pipe-*), IMO we should just keep it enabled (and
> rebuild packages already built with rtti-less llvm 7, if necessary).

I can see you have already fixed the spec, but how do we build it now?
It seems the builders currently cannot handle it.

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

Mesa 18.3.0, Meson, LLVM, RTTI and OpenCL

[Jacek Konieczny]

Hi,

I am preparing package for Mesa 18.3.0, switching the build system to
Meson, as autoconf/automake is deprecated.

I made it build, but without OpenCL. The problem is the Clover part of
Mesa requires RTTI to build (uses dynamic_cast) and Mesa is build
-fno-rtti when compiled with LLVM built without RTTI.

LLVM builds without RTTI by default, but it should be possible to build
it with RTTI, using 'REQUIRES_RTTI=1', which we have in our llvm.spec.
It doesn't seem to work, though:

[jajcus@jajo ~]$ llvm-config --has-rtti
NO
[jajcus@jajo ~]$ rpm -qf `which llvm-config`
llvm-devel-7.0.0-1.x86_64

Should we fix it? It is disabled in LLVM for a reason, but it seems Mesa
expects it rather enabled. Also, changing the setting now will change
the ABI, which will force us to recompile everything compiled with
current LLVM. And I am not sure how to fix it, anyway.


Other than that, I would be glad if someone would try the new Mesa, to
see if the build works for anything other than Intel GPU. Especially the
Gallium drivers.

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

Re: glibc and ldconfig dependency loop

[Jacek Konieczny]

On 2018-10-01 16:42, glen wrote:
> On 10/1/18 11:36 AM, Jacek Konieczny wrote:

>> Possible solutions:
>> – disable autogenerated dependency for ldconfig, to force installing it
>> before glibc
>> – include ldconfig in the main glibc package
>> – change glibc %post so it won't fail on ldconfig error. The easiest
>> one, will fix the glibc installation failure, but won't break the
>> dependency loop.
>>
>> Any better ideas?
> 
> make ldconfig package skip rtld(GNU_HASH) dependency.
> by building (linking?) it it differently; or just do rpm ignore magic?

I found another idea and implemented it – I have separated 'ld' package,
to provide both the dynamic linker (/lib/ld-*) an the ldconfig tool.
This is what contains those cross-dependencies and it does not pull any
other dependency that whole glibc package could pull.

Currently pushed with 'Release: 6.1', to become 'Release: 7' if there
are no objections.

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

Re: Fwd: Cron ~/rpm/PLD-doc/notify-specsupdate.sh

[Jacek Konieczny]

On 2018-10-23 13:01, Arkadiusz Miśkiewicz wrote:
> On 23/10/2018 12:43, glen wrote:
>> any plans to fix cvs.pld-linux.org?
> 
> cvs-nserver segfaults and needs some debugging or better switching to
> other maintained cvs
> 
> 
>> cvs [status aborted]: reading from server: Connection reset by peer

Or maybe it is time to finally ditch CVS all together.

There is really no good reason we are still using this crap for anything.


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

Re: [packages/openssl102: 432/432] - cloned from openssl branch v1.0.2 as openssl102 to make it parallel-installable with current 1.1.1

[Jacek Konieczny]

On 01/10/2018 22.17, Elan Ruusamäe wrote:
> On 29/09/2018 02:37, adwol wrote:

> altho i prefer just to keep same package multiple versions installed:
> 
> 
> # rpm -q openssl
> openssl-1.0.2o-1.x86_64
> openssl-1.1.1-1.x86_64

This does not work well with upgrades (e.g. „upgrade *” in poldek gives
„multiple versions installed”). IMHO separate package with own name is
much cleaner.

For me it does not matter much if it is build from a different branch of
the same spec or from a separate repo, but as branches is how we do it
with kernel or php, then I guess it is the way to go.


Jacek
___
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

[Jacek Konieczny]

On 27/09/2018 18.59, Arkadiusz Miśkiewicz wrote:
> 
> +- current TODO:
> 

> pjproject.spec

Does anything use it? Except Asterisk, which uses own bundled version
(the patches and configuration included there is quite important for
proper Asterisk operation).

If not, then we can drop it and update only when needed.

Jacek
___
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

[Jacek Konieczny]

On 20/09/2018 20.57, Adam Osuchowski wrote:
> 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.

+1

openssl 1.0.2 will also be required for many third-party binary software
(read: games).

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

Re: less aggressive glibc rebuilds

[Jacek Konieczny]

On 2018-09-06 10:50, glen wrote:
> could we make not so often glibc upgrades in th?
> 
> at least keep builders glibc version low, so that built packages do not
> require the latest and bleeding glibc SONAME symbols? (unless there's
> actual benefit in that package for newer glibc)
> 
> it's very disturbing that wanting to install some new package, i'm
> forced to upgrade whole system.

Why whole system? Glibc upgrades are backward compatible most of the
time. So it is just upgrading the package you want and glibc, not a big
issue. I cannot recall the last time glibc upgrade pulled anything more.

openssl upgrades are much more problematic.


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

openssl manual pages broken?

[Jacek Konieczny]

[jajcus@jajo ~]$ man openssl-pkcs12
man: /usr/share/man/man1/openssl-pkcs12.1 is self referencing
No manual entry for openssl-pkcs12
[jajcus@jajo ~]$ cat /usr/share/man/man1/openssl-pkcs12.1
.so man1/openssl-pkcs12.1

And the same for most openssl-* pages.

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

RFC: x86-runtime packages (was: Re: libexec and multi-arch)

[Jacek Konieczny]

On 2018-02-12 07:42, Tomasz Pala wrote:
>> Truly the best way out of all these discussions is to complete the 10+ year 
>> transition from 32bit to 64bit and stop the endless discussions and fiddle 
>> up retrofits.
> 
> Be my guest and just convert all the binary-only programs to 64 bit.
> Including the commercial ones.

I was thinking about some other solution: Make some '32bit runtime'
packages which would be built from our i686 packages and contain only
the libraries and other necessary files needed to run x86 apps on x86_64
system.

This packages would be explicitly made not to conflict with anything
from x86_64 packages and installing .i686 packages in x86_64 system
would not be needed any more.

The packages could be:

x86-runtime-basesystem (glibc, libstdc++ with dependencies)
x86-runtime-X11 (X11 libraries, maybe with the popular toolkits)
x86-runtime-SDL (SDL_* – mostly for games)
etc.

'Source*' in those specs would point to .i686.rpm files built by our
i686 builders.

Updating of the spec files could be partially automated.


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

Re: libexec and multi-arch

[Jacek Konieczny]

On 2018-02-05 10:36, Jan Rękorajski wrote:
> On Mon, 05 Feb 2018, Arkadiusz Miśkiewicz wrote:
> 
>>
>> What's the approach for problems like:
>>
>> error: Install/Erase problems:
>> file /usr/libexec/getconf/POSIX_V6_ILP32_OFFBIG conflicts between 
>> attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
>> file /usr/libexec/getconf/POSIX_V7_ILP32_OFFBIG conflicts between 
>> attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
>> file /usr/libexec/getconf/XBS5_ILP32_OFFBIG conflicts between 
>> attempted installs of glibc-2.27-1.i686 and glibc-2.27-1.x32
>>
>> ?
> 
> Use the --force, Luke.
> 
> I haven't find anything smarter yet.

Using lib/lib64/libx32 instead of libexec was much smarter in this case.
Are we dropping multi-arch support in PLD all together?

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

Re: Mesa 17.2 from th-test is broken

[Jacek Konieczny]

On 2017-09-19 20:53, Łukasz Maśko wrote:
> Dnia wtorek, 19 września 2017 20:02:11 Jan Rękorajski pisze:
>> Xserver crashes for me after installing Mesa 17.2 from th-test
> [...]
> 
> Just to report: 12.7.1.x86_64 + Intel works for me.

I just wanted to write the same – no problem in Intel.

Is there any llvm or libstdc++ version conflict possible? Gallium driver
are quite sensitive to those.

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

Re: Fwd: Re: [Nurmukhamed/centos-7-build-asterisk-rpms] License missing (#2)

[Jacek Konieczny]

On 2017-08-21 13:02, Elan Ruusamäe wrote:
> the copying file was present in CVS
> 
> 
> http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/SPECS.old/COPYING
> 
> http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/packages/COPYING
> 
> 
> but lost with git migration because there's no place to put the file.

Thanks! That was what I was looking for.

We should fix this somehow, though, so the license is known.

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

Fwd: Re: [Nurmukhamed/centos-7-build-asterisk-rpms] License missing (#2)

[Jacek Konieczny]

Hi,

I got such question from a GitGHub user: what is the license of our spec
files and patches – the asterisk package in particular.

I am pretty sure it was GNU GPL, but I cannot find any confirmation.

So, what is the license of our work?

Jacek


 Forwarded Message 
Subject:Re: [Nurmukhamed/centos-7-build-asterisk-rpms] License missing
(#2)
Date:   Fri, 18 Aug 2017 15:23:06 + (UTC)
From:   Alexander Aleksandrovič Klimov <notificati...@github.com>
Reply-To:   Nurmukhamed/centos-7-build-asterisk-rpms
<reply+000bada3081d368c42d09a4f626afdee85de558da923711292cf000115aec85992a169ce0ed26...@reply.github.com>
To: Nurmukhamed/centos-7-build-asterisk-rpms
<centos-7-build-asterisk-r...@noreply.github.com>
CC:     Jacek Konieczny <jaj...@jajcus.net>, Mention
<ment...@noreply.github.com>



Hello @Nurmukhamed <https://github.com/nurmukhamed>,

I asked you for adding the license for all the files in this repository
because my employer wants to provide Asterisk packages to a customer,
but we'd like to see some kind of *terms of use* (GPLv2+ / BSD3 /
whatever) and a *full list of authors* (you, me and all the guys from
"mostly borrowed from https://github.com/pld-linux/asterisk/ ...")
before we *distribute* 3rd party stuff *commercially*.

I couldn't find the license of https://github.com/pld-linux/asterisk/.
If I did, I had already opened a pull request so you could just merge it.

(The license would affect my changes as well, but I don't mind wich one
it is as long as it's not "all rights reserved" or BSD4 or similar.)

@Jajcus <https://github.com/jajcus> seems to be the biggest contributor
of the repo you forked this from. I think I gonna ask him...

Best,
AK

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/Nurmukhamed/centos-7-build-asterisk-rpms/issues/2#issuecomment-323383533>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAuto9CTZIE0BVTQ55rrh-JvzzR99GxCks5sZaxZgaJpZM4Owi4o>.

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

Re: [packages/iptables] - added ebtables init scripts

[Jacek Konieczny]

On 2016-04-09 15:45, baggins wrote:

commit 9ec3dc4d5d00befe1b59d557cc4d4e34635816c5
Author: Jan Rękorajski 
Date:   Sat Apr 9 21:57:09 2016 +0900

- added ebtables init scripts


Have you actually tested this?



+   if is_yes "$EBTABLES_BINARY_FORMAT"; then
+   for table in $(ls /etc/sysconfig/ebtables.* 2>/dev/null 
| sed -e 's/.*ebtables\.//' -e '/save/d' ); do
+   /usr/sbin/ebtables -t $table --atomic-file 
/etc/sysconfig/ebtables.$table --atomic-commit || RETVAL=1
+   done


--atomic-file, --atomic-commit do not seem to work at all in the 
iptables-provided 'ebtables'


[root@jajo ~]# ebtables-compat -t filter  --atomic-file /tmp/x 
--atomic-commit

Extensions only for -A, -I, -D and -C.
[root@jajo ~]# ebtables-compat -t filter  --atomic-file /tmp/x --atomic-save
Extensions only for -A, -I, -D and -C.



+   else
+   /usr/sbin/ebtables-restore < /etc/sysconfig/ebtables || 
RETVAL=1
+   fi


And there is no such thing as ebtables-restore or ebtables-save here,

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

Re: [packages/iptables] - added ebtables patch to support plain ebtables command

[Jacek Konieczny]

On 2016-02-28 10:30, qboosh wrote:

commit 87ffab9ee39fd264c3cbae4bd42e4c8b663d04bf
Author: Jakub Bogusz 
Date:   Sun Feb 28 10:33:51 2016 +0100

- added ebtables patch to support plain ebtables command


I lost a few hours of work today because of this
not-well-thought-out change.

There was a reason this command is not there upstream. This is not 
compatible with original ebtables, and buggy even in the basic 
functionality it is supposed to provide.


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

Re: Going back to IcedTea, openjdk8 is obsolete

[Jacek Konieczny]

On 2017-06-05 09:52, Tomasz Pala wrote:

On Mon, Jun 05, 2017 at 08:46:36 +0200, Jacek Konieczny wrote:


/usr/lib64/jvm/java -> icedtea8-3.4.0 symlink is provided by icedtea8-jdk
- this package contains symlinks and manuals only, BUT also:

Requires:   icedtea8-jar = 3.4.0-1, icedtea8-jdk-base = 3.4.0-1
one symlink and 2 mans, ...20 MB of unnecessary stuff


The Requires are the main part of this package ? as it brings all the
stuff together to make the complete 'JDK'.


So (assumink JDK means Development Kit) the directory is not a part of
JDK and should be moved somewhere outside. Consider what's the purpose of
splitting icedtea8-jdk from icedtea8-jdk-base then.


You can have icedtea8-jdk-base, icedtea7-jdk-base and 
oracle-java-jdk-base installed at the same time – all of them would be 
fully usable provided you use their actual paths (e.g. 
/usr/lib64/jvm/icedtea8-3.4.0/jre/bin/java).


Then you can install single 'jdk' package, which includes symlinks so 
the binaries and libraries are available at the generic path.



The library is a part of the JRE. I guess we could move the
%{_libdir}/jvm/java symlink to icedtea8-jre, but it still needs to pull
whole JRE (that is still less than JDK).


Yes, something like icedtea8-jre (with R: icedtea8-jre-base itself) should
be used to system-select the JRE to be used.


Yes, that was the idea.


The symlink is there to allow multiple JDK/JRE versions installed (Java
world is crazy and one may need that) ? the symlink points to the
current default one.


Moreover, we should have sth like oracle-jre package with appropriate
symlink and fake provides for the systems with self-installed Oracle
non-distributables.


Yes. The Sun and then Oracle Java used to be packaged that way. I have 
not been maintaining or using those any more so I don't know if this is 
still the case or if it has degraded somehow.


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

Re: Going back to IcedTea, openjdk8 is obsolete

[Jacek Konieczny]

On 2017-06-05 00:46, Tomasz Pala wrote:

On Wed, Sep 21, 2016 at 12:51:55 +0200, Jacek Konieczny wrote:


I gave it a try and managed to build PLD packages with it. Those seem to
work on x32 properly and have no limit on crypto keys length. Much
better than the openjdk8-* packages.

I suggest that openjdk8 packages should be obsoleted and icedtea8 should
be used as our JDK from now on, unless someone finds some problems with it.

And a reminder: Oracle Java has really evil license, which does not
allow us to redistribute it with the distribution. OpenJDK/IcedTea is
the only way for us.


objdump -x /usr/lib64/libgdal.so | grep RPATH
  RPATH/usr/lib64/jvm/java../jre/lib/amd64/server
libjvm.so resides in:  
/usr/lib64/jvm/icedtea8-3.4.0/jre/lib/amd64/server/libjvm.so

/usr/lib64/jvm/java -> icedtea8-3.4.0 symlink is provided by icedtea8-jdk
- this package contains symlinks and manuals only, BUT also:

Requires:   icedtea8-jar = 3.4.0-1, icedtea8-jdk-base = 3.4.0-1
one symlink and 2 mans, ...20 MB of unnecessary stuff


The Requires are the main part of this package – as it brings all the 
stuff together to make the complete 'JDK'.



I'm not a JAVA guy, however this seems to be swapped: icedtea8-jdk and
icedtea8-jdk-base. I need the directory symlink mentioned only (to be
suggested by gdal).


Only the symlink, or rather the libjvm.so library with all the dependencies?

The library is a part of the JRE. I guess we could move the 
%{_libdir}/jvm/java symlink to icedtea8-jre, but it still needs to pull 
whole JRE (that is still less than JDK).


The symlink is there to allow multiple JDK/JRE versions installed (Java 
world is crazy and one may need that) – the symlink points to the 
current default one.



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

Re: [packages/man-db] Added cronjob timer+service.

[Jacek Konieczny]

On 2017-04-05 11:27, Mateusz Korniak wrote:



By the way, I was not able to respond to a mail on this topic, because:
: host 31.179.132.94[31.179.132.94] said: 554 5.7.1
 : Recipient address rejected: Access denied (in
 reply to RCPT TO command)



94.132.179.31.in-addr.arpa domain name pointer tropek.jajcus.net.
Is 31.179.132.94 yours host?


Yes, it is… I should have checked it myself first :)


Any idea why is not relaying to ant.gliwice.pl MX (93.179.197.152)?


Due to greylisting on ant.gliwice.pl the mail was passed to the backup 
server, which was not configured right.


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

Re: [packages/man-db] Added cronjob timer+service.

[Jacek Konieczny]

On 2017-04-05 10:39, matkor wrote:

commit 43f653030a061f129444d0c41e389b54cc7379a9
Author: Mateusz Korniak 
Date:   Wed Apr 5 10:38:34 2017 +0200

Added cronjob timer+service.


Not needed in this case, as there is /etc/cron.daily script, which will
be called by systemd-cronjobs anyway. Now mandb update will be called
twice.

The /etc/cron.daily script should be replaced with package's own crontab
for more efficient execution from both crond and systemd or this change
should be reverted.


By the way, I was not able to respond to a mail on this topic, because:


: host 31.179.132.94[31.179.132.94] said: 554 5.7.1
: Recipient address rejected: Access denied (in
reply to RCPT TO command)

Jacek

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

Re: [packages/tzdata] break dependency loop

[Jacek Konieczny]

On 2017-04-03 21:23, Elan Ruusamäe wrote:

On 13.03.2017 10:30, jajcus wrote:

commit 2141fdbf9a858852a7c635341b346a5ca42787f1
Author: Jacek Konieczny <j.koniec...@eggsoft.pl>
Date:   Mon Mar 13 09:26:54 2017 +0100

 break dependency loop
  warning: LOOP:
 warning: removing tzdata-zoneinfo-2016j-1.aos1.noarch "Requires:
/etc/localtime" from tsort relations.
 warning: removing tzdata-2016j-1.aos1.noarch "Requires:
tzdata-zoneinfo = 2016j-1.aos1" from tsort relations.
  This breaks package install order on clean systems.
  Release: 2


[...]


now %{_datadir}/zoneinfo is packaged on both packages (tzdata and
tzdata-zoneinfo)

main package should not include it as main package rewquires
tzdata-zoneinfo anyway.


Then tzdata-zoneinfo should not require the main package through  the 
/etc/localtime symlink.



I think this is all to complicated anyway:
- /etc/rc.d/init.d/timezone should be a part of rc-scripts, only as a 
fallback for systemd-less systems (systemd does handle timezones better 
and has timedatectl)
- there is no need for the tzdata/tzdata-zoneinfo  split. Now we have 
'tzdata' package, which contains no 'data' and is quite obsolete on 
modern systems
- /etc/localtime should not be a symlink. systemd does not make it a 
symlink and it being a symlink causes potential problems (/usr 
unmounted, change in zone file names).



One 'tzdata' package only with the data and no external dependencies 
would be enough.


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

Re: [packages/xorg-xserver-server] P: xorg-driver-video-modesetting, xorg-driver-video

[Jacek Konieczny]

On 2016-11-23 23:12, Elan Ruusamäe wrote:

On 23.11.2016 17:16, atler wrote:

  # Usual desktop setups need least one video driver to run, see
xorg.log which one exactly
  Suggests:xorg-driver-video
+Provides:xorg-driver-video
+Provides:xorg-driver-video-modesetting


nono no, do not provide "xorg-driver-video"!

it's virtual package indicating "any video driver"


But in some cases (like newer Intel cards) the 
xorg-driver-video-modesetting, included in the server package, is the 
best driver one can use. xorg-driver-video-intel is not really 
maintained any more and doesn't work properly with Skylake chips.


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

Re: [packages/kernel] - remove bugus ifs, kernel 4.6+ has default -Werror=incompatible-pointer-types

[Jacek Konieczny]

On 2016-11-13 10:56, baggins wrote:
> commit 0704af311ff89256bd08d2e75c08d104899ec4dd
> Author: Jan Rękorajski 
> Date:   Sun Nov 13 10:55:37 2016 +0100
> 
> - remove bugus ifs, kernel 4.6+ has default 
> -Werror=incompatible-pointer-types

I was unaware. Thanks!

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

Re: mysql/percona/maria...

[Jacek Konieczny]

On 2016-10-29 11:17, Arkadiusz Miśkiewicz wrote:
> On Saturday 29 of October 2016, Elan Ruusamäe wrote:
>> On 29.10.2016 11:25, Elan Ruusamäe wrote:
>>> should we introduce mysql57, mysql80 packages instead?
> 
> Only if there are incompatible on upgrade path. To be verified with docs. 
> Otherwise all versions as mysql package.

That (nameXY) would be more usefull for PostgreSQL, where old and new
version need to be installed for a database upgrade between different
major versions. Currently PostgreSQL upgrade in PLD is a problem.
Though, I am not sure doing it right and maintaining later is worth the
effort for our tiny team.

>> here's some idea:
>>
>> 1. make percona-server.spec:5.7 clean upgrade path from mysql.spec:5.6
>> 2. do not build mysql.spec officially at all
>> 3. build system tools using percona-server-devel via "Provides:
>> mysql-devel" 4. mariadb - ship it only if it does not conflict with
>> mysql-libs or mysql-devel
> 
> Sounds good to me.
> 
> (I would switch entire distribution to mariadb though (but keep percona 
> server 
> package, too)

Sound goot to me to. It seems other distributions do similarily –
mariadb is used instead of Oracle mysql and no non-Oracle mysql fork is
packaged as 'mysql'.

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

Re: nginx-standard drop

[Jacek Konieczny]

On 2016-10-28 09:46, Elan Ruusamäe wrote:

On 27.10.2016 17:17, Jacek Konieczny wrote:

On 2016-10-26 23:14, Elan Ruusamäe wrote:

On 19.10.2016 00:51, Elan Ruusamäe wrote:

proposition:
  drop nginx "-standard" suffix? in package and filenames


so, zero feedback on my dev changes. i'm going to merge this to master
in few days then.


I had not time to look into that, but if you push a package (before or
after the merge, doesn't matter to me) into th-test I'll try to test
it somewhere.

The general idea seems right. I am a bit afraid of the transition,
though.


there's no transition (by design),
you need to setup again using new package names. it will not upgrade
automatically due broken (deliberately) package deps


That is ok with me.


you can apply this patch to be just poldek -u nginx, but note the
configs are not migrated


I prefer the deliberately-broken deps approach.


i do not plan to add upgrade path. because then i would be blamed i did
it incomplete & wrong, etc.


makes sense :)

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

Re: nginx-standard drop

[Jacek Konieczny]

On 2016-10-26 23:14, Elan Ruusamäe wrote:

On 19.10.2016 00:51, Elan Ruusamäe wrote:

proposition:
  drop nginx "-standard" suffix? in package and filenames


so, zero feedback on my dev changes. i'm going to merge this to master
in few days then.


I had not time to look into that, but if you push a package (before or 
after the merge, doesn't matter to me) into th-test I'll try to test it 
somewhere.


The general idea seems right. I am a bit afraid of the transition, though.

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

Re: nginx-standard drop

[Jacek Konieczny]

On 2016-10-18 23:51, Elan Ruusamäe wrote:

proposition:
  drop nginx "-standard" suffix? in package and filenames


+1

And get rid of all other HTTP versions. The "-mail" can stay, I guess.

Does anybody actually use anything other than "-standard"?

I never changed it, not to break things for somebody who used it. And 
because I had no idea why anybody would split the package this way.


> rationale:
>   why pld should be again unique and packaging nginx differently

PLD does too much of that.

> i tried to hack in my base image adding symlinks, but even accesslogs
> are different
>
> /var/log/nginx/nginx-standard_error.log
> vs
> /var/log/nginx/access.log

I would often just make my own nginx.conf file and own systemd unit 
nginx.service, with all paths restored to normal.


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

Re: [packages/ardour] force build with MMX and SSE

[Jacek Konieczny]

On 2016-10-12 09:30, Elan Ruusamäe wrote:

you can enforce runtime probe dependency:

$ grep -r Requires.*cpuinfo ~/all-specs
/home/users/glen/all-specs/adobe-flash.spec:Requires: cpuinfo(sse2)
/home/users/glen/all-specs/google-earth.spec:Requires: cpuinfo(sse2)
/home/users/glen/all-specs/kernel.spec:Requires: cpuinfo(pae)
/home/users/glen/all-specs/ClanLib.spec:%{?with_sse2:Requires:
cpuinfo(sse2)}


Good to know.

Even better would be to also know what are the CPU extensions supposed 
to be available on our 'i686'.



sorry if this is totally out of context.


No, it is not.

It seems Ardour is supposed to detect and enable SSE on runtime, but I 
am not sure it works and I have no way to test it. MMX suuport seems to 
be hardcoded.


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

Re: [projects/pld-builder.new] drop building intel drivers and nvidiabl for head kernels

[Jacek Konieczny]

On 2016-10-12 07:31, Elan Ruusamäe wrote:

please announce any of such droppings.


A nice way to say 'announce any of this shit' ;-)

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

Re: apache-mod_wsgi.spec

[Jacek Konieczny]

On 2016-10-01 20:18, Elan Ruusamäe wrote:
> 1.
> apache-mod_wsgi = python2
> apache-mod_wsgi3 = python3

That will encourage keeping python2 as 'the python' forever…


> 2.
> apache-mod_wsgi = RIP
> apache-mod_wsgi-py2 = python2
> apache-mod_wsgi-py3 = python3
> 
> 3.
> apache-mod_wsgi = requires %name(mod_wsgi)
> apache-mod_wsgi-py2 = python2, provides %name(mod_wsgi)
> apache-mod_wsgi-py3 = python3, provides %name(mod_wsgi)

Both seem ok for me. The first one is even better, unless there are some
common files to include there.

And don't forget to add:

Obsoletes: apache-mod_wsgi < first_version_split

To -py2.

> the more suffix variants include:
> - -2, -3
> - -py2, -py3
> - -python2, -python3

-py2, -py3, seems good for me. '-2', '-3' could suggest it is wsgi, not
Python version. '-python2', '-python3' would be good for packages that
do not imply Python, like mod_wsgi does, but are not needed here ('py2'
is clear enough).

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

Going back to IcedTea, openjdk8 is obsolete

[Jacek Konieczny]

Hi,


For long time IcedTea was not available for building OpenJDK8, so I 
packaged OpenJDK directly. It seemed good idea anyway – why using some 
intermediate system when OpenJDK can be directly compiled on Linux.


It even worked when I packaged it. I was not sure if it is 'stable' or 
'current' release, but it was better than Java 7 we had before.


Problems started when I tried to upgrade. I still have no idea what the 
OpenJDK release process is, how the versioning works and what are 
important changes between the version. Anyway, I have tried two newer 
'releases'… and those wouldn't work on x32. I was  not able to fix it 
(x32 patches from Debian didn't help), no one else in PLD seemed 
interested in fixing that either.


Then, I have discovered something even worse: our OpenJDK 8 build 
cryptography was limited to the 'export' strength, at least for some 
functions on AES cipher. This should not be the case in OpenJDK (as is 
in Oracle JDK), but in PLD it was. And I was not able to find any 
information how to fix that.


Fortunately, IcedTea for Java 8 has been finally released earlier this 
year. It has regular versioning, changelog and will probably be 
maintained like previous IcedTea versions were.


I gave it a try and managed to build PLD packages with it. Those seem to 
work on x32 properly and have no limit on crypto keys length. Much 
better than the openjdk8-* packages.


I suggest that openjdk8 packages should be obsoleted and icedtea8 should 
be used as our JDK from now on, unless someone finds some problems with it.


And a reminder: Oracle Java has really evil license, which does not 
allow us to redistribute it with the distribution. OpenJDK/IcedTea is 
the only way for us.


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

Re: npm and bundled modules

[Jacek Konieczny]

On 2016-09-10 23:46, Paweł A. Gajda wrote:

npm itself bundle its dependencies,so, what I like to do is just to bundle
them into package as well. It just works and would make upgrades much, much
easier. Any objections?


+1, no objections.

Node dependencies and packaging is totally crazy and mantaining it right 
with RPM (making RPM package for each node package, which may contain a 
single .js file with a single function) would require 100x bigger team 
of developers than we have. So, instead of fighting that, lets just 
package together as much as it is convenient.


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

distfiles misbehaving

[Jacek Konieczny]

Distfiles truncated an archive I have just uploaded there:

[jajcus@jajo tmp]$ wget 
http://distfiles.pld-linux.org/distfiles/by-md5/6/6/66f3cfc0f6c3963a6c6c41e741b1518a/compton-20160811.tar.xz
--2016-09-05 12:45:20-- 
http://distfiles.pld-linux.org/distfiles/by-md5/6/6/66f3cfc0f6c3963a6c6c41e741b1518a/compton-20160811.tar.xz

Resolving distfiles.pld-linux.org (distfiles.pld-linux.org)... 193.239.45.41
Connecting to distfiles.pld-linux.org 
(distfiles.pld-linux.org)|193.239.45.41|:80... connected.

HTTP request sent, awaiting response... 200 OK
Length: 65536 (64K) [application/octet-stream]
Saving to: ‘compton-20160811.tar.xz’

compton-20160811.ta 100%[=>]  64.00K  --.-KB/s   in 
0.04s


2016-09-05 12:45:21 (1.46 MB/s) - ‘compton-20160811.tar.xz’ saved 
[65536/65536]


[jajcus@jajo tmp]$ file compton-20160811.tar.xz
compton-20160811.tar.xz: XZ compressed data
[jajcus@jajo tmp]$ ls -l compton-20160811.tar.xz 
~/rpm/packages/compton/compton-20160811.tar.xz

-rw-r--r-- 1 jajcus users  65536 Sep  5 11:27 compton-20160811.tar.xz
-rw-r--r-- 1 jajcus users 130628 Sep  5 11:04 
/home/users/jajcus/rpm/packages/compton/compton-20160811.tar.xz


[jajcus@jajo tmp]$ md5sum compton-20160811.tar.xz 
/home/users/jajcus/rpm/packages/compton/compton-20160811.tar.xz

1ae2151dce0460c57c53410ce198067e  compton-20160811.tar.xz
66f3cfc0f6c3963a6c6c41e741b1518a 
/home/users/jajcus/rpm/packages/compton/compton-20160811.tar.xz


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

Re: udev rules help

[Jacek Konieczny]

On 2016-08-31 09:51, Elan Ruusamäe wrote:

On 31.08.2016 10:47, Jacek Konieczny wrote:

# grep add /etc/udev/rules.d/80-idcard.rules
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device",
ENV{ID_MODEL}=="*Smart*Card*Reader*", RUN+="/sbin/service pcscd start"


What init do you use.


i mean the RUN+= part is never executed no matter what rules i write.
even only the ACTION="add" part


Is the rule actually matched?
Maybe there is some other rule later with RUN= instead of RUN+=?
Have you tried "change" instead of "add"? Handling "add" only often 
causes problems (the device is not fully set up, or the "add" was 
handled long before the rule become available (e.g. in initramfs)).


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

Re: udev rules help

[Jacek Konieczny]

On 2016-08-31 07:28, Elan Ruusamäe wrote:

i'm trying to write udev rule to start service when usb device is attached

here's what i got. yet it doesn't work

# grep add /etc/udev/rules.d/80-idcard.rules
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device",
ENV{ID_MODEL}=="*Smart*Card*Reader*", RUN+="/sbin/service pcscd start"


What init do you use. This _might_ work with systemd, as 'service' just 
shcedules a systemd job, but won't work with rc-scripts, as udev rules 
are not allowed to start long running processes.


udev rules are not a place for starting daemons, which is well 
documented thing.



i even tried something very simple:
ACTION=="add", RUN+="/sbin/service pcscd start"

that also didn't work (attaching device did not start the service), how
to debug this?


Just don't do this. Switch to systemd and use systemd device 
dependencies in the .service file to start the service.


If you want to stick with rc-scripts, then wait for the device in the 
init script.


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

Icedtea8 and x32

[Jacek Konieczny]

Hi,

I have updated the openjdk8.spec for more recent update… and the x32 
binaries stopped working. I have no idea how to debug it or what could 
go wrong, as I have very little experience with x32 and the JVM 
implementation is not some simple code.


I have tried two different code versions, I have tried dropping 
PLD-specific CFLAGS. The 'x32.patch' seems to match what Debian does (in 
fact it even uses dpkg right now to detect x32 architecture, which 
should probably be changed to something less exotic or included in the 
dependencies).


The freshly built 'java' binary crashes on some NULL pointer 
dereference, but I was not able to locate any obvious reason.


i686 and x86_64 builds work, but they use a bit different code 
(architecture-specific JIT instead of the 'zero assembly' JVM).


Can anyone here look into that? Having old JDK is no good.

We could also switch to Icedtea again, as Icedtea for JDK8 is now 
available, but that would require preparing the new package.


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

Re: [packages/ipmitool] do not suggest some crafted script when there are contemporary and generic module loaders

[Jacek Konieczny]

On 2016-07-29 13:10, Elan Ruusamäe wrote:

On 28.07.2016 23:39, Tomasz Pala wrote:

who knows what device would become available at /dev/ipmi0 at next
reboot... (unless cleaned in rc.sysinit). This package should be banned,


+1


I'm considering C: ipmi-init somewhere, but I'm not sure where to put
it...

you could as well fix the script to always replace /dev/ipmi0 if /dev is
static


There is no point in keeping every legacy stuff just because we had it 
in PLD at some time. Some pieces of software were just mistakes, that is 
it. Maintaining broken stuff 'for compatibility' is pointless, it still 
requires work bringing, but only brings problems.


If some system relies on old, broken behavior, then the system needs an 
update. Much bigger distibutions won't support indefinite backward 
compatibility. We cannot afford that even more.


It is the same case for 'Require: mingetty' in rc-scripts.

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

Re: [packages/vulkan-sdk] - do not require icd in -demos if package was build without it - rel 2

[Jacek Konieczny]

On 2016-07-02 16:40, baggins wrote:
> commit 995b0954e3734535a29e3b3888054f35bb981d39
> Author: Jan Rękorajski 
> Date:   Sat Jul 2 16:40:30 2016 +0200
> 
> - do not require icd in -demos if package was build without it
> - rel 2

ICD is a Vulkan driver. Demos are useles without a driver.

The ICD which could be built from the SDK sources was just a reference
own. Proper one comes with prioprietary nVidia or AMD drivers or with
Mesa 12 (for Intel).

Jacek

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

Re: python packaging

[Jacek Konieczny]

On 2016-06-20 14:58, Elan Ruusamäe wrote:

so, what way we should do the package naming?

1. egg name


That probably makes most sense today.


2. python module name [*]


That was decided before python eggs started being a thing. And that is 
how most of our packages are named now.



3. upstream tarball name
4. pld own convention


Both would give quite random results.


[*] this is said to be the recommendation in template-specs


As it was decided long time ago, when it made sense.


reality is that we have no consistency,


Some people seem to don't care at all. :-(
I am afraid, that whatever scheme we decide on, people will still commit 
crap. That is minority, but quite annoying.



the package naming is from any of the four choices:

the results vary from name letter cases (South vs south), separators (_
vs -), name itself (picklefield module vs django_picklefield egg)


I hate this too. Especially when I find out a package exists after I 
package it again under a more standard name.


I think the best naming scheme would be python-${egg_name} now. But that 
is inconsistent with what we used to do. Renaming all the affected 
packages might be quite problematic.


Anything that doesn't match 1. or 2. should be renamed, but doing it 
after it went to th causes compatibility problems.


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

Re: ERRORS: openchange.spec

[Jacek Konieczny]

On 2016-06-15 13:40, Arkadiusz Miśkiewicz wrote:

th-i686 and buildlogs is back to life


buildlogs do not seem right:

http://buildlogs.pld-linux.org//index.php?dist=th=x86_64=1=wget=77718e81-0246-4533-aa72-d97b07abbd8e=tail

Jacek

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

Re: ldconfig forgotten

[Jacek Konieczny]

On 2016-05-31 08:52, Elan Ruusamäe wrote:

D:   install: %post(procps-3.3.11-1.x86_64) skipping redundant "/sbin/ldconfig".


Looks like it is skipped on purpose… I wonder what is the reasoning 
behind it.


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

Re: ping package

[Jacek Konieczny]

On 2016-05-24 11:30, Elan Ruusamäe wrote:

proposition:

rename iputils-ping -> ping


+1

And an 'Obsoletes:', of course.

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

Re: [packages/glibc] - rel 4; more upstream git branch updates

[Jacek Konieczny]

On 2016-05-18 14:35, Elan Ruusamäe wrote:

On 18.05.2016 14:54, Arkadiusz Miśkiewicz wrote:

On Wednesday 18 of May 2016, Elan Ruusamäe wrote:

On 18.05.2016 14:18, arekm wrote:

commit ee4a0bb9cd9a8e7f552c9948963a69c61865845c
Author: Arkadiusz Miśkiewicz
Date:   Wed May 18 13:16:40 2016 +0200

  - rel 4; more upstream git branch updates
  glibc-git.patch | 60944
   -- glibc.spec
   | 3 +-

why keep this git.patch in our git, why not upload to distfiles?
it's not like it's diff of .patch is something useful to look at.

Maybe not for you but I was ofter doing git diff and git log on patch
files
like this to see what has changed etc.


"log" seems to be mostly just "updated from upstream".

https://github.com/pld-linux/glibc/commits/master/glibc-git.patch


I hate those 'git patches' and 'updated from upstream' logs. That gives 
no version information. I would prefer to see some snapshot / upstream 
revision number, which I could use to check actual changes upstream.


Or full upstream patches, with their commit messages. The 
'glibc-git.patch' with 'updated from upstream' logs is not much more 
useful than a random binary blob.


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

Re: /usr/lib64/jvm/java symlink

[Jacek Konieczny]

On 2016-05-15 11:57, Tomasz Pala wrote:
> I'm trying to compile qgis using gdal:
> 
> /usr/bin/ld: warning: libjvm.so, needed by 
> /usr/lib64/gcc/x86_64-pld-linux/5.3.0/../../../../lib64/libgdal.so, not found 
> (try using -rpath or -rpath-link)
> 
> gdal.rpm requires libjvm.so, so I've installed the same java version it was
> compiled with, i.e. openjdk8-jre-base; however libgdal.so uses
> /usr/lib64/jvm/java path, which exists in openjdk8-jdk:
> /usr/lib64/jvm/java -> openjdk8-8u72.b15
> JRE contains only
> openjdk8-jre -> openjdk8-8u72.b15/jre
> symlink.
> 
> Something needs to be fixed: either
> - gdal should require JDK package - overkill, or

It is link time dependency, so it would be normal do include 'devel'
package and JDK is 'devel'. But I agree, it is a bit of overkill here.

> - symlink should be moved to JRE,

IMHO this is the way to go.

 or
> - symlink should be moved to some java-default package and this one
>   should be required by gdal,


The split between *-jre and *-jre-base is just for this – -jre is the
'default' JRE (only one installed) and -jre-base is the actual JRE, but
without anything conflicting with another JRE implementation

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

Re: python3 optional deps

[Jacek Konieczny]

On 2016-05-06 10:59, Elan Ruusamäe wrote:

On 06.05.2016 11:47, Jacek Konieczny wrote:


Feel free to separate it :-)

sure. suggest package name?


rpm-pythonprov? It is already a separate package, just built with whole RPM.



looks like there's just one file to move:
/usr/lib/rpm/pythoneggs.py



[jajcus@jajo ~]$ rpm -ql rpm-pythonprov
/usr/lib/rpm/pythondeps.sh
/usr/lib/rpm/pythoneggs.py

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

Re: python3 optional deps

[Jacek Konieczny]

On 2016-05-06 09:41, Elan Ruusamäe wrote:

On 06.05.2016 10:11, Jacek Konieczny wrote:


I guess the python dependency generator should be fixed in our RPM, to
ignore the 'extras' dependencies (or to make them 'suggest', skipping
the ':python_version' ones.

is there python module to parse the egg info? or just manual parsing
each time

btw, maybe it's better to extract the python dependency generators as
separate package, out of rpm sourcetree?
it would be a lot simplier to maintain, than patching patch patching the
previous patch. our patches will likely never end up upstream.


Feel free to separate it :-)

I can try to fix it then.

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

Re: python3 optional deps

[Jacek Konieczny]

On 2016-05-04 11:11, Elan Ruusamäe wrote:


can someone check (and fix?) why those optional deps:
https://github.com/docker/docker-py/blob/1.8.1/setup.py#L14-L17




extras_require = {

':python_version < "3.5"': 'backports.ssl_match_hostname >= 3.5',

':python_version < "3.3"': 'ipaddress >= 1.0.16',

}



end up in python3 egg and therefore rpm deps:


They will end up in the egg, that is the design. Those should not be 
converted to rpm deps, though. And for python3 package these deps are 
useless even in the egg-info.


I guess the python dependency generator should be fixed in our RPM, to 
ignore the 'extras' dependencies (or to make them 'suggest', skipping 
the ':python_version' ones.


The easy fix for python-docker.spec would be to strip those from
docker_py-1.8.1-py3.5.egg-info/requires.txt (everything from the first '[').

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

Re: python rebuild procedure?

[Jacek Konieczny]

On 2016-05-04 11:17, Elan Ruusamäe wrote:

On 03.05.2016 23:59, Arkadiusz Miśkiewicz wrote:

What's the rebuild procedure in case of openssl bump after this change?


python2 fixed, python3 looks like broken due other reasons, fails with
install even without tests.


That could be because of the recent changes to python3.spec by Jan, 
which I knew they are breaking something, but I couldn't tell what.


Does python3.spec build with older python3?

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

Re: [packages/python3] - use 'share' not 'lib' for platform independent files - rel 3

[Jacek Konieczny]

On 2016-04-26 09:14, Jan Rękorajski wrote:

You are probably breaking pypi and /usr/local installs again!

Proper directories for RPM packages are set with setup.py options via
%py_build/%py_install macros. Packages not using distutils/setuptools may
need patching, but that is better than breaking Python for non-RPM usage.



It caused distutils.sysconfig.get_python_lib() to return /usr/lib for
platform independent modules location which is not what we want and breaks
automake's python.m4.


I am sure I have left this for purpose. Many python packages, including 
'core' ones, like setuptools/pip/virtualenv assume that python_lib is 
${prefix}/lib. Things were quite broken when we patched Python to do 
things 'the right way'.


We only need to force platform independent modules installed in 
/usr/share when building RPM packages and that is mostly solved by our 
%py_build/%py_install macros. The few packages left can always be patched.



That said… I have tested the python3 package after your change to find 
what has been broken… and failed to get the expected results. Either I 
cannot recall the exact thing broken (I have tested various pip and 
virtualenv usage, using upstream packages) or this one change doesn't 
break anything (the 'lib' is hardcoded in a similar way in a few places, 
IIRC).


So it is possible that nothing have been broken in this case, but we 
should be very careful about this.


virtualenv and pip _must_ work properly with unpatched upstream code for 
/usr/local and $HOME installs – that is how lots of Python packages is 
expected to be installed and we are not able to package everything 
ourselves.


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

Re: [packages/python3] - use 'share' not 'lib' for platform independent files - rel 3

[Jacek Konieczny]

On 2016-04-23 22:45, baggins wrote:

commit f69d21534e5f5805751fca202e9e2ae82cb10d35
Author: Jan Rękorajski 
Date:   Sat Apr 23 22:44:51 2016 +0200

- use 'share' not 'lib' for platform independent files
- rel 3

 python3-multilib.patch | 6 ++
 python3.spec   | 2 +-
 2 files changed, 3 insertions(+), 5 deletions(-)
---
diff --git a/python3.spec b/python3.spec
index e89ded1..694d20f 100644
--- a/python3.spec
+++ b/python3.spec
@@ -34,7 +34,7 @@ Summary(tr.UTF-8):X arayüzlü, yüksek düzeyli, kabuk 
yorumlayıcı dili
 Summary(uk.UTF-8): Мова програмування дуже високого рівня з X-інтерфейсом
 Name:  python3
 Version:   %{py_ver}.1
-Release:   2
+Release:   3
 Epoch: 1
 License:   PSF
 Group: Development/Languages/Python
diff --git a/python3-multilib.patch b/python3-multilib.patch
index 30e0e94..f5a49b0 100644
--- a/python3-multilib.patch
+++ b/python3-multilib.patch
@@ -52,7 +52,7 @@ diff -dur Python-3.5.0.orig/Lib/distutils/sysconfig.py 
Python-3.5.0/Lib/distutil
 +if plat_specific:
 +lib = sys.lib
 +else:
-+lib = 'lib'
++lib = 'share'
  libpython = os.path.join(prefix,
 - "lib", "python" + get_python_version())
 + lib, "python" + get_python_version())


You are probably breaking pypi and /usr/local installs again!

Proper directories for RPM packages are set with setup.py options via 
%py_build/%py_install macros. Packages not using distutils/setuptools 
may need patching, but that is better than breaking Python for non-RPM 
usage.


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

Re: PLD New Rescue th2015-1.5

[Jacek Konieczny]

On 2016-04-19 15:59, Grzesiek Pycia wrote:

 Works fine for me, both 32&64bit.
 Under qemu/kvm it does not power off machine, but version  th-2014
 stops on "System halted" to.


On 2016-04-20 18:07, Elan Ruusamäe wrote:

reported okay with:

proxmox-ve 4.1-41, pve-qemu-kvm 2.5-9


Thanks!

I'll remove the 'pre-release' flag on GitHub.

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

PLD New Rescue th2015-1.5

[Jacek Konieczny]

I have just built PLD New Rescue based on the th-2015 snapshot:

https://github.com/Jajcus/pld-new-rescue/releases/tag/th2015-1.5

Please do test it in any way you need to use this. I have done only some
very basic testing.

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

Re: rescue

[Jacek Konieczny]

On 2016-04-14 14:50, Elan Ruusamäe wrote:

https://github.com/Jajcus/pld-new-rescue/releases

can we get rescue images for 2015 and 2016 snaps?


Yes, when I finally manage to do that. Maybe this weekend…

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

Re: [packages/php] - added Obsoleted for withdrawn modules

[Jacek Konieczny]

On 2016-03-17 20:20, Elan Ruusamäe wrote:
> 
> not that i care about php4, but in general:
> 
>i would rather see my system not updating due broken deps,
>than some random package uninstalling previous working module!

+1

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

Re: Vulkan 3D drivers test request

[Jacek Konieczny]

On 2016-03-05 18:27, Jan Rękorajski wrote:

>> 1. the Vulkan loader
> 
> Just my $0.02, there are two vulkan-loader packages, one built from
> vulkan-loader and one from vulkan-sdk. This messes up dependency
> resolution. Could you please sort this out?

vulkan-loader is obsolete, the source package has been renamed to
vulkan-sdk.

Everything built from vulkan-loader.spec is to be removed.

Jacek

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

Re: Vulkan 3D drivers test request

[Jacek Konieczny]

On 2016-03-01 12:32, Łukasz Maśko wrote:

Dnia czwartek, 25 lutego 2016 13:12:31 Jacek Konieczny pisze:

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


Well... The demos seem to work for me:


With the latest Mesa-vulkan-icd-intel snapshots they work for me too. 
Though The Talos Principle still does not.



VkPhysicalDeviceProperties:
===
apiVersion = 4194306
driverVersion  = 1
vendorID   = 0x8086
deviceID   = 0x1616
deviceType = INTEGRATED_GPU
deviceName = Intel(R) HD Graphics 5500 (Broadwell GT2)


So it is better that mine and the one better supported but the driver.


[...]
(too long to include everything). I have run vulcan-cube and vulcan-tri (looks
a bit strange). I have not tried anything else.


Yes, vulkan-tri is strange… it probably tests something we don't 
understand ;-)


Thanks!

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

Re: Fwd: [packages/thefuck] python3.spec hack

[Jacek Konieczny]

On 2016-03-01 11:11, Elan Ruusamäe wrote:

i wonder where the proper fix would be?

➔ rpm -ql python3-modules|grep -F pathlib
/usr/lib64/python3.5/__pycache__/pathlib.cpython-35.opt-1.pyc
/usr/lib64/python3.5/__pycache__/pathlib.cpython-35.opt-2.pyc
/usr/lib64/python3.5/__pycache__/pathlib.cpython-35.pyc
/usr/lib64/python3.5/pathlib.py


You could add egg-info file/directory for pathlib to python3.spec.

Jacek

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

Vulkan 3D drivers test request

[Jacek Konieczny]

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

Re: alsa vs bacula

[Jacek Konieczny]

On 2016-01-22 17:59, Elan Ruusamäe wrote:
> file /usr/bin/bat from install of alsa-utils-1.1.0-1.x86_64
> conflicts with file from package bacula-console-qt-5.2.13-4.x86_64
> file /usr/share/man/man1/bat.1.gz from install of
> alsa-utils-1.1.0-1.x86_64 conflicts with file from package
> bacula-console-qt-5.2.13-4.x86_64

I have noticed that too.

The 'bat' from ALSA is a test tool, the one from bacula is an end user
application. Also, we have had Bacula's BAT in PLD longer, so I think
ALSA side should be 'fixed'.

I can see two options:
- separate ALSA bat into a new package. Still conflicting, but a chance
that someone would need ALSA bat and Bacula bat at the same time are small
- rename the ALSA utility – it will be a bit more difficult to find it,
when someone expects 'bat', but there would be no conflict any more.

Jacek

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

Re: [packages/nodejs] up to 0.10.41, add link in doc package

[Jacek Konieczny]

On 2016-01-07 20:15, glen wrote:
> commit 05e85ef1932b3ca1a47905ad69fe43a82079d2d4
> Author: Elan Ruusamäe 
> Date:   Thu Jan 7 21:14:48 2016 +0200
> 
> up to 0.10.41, add link in doc package

What is the point of maintaining this acient version, when the current
'stable' one is 4.2.4 and latest is 5.4.0 (according to
https://nodejs.org/en/)?

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

Re: distribute

[Jacek Konieczny]

On 2015-12-31 11:58, Elan Ruusamäe wrote:

shouldn't python3-distribute be just dropped from th?


The egg-info provided by python-distribute may be still required by some 
old Python software. Our python-distribute packages do not contain much 
more.



python3-pygments-2.0.2-5.noarch: required "python3-setuptools" is
provided by the following packages:
a) python3-distribute-0.7.3-3.noarch
b) python3-setuptools-18.6.1-3.noarch


This is an error. python3-distribute must not provide 
python3-setuptools. I would fix it immediately by our GIT server stopped 
accepting my office SSH key.


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

SSH to git.pld-linux.org (was: Re: distribute)

[Jacek Konieczny]

On 2015-12-31 15:32, Kacper Kornet wrote:

On Thu, 31 Dec 2015 12:46:58 +0100
Jacek Konieczny <jaj...@jajcus.net> wrote:



python3-setuptools. I would fix it immediately by our GIT server
stopped accepting my office SSH key.


Please, try once more. I have enabled back DSA keys for some time.


Now it is even worse:
$ ssh g...@git.pld-linux.org
ssh: connect to host git.pld-linux.org port 22: Connection refused

And I think I have used RSA keys from this host recently, but that 
stopped to work. And the last time I tried the 'sskm' thing to update my 
keys, it didn't work.


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

Re: RFC: default python installlation directories

[Jacek Konieczny]

On 2015-12-17 21:34, Jan Palus wrote:

Regarding migration to new %py_* macros -- is there a way to define
setup.py options instead of "action" options? For example how to
correctly migrate following invocation:

%{__python} setup.py \
--no-compile-schemas \
--no-update-icon-cache \
install \
--optimize=2 \
--root=$RPM_BUILD_ROOT

to be more specific -- how to pass --no-* options?


There is probably no way – in such rare cases you need to expand the 
%py_build and/or %py_install macro by hand and put the needed options there.


BTW those '--no-compile-schemas' and '--no-update-icon-cache' are not 
standard distutils/setuptools options. We cannot handle anything called 
'setup.py' with our %py_* macros, like our '%configure' macro usually 
doesn't work with 'configure' scripts made by hand and not with autoconf.


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

Re: RFC: default python installlation directories

[Jacek Konieczny]

On 2015-12-18 13:03, Elan Ruusamäe wrote:


perhaps add macro which is to be defined in .spec:

%define py_install_options --no-compile-schemas --no-update-icon-cache

%py_install


For a single spec?

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

Re: pythonegg() vs manual dependencies

[Jacek Konieczny]

On 2015-12-02 16:33, Jakub Bogusz wrote:
> Currently many packages, for which pythonegg()/python3egg() dependencies
> are generated, have the same set of dependencies (or outdated version of it)
> specified manually in .spec by package name.

We can do that.

> Manually specified dependencies duplicating autodetected ones could be
> dropped now, but what should be specified as rpm-pythonprov version to
> ensure functional pythonegg/python3egg depdencies detector?

rpm-pythonprov-5.4.15-31 seems to work properly now, but versions before
my optimizations were also ok. The broken RPM never got into th-main AFAIK.

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

Re: [packages/python] Prevent pyconfig.h conflicts on multiarch systems

[Jacek Konieczny]

On 2015-12-02 15:54, Jacek Konieczny wrote:
> On 2015-12-02 15:35, Jakub Bogusz wrote:
>> On Wed, Dec 02, 2015 at 02:56:28PM +0100, Jacek Konieczny wrote:
> 
>>> At least for this:
>>> https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422
>>>
> 
>>
>> get_config_h_filename() should return the ABI-specific file for multilib
>> installs to work correctly.
> 
> But then virtualenv will probably fail to copy the right file to the
> right place when making the virtual environment. I will check this, though.

It seems virtualenv symlinks whole python include directory and would
not mind different pyconfig*.h files. So patching
get_config_h_filename() and making pyconfig.h include platform-dependent
header could work.

Now I have questions:
1. how should we call thee platform-dependent header files?
2. What set of #if/#ifdef should i use in pyconfig.h to include proper
file on a platform?

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

Re: [packages/python] Prevent pyconfig.h conflicts on multiarch systems

[Jacek Konieczny]

On 2015-12-02 15:35, Jakub Bogusz wrote:

On Wed, Dec 02, 2015 at 02:56:28PM +0100, Jacek Konieczny wrote:



At least for this:
https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422





get_config_h_filename() should return the ABI-specific file for multilib
installs to work correctly.


But then virtualenv will probably fail to copy the right file to the 
right place when making the virtual environment. I will check this, though.


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

Re: RFC: default python installlation directories

[Jacek Konieczny]

On 2015-12-01 19:57, Jan Rękorajski wrote:
> Well, icedove still doesn't build, this time with:
[...]
> checking Python environment is Mozilla virtualenv... Traceback (most recent 
> call last):
>   File "", line 1, in 
> ImportError: No module named mozbuild.base
> configure: error: Python environment does not appear to be sane.

Try python-2.7.10-6.1 and rpm-build-macros-1.713

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

Re: [packages/python] Prevent pyconfig.h conflicts on multiarch systems

[Jacek Konieczny]

On 2015-12-01 23:19, Elan Ruusamäe wrote:
> On 01.12.2015 19:49, jajcus wrote:
>>  The hack is to have architecture-specific pyconfig-*.h files and
>> a ghost
>>  symlink updated with python-devel install. I hope this works.
> 
> a cleaner way is to install wrapper header file which based on
> preprocessor variables includes proper arch specific file
> no triggers, no scriptlets, no ghosts.

Is it better now?

Jacek

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

Re: [packages/python] Prevent pyconfig.h conflicts on multiarch systems

[Jacek Konieczny]

On 2015-12-02 13:03, Elan Ruusamäe wrote:

How would you convince python library to parse this file correctly?
Another PLD-specific Python patch, which would cause many standard
Python packages to fail?

My solution is not pretty, but doesn't change a thing from the Python
perspective.


ee, what patch?


At least for this:
https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422

There might be other Python code parsing this header, as it is 
considered a part of standard Python interface.



i'm speaking of installing "config.h" from static source111, and python
original rename as config-ARCH.h when packaging.
and the preprocessor macros are generic, from compiler


But this file is not only used by the C compiler. If it would be the 
case, then we would ship the file in the -devel package and not the 
-libs packages and there would be no problem.


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

Re: RFC: default python installlation directories

[Jacek Konieczny]

On 2015-12-01 19:57, Jan Rękorajski wrote:
> On Tue, 01 Dec 2015, Jacek Konieczny wrote:
> Well, icedove still doesn't build, this time with:
> 
> Creating Python environment
> New python executable in 
> /home/users/baggins/devel/PLD/rpm/BUILD/icedove-38.4.0/obj-x86_64/_virtualenv/bin/python2.7
> Also creating executable in 
> /home/users/baggins/devel/PLD/rpm/BUILD/icedove-38.4.0/obj-x86_64/_virtualenv/bin/python
> Installing setuptools, pip, wheel...done.
> running build_ext
> 
> checking Python environment is Mozilla virtualenv... Traceback (most recent 
> call last):
>   File "", line 1, in 
> ImportError: No module named mozbuild.base
> configure: error: Python environment does not appear to be sane.
> -- config.log --
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> 
> Doesn't matter if I use mozilla virtualenv, our virtualenv or virtualenv-2.7.

I can see what is the problem now. I'll try to fix it tomorow.

Lets keep that lib/share split only for the site-packages under the /usr
prefix. We need it there. /usr/local and virtualenvs can have the Python
way.

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

Re: RFC: default python installlation directories

[Jacek Konieczny]

On 2015-11-30 09:19, Jan Rękorajski wrote:
> On Mon, Nov 30, 2015 at 8:07 AM, Jacek Konieczny <jaj...@jajcus.net> wrote:
>> On 2015-11-29 23:30, Jan Rękorajski wrote:

>>> OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7'

>> I will investigate this further in the evening.
> 
> A food for thought - what about dropping PLD specific hack with with
> lib<->share split?
> It constantly gives us grief with virtualenv.

I guess I have managed to fix that. Vanila upstream virtualenv seems to
work correctly now, at least when not using --system-site-packages.

I hope I have not introduced many new problems ;)

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

Re: [packages/python] Prevent pyconfig.h conflicts on multiarch systems

[Jacek Konieczny]

On 2015-12-01 23:19, Elan Ruusamäe wrote:

On 01.12.2015 19:49, jajcus wrote:

 The hack is to have architecture-specific pyconfig-*.h files and
a ghost
 symlink updated with python-devel install. I hope this works.


a cleaner way is to install wrapper header file which based on
preprocessor variables includes proper arch specific file
no triggers, no scriptlets, no ghosts.


…and new compatibility problems with all the Python world,


and if the file is identical on both multilib packages, rpm will happily
install it without complaining

so, it would be something like:

#if X86_64
#include "py-x86_64.h"
#elseif IX86
#include "py-ix86.h"
#else
#error unsupported arch
#endif


How would you convince python library to parse this file correctly? 
Another PLD-specific Python patch, which would cause many standard 
Python packages to fail?


My solution is not pretty, but doesn't change a thing from the Python 
perspective.


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

Re: RFC: default python installlation directories

[Jacek Konieczny]

On 2015-11-30 09:19, Jan Rękorajski wrote:
> A food for thought - what about dropping PLD specific hack with with
> lib<->share split?
> It constantly gives us grief with virtualenv.

Ok, now I can see what can be done. We need to keep the split between
/usr/{lib64,share}/pythonX.Y/site-packages – for noarch packages, but
there is probably no reason to split the Python package itself into
/usr/{lib64,share}/pythonX.Y. That should help virtualenv.

But I first check if there is no easier way.

Jacek

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

Re: [packages/sphinx-pdg] py_build/py_install macros, use python3 by default

[Jacek Konieczny]

On 2015-11-30 21:07, Jakub Bogusz wrote:
> On Sat, Nov 28, 2015 at 03:11:04PM +0100, jajcus wrote:
>> commit b9b9d28833bd29bd614464718b69ccd003ea238b
>> Author: Jacek Konieczny <jaj...@jajcus.net>
>> Date:   Sat Nov 28 15:10:30 2015 +0100
>>
>> py_build/py_install macros, use python3 by default
> 
> Maybe always create both -2 and -3 (with non-bconditional content)
> and base package with just symlinks to default version (bconditional)?

I assumed that a package with symlinks only is a bad idea. Though I am
not very attached to this assumption.

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

Re: [packages/python-amqp] fix apidocs build

[Jacek Konieczny]

On 2015-11-30 21:13, Jakub Bogusz wrote:
> On Mon, Nov 30, 2015 at 07:17:21PM +0100, jajcus wrote:
>> commit 8df16ed9ea864060d2f64e4da41c5b7261d4f1ad
>> Author: Jacek Konieczny <jaj...@jajcus.net>
>> Date:   Mon Nov 30 19:16:45 2015 +0100
>>
>> fix apidocs build
> 
>>  %if %{with doc}
>>  BuildRequires:  python-sphinxcontrib-issuetracker
>> -BuildRequires:  sphinx-pdg
>> +BuildRequires:  sphinx-pdg-2
>>  %endif
>>  %endif
>>  %if %{with python3}
>> @@ -40,6 +40,10 @@ BuildRequires:python3-mock
>>  BuildRequires:  python3-nose
>>  BuildRequires:  python3-nose-cover3
>>  %endif
>> +%if %{with doc}
>> +BuildRequires:  python3-sphinxcontrib-issuetracker
>> +BuildRequires:  sphinx-pdg-3
>> +%endif
>>  %endif
> 
>> @@ -120,6 +145,12 @@ rm -rf $RPM_BUILD_ROOT
>>  %dir %{py_sitescriptdir}/%{module}/tests
>>  %{py_sitescriptdir}/%{module}/tests/*.py[co]
>>  %{py_sitescriptdir}/%{module}-%{version}-py*.egg-info
>> +
>> +%if %{with doc}
>> +%files apidocs
>> +%defattr(644,root,root,755)
>> +%doc docs/.build2/html/*
>> +%endif
>>  %endif
>>  
>>  %if %{with python3}
>> @@ -128,10 +159,10 @@ rm -rf $RPM_BUILD_ROOT
>>  %doc Changelog README.rst
>>  %{py3_sitescriptdir}/%{module}
>>  %{py3_sitescriptdir}/%{module}-%{version}-py*.egg-info
>> -%endif
>>  
>>  %if %{with doc}
>> -%files apidocs
>> +%files -n python3-%{module}-apidocs
>>  %defattr(644,root,root,755)
>> -%doc docs/.build/html/*
>> +%doc docs/.build3/html/*
>> +%endif
>>  %endif
> 
> Why -apidocs for both python versions?
> Does documentation differ?

It may differ. Python 3 version may have extended API (using the new
features) or one of versions (Python 2 or Python 3) may be not
feature-complete.

Also, it was easier to handle the with_python2/with_python3 bconds.

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

Re: RFC: default python installlation directories

[Jacek Konieczny]

On 2015-11-30 09:19, Jan Rękorajski wrote:

A food for thought - what about dropping PLD specific hack with with
lib<->share split?


What do you choose?
– binaries (*.so) in /usr/share and conflicts between x86_64 and i686 
packages
– all python modules in %{_libdir} and no more 'noarch' Python packages 
(as %{_libdir} is different on x86_64 and i686)
– all python modules in /usr/lib – pure python modules could stay 
'noarch', but binary modules (*.so) would conflict between x86_64 and 
i686 packages


However we handle dropping the the split, it will cause new problems.


It constantly gives us grief with virtualenv.


Does it?

The funny thing is that original Python sources have notion of different 
locations for platform-dependent and platform-independent modules. But 
those paths, on 'unix' differ by the prefix (--prefix vs --exec-prefix), 
not further path. I have no idea why they have chosen to ignore FHS. 
Other distributions have to patch this too, unless they ignore FHS or 
mult-lib installations too.


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

Re: RFC: default python installlation directories

[Jacek Konieczny]

On 2015-11-29 10:51, Elan Ruusamäe wrote:
> looks like python egg dependency generator is broken, none provided:
> 
> ➔ rpm -q --provides python-defusedxml
> python-defusedxml = 0.4.1-7

Already fixed in rpm.

> https://srcbuilder.pld-linux.org/~pldth/qa.php?q=main-ready-test
> currently 30 matches for missing "pythonegg", it will probably grow as
> the queue is big

I will rebuild the affected packages when this batch is done.

> ps: should use bigger than default pri=2 when doing mass builds, so
> normal builds get built first.

I will remember the next time.

Jacek

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

Re: [packages/python-setuptools] adapter, use realtive symlink

[Jacek Konieczny]

On 2015-11-28 15:16, glen wrote:
> commit b6cbc91d94c8fad86e0ad1b271429f6772218700
> Author: Elan Ruusamäe 
> Date:   Sat Nov 28 16:16:47 2015 +0200
> 
> adapter, use realtive symlink
[...]

> -ln -f $RPM_BUILD_ROOT/%{_bindir}/easy_install-%{py3_ver} 
> $RPM_BUILD_ROOT/%{_bindir}/easy_install
> +ln -sf easy_install-%{py3_ver} $RPM_BUILD_ROOT%{_bindir}/easy_install
>  %else
> -ln -f $RPM_BUILD_ROOT/%{_bindir}/easy_install-%{py_ver} 
> $RPM_BUILD_ROOT/%{_bindir}/easy_install
> +ln -sf easy_install-%{py_ver} $RPM_BUILD_ROOT%{_bindir}/easy_install
>  %endif

Why symlink? There was a hard-link for purpose. No need for extra
redirection. And there are no relative hard links.

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

Re: ERRORS: libmateweather.spec OK: libmatekbd.spec libmatemixer.spec mate-menus.spec

[Jacek Konieczny]

On 2015-11-28 20:12, Jacek Konieczny wrote:
> Clearly some access before the buffer.

Fixed, I think.

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

Re: ERRORS: libmateweather.spec OK: libmatekbd.spec libmatemixer.spec mate-menus.spec

[Jacek Konieczny]

On 2015-11-28 19:32, Arkadiusz Miśkiewicz wrote:

> reproduced (3 times in the same place) on carme-i686 by doing
> 
> ../builder -bi python-setuptools.spec
> while (rpmbuild --short-circuit -bi python-setuptools.spec); do echo x; done
> 
> ~50 iterations, 10 minutes to reproduce

No need to build anything.


valgrind rpm --eval '%{?__noautoprovfiles}'

shows the problem:

==102752== Conditional jump or move depends on uninitialised value(s)
==102752==at 0x429E22B: doShellEscape (in /lib/librpmio-5.4.so)
==102752==by 0x429CACA: expandMacro (in /lib/librpmio-5.4.so)
==102752==by 0x429EA11: expandT (in /lib/librpmio-5.4.so)
==102752==by 0x429D1D6: expandMacro (in /lib/librpmio-5.4.so)
==102752==by 0x429DE86: expandMacros (in /lib/librpmio-5.4.so)
==102752==by 0x429DFEA: rpmExpand (in /lib/librpmio-5.4.so)
==102752==by 0x40D70B5: rpmcliAllArgCallback (in /lib/librpm-5.4.so)
==102752==by 0x4635F5BC: ??? (in /lib/libpopt.so.0.0.0)
==102752==by 0x4635F5F6: ??? (in /lib/libpopt.so.0.0.0)
==102752==by 0x46360EB5: poptGetNextOpt (in /lib/libpopt.so.0.0.0)
==102752==by 0x40D778C: rpmcliInit (in /lib/librpm-5.4.so)
==102752==by 0x8049CB7: main (in /bin/rpm)

Having anything before the expanded macro will fix it:

valgrind rpm --eval 'x%{?__noautoprovfiles}'

Clearly some access before the buffer.

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

Re: RFC: default python installlation directories

[Jacek Konieczny]

On 2015-11-27 10:28, Elan Ruusamäe wrote:

On 25.11.2015 22:19, Jacek Konieczny wrote:

If there are no objections, I may try a mass-update of python-* specs
tomorrow.


more like in the weekend ;)


afaik not all packages supported --build-base thing. i don't know why.


Most current Python packages can use setup.py same way. There might be 
problem with outdated packages, but you can find such which wouldn't 
even use 'setup.py' at all.


I think a very small minority of the packages would be broken by 
replacing setup.py with py_build/py_install.


Most of our python specs that don't use '--build-base' are those which 
were never updated for Python 3 support or which were written before the 
'--build-base' trick was known to the spec author.




you can find such packages with something like this:

➔ grep -r 'set --' ~/all-specs
/home/users/glen/all-specs/python-httplib2.spec:set -- *


Are you sure this is not some alternative to the '--build-base'?

But thanks, I will look at those.

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

Re: RFC: default python installlation directories

[Jacek Konieczny]

On 2015-11-22 18:52, Jan Rękorajski wrote:
> On Sun, 22 Nov 2015, Jacek Konieczny wrote:
>>
>> I suggest patching python, python3 and, if neccessary, other packages,
>> so distutils/setuptools/pip would install Python modules to /usr/local
>> by default – like autoconf configure scripts do. Python would look for
>> modues in /usr/local first and then in /usr.
> 
> Makes sense. Go ahead and do it.

Done.

New RPM build macros added:
%py_build
%py_install
%py3_build
%py3_install

Just %setup_py and %setup_py3 wouldn't do as we cannot change options
order:
'setup.py --prefix=/usr install' is wrong,
'setup.py install --prefix=/usr' is ok.

I have updated the python template specs and a few packages. Things
seems to work well. Including distutils, setuptools and pip.

If there are no objections, I may try a mass-update of python-* specs
tomorrow.

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

Re: Terrible performance of Python dependency generator

[Jacek Konieczny]

On 2015-11-22 22:03, Jeffrey Johnson wrote:

Dependencies are automatically generated only for executable files.


That is not true for Python dependencies and this would not work for
Python dependencies.

There are two useful types of Python dependencies:

1. python(abi) – this is extracted from .pyc or .pyo files. These are
not the executable scripts, but non-executable library files in /usr/lib
or /usr/share. Checking a single *.py[co] file would do for the whole
package. On the other hand, this dependency is a bit redundant, because
files for each python abi are going to a different directory and the
directory dependency should be enough.

2. pythonegg(*) – this are extracted from meta-data in *.egg-info
directories. A package usually contains only one such directory.

Currently it works as all /usr/{lib*,share}/pythonX.Y/* files are passed
to pythoneggs.py. Among this file there would be some *.pyc and some
file from the egg-info directory, so all the important dependencies
would be extracted.

Examining only the executables would return only the '/usr/bin/python',
or even '/bin/sh' dependency.

I guess I will hack rpmfc.c to run Python helper only for a single
py[co] file and a single file in every egg-info directory.


So
using %files -f manifest, one can make a pass in %install to generate
the manifest, and doing both
1) add a %attr marker to set the execute bits
2) chmod -x on the file in %buildroot

and then generate dependencies manually (using a two pass build to
edit Requires: etc into the spec file.


Sounds like a very ugly hack.

BTW we don't need a manifest to preserve proper file permissions as in
PLD we _always_ provide permissions explicitly in %files. So we could
just chmod -R a-x all the Python files. But that is not what file
permissions are for!


The better fix would be to use the embedded python interpreter yo
avoid repeatedly involving a shell that invokes python.


That wouldn't work much better than no repeat a stupid check for each file.


Bur the fundamental problem is with user overridable external
helper scripts that conform to ancient expectations of the helper API
and still must classify files and generate cross referenced tag data
dynamically.


The 'ancient expectations of the helper API' actually made some sense in
terms of performance (single process to handle a file list). Executing
any external process for every file is plain stupid.

And Python (and probably not only Python) dependencies are not per-file,
but per python package. Linking dependencies checks to specific files is
quite artificial.

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

RFC: default python installlation directories

[Jacek Konieczny]

Hi,

Most Python HOWTOs and similar resources suggest using 'pip',
'easy_install' or other tools to install python modules or python-based
programs. The problem is, that in PLD those tools would install modules
in /usr/{lib{64},share}/pythonX.Y/site-packages – the same place, where
python modules from our RPM packages go.

This is a mess and may destroy already installed packages – using pip to
install a single innocent program may cause chain reaction of installing
dependency modules and overwitting old versions of those already in the
system.

virtualenv can help, but only if one chooses to use it.

I suggest patching python, python3 and, if neccessary, other packages,
so distutils/setuptools/pip would install Python modules to /usr/local
by default – like autoconf configure scripts do. Python would look for
modues in /usr/local first and then in /usr.

Effects:

1. easy_install/pip/etc  would not overwrite distribution packages –
that is what we want.

2. modules installed with easy_install/pip/etc would override those
installed from RPM – that is what the user would expect installing
something manually.

3. No existing python-*.spec would build any more.

All python specs would need to be updated to force proper instalation
directories. I would prepare %setup_py2 and %setup_py3. Those would use
proper python interpreter and compiler flags too.

I guess a 'sed' job on all the python-*.spec would do the trick for most
packages.

4. Existing packages (except, maybe, a few exceptions, like pip itself
would not have to be rebuilt immediately – the paths used by the
packages would still be ok

What do you think?

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

Re: RFC: default python installlation directories

[Jacek Konieczny]

On 2015-11-22 16:57, Tomasz Pala wrote:
> On Sun, Nov 22, 2015 at 13:25:16 +0100, Jacek Konieczny wrote:
> 
>> I suggest patching python, python3 and, if neccessary, other packages,
>> so distutils/setuptools/pip would install Python modules to /usr/local
>> by default ??? like autoconf configure scripts do. Python would look for
>> modues in /usr/local first and then in /usr.
> 
> If any tool installs anything with /usr prefix, not /usr/local, this
> should be considered as a bug and reported upstream. FHS clearly states
> that /usr/local should be used, so go ahead with this approach.

Python's default prefix is /usr/local, but that is, obviously, changed
for our python package. Most python software use the paths provided by
python standard library and that is the prefix Python was configured
with.

Please note that Python software is built for Python, not for Linux, so
python specifications (official Python documentation and various PEPs)
are follwed first. If that could be solved upstream Debian would already
forced that, but they use patches similar to what I suggest.

>> 3. No existing python-*.spec would build any more.
>>
>> All python specs would need to be updated to force proper instalation
>> directories. I would prepare %setup_py2 and %setup_py3. Those would use
>> proper python interpreter and compiler flags too.
> 
> Can't this be accomplished by detecting some environment variables?

Probably, but I don't think this is the most elegant solution. We
usually don't use rpm-build-specific variables and rather use
'%configure', '%cmake' and similar macros or pass the parameters to the
build process directly. Another set of macros for Python software seems
consistent with that.

>> What do you think?
> 
> I'm really tired of not having the ability to run some code just because
> there is no PLD package (and no point in creating one, there are dozens
> of perl/python/ruby modules) and I already have some other installed
> from rpms.

So you understand the problem well :)

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

Terrible performance of Python dependency generator

[Jacek Konieczny]

Hi,

We will probably need to rebuild the python-* packages again and I
already hate that. Such python-django takes 45 minutes to build and most
of that is in the auto-dependency generator. That is insane! It should
not take that long!

/usr/lib/rpm/pythoneggs.py is used to find the dependencies and it is
not that slow by itself… but it is called twice (Provides + Requires)
for each file in /usr/share/pythonX.Y. And big Python packages have lots
of files there. Most of them not adding any extra dependency
information.

That is strange, as the dependency helpers accept list of file names on
their stdout… and RPM (in lib/rpmfc.c) always feeds them with one
filename only. Why is that?

I can even see a buffer for a file list in the code (iob_python in the
rpmfc_s struct), but it seems not used.

I tried to invent some smart hack to limit number of files examined –
usually checking a single *.py file and the *.egg-info/PKG-INFO should
be enough, but I was not able to inject this in the weird rpmfc logic.
And I do not quite understand what it is supposed to do (what are those
'colors' and what files should be python-colored).

Can this be fixed somehow? How have we ended with this?

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

OpenJDK 8

[Jacek Konieczny]

Hi,

I have prepared openjdk8 packages, so we finally have Java 8 in PLD.
We used to use IcedTea to build Java 7 from OpenJDK7 source and a few
other projects, but OpenJDK8 is more self-contained and could be built
directly. That causes package name change, but it may also mean, that
the new packages are missing something.

Please test the new openjdk8-* packages with your favorite Java software
and let me know if everything works as expected. 'openjdk8' should
replace 'icedtea7' in PLD soon.

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

Re: systemd /tmp tmpfs

[Jacek Konieczny]

On 2015-09-17 12:54, Elan Ruusamäe wrote:

On 17.09.2015 13:14, Tomasz Pala wrote:

On Wed, Sep 16, 2015 at 16:16:20 +0300, Elan Ruusamäe wrote:


what's more annoying is that it's mounted "as soon as it (systemd) can"
meaning in the middle of working x11-session (GRRR!)

Maybe something in this session activated it via dbus? This shouldn't
happen when tmp.mount is masked though, so was it before that happened?


tmp.mount was not masked, masking of course helped. but i never masked
it before, so something changed that now i need to mask

i would prefer if default is masked, and should unmask to enable /tmp
tmpfs.


To make PLD different to anything else in yet another way?

I would prefer sticking to the systemd ways. They usually have good 
reasons to do things one way or another.


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

Re: [packages/systemd] removed depreciated /etc/timezone, fixed /var/log/btmp group and mode, adjusted /etc/machine-id and

[Jacek Konieczny]

On 2015-09-07 07:15, Jan Rękorajski wrote:

attr 444 on machine-id is really no different than defattr 644.


But that is what systemd uses by default, I guess it is a hint to the 
administrator that this file should really never ever be modified.


[jajcus@jajo ~]$ systemd-machine-id-setup --root=/tmp/dupa
Initializing machine ID from random generator.
[jajcus@jajo ~]$ ls -l /tmp/dupa/etc/
total 4
-r--r--r-- 1 jajcus users 33 Sep  7 10:01 machine-id

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