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

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

Re: firefox and builders...

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

git push: No space left on device

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

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

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

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

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/ru

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

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 r

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

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]:

Re: python3 only packages

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

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

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

PLD New Rescue Th-2018 1.6

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

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

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

Mesa 18.3.0, Meson, LLVM, RTTI and OpenCL

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

Re: glibc and ldconfig dependency loop

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 %

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

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

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

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

Re: openssl 1.1.1 rebuild - need for help

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

Re: openssl 1.1.1 rebuild - need for help

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

Re: less aggressive glibc rebuilds

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

openssl manual pages broken?

[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

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

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. >

Re: libexec and multi-arch

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

Re: Mesa 17.2 from th-test is broken

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

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

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

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

<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://

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

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";

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

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

Re: Going back to IcedTea, openjdk8 is obsolete

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-

Re: Going back to IcedTea, openjdk8 is obsolete

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

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

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

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

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

Re: [packages/tzdata] break dependency loop

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

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

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

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

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

Re: mysql/percona/maria...

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. >

Re: nginx-standard drop

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.

Re: nginx-standard drop

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

Re: nginx-standard drop

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

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

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)

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

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

Re: apache-mod_wsgi.spec

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

Going back to IcedTea, openjdk8 is obsolete

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

Re: npm and bundled modules

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

distfiles misbehaving

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

Re: udev rules help

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

Re: udev rules help

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",

Icedtea8 and x32

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

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

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

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

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

Re: python packaging

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.

Re: ERRORS: openchange.spec

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

Re: ldconfig forgotten

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

Re: ping package

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

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

Re: /usr/lib64/jvm/java symlink

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

Re: python3 optional deps

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

Re: python3 optional deps

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

Re: python3 optional deps

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"':

Re: python rebuild procedure?

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

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

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

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

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

Re: PLD New Rescue th2015-1.5

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

PLD New Rescue th2015-1.5

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

Re: rescue

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

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

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

Re: Vulkan 3D drivers test request

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

Re: Vulkan 3D drivers test request

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

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

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

Vulkan 3D drivers test request

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'

Re: alsa vs bacula

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

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

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

Re: distribute

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

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

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 som

Re: RFC: default python installlation directories

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

Re: RFC: default python installlation directories

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

Re: pythonegg() vs manual dependencies

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

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

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

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

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

Re: RFC: default python installlation directories

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

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

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

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

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

Re: RFC: default python installlation directories

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/_virtua

Re: RFC: default python installlation directories

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 investiga

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

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

Re: RFC: default python installlation directories

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 –

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

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

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

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

Re: RFC: default python installlation directories

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

Re: RFC: default python installlation directories

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

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

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} >

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

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

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

Re: RFC: default python installlation directories

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

Re: RFC: default python installlation directories

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 c

Re: Terrible performance of Python dependency generator

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

RFC: default python installlation directories

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

Re: RFC: default python installlation directories

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 ???

Terrible performance of Python dependency generator

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

OpenJDK 8

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

Re: systemd /tmp tmpfs

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

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

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

  1   2   3   4   >