Re: Firefox

[Jan Palus]

On 16.10.2005  17:52, Patrys :: Patryk Zawadzki wrote:
 Could you do the same with the --enable-optimization line removed? I
 think this might be the problem and having this removes is still better
 than using Mozilla-provided binary packages (and they happen to have
 this option removed when compiling anyway).

No change, the same problem.

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

Re: Firefox

[Jan Palus]

I played with mozilla-firefox.spec today and managed to get more or
less working firefox. I disabled freetype2 and enabled xft because
firefox starts then and after all offical realeses seem to be built
this way. The issues with faq.fedora.pl (see pld-users) and search
engines crashing firefox were fixed by removing --enable-native-uconv.
I have no idea why it breaks stuff, I just wanted to get rid of these
problems. I'm not sure about the memory corruption issue (strange
characters) - I haven't seen any wrongly rendered page so far.
Could someone provide any URL that is 100% testcase, so I could
check it.

You can download those builds at:
http://polaris.put.poznan.pl/~jan.palus/mozilla-firefox-1.0.7-2.1.i686.rpm
http://polaris.put.poznan.pl/~jan.palus/mozilla-firefox-lang-en-1.0.7-2.1.i686.rpm

Diff for spec attached.

-- 
atler
Index: mozilla-firefox.spec
===
RCS file: /cvsroot/SPECS/mozilla-firefox.spec,v
retrieving revision 1.109
diff -u -r1.109 mozilla-firefox.spec
--- mozilla-firefox.spec15 Oct 2005 16:19:55 -  1.109
+++ mozilla-firefox.spec18 Oct 2005 14:27:51 -
@@ -195,13 +195,12 @@
 ac_add_options --disable-ldap
 ac_add_options --disable-mailnews
 ac_add_options --disable-profilesharing
-ac_add_options --disable-xft
+ac_add_options --enable-xft
 ac_add_options --disable-xprint
 ac_add_options --enable-crypto
 ac_add_options --enable-default-toolkit=gtk2
-ac_add_options --enable-freetype2
+ac_add_options --disable-freetype2
 ac_add_options --enable-mathml
-ac_add_options --enable-native-uconv
 ac_add_options --enable-reorder
 ac_add_options --enable-single-profile
 ac_add_options --enable-strip
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

shaperd.2.spec

[Jan Palus]

Few patches to shaperd.2:
- updated to the latest snap
- changed versioning scheme to enable updates (DDMMYY-YYMMDD)
- passing and respecting CC and CFLAGS by make
- fixed bug causing random crashes of shaperd (uninitialized var) -
  should be fixed in next realese.

Please review the patches and if good enough add them. Thanks.

-- 
atler
Index: shaperd.2.spec
===
RCS file: /cvsroot/SPECS/shaperd.2.spec,v
retrieving revision 1.28.2.1
diff -u -r1.28.2.1 shaperd.2.spec
--- shaperd.2.spec  27 Jun 2005 14:46:58 -  1.28.2.1
+++ shaperd.2.spec  29 Oct 2005 12:44:36 -
@@ -2,8 +2,8 @@
 Summary:   Shaperd - bandwidth limiting
 Summary(pl):   Shaperd - dzielenie łącza
 Name:  shaperd.2
-%definesnap060505
-Version:   2.24
+%definesnap050805
+Version:   2.25
 Release:   0.%{snap}.1
 License:   GPL
 Group: Networking/Admin
@@ -11,11 +11,13 @@
 # Changed source to decrease traffic at republika.pl
 #Source0:  http://www.cbq.trzepak.net/prg/%{name}.%{version}.tar.gz
 Source0:   http://www.cbq.trzepak.net/prg/shaperd_snapshot.tar.gz
-# Source0-md5: 5695ba2968d40fd7045eb5859f31597f
+# Source0-md5: 94ab3a29a74c97ad830a4cb3a581dc8f
 Source1:   %{name}.init
 Source2:   %{name}.conf
 Patch0:%{name}-fhs.patch
 Patch1:%{name}-iptables_path.patch
+Patch2:%{name}-makefile.patch
+Patch3:%{name}-crash_fix.patch
 #URL:  http://sp9wun.republika.pl/linux/shaperd_cbq.html
 URL:   http://www.cbq.trzepak.net/linux/shaperd_cbq.html
 PreReq:rc-scripts
@@ -55,13 +57,13 @@
 %setup -q -n shaperd
 %patch0 -p1
 %patch1 -p1
+%patch2 -p1
+%patch3 -p1
 
 %build
-%{__make}
-
-#{__make} \
-#CC=%{__cc} \
-#CFLAGS=%{rpmcflags} -Wall
+%{__make} \
+   CC=%{__cc} \
+   CFLAGS=%{rpmcflags} -Wall
 
 %install
 rm -rf $RPM_BUILD_ROOT
diff -Nur shaperd.old/Makefile shaperd/Makefile
--- shaperd.old/Makefile2005-10-29 13:47:51.0 +0200
+++ shaperd/Makefile2005-10-29 14:52:22.0 +0200
@@ -10,7 +10,9 @@
 
 MAKE=make
 INSTALL=install
-SYS_CC=gcc
+ifndef $(CC)
+   CC=gcc
+endif
 
 All: sources
 
diff -Nur shaperd.old/src/Makefile shaperd/src/Makefile
--- shaperd.old/src/Makefile2005-10-29 13:47:51.0 +0200
+++ shaperd/src/Makefile2005-10-29 14:52:38.0 +0200
@@ -13,24 +13,28 @@
 
 CFLAGS += -Wall
 
-CC = $(SYS_CC) $(DEFINES)
-
 shaperd: $(OBJS)
 
 shaperd.o: shaperd.c shaperd.h
+   $(CC) $(CFLAGS) $(DEFINES) -c $
 
 shaperd_old.o: shaperd_old.c shaperd_config.h shaperd_old.h read_config.h 
read_iplist.h firewall.h
-   $(CC) -c shaperd_old.c
+   $(CC) $(CFLAGS) $(DEFINES) -c $
 
 read_config.o: read_config.c read_config.h read_iplist.h firewall.h 
shaperd_old.h
+   $(CC) $(CFLAGS) $(DEFINES) -c $
 
 read_iplist.o: read_iplist.c read_iplist.h firewall.h shaperd_old.h
+   $(CC) $(CFLAGS) $(DEFINES) -c $
 
 firewall.o:firewall.c shaperd_config.h shaperd_old.h read_iplist.h
+   $(CC) $(CFLAGS) $(DEFINES) -c $
 
 shaperd_cmdline.o: shaperd_cmdline.c shaperd_config.h shaperd.h
+   $(CC) $(CFLAGS) $(DEFINES) -c $
 
 shaperd_helpers.o: shaperd_helpers.c
+   $(CC) $(CFLAGS) $(DEFINES) -c $
 
 clean-all: 
rm -f $(OBJS) 
--- shaperd/src/shaperd_old.c.orig  2005-10-29 14:38:34.0 +0200
+++ shaperd/src/shaperd_old.c   2005-10-29 14:38:40.0 +0200
@@ -3150,7 +3150,7 @@
 intf1,m,n;
 struct stat stbuf;
 unsigned long int  cnt1,cnt2;
-unsigned long int  dd1,dd2,dd3,dd4;
+unsigned long int  dd1,dd2 = 0,dd3,dd4;
 char   aa[12][20];
 char   *src;
 char   buf[30];
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: lstat.spec

[Jan Palus]

 - disabled building lstat with mod_perl1 support (with mod_perl1 live
   graphs are not generated for me)

Sorry, one more Req missing for apache1 build: apache1-mod_cgi.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

php5.1 with apache1

[Jan Palus]

# service apache start
Starting apache service.[FAIL ]
Processing config directory: /etc/apache/conf.d/*.conf
 Processing config file: /etc/apache/conf.d/01_mod_access.conf
 Processing config file: /etc/apache/conf.d/02_mod_alias.conf
 Processing config file: /etc/apache/conf.d/09_mod_log_config.conf
 Processing config file: /etc/apache/conf.d/12_mod_mime.conf
 Processing config file: /etc/apache/conf.d/20_common.conf
 Processing config file: /etc/apache/conf.d/70_mod_php.conf
Syntax error on line 1 of /etc/apache/conf.d/70_mod_php.conf:
Cannot load /etc/apache/modules/libphp5.so into server:
/etc/apache/modules/libphp5.so: undefined symbol:
php_mb_set_zend_encoding

# rpm -qa|grep 'apache\|php'
apache1-mod_php-5.1.1-5
apache1-apxs-1.3.34-5
apache1-mod_access-1.3.34-5
apache1-mod_mime-1.3.34-5
apache1-mod_alias-1.3.34-5
php-common-5.1.1-5
php-sqlite-5.1.1-5
php-pgsql-5.1.1-5
apache1-mod_log_config-1.3.34-5
php-pcre-5.1.1-5
apache1-1.3.34-5

arch: i[56]86

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

Re: AC TODO [19/01/2006]

[Jan Palus]

What about WindowMaker 0.92 from HEAD? It doesn't have full release. I'm
using it on i686/athlon without problems and it fixes some minor bugs.
If it's fine on other archs, it should go into ac.

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

ghc missing patches

[Jan Palus]

As our ghc on ftp is missing libreadline.so.5 dependency I wanted to
rebuild it myself and found that two patches are missing
(ghc-system-libffi.patch, ghc-system-haddock.patch). Could somebody
(glen?) add them to repo?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: HELP: New PLD Rescue CD

[Jan Palus]

On 05.06.2010 19:15, Arkadiusz Miskiewicz wrote:
 New PLD RescueCD is hopefuly to be produced at the end of this month but areq 
 needs help with fixing packages. 
 
 Current set of problems is at:
 
 http://pld.areq.eu.org/th-i486h/problems/
 
 Please help and commit fixes or email patches here.

cdrdao - fixed, should probably be built --without gnome also
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

texlive-jadetex fmt files

[Jan Palus]

I'm not familiar with texlive.spec and fetching 1gb of texlive
distribution just to test if a small commit works is not an option, so
I'll ask here (uzsolt?). Our texlive-jadetex is missing fmt files
(branch TEXLIVE_20080816, I don't care about HEAD as it's even bigger
mess with jadetex files section commented out). I'd like to add them to
generation list but the question is, where does fmtutil takes input
files from? Is it source distribution or should I add BR: texlive-jadetex?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: texlive-jadetex fmt files

[Jan Palus]

On 21.09.2010 15:04, Jan Palus wrote:
 I'm not familiar with texlive.spec and fetching 1gb of texlive
 distribution just to test if a small commit works is not an option, so
 I'll ask here (uzsolt?). Our texlive-jadetex is missing fmt files
 (branch TEXLIVE_20080816, I don't care about HEAD as it's even bigger
 mess with jadetex files section commented out). I'd like to add them to
 generation list but the question is, where does fmtutil takes input
 files from? Is it source distribution or should I add BR: texlive-jadetex?

I was enlightened by good people on #pld and missing fmt file was added
to texlive-texmf.spec.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: /proc for docker

[Jan Palus]

On 11.01.2014 19:44, Elan Ruusamäe wrote:
 root@e0ea0ce6904b:/# ls -l /proc
 ls: cannot access /proc/1: No such file or directory
 ls: cannot access /proc/10: No such file or directory

Just a wild guess, but that reminds me of issues with our default mount
option for /proc -- hidepid=2.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Building against ffmpeg with opencl

[Jan Palus]

Hi,

I'm trying to build new release of mpv against ffmpeg-2.2.5 which is now
built with opencl. Unfortunately I get undefined symbols during linking:

/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined 
reference to `clReleaseMemObject@OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined 
reference to `clReleaseCommandQueue@OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavfilter.so: 
undefined reference to `clFinish@OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined 
reference to `clSetKernelArg@OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavfilter.so: 
undefined reference to `clReleaseProgram@OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined 
reference to `clGetPlatformInfo@OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined 
reference to `clEnqueueUnmapMemObject@OPENCL_1.0'
/usr/lib64/gcc/x86_64-pld-linux/4.8.3/../../../../lib64/libavutil.so: undefined 
reference to `clCreateProgramWithSource@OPENCL_1.0'
...

I suppose it is somewhat connected to the fact that NVIDIA's libOpenCL
(which I have installed) does not provide versioned symbols. Any ideas
how this could be solved? Adding -lOpenCL fixes the problem but I don't
think it is a right direction.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Building against ffmpeg with opencl

[Jan Palus]

On 26.07.2014 15:48, Jan Palus wrote:
 On 26.07.2014 15:29, Jakub Bogusz wrote:
  (Side note: Mesa libOpenCL doesn't provide @OPENCL_1.0 versioning, AMD's
  (fglrx) IIRC does).
  
  Use ocl-icd libOpenCL, which redirects calls to selected target library
  (every implementation should provide a file in /etc/OpenCL/vendors dir).
 
 That fixed compilation indeed thanks, but is this ocl-icd preferred solution
 now?  Instead of providing custom ld.so.conf should nvidia libs require
 ocl-icd-libOpenCL along with ocl-icd vendor config?
 
 While compilation was fixed, it seems mpv is unable to start, probably
 due to failed opencl initialization in ffmpeg. Any ideas?
 
 % mpv
 X server found. dri2 connection failed! 
 Trying to open render node...
 open(/dev/dri/renderD128, O_RDWR) failed: No such file or directory

ok found the issue with OCL_ICD_DEBUG=2 - it turned out I had beignet
package installed which provides ocl-icd vendor file. Is there any way
to choose preferred vendor instead of running into such issues when one
only wants to play a movie?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Building against ffmpeg with opencl

[Jan Palus]

On 26.07.2014 16:18, Jan Palus wrote:
 ok found the issue with OCL_ICD_DEBUG=2 - it turned out I had beignet
 package installed which provides ocl-icd vendor file. Is there any way
 to choose preferred vendor instead of running into such issues when one
 only wants to play a movie?

One more observation based on mpv build - zsh completion is built at the
end of the process by invoking newly created binary: mpv --list-options
which failed silently with beignet package installed. This in turn
created corrupted completion file. While one may argue if build process
should continue after failed invocation, the problem remains that
builders should probably be independent of all this opencl vendors. No
idea how this should be solved as I have no working knowledge about
opencl.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [all] builder queue problem

[Jan Palus]

On 11.11.2015 16:06, PLD all builder wrote:
> there were problems sending files from queue 
> /home/pld/builderth/pld-builder.new/spool/notify:
> problems:
> [src: 
> /home/pld/builderth/pld-builder.new/spool/notify/897a4ea6-eea2-4ae7-9cdc-8b83a5f02230]
> 
>  (_ssl.c:581)>
> [src: 
> /home/pld/builderth/pld-builder.new/spool/notify/26618bd6-7ede-4d59-a629-c1ec3e8ce199]
> 
>  (_ssl.c:581)>
> [src: 
> /home/pld/builderth/pld-builder.new/spool/notify/5b33c564-6b37-4f58-be8c-96237f011088]
> 
>  (_ssl.c:581)>
> 

Can someone have a look or at least disable cron job until issue is
resolved so above message is not resent every 5min?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: consolekit

[Jan Palus]

On 03.11.2015 11:22, Elan Ruusamäe wrote:
> well, my actual problem is that i can no longer suspend laptop from 
> mate. have to type "poweroff" command, very annoying!

Just note from my side -- no issues with suspend/shutdown from mate
here, though it looks I don't even have consolekit installed:

> $ rpm -q ConsoleKit polkit lightdm systemd
package ConsoleKit is not installed
polkit-0.113-1.x86_64
lightdm-1.16.4-1.x86_64
systemd-221-7.x86_64
___
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

[Jan Palus]

On 07.11.2015 12:28, PLD th-i686 builder wrote:
> Conflicts: mate-applet-gweather < 1.6.1
> Processing files: libmateweather-devel-1.12.0-1.i686
> Segmentation fault

> ended at: Sat Nov  7 13:27:32 2015, done in 0:04:49.335941
> error: No files produced.

Can someone have a look what is failing on i686 builder? Seems to be
reproducible -- two attempts failed the same way.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Failed delivery of build request

[Jan Palus]

Could someone have a look why build request sent on Aug 30 keeps on
failing?

On 01.09.2015 19:18, Mail Delivery Subsystem wrote:
> This is an automatically generated Delivery Status Notification
> 
> THIS IS A WARNING MESSAGE ONLY.
> 
> YOU DO NOT NEED TO RESEND YOUR MESSAGE.
> 
> Delivery to the following recipient has been delayed:
> 
>  builde...@pld-linux.org
> 
> Message will be retried for 1 more day(s)
> 
> Technical details of temporary failure: 
> Google tried to deliver your message, but it was rejected by the server for 
> the recipient domain pld-linux.org by b.mx.pld-linux.org. [217.149.246.12].
> 
> The error that the other server returned was:
> 452 4.3.1 Insufficient system storage
> 
> 
> - Original message -
> 
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> d=gmail.com; s=20120113;
> h=sender:date:from:to:subject:message-id;
> bh=WGnmFPncFP3x+Sp6pv9u3LXOx4w5E7/8wHd5fMrvSCw=;
> b=mQ+OVhQl4XUr3mA2IagGOXwkVQIoavAfk33l+buIE7zgisnhHi0LfMpjP5lKjhXZhO
>  WWPsCKoX3CxIfVL5/fbZnCM6zUvwLP0mVv/IZRkVa0EnJM12vx0HhJIBAzq7IHW0QXvJ
>  Lxa5xTJOi1FNkotAiWhPLNAw0p+YP/7QTNYL1u4fN27JwXB+tJhwqhqseaHhbTwSiO6a
>  JLGKnXRKdnVXWINtu8xzesUPIvd50OpoJXwrCkeI59PZg6gODX2DaPi36nEE83nx06Qb
>  58mUpou0lZl+P7YyLmlyzTQR8ONfHxiftLjhGfGZAmyDVjMNkNCZ74P/YRwb1LSKLfxE
>  6e7A==
> X-Received: by 10.180.20.210 with SMTP id p18mr11847576wie.6.1440940674877;
> Sun, 30 Aug 2015 06:17:54 -0700 (PDT)
> Return-Path: <jan.pa...@gmail.com>
> Received: from localhost (dlb37.neoplus.adsl.tpnet.pl. [83.24.31.37])
> by smtp.gmail.com with ESMTPSA id 
> en5sm13161299wib.18.2015.08.30.06.17.49
> for <builde...@pld-linux.org>
>         (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
> Sun, 30 Aug 2015 06:17:53 -0700 (PDT)
> Sender: Jan Palus <jan.pa...@gmail.com>
> Date: Sun, 30 Aug 2015 15:17:49 +0200
> From: at...@pld-linux.org
> To: builde...@pld-linux.org
> Subject: build request
> Message-Id: <cc9096ea-1890-4c91-b7e7-43ac76e0c0cc@cukinia>
> X-New-PLD-Builder: request
> X-Requester-Version: 1.87
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
>   1440940669
>   2
> 
>   
>pidgin-sipe.spec
>HEAD
>
>
>
> 
> 
>  th-*
>   
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJV4wJ9AAoJEG1dyvySXCLzhnAIAI8vxPliNdP6daL8T8neDKdH
> qKnxvRJGO7dW9Yk4zTlfMlDpkKKsoppPatTt3WGiT2xV7QFViiAb5FUCj55NYltb
> Nt13FSVNcWO8c6xg57R+khZFyKNmH7G/nO7jgfmXHYsIUdFXSqgOwtrOVTEUNIVB
> OiPstztlIe9GnvprkAHLoez/w2OnnG0Mpjd2032PSXjpBab9GYNCbQ7Qs6mR+GAN
> kR3kQYvOLsx64cKexwTkHGE+3ZSbfPsv3SlzDOhuVNWIwfeFnqMN+sn03GVlGzm5
> cTmwVCswGZdxDHUBRiVZ85pYNPv8ZznYWHQRyQwU05IUp5Stb8Enj4eUpFVsrl0=
> =IuNy
> -END PGP SIGNATURE-
___
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

[Jan Palus]

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

[Jan Palus]

Are there any guidelines on how to adjust packages using automake for
python installation? In particular those using AM_PATH_PYTHON which
currently determines pythondir = ${prefix}/lib64/python3.5/site-packages
while previously it was evaluated to %{prefix}/share/python3.5/site-packages.
In my case the example package is redshift.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

building kernel modules

[Jan Palus]

In latest VirtualBox release there was an issue with building kernel
modules for LTS kernel 3.10 which was basically caused by missing
KERNELRELEASE definition. Since for one module build depends on
target kernel version, the decision was made incorrectly in the absence
of above var. Now from top level Makefile in kernel-headers:

KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)

kernel.release file is fine and contains correct value, however the
implicit requirement is to have $PWD pointing to kernel headers top dir.
That's not the case for our %build_kernel_modules macro which uses
O=$PWD/o in turn causing `cd $O` before evaluating KERNELRELEASE. As a
result KERNELRELEASE ends up empty.

As I'm not really proficient with build process of kernel modules, can
someone advise if O= is really necessary or is there some other way to
fix the issue?


___
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

[Jan Palus]

On 24.11.2016 00: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"
> 
> if you changed that "suggest xorg-driver-video" to "provides
> xorg-driver-video" you may as well just drop it, it's pointless because the
> dependency will resolve by package itself.
> 
> do you see the above comment there above?
> 
>  # Usual desktop setups need least one video driver to run, see xorg.log 
> which one exactly
>  Suggests:xorg-driver-video

Suggests is no longer there, but anyway I assume you don't want xserver
to provide video driver even though it provides video driver (so user
can select some other one). I don't really care so if there are no
objections I will replace Provides with Suggests tomorrow.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/VirtualBox] do not package vboxvideo_drv; kernel driver is now preferred

[Jan Palus]

On 23.11.2016 13:25, Jan Rękorajski wrote:
> What about older kernels? Will 3.18, 4.1 or 4.4 work as well?

I would assume so but didn't really check in practice. The only
prerequisites are KMS in kernel (present in 3.18) and xorg's modesetting
driver in userspace. From dependencies point of view I suppose we could
add P: xorg-driver-video-modesetting to xorg-xserver-server and
R: xorg-driver-video-modesetting to VirtualBox-guest-x11.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/VirtualBox] do not package vboxvideo_drv; kernel driver is now preferred

[Jan Palus]

On 23.11.2016 15:16, Jan Palus wrote:
> On 23.11.2016 13:25, Jan Rękorajski wrote:
> > What about older kernels? Will 3.18, 4.1 or 4.4 work as well?
> 
> I would assume so but didn't really check in practice. The only
> prerequisites are KMS in kernel (present in 3.18) and xorg's modesetting
> driver in userspace. From dependencies point of view I suppose we could
> add P: xorg-driver-video-modesetting to xorg-xserver-server and
> R: xorg-driver-video-modesetting to VirtualBox-guest-x11.

Anyway confirmed it works on 3.18.44 and 4.8.10 equally well.
___
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

[Jan Palus]

On 24.11.2016 07:23, Arkadiusz Miśkiewicz wrote:
> > Suggests is no longer there, but anyway I assume you don't want xserver
> > to provide video driver even though it provides video driver (so user
> > can select some other one). I don't really care so if there are no
> > objections I will replace Provides with Suggests tomorrow.
> 
> Well, modesetting works on any KMS hardware, so I would go with dropping 
> entire virtual xorg-driver-video thing from all drivers.

Except it might provide sluggish performance even in 2D like on many
NVIDIA chips which still lack reclocking in nouveau. I guess it could be
a valid reason to give user a choice of proprietary driver.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

cpio: File digest mismatch

[Jan Palus]

I've created a basic package for libguestfs fixed appliance 
(http://download.libguestfs.org/binaries/appliance/) however there seems to be 
an issue with how filesystem image is packaged by rpm. It's an ext2 fs file with 
size of 4G and only about ~256M used space:


$ file root
root: Linux rev 1.0 ext2 filesystem data, 
UUID=99344094-4997-41f9-9e01-73452b284ab3 (large files)

$ ls -lh root
-rw-r--r-- 1 jan users 4.0G 08-14 20:16 root

$ du -h root
275Mroot

Now rpm installation fails with:

error: unpacking of archive failed on file /usr/lib64/guestfs/root;5991e7a3: 
cpio: File digest mismatch

Looking at cpio output:

$ rpm2cpio libguestfs-appliance-fixed-1.36.1-1.x86_64.rpm|cpio -idmv
./usr/lib64/guestfs/initrd
./usr/lib64/guestfs/kernel
./usr/lib64/guestfs/root
cpio: warning: skipped 4026531840 bytes of junk
...

it seems like "free space" is just considered "junk". Not really sure if that's 
the issue but is there a way to tell rpm not to treat it as junk?



___
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

[Jan Palus]

On 19.09.2017 18:02, Jan Rękorajski wrote:

Xserver crashes for me after installing Mesa 17.2 from th-test
Updating ati driver does not help.


Arch has similar report:

https://bugs.archlinux.org/task/1

https://bugs.freedesktop.org/show_bug.cgi?id=101832

initially fixed by disabling swr but now I think this patch is supposed to fix 
it


https://bugs.freedesktop.org/attachment.cgi?id=133894
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/firefox] filterout -Werror=format-security to fix build with gcc7

[Jan Palus]

On 27.08.2017 17:39, Arkadiusz Miśkiewicz wrote:

On Saturday 26 of August 2017, atler wrote:

commit a132acc2832bf9003b9693a696c0cb6d96e44a5e
Author: Jan Palus <at...@pld-linux.org>
Date:   Sat Aug 26 22:25:55 2017 +0200

filterout -Werror=format-security to fix build with gcc7


Why not fix these errors instead?


If it was an issue with format I would fix it, but it's a problem with option 
parsing semantics in gcc:


$ gcc -Wformat -Werror=format-security -Wno-format test.c
$ rpm -q gcc
gcc-6.4.0-1.x86_64

$ gcc -Wformat -Werror=format-security -Wno-format test.c
cc1: error: -Wformat-security ignored without -Wformat [-Werror=format-security]
cc1: some warnings being treated as errors
$ rpm -q gcc
gcc-7.2.0-1.x86_64

Apparently firefox is quite selective about passing -Wno-format as most files 
are compiled without it. I prefer to wait until either gcc or firefox steps up 
and fixes it on their side.

___
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] - rel 1

[Jan Palus]

On 13.11.2017 19:18, Jan Rękorajski wrote:
> Good luck fixing almost all kernel module packages.
> Looks like there are some really breaking API changes :(

Note that it might be something with our packaging, macros, patches, other? (I'm
clueless about kernel build system). After unpacking vanilla kernel, taking same
.config as in kernel-4.14.0-1 and initial build, I can successfully build nvidia
driver and VirtualBox host driver after pointing them to full vanilla tree. On
builders you can see compilation does not even start -- nvidia attempts linking
before compilation? vbox does not find rule how to build object?
___
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-driver-video-nvidia] - drop ifarch mess and just make the package exclusevarch to x8664

[Jan Palus]

On 06.05.2018 12:56, baggins wrote:
> commit 2ea8529d8aa59a06136fff1888587dbb2c6ff24c
> Author: Jan Rękorajski 
> Date:   Sun May 6 12:55:39 2018 +0200
> 
> - drop ifarch mess and just make the package exclusevarch to x8664

The point of "ifarch mess" was to still be able to run 32bit apps (like most of
the games) on 64bit systems.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/poppler61] compatibility package with last poppler version supporting qt4 api (0.61.0)

[Jan Palus]

On 20.05.2018 21:21, Jakub Bogusz wrote:
> On Sun, May 20, 2018 at 09:11:52PM +0200, atler wrote:
> > commit 48b431eaeb96e110b3654a9f5984ad9e655b98f1
> > Author: Jan Palus <at...@pld-linux.org>
> > Date:   Sun May 20 21:09:36 2018 +0200
> > 
> > compatibility package with last poppler version supporting qt4 api 
> > (0.61.0)
> > 
> >  poppler61.spec | 375 
> > +++--
> 
> I'd suggest using poppler0.61 as name.
> The leading "0" would most likely change some day and "61" become
> ambiguous.

Thanks, renamed. However by the time it gets ambiguous I do hope we'll be done
with all legacy qt4 apps and this one.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: ERRORS: mate-applet-indicator.spec mate-terminal.spec mate-netbook.spec

[Jan Palus]

On 19.06.2018 00:38, PLD th-x32 builder wrote:
> poldek: Processing dependencies...
> poldek: gtk+3-devel-3.22.30-1.x32 marks 
> gobject-introspection-devel-1.56.1-1.x32 (cap /usr/share/gir-1.0)
> poldek:  gobject-introspection-devel-1.56.1-1.x32 marks glibc-misc-2.27-9.x32 
> (cap glibc-misc)
> poldek:   glibc-misc-2.27-9.x32 marks glibc-2.27-9.x32 (cap glibc = 6:2.27-9)
> poldek:glibc-2.27-8.x32 obsoleted by glibc-2.27-9.x32
> poldek:glibc-2.27-9.x32 marks ldconfig-2.27-9.x32 (cap ldconfig = 
> 6:2.27-9)
> poldek: ldconfig-2.27-8.x32 obsoleted by ldconfig-2.27-9.x32
...
> poldek: There are 23 packages to install (20 marked by dependencies), 2 to 
> remove:
> poldek: I gtk+3-devel-3.22.30-1.x32  libindicator-gtk3-devel-12.10.1-2.x32
> poldek: I mate-panel-devel-1.20.2-1.x32
> poldek: D Mesa-libwayland-egl-devel-18.1.2-1.x32  
> at-spi2-atk-devel-2.26.2-1.x32
> poldek: D at-spi2-core-devel-2.28.0-1.x32  atk-devel-2.28.1-1.x32
> poldek: D cairo-devel-1.14.12-2.x32  cairo-gobject-devel-1.14.12-2.x32
> poldek: D fontconfig-devel-2.13.0-3.x32  fribidi-devel-1.0.3-1.x32
> poldek: D gdk-pixbuf2-devel-2.36.12-1.x32  glibc-2.27-9.x32
> poldek: D glibc-misc-2.27-9.x32  gobject-introspection-devel-1.56.1-1.x32
> poldek: D ldconfig-2.27-9.x32  libthai-devel-0.1.27-1.x32
> poldek: D pango-devel-1.42.1-1.x32  pixman-devel-0.34.0-1.x32
> poldek: D python-Mako-1.0.4-2.noarch  wayland-protocols-1.13-1.noarch
> poldek: D xorg-lib-libXcomposite-devel-0.4.4-3.x32
> poldek: D xorg-lib-libXft-devel-2.3.2-2.x32
> poldek: R glibc-2.27-8.x32  ldconfig-2.27-8.x32
> poldek: This operation will use 24.3MB of disk space.
> poldek: Need to get 6.0MB of archives (70.1KB to download).
> poldek: 
> poldek: Retrieving [1/3] th::fribidi-devel-1.0.3-1.x32.rpm...
> poldek: ..done
> poldek: Retrieving [2/3] th::libindicator-gtk3-devel-12.10.1-2.x32.rpm...
> poldek: ..done
> poldek: Retrieving [3/3] th::mate-panel-devel-1.20.2-1.x32.rpm...
> poldek: ..done
> poldek: Executing pm-command.sh --upgrade -vh --test --root / --define 
> _check_dirname_deps 1...
> poldek: Preparing...
> ##
> poldek: error: Install/Erase problems:
> poldek:   file /usr/share/doc/glibc-2.27/NEWS.gz from install of 
> glibc-2.27-9.x32 conflicts with file from package glibc-2.27-8.x86_64
> poldek:   file /usr/share/doc/glibc-2.27/NEWS.gz from install of 
> glibc-2.27-9.x32 conflicts with file from package glibc-2.27-8.i686

Could someone please have a look at x32 builder?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Missing packages

[Jan Palus]

On 25.06.2018 17:14, PLD th-x86_64 builder wrote:
> NetworkManager-applet.spec (HEAD): OK
> 
> --- NetworkManager-applet.spec:HEAD:
> upgrading packages
> Preparing...##
> NetworkManager-gtk-lib  ##
> Build-Time: user:105.32s sys:24.10s real:76.05s (faults io:19 non-io:8340882)
> 
> Files queued for ftp:
>1971561 NetworkManager-applet-debuginfo-1.8.14-1.x86_64.rpm
>  27747 NetworkManager-gtk-lib-apidocs-1.8.14-1.x86_64.rpm
>  20568 NetworkManager-gtk-lib-devel-1.8.14-1.x86_64.rpm
> 123330 NetworkManager-gtk-lib-1.8.14-1.x86_64.rpm
>1020520 NetworkManager-applet-1.8.14-1.x86_64.rpm
>341 NetworkManager-applet-1.8.14-1.src.rpm.uploadinfo

Yesterday I've managed to update one machine with new packages but today
they are gone from ftp. Any idea what happened to them?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: New NM 1.12 and OVPN

[Jan Palus]

On 18.07.2018 10:18, Andrzej Zawadzki wrote:
>After upgrade to newest version of NM, plugin
>NetworkManager-openvpn-1.8.4-1 doesn't work.
>Plugin is too old?

Try NetworkManager-1.12.0-2 once it's built. As a quick workaround in current
release you can use:

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

Re: upgrade failed OK: openjpeg2.spec

[Jan Palus]

Thanks. Done.

One more related thing though - any idea why upgrade failed?

On 31.08.2018 18:44, PLD th-x86_64 builder wrote:
> upgrading packages
> error: Failed dependencies:
>   openjpeg2-progs = 2.3.0-2 is needed by openjpeg2-devel-2.3.0-2.x86_64
> package upgrade failed
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: TEST build ERRORS: vlc.spec

[Jan Palus]

On 01.09.2018 19:04, PLD th-x32 builder wrote:
> /usr/libx32/qt5/bin/uic -tr "Q_" gui/qt/ui/open_capture.ui >> 
> gui/qt/ui/open_capture.h.tmp
> /usr/libx32/qt5/bin/uic: relocation error: /usr/libx32/qt5/bin/uic: symbol 
> qt_qhash_seed version Qt_5 not defined in file libQt5Core.so.5 with link time 
> reference

Could someone upgrade Qt5* and qt5* on th-x32?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/open-vm-tools] we don't provide vmxnet module, drop support for it

[Jan Palus]

On 02.09.2018 18:06, adamg wrote:
> commit 21d43020dfd7dc915c941739408c48f91b9681f5
> Author: Adam Gołębiowski 
> Date:   Sun Sep 2 18:03:55 2018 +0200
> 
> we don't provide vmxnet module, drop support for it

I'm not using PLD in VMware VM anymore, but please keep in mind vmxnet module is
now part of mainline kernel, though apparently it's called vmxnet3 nowadays.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: TEST build ERRORS: fontconfig.spec

[Jan Palus]

> 69f4b771-2f60-43f1-bcca-ece370059cce/tmp/B.af_pNM/BUILD/fontconfig-2.13.0/test/cache.dir/b9d99059-517f-4a54-9228-3fc60336fa91-le32d4.cache-7
> No permissions to creating new namespace, likely because the kernel does not 
> allow non-privileged user namespaces. On e.g. debian this can be enabled with 
> 'sysctl kernel.unprivileged_userns_clone=1'.
> *** Test failed: Basic functionality with the bind-mounted cache dir
> file property doesn't points to the new place: 
> /tmp/fontconfig.EiWDNCv2/fonts/4x6.pcf

To be honest I don't really follow, can someone advise whether this is expected 
behavior on builders?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: TEST build ERRORS: fontconfig.spec

[Jan Palus]

On 10.03.2018 13:48, PLD th-x86_64 builder wrote:
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See test/test-suite.log

would someone with proper access be so kind to send me above file from any
builder?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/libutf8proc] - rel 4; avoid includedir subdir (compatible with other distros)

[Jan Palus]

On 14.04.2018 17:45, arekm wrote:
> commit f8274d04fe4385692919d8ca584f1686c82fba29
> Author: Arkadiusz Miśkiewicz 
> Date:   Sat Apr 14 17:44:57 2018 +0200
> 
> - rel 4; avoid includedir subdir (compatible with other distros)

Looks like someone else is also upgrading subversion. Note that utf8proc was
started by netsurf team, later maintenance was passed over to Julia Lang. Last
version released by netsurf (1.3.1) has include file in a subdir and ships with
pkgconfig file, latest version released by Julia Lang (2.1.0) does not have a
subdir and does not ship a pkgconfig file (moronic breakage of compatibility if
you ask me). netsurf's version is required by... netsurf itself (includes file
with subdir, uses pkgconfig), while Julia's version is required by subversion. I
guess the way forward is to either:

- upgrade utf8proc to 2.1.0 and adjust netsurf to build with new library
  (preferred)

- package these two independently


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

Re: ERRORS: firefox.spec

[Jan Palus]

On 25.09.2018 21:37, Jan Palus wrote:
> On 25.09.2018 19:14, PLD th-i686 builder wrote:
> > firefox.spec (auto/th/firefox-62.0.2-1): FAILED
> 
> I got failed firefox build on i686 in some random place, followed by OK test
> build, followed by this failure in another random place. Can someone have look
> at th-i686 builder? Is there any trace of segfault in dmesg? Disk space issues
> perhaps? Anything of interest?

VirtualBox has similar symptoms now on th-i686.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: TEST build ERRORS: cups-filters.spec (PHP version on builders)

[Jan Palus]

On 05.11.2018 11:45, PLD th-x32 builder wrote:
> cups-filters.spec (HEAD): FAILED
...
> installing BR: php55\-devel
> + poldek --noask --caplookup -Q -v '--ignore=hhvm-*' '--ignore=php4-*' 
> '--ignore=php52-*' '--ignore=php54-*' '--ignore=php55-*' '--ignore=php56-*' 
> '--ignore=php70-*' '--ignore=php71-*' '--ignore=php72-*' '--ignore=php73-*' 
> --upgrade php55-devel
...
> error: php55-devel: no such package

Are builders expected to have consistent php*-devel version installed? If yes
any idea why i686 has php53-devel, while x86_64 and x32 have php73?

Does it even make sense to build php module for things like cups-filters which
produce extension for single version and previously it was built for php56 as
far as I can tell? Is there something like main or default php version?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: TEST build ERRORS: poppler.spec

[Jan Palus]

On 31.08.2018 17:19, PLD th-x86_64 builder wrote:
> CMake Error at /usr/lib64/openjpeg-2.3/OpenJPEGTargets.cmake:90 (message):
>   The imported target "openjp2_static" references the file
> 
>  "/usr/lib64/libopenjp2.a"
> 
>   but this file does not exist.  Possible reasons include:
> 
>   * The file was deleted, renamed, or moved to another location.
> 
>   * An install or uninstall procedure did not complete successfully.
> 
>   * The installation package was faulty and contained
> 
>  "/usr/lib64/openjpeg-2.3/OpenJPEGTargets.cmake"
> 
>   but not all the files it references.

It appears that openjpeg2-devel requires both openjpeg2-static (libopenjp2.a)
and openjpeg2-progs (opj_decompress). Now is it valid to specify circular
dependency:

-devel: R: -static
-static: R: -devel

>From what I've gathered empirically poldek/RPM are smart enough to handle it. 
>Any
other ideas? Disable static libs?


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

Re: ERRORS: firefox.spec

[Jan Palus]

On 25.09.2018 19:14, PLD th-i686 builder wrote:
> firefox.spec (auto/th/firefox-62.0.2-1): FAILED

I got failed firefox build on i686 in some random place, followed by OK test
build, followed by this failure in another random place. Can someone have look
at th-i686 builder? Is there any trace of segfault in dmesg? Disk space issues
perhaps? Anything of interest?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: DISTFILES: sqlite3: ERRORS: sqlite-src-3260000.zip

[Jan Palus]

On 13.12.2018 12:28, atler wrote:
> Request by: atler
> 
> sqlite3: undefined macro lua:vn=rpm.expand("%vnum");v="";for i in 
> string.gmatch(string.format("%08d", vn), "..") do v=v.."."..i:gsub("^0", 
> "");end;v=v:gsub("^.",""):gsub("\.0$","");print(v)
> 
> 
> 
> Files fetched: 0
> 
> ALREADY GOT: http://www.sqlite.org/2018/sqlite-src-326.zip
>   dfc2ae0e9b810e9e3db553f71ea832ad  sqlite-src-326.zip

Anyone knows why distfiles is unable to expand this lua macro?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: DISTFILES: sqlite3: ERRORS: sqlite-src-3260000.zip

[Jan Palus]

On 13.12.2018 12:37, Arkadiusz Miśkiewicz wrote:
> On 13/12/2018 12:30, Jan Palus wrote:
> > On 13.12.2018 12:28, atler wrote:
> >> Request by: atler
> >>
> >> sqlite3: undefined macro lua:vn=rpm.expand("%vnum");v="";for i in 
> >> string.gmatch(string.format("%08d", vn), "..") do v=v.."."..i:gsub("^0", 
> >> "");end;v=v:gsub("^.",""):gsub("\.0$","");print(v)
> >>
> >>
> >>
> >> Files fetched: 0
> >>
> >> ALREADY GOT: http://www.sqlite.org/2018/sqlite-src-326.zip
> >>dfc2ae0e9b810e9e3db553f71ea832ad  sqlite-src-326.zip
> > 
> > Anyone knows why distfiles is unable to expand this lua macro?
> 
> It's a simple perl script that expands these macros and doesn't handle
> complicated cases.
> 
> Is this macro expansion needed anyway for sqlite3.spec? It fetched
> source correctly, so likely it is not needed.

It's needed to fetch replication patch:

%define ver %{lua:vn...
...
Patch1: 
https://github.com/CanonicalLtd/sqlite/releases/download/version-%{ver}%%2Breplication3/sqlite-%{ver}.diff

I wonder how it worked the first time.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: PLD-doc: PLD-update-TODO - updated

[Jan Palus]

Is this update job working correctly? Just few examples that are out of date:


avfs(11) [OLD] 1.0.0 [NEW] 1.0.6 --> 1.0.6 is in Git for a week now
ell(12) [OLD] 0.12 [NEW] 0.14 --> the latest version is 0.15 not 0.14 and 0.15
  is in repo for 2 weeks now
guvcview(12) [OLD] 2.0.5 [NEW] 2.0.6 --> 2.0.6 is in Git for 1.5 months now
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/qt5-qtbase] build without statx to support kernels older than 4.11

[Jan Palus]

On 21.03.2019 09:58, Arkadiusz Miśkiewicz wrote:
> On 21/03/2019 00:35, atler wrote:
> > commit fc41f21cbe3529378b0600ec3e027668b7f878d4
> > Author: Jan Palus 
> > Date:   Thu Mar 21 00:30:10 2019 +0100
> > 
> > build without statx to support kernels older than 4.11
> 
> 
> Hm, it doesn't fallback? It should since it check ENOSYS

It does not have a chance to:

$ readelf -n /usr/lib64/libQt5Core.so.5.12.2

...

Displaying notes found in: .note.ABI-tag
  Owner Data size   Description
  GNU  0x0010   NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 4.11.0
^^

See src/corelib/global/{minimum-linux_p.h,minimum-linux.S}.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Missing buildlogs

[Jan Palus]

Looks like starting with gcc build 
(https://srcbuilder.pld-linux.org/th/queue.html#184029)
buildlogs went missing. Can someone check?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: Missing buildlogs

[Jan Palus]

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

Right, thanks. Seems like at some point in time I got too overwhelmed by those
messages and created rule to get rid of them completely.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

freshness' freshness

[Jan Palus]

For some time now it seems that freshness report does not include new changes,
any idea what happened?

http://ep09.pld-linux.org/~pldth/qa.php?q=freshness

Sample missing packages: libbluray tasksh glib-networking gobject-introspection
vala gvfs libinput vte mate-icon-theme
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: freshness' freshness

[Jan Palus]

On 11.04.2019 13:00, glen wrote:
> seems ok now.
> 
> 
> new commit created as:
> 
> git diff 625690e48..96bb43df4

thanks!
___
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] continue using hybrid cgroup hierarchy

[Jan Palus]

On 04.09.2019 08:01, Arkadiusz Miśkiewicz wrote:
> On 03/09/2019 23:13, atler wrote:
> > commit d43959e98fc5590888c9a43d2345178c34e4f2c4
> > Author: Jan Palus 
> > Date:   Tue Sep 3 23:08:49 2019 +0200
> > 
> > continue using hybrid cgroup hierarchy
> > 
> > ...for docker compatibility. upstream switched default to unified
> > hierarchy exposing core cgroupv2 functionality only
> 
> Shouldn't we go for upstream default and only those who use docekr
> should switch via cmdline option ?

I do use docker but I don't care much about cgroups so can't really tell what
are benefits of keeping "unified" hierarchy. The main point was not to break
existing installations. If you believe "unified" hierarchy would be better,
please feel free to change.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: TEST build ERRORS: kf5-ktexteditor.spec

[Jan Palus]

On 25.07.2019 19:57, PLD th-i686 builder wrote:
> -DQT_NO_DEBUG  -Wl,--no-undefined -Wl,--fatal-warnings
...
> /usr/bin/ld: warning: /lib/ld-linux.so.2: corrupt GNU_PROPERTY_TYPE (5) size: > 0
> collect2: error: ld returned 1 exit status

any idea why /lib/ld-linux.so.2 appears to be broken on i686?

$ readelf -n /lib/ld-linux.so.2

Displaying notes found in: .note.gnu.build-id
  Owner Data size   Description
  GNU  0x0014   NT_GNU_BUILD_ID (unique build ID 
bitstring)
Build ID: 99315096abbe23e4eac6ea4ac07fc9f5c86e2fe7

Displaying notes found in: .note.gnu.property
  Owner Data size   Description
  GNU  0x   NT_GNU_PROPERTY_TYPE_0
  Properties: 
  ^




on x86_64 it appears to be fine:

$ readelf -n /lib64/ld-linux-x86-64.so.2

Displaying notes found in: .note.gnu.property
  Owner Data size   Description
  GNU  0x0010   NT_GNU_PROPERTY_TYPE_0
  Properties: x86 feature: IBT, SHSTK

Displaying notes found in: .note.gnu.build-id
  Owner Data size   Description
  GNU  0x0014   NT_GNU_BUILD_ID (unique build ID 
bitstring)
Build ID: ee43aed962e9e79b6d6831ad5f68d1ee5bb64f3b
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: git push: No space left on device

[Jan Palus]

Happened again:

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 316 bytes | 316.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: fatal: write failure on standard output: No space left on device
remote: error: unable to write file sip.spec
remote: Updated 1 path from 822c76c
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
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

package missing on github mirror

[Jan Palus]

Just got following error when pushing to dxr2-driver:

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 311 bytes | 311.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Updated 1 path from c57d3d5
remote: ERROR: Repository not found.
remote: fatal: Could not read from remote repository.
remote:
remote: Please make sure you have the correct access rights
remote: and the repository exists.

Since commit reached git.pld-linux.org just fine, I believe the issue is caused
by missing package on github:

https://github.com/pld-linux/dxr2-driver
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: package missing on github mirror

[Jan Palus]

On 18.05.2020 11:34, Elan Ruusamäe wrote:
> > Since commit reached git.pld-linux.org just fine, I believe the issue is 
> > caused
> > by missing package on github:
> > 
> > https://github.com/pld-linux/dxr2-driver
> 
> 
> repo created
> 
> 
> ```
> 
> 
> root@1822-cvs hooks/post-receive.d# sudo -H -u git ~git/bin/pldgithub.py
> create dxr2-driver
> Cannot create irc hook for dxr2-driver on github
> 
> ```

Thanks. Not a big deal but description is missing -- other packages use Summary:
for this purpose.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/rust-cbindgen] add aarch64 to supported archs

[Jan Palus]

On 06.05.2020 09:26, Elan Ruusamäe wrote:
> On 5/3/20 9:05 PM, atler wrote:
> 
> > commit dbd044c3e9564926c69806df3133b1322dd32d0b
> > Author: Jan Palus 
> > Date:   Sun May 3 20:02:33 2020 +0200
> > 
> >  add aarch64 to supported archs
> 
> are you building pld for arm?
> 
> do you have boostrap packages available?

I am. Announcement will be made once I finish building all packages that I need
and after uploading chroot/packages somewhere.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: kwin with new Mesa

[Jan Palus]

On 11.05.2020 10:01, Andrzej Zawadzki wrote:
>On 07.05.2020 23:20, Jan Palus wrote:
> 
> On 06.05.2020 13:04, Andrzej Zawadzki wrote:
> 
>Hi,
> 
>after upgrade Mesa* to 20.0.6, kwin dies as below:
> 
> >From which version you have upgraded (what was the last working version)?
> 
>19.3.4
> 
> Which GPU?
> 
>VGA compatible controller: Intel Corporation Skylake GT2 [HD Graphics
>520] (rev 07)
> 
> What driver?
> 
>i915

Which DDX driver intel or modesetting? If "intel" please try with "modesetting".
The former is basically unsupported now.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: libc 2.31/i686: operation not permitted for preserving timestamps

[Jan Palus]

On 24.03.2020 21:20, Elan Ruusamäe wrote:
> does i686 even work for someone really?
> 
> 
> some errors here and there

FWIW my up-to-date i686 VM (QEMU) used for package testing purposes works fine.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: kwin with new Mesa

[Jan Palus]

On 06.05.2020 13:04, Andrzej Zawadzki wrote:
>Hi,
> 
>after upgrade Mesa* to 20.0.6, kwin dies as below:

>From which version you have upgraded (what was the last working version)?

Which GPU?

What driver?

Is there anything in xorg log?

Is there anything in dmesg?

Can you provide stack with debuginfo packages installed?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

chroot for aarch64

[Jan Palus]

For the last couple of days I've been boostrapping PLD for aarch64 and I'm happy
to report that my Pinebook Pro boots into PLD now (with just a little help from
Manjaro's kernel and wifi firmware). Basically everything works fine including,
but not limited to: rpm, poldek, X, Mesa, MATE, firefox, Qt5 apps, mpv.

In case anyone's interested I've created base chroot with some additional
packages so it's bootable and remotely accessible (systemd, openssh). Available
for download from GitHub:

https://github.com/jpalus/pld-linux-aarch64/releases

All packages built so far are available as poldek's repository (already
configured in chroot):

http://jpalus.fastmail.com.user.fm/dists/th/PLD/aarch64/RPMS/

Note that package list reflects my needs and you may not find what you're
looking for. However most of critical devel packages are there (ie gcc, llvm,
python, perl, ruby, rust, icedtea) making building new packages yourself smooth
and easy.

All fixes needed to build those packages are already committed to
git.pld-linux.org.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/rpm-pld-macros] - version 1.749: fixed _ver_* macros

[Jan Palus]

On 27.09.2020 20:17, qboosh wrote:
> commit a04002a841905f8c84ca1c955e047676994c1ef2
> Author: Jakub Bogusz 
> Date:   Sun Sep 27 20:20:03 2020 +0200
> 
> - version 1.749: fixed _ver_* macros
...
> -# BuildRequires: rpmbuild(macros) >= 1.748
> -%_ver_lt()   %(test rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1 -eq 2; echo $?)
> -%_ver_ge()   !%(test rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1 -eq 2; echo $?)
> +# BuildRequires: rpmbuild(macros) >= 1.749
> +%_ver_lt()   %(test $(rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1; echo $?) -eq 
> 2; echo $?)
> +%_ver_ge()   %(test $(rpmvercmp "%{1}" "%{2}" >/dev/null 2>&1; echo $?) -ne 
> 2; echo $?)

Isn't it the other way? -ne 2 for_ver_lt and -eq 2 for _ver_ge?

"Satisfied condition" in terms of test return code (0) is the opposite
of "satisfied condition" as interpreted by rpm (1).

$ rpm -E '%{_ver_lt 0 0}'
1

$ rpm -E '%{_ver_lt 0 1}'
0

$ rpm -E '%{_ver_lt 1 0}'
1

$ rpm -E '%{_ver_ge 0 0}'
0

$ rpm -E '%{_ver_ge 5.4.15 4.6}'
0

$ rpm -q rpm-pld-macros-build
rpm-pld-macros-build-1.749-1.noarch


or how is it supposed to be used?

ie rapidjson has:

%if %{_ver_ge "%{_rpmversion}" "4.6"}

which I suppose does not work correctly at the moment.

while glabels has:

%if 0%{?_ver_ge "%{_rpmversion}" "4.6"}

but I don't quite get it, I thought %{? construct is only to check if
something is defined or does it somehow interpret return value?
It seems to return same value for all cases:

$ rpm -E '%{?_ver_ge 0 0}'
1

$ rpm -E '%{?_ver_ge 0 1}'
1

$ rpm -E '%{?_ver_ge 1 0}'
1
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm.org's rpm 4.16.0 ready for testing

[Jan Palus]

On 24.10.2020 17:15, Jan Rękorajski via pld-devel-en wrote:
> I have prepared rpm 4.16, poldek and support packages, they are
> available on http://ftp1.pld-linux.org/people/baggins/rpm.org/
> 
> I would appreciate if you could test the uprade path, functionality
> and tell me if anything is missing / broken.

On a related note -- once it gets to integer release can we consider
doing mass rebuild of everything? Some of our packages were not rebuilt
for a very very long time :) (...and those who need to build them anyway
suffer alone)
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm.org's rpm 4.16.0 ready for testing

[Jan Palus]

On 24.10.2020 17:15, Jan Rękorajski via pld-devel-en wrote:
> I have prepared rpm 4.16, poldek and support packages, they are
> available on http://ftp1.pld-linux.org/people/baggins/rpm.org/
> 
> I would appreciate if you could test the uprade path, functionality
> and tell me if anything is missing / broken.

First of all great work, thanks!

FWIW I did a build on aarch64 with few minor fixes and looks like it
all works fine. Some funky things that I've noticed so far:

* after build with -bb --short-circuit package has weird dependency:

error: Failed dependencies:
rpmlib(ShortCircuited) <= 4.9.0-1 is needed by 
poldek-libs-0.42.2-3.aarch64
rpmlib(ShortCircuited) <= 4.9.0-1 is needed by 
poldek-0.42.2-3.aarch64

  if you're not doing %prep, %build or %install then you're... cheating
  and end up with this dep?

build/build.c:

int didBuild = (what & (RPMBUILD_PREP|RPMBUILD_BUILD|RPMBUILD_INSTALL));
...
packageBinaries(spec, cookie, (didBuild == 0))


build/pack.c:

rpmRC packageBinaries(rpmSpec spec, const char *cookie, int cheating)
...
if (cheating) {
(void) rpmlibNeedsFeature(pkg, "ShortCircuited", "4.9.0-1");
}

* libraries have build id symlinks, not sure what's that for:

  $ rpm -ql rpm-lib
  /lib64/librpm.so.9
  /lib64/librpm.so.9.1.0
  /lib64/librpmbuild.so.9
  /lib64/librpmbuild.so.9.1.0
  /lib64/librpmio.so.9
  /lib64/librpmio.so.9.1.0
  /lib64/librpmsign.so.9
  /lib64/librpmsign.so.9.1.0
  /usr/lib/.build-id
  /usr/lib/.build-id/2f
  /usr/lib/.build-id/2f/fc726b33e23f339fb4140cb2a858800f92f245
  /usr/lib/.build-id/72
  /usr/lib/.build-id/72/65fcdb96f521c1953560d780a5f82fa2017c2a
  /usr/lib/.build-id/73
  /usr/lib/.build-id/73/5b7b1130a7b6a74436438fb3fc02cad816224d
  /usr/lib/.build-id/e6
  /usr/lib/.build-id/e6/7a230d27a1b3fceb891aa2df1bfa5e1e980f50
  /usr/lib64/rpm-plugins

* are we sticking to new patch fuzz level (0) or go back to patch
  default (2)?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/rpm/rpm.org] - drop lua hacks and look for default lua version - don't obsolete rpm-getdeps, this rpm does not su

[Jan Palus]

On 24.10.2020 16:12, baggins wrote:
> commit be07e71c8acd92e61d42ccb1c92200f92ed152c9
> Author: Jan Rękorajski 
> Date:   Sat Oct 24 15:50:57 2020 +0200
> 
> - drop lua hacks and look for default lua version
> -BuildRequires:   lua53-devel >= 5.3.5
> +BuildRequires:   lua-devel >= 5.1

lua51-devel provides lua-devel however it does not have lua.pc expected
by rpm. Perhaps replace with?

BuildRequires:  pkgconfig(lua) >= 5.1
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/qt4] - icu 67 rebuild - release 28 (by relup.sh)

[Jan Palus]

On 07.07.2020 12:30, Andrzej Zawadzki wrote:
>Hi!
> 
>After upgrade that package KDE4 stop working - flood of core dumps.
> 
>Maybe rebuilding KDE4 is enough to fix this issue?
> 
>ps. I don't have stack trace.

kde4/qt4 should either get a maintainer -- I propose you -- or be moved to
th-obsolete. In the latter case users would need to keep two versions of
libraries:

- one for legacy stuff like kde4
- one for rest of the system

for as long as they can (ie you'd be better off installing both libicu 65 and 67
now instead of upgrading qt4 and kde4). This will inevitably break at some point
though.

Personally I'm not willing to maintain qt4/kde4. Actually as far as I'm
concerned this was the last time I attempted to fix dependency problems in
qt4/kde4.
___
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] - this version is broken in an interesting way, rebooted during upgrade and then became unable to

[Jan Palus]

On 10.06.2020 09:35, baggins wrote:
> commit bcc348b831315aef4775c2f8f9c3b349b3337d5b
> Author: Jan Rękorajski 
> Date:   Wed Jun 10 09:35:13 2020 +0200
> 
> - this version is broken in an interesting way, rebooted during upgrade
>   and then became unable to boot fully

Any clue what went wrong? Worked fine for me in a VM and on real hardware (efi +
secure boot + full disk enc + grub2 + dracut).
___
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] - this version is broken in an interesting way, rebooted during upgrade and then became unable to

[Jan Palus]

On 12.06.2020 20:01, Jan Rękorajski wrote:
> Yes, there must be some intricate issue when updating from 244 to 245.
> Updating 245 to 245 shows no side effects, clean restart.
> 
> If you know of anything I should look at, or have any pointers where
> should I dig, I'm open to suggestions.

The only thing I could think of is journalctl output from the moment of upgrade
till reboot.

> BTW, did anyone else try to do the update? Folks?

FWIW I have upgraded my aarch64 laptop and still no reboot. It ended my user
session though -- a bug in systemd which is already fixed since yesterday.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

iptables-nft broken?

[Jan Palus]

Does iptables-nft work for anyone in PLD? iptables-nft -L is supposed to
create table/chains already but it does nothing. Same for any
iptables-nft -A  No errors just nothing. If I create INPUT chain
and add single rule manually with nft then I can see it in iptables-nft -L.
Almost as if iptables-nft was "read-only". Am I missing something?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm4 on carme*

[Jan Palus]

If commit message includes '%' then rpmbuild spawned by builder script
fails. See ie test.spec which includes '%prep':

error: line 40: second %prep

builder creates spec copy with %changelog appended. Apparently rpm.org
evaluates macros in %changelog while rpm5 does not. Not sure whether
we're supposed to escape macros in changelog now or whether rpm.org
should read %changelog as is.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm4 on carme*

[Jan Palus]

On 18.12.2020 20:31, Jan Rękorajski wrote:
> On Sun, 13 Dec 2020, Jan Palus via pld-devel-en wrote:
> 
> > Looks like poldek does not recognize R:(post, postun) and fails to
> > install packages even though dependencies are present:
> > 
> > $ ag '^R.*post' mpd.spec
> > 86:Requires(post,postun):   gtk-update-icon-cache
> > 87:Requires(post,preun,postun): systemd-units >= 38
> > 
> > $ poldek --cmd desc -r mpd |grep gtk-update-icon-cache
> > Requires(pre):  /bin/sh, /bin/sh, gtk-update-icon-cache, systemd-units >= 38
> > Requires(un):   /bin/sh, /bin/sh, gtk-update-icon-cache, systemd-units >= 38
> > 
> > $ poldek -u mpd
> > ...
> > Processing dependencies...
> > There are 1 package to install:
> > A mpd-0.22.3-1
> > This operation will use 1.4MB of disk space.
> > Need to get 507.6KB of archives.
> > mpd-0.22.3-1.armv6hl.rpm: digests OK
> > Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 
> > 1...
> > error: Failed dependencies:
> > gtk-update-icon-cache is needed by mpd-0.22.3-1.armv6hl
> > 
> > Manual installation of gtk-update-icon-cache followed by installation of
> > mpd is all fine.
> 
> Works for me.
> Maybe it's rpm4 that does not produce deps for R:(post, postun)?
> 
> [r...@pldmachine-rpm.org ~]# rpm -q rpm poldek
> rpm-4.16.0-0.12.x86_64
> poldek-0.42.2-3.5.x86_64
> 
> 
> poldek:/all-avail> install -t mpd-0.22.3-2.x86_64 
> Processing dependencies...
> mpd-0.22.3-2.x86_64 marks gtk-update-icon-cache-3.24.23-1.x86_64 (cap 
> gtk-update-icon-cache)

Is this by any chance mpd from main th repo built with rpm5? The
difference is most likely here:

> > $ poldek --cmd desc -r mpd |grep gtk-update-icon-cache
> > Requires(pre):  /bin/sh, /bin/sh, gtk-update-icon-cache, systemd-units >= 38

With rpm4 + poldek(rpm4) gtk-update-icon-cache lands in Requires(pre):
while with rpm5 + poldek(rpm5) it's just in Requires:. I suppose poldek
ignores Requires(pre).
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: problem with mpd and libvirt

[Jan Palus]

On 15.12.2020 12:48, Elan Ruusamäe wrote:
> On 15.12.2020 10:51, Jan Palus wrote:
> 
> > On 14.12.2020 23:19, Krzysztof Mrozowicz wrote:
> > > Hi,
> > > I upgraded my PLD installation with today's "ready" repo and just 
> > > discovered
> > > that two services I use started to segfault.
> > > 
> > > libvirtd:
> > > gru 14 23:06:34 oko libvirtd[22095]: internal error: Failed to start QEMU
> > > binary /usr/bin/qemu-system-x86_64 for probing: qemu-system-x86_64:
> > > /tmp/B.HHaAz_/BUILD/qemu-5.0.0/util/fdmon-io_uring.c:292:
> > > fdmon_io_uring_wait: Assertion `ret >= 0' failed.
> > > gru 14 23:06:34 oko libvirtd[22095]: Failed to probe capabilities for
> > > /usr/bin/qemu-system-x86_64: internal error: Failed to start QEMU binary
> > > /usr/bin/qemu-system-x86_64 for probing: qemu-system-x86_64:
> > > /tmp/B.HHaAz_/BUILD/qemu-5.0.0/util/fdmon-io_uring.c:292:
> > > fdmon_io_uring_wait: Assertion `ret >= 0' failed.
> > > 
> > > mpd:
> > > gru 14 23:16:49 oko systemd[1]: Starting Music Player Daemon...
> > > gru 14 23:16:49 oko systemd-coredump[51998]: [] Process 50078 (mpd) of 
> > > user
> > > 204 dumped core.
> > > 
> > > If I can do anything to help to identify the problem, please let me know.
> > mpd works fine for me but can you try upgrading mpd/qemu* to
> > versions from th-test and see if it fixes your issues?
> 
> io_uring may be related to kernel, what is your kernel, glibc, liburing,
> qemu?

It looks like ABI breakage to me -- the reason why mpd worked for me
(qemu fails the same way) is most likely due to:

* on x86_64 I'm using mpd in user session which in default configuration
  does not use io_uring (mpd requires 64M `ulimit -l` while by
  default 64K is available)

* on ARM I'm using system instance but mpd was compiled with liburing
  0.7

After quick look at liburing commits between 0.6 and 0.7 I'd say it
would be this one:

https://github.com/axboe/liburing/commit/0f0517331307605e576b3492c93dc4988e06fdc0
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: problem with mpd and libvirt

[Jan Palus]

On 14.12.2020 23:19, Krzysztof Mrozowicz wrote:
> Hi,
> I upgraded my PLD installation with today's "ready" repo and just discovered
> that two services I use started to segfault.
> 
> libvirtd:
> gru 14 23:06:34 oko libvirtd[22095]: internal error: Failed to start QEMU
> binary /usr/bin/qemu-system-x86_64 for probing: qemu-system-x86_64:
> /tmp/B.HHaAz_/BUILD/qemu-5.0.0/util/fdmon-io_uring.c:292:
> fdmon_io_uring_wait: Assertion `ret >= 0' failed.
> gru 14 23:06:34 oko libvirtd[22095]: Failed to probe capabilities for
> /usr/bin/qemu-system-x86_64: internal error: Failed to start QEMU binary
> /usr/bin/qemu-system-x86_64 for probing: qemu-system-x86_64:
> /tmp/B.HHaAz_/BUILD/qemu-5.0.0/util/fdmon-io_uring.c:292:
> fdmon_io_uring_wait: Assertion `ret >= 0' failed.
> 
> mpd:
> gru 14 23:16:49 oko systemd[1]: Starting Music Player Daemon...
> gru 14 23:16:49 oko systemd-coredump[51998]: [] Process 50078 (mpd) of user
> 204 dumped core.
> 
> If I can do anything to help to identify the problem, please let me know.

mpd works fine for me but can you try upgrading mpd/qemu* to
versions from th-test and see if it fixes your issues?
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm4 on carme*

[Jan Palus]

On 06.11.2020 20:49, Jan Palus wrote:
> On 27.10.2020 23:21, Jan Rękorajski wrote:
> > All carme machines are now running rpm 4.16.0. Please test and report
> > any issues.
> 
> * poldek appears to still enforce directory deps while rpms does not
>   (that concerns mainly /usr/lib/.build-id subdirs)
> 
> * rpm.org is missing %{__ln} macro. spotted only single occurrence in
>   xrdp.spec

* missing __bash macro

* most noarch conditions stopped working now since 4.16 < 4.6
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm4 on carme*

[Jan Palus]

On 10.11.2020 18:18, Jan Palus wrote:
> On 06.11.2020 20:49, Jan Palus wrote:
> > On 27.10.2020 23:21, Jan Rękorajski wrote:
> > > All carme machines are now running rpm 4.16.0. Please test and report
> > > any issues.
> > 
> > * poldek appears to still enforce directory deps while rpms does not
> >   (that concerns mainly /usr/lib/.build-id subdirs)
> > 
> > * rpm.org is missing %{__ln} macro. spotted only single occurrence in
> >   xrdp.spec
> 
> * missing __bash macro
> 
> * most noarch conditions stopped working now since 4.16 < 4.6

* Provides for libraries are not populated if %install does not set
  executable bit on ELF file. One such notable example is libgcc_s
  installed with mode 644 by `make install`:

rpm5:

$ rpm -q --provides libgcc | grep libgcc_s
libgcc_s.so.1
libgcc_s.so.1(GCC_3.0)
libgcc_s.so.1(GCC_3.3)
libgcc_s.so.1(GCC_3.3.1)
libgcc_s.so.1(GCC_3.4)
libgcc_s.so.1(GCC_3.4.2)
libgcc_s.so.1(GCC_4.0.0)
libgcc_s.so.1(GCC_4.2.0)
libgcc_s.so.1(GCC_4.3.0)
libgcc_s.so.1(GCC_4.4.0)
libgcc_s.so.1(GCC_4.5.0)
libgcc_s.so.1(GCC_4.7.0)
libgcc_s.so.1(GCC_4.8.0)
libgcc_s.so.1(GCC_7.0.0)
libgcc_s.so.1(GLIBC_2.0)
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libgcc_s.so.1(GCC_3.3)(64bit)
libgcc_s.so.1(GCC_3.3.1)(64bit)
libgcc_s.so.1(GCC_3.4)(64bit)
libgcc_s.so.1(GCC_3.4.2)(64bit)
libgcc_s.so.1(GCC_3.4.4)(64bit)
libgcc_s.so.1(GCC_4.0.0)(64bit)
libgcc_s.so.1(GCC_4.2.0)(64bit)
libgcc_s.so.1(GCC_4.3.0)(64bit)
libgcc_s.so.1(GCC_4.7.0)(64bit)
libgcc_s.so.1(GCC_4.8.0)(64bit)
libgcc_s.so.1(GCC_7.0.0)(64bit)

rpm4:

$ rpm -q --provides -p libgcc-10.2.0-1.x86_64.rpm | grep libgcc_s
(empty)

Aa a workaround we could remove "exeonly" from %__elf_flags in
/usr/lib/rpm/fileattrs/elf.attr but ideally RPM should not look at
actual file mode on disk but rather on mode configured in %files.

Other such example: ossp-uuid

* possibly similar case but I haven't debugged it: perl-modules does not
  provide perl(unicore::Name)

* Requires(triggerpostun) is not supported (pam.spec)

* Obsoletes fails if it does not contain "package name only" examples:
  
  systemd.spec: Obsoletes:  virtual(init-daemon) (illegal char '(')
  perl.spec: Obsoletes: perl-Params::Check < %perl_modverrel Params::Check 99 
(illegal char ':')

* similar thing in Provides:

  perl.spec: Provides: perldoc = 3.14_02@5.30.3 (illegal char '@')
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm4 on carme*

[Jan Palus]

* adding to the list of invalid chars in Obsoletes: '/' (msmtp: Obsoletes:  
/usr/lib/sendmail)

* python-Cython built with rpm.org has weird unsatisfied R: 
python2.7dist(setuptools) / python3.8dist(setuptools)

  python-setuptools built with rpm.org does not have such P:
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: th-i686 not working again

[Jan Palus]

On 20.11.2020 21:04, Arkadiusz Miśkiewicz wrote:
> W dniu 20.11.2020 o 20:48, Jakub Bogusz pisze:
> > It seems that th-i686 builder is dead or got stuck on openjdk11 build.
> > 
> > Who can fix it?
> 
> I but only on the site (if at all). It doesn't see disks (in bios).
> 
> Maybe I'll get there in the weekend.

Hopefully it gets back soon, but in order to help it get up to speed
whoever has proper permissions feel free to skip following build
requests on th-i686:

test builds:

6d9c45e9-c958-4ea9-bf8f-d0fe6c7f93e9
b71ae8d3-f41c-431a-87e6-859f0c31bfa9
0365cd79-867e-44db-898a-65e0ce51b547
8057abcf-eab0-460d-8de3-4d1f4aa87c20
8a3fc358-957a-4be0-9cc5-812e54e1359b
8698b6d0-c807-4b3d-825a-0e991ab384bc
915e9cd4-6f21-446f-87f5-94872b7af0ea
ee2e7ddb-33f9-4056-a27a-bd60feb456d6
851179c8-8766-4aec-ae87-9981365c8e56

release builds:

f3f8bb5c-3dcd-4240-b049-299936296db7 (thunderbird 78.4.3 superseded by 78.5.0)
89fe1778-4cd1-4b66-954b-19599dc088c3 (qt5-qtwebkit will fail)
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rpm4 on carme*

[Jan Palus]

On 27.10.2020 23:21, Jan Rękorajski wrote:
> All carme machines are now running rpm 4.16.0. Please test and report
> any issues.

* poldek appears to still enforce directory deps while rpms does not
  (that concerns mainly /usr/lib/.build-id subdirs)

* rpm.org is missing %{__ln} macro. spotted only single occurrence in
  xrdp.spec
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/kf5-kcontacts] - Initial version - ka5-kcontacts is now kf5-kcontacts.

[Jan Palus]

On 10.01.2021 23:24, lmasko wrote:
> commit dafe4e812b30fb4c82eb24be3b726bc549b64210
> Author: Łukasz Maśko 
> Date:   Sun Jan 10 23:23:28 2021 +0100
> 
> - Initial version - ka5-kcontacts is now kf5-kcontacts.
> 
>  kf5-kcontacts.spec | 85 
> ++
>  1 file changed, 85 insertions(+)
> ---
> diff --git a/kf5-kcontacts.spec b/kf5-kcontacts.spec
> new file mode 100644
> index 000..f9d368c
> --- /dev/null
> +++ b/kf5-kcontacts.spec
> @@ -0,0 +1,85 @@
> +%define  kdeframever 5.77
> +%define  qtver   5.15.0
> +%define  kfname  kcontacts
> +Summary: kcontacts
> +Name:kf5-%{kfname}

You do wanna use `copy` for such renames to keep history intact.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: audacity 2.4.x and wxWidgets

[Jan Palus]

On 22.01.2021 10:08, Krzysztof Mrozowicz wrote:
> Hi,
> I updated audacity spec to version 2.4.2, but during the work I found that
> this version no longer compiles on 32 bits. I don't know what exactly should
> be added to the spec file to inform builders to do not try to build it on
> unsupported architectures. Can someone help?

Compilation on i686 was fixed however few things still can be improved:

- in %prep drop all sources from lib-src/ which are already packaged in
  PLD also verify whether respective BRs are present

- consider upgrading libsbsms2 to 2.1.0 from 
https://github.com/claytonotey/libsbsms
  and with small cmake patch you could possibly use system sbsms
  (library which was failing on i686)

cmake-proxies/CMakeLists.txt:
-addlib( sbsms  sbsms   SBSMS   NOYES   "" )
+addlib( sbsms  sbsms   SBSMS   NOYES   "sbsms" )

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

Re: git default branch

[Jan Palus]

On 02.02.2021 14:30, Arkadiusz Miśkiewicz wrote:
> W dniu 02.02.2021 o 14:11, Jan Palus pisze:
> > Could someone please silent this hint? FWIW "master" is still perfectly
> > fine as far as I'm concerned.
> > 
> > $ git pld init alacritty
> > hint: Using 'master' as the name for the initial branch. This default 
> > branch name
> > hint: is subject to change. To configure the initial branch name to use in 
> > all
> > hint: of your new repositories, which will suppress this warning, call:
> > hint:
> > hint:   git config --global init.defaultBranch 
> > hint:
> > hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> > hint: 'development'. The just-created branch can be renamed via this 
> > command:
> > hint:
> > hint:   git branch -m 
> > Initialized empty Git repository in 
> > /cvs/root/gitolite/repositories/packages/alacritty.git/
> 
> git config --global init.defaultBranch master
> 
> doesn't make it silent aka is this from local or remote git?

remote I believe, especially judging by last line. defaultBranch was
already set in my local config.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

git default branch

[Jan Palus]

Could someone please silent this hint? FWIW "master" is still perfectly
fine as far as I'm concerned.

$ git pld init alacritty
hint: Using 'master' as the name for the initial branch. This default branch 
name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint:   git config --global init.defaultBranch 
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint:   git branch -m 
Initialized empty Git repository in 
/cvs/root/gitolite/repositories/packages/alacritty.git/
___
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] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti

[Jan Palus]

On 15.05.2021 11:44, Neal Gompa wrote:
> On Sat, May 15, 2021 at 10:41 AM Adam Gołębiowski  wrote:
> >
> >
> > W dniu 2021-05-15 o 15:26, Neal Gompa pisze:
> > > On Sat, May 15, 2021 at 6:23 AM Adam Gołębiowski  
> > > wrote:
> > >>
> > >> W dniu 2021-05-15 o 11:52, Neal Gompa pisze:
> > >>> On Sat, May 15, 2021 at 5:38 AM Adam Gołębiowski  
> > >>> wrote:
> >  W dniu 2021-05-13 o 21:32, Elan Ruusamäe pisze:
> > 
> > > point of that guard was to wait for support to become available or
> > > someone implement a solution.
> > > (...)
> > > but as no such solution as provided, you need to update obsoletes to
> > > fill **all** package names that provide that file path.
> > >
> > > I refuse to do that myself as it's pretty stupid.
> >  ugly, for sure, but unless we come up with another solution (patching
> >  rpm to support Obsoletes: /path), we will need to maintain 11 
> >  Obsoletes:
> >  lines per package ...
> > 
> > >>> What problem are you trying to solve here? I'm not sure I understand
> > >>> why you're doing this.
> > >> Each of the php*-program packages provide /usr/bin/php symlink:
> > >>
> > >> /poldek:/all-avail> install phpcsProcessing 
> > >> dependencies...phpcs-3.4.1-2.noarch: required "/usr/bin/php" is 
> > >> provided by the
> > >> following packages:a) php4-program-4.4.9-67.x86_64b) 
> > >> php52-program-5.2.17-20130717.35.x86_64c) 
> > >> php53-program-5.3.29-52.x86_64d) 
> > >> php54-program-5.4.45-30.x86_64e) 
> > >> php55-program-5.5.38-22.x86_64f) php56-program-5.6.40-9.x86_64g) 
> > >> php70-program-7.0.33-8.x86_64h) php71-program-7.1.33-3.x86_64i) 
> > >> php72-program-7.2.34-1.x86_64j) php73-program-7.3.24-1.x86_64k) 
> > >> php74-program-7.4.12-2.x86_64l) 
> > >> php80-program-8.0.0-2.x86_64Which one do you want to install ('Q' to 
> > >> abort)?
> > >> [php4-program-4.4.9-67.x86_64]/
> > >>
> > >>
> > >>
> > >> Prior to rpm switch, each of those packages also had Obsoletes: 
> > >> /usr/bin/php so that you could easily switch the provider of 
> > >> /usr/bin/php symlinkL
> > >> /poldek:/all-avail> install php80-program-8.0.0-2.x86_64///
> > >>
> > >> /Loading [pndir]th-2020-updates...
> > >> Loading [pndir]th-2020-updates...
> > >> Loading [pndir]th-2020...
> > >> Loading [pndir]th-2020...
> > >> 29952 packages read
> > >> Processing dependencies...
> > >> php80-program-8.0.0-2.x86_64 marks php80-cli-8.0.0-2.x86_64 (cap
> > >> php80-cli = 4:8.0.0-2)
> > >>php80-cli-8.0.0-2.x86_64 marks php80-common-8.0.0-2.x86_64 (cap
> > >> /etc/php80)
> > >> There are 3 packages to install (2 marked by dependencies):
> > >> A php80-cli-8.0.0-2.x86_64  php80-common-8.0.0-2.x86_64
> > >> php80-program-8.0.0-2.x86_64
> > >> This operation will use 4.6MB of disk space.
> > >> Need to get 1.4MB of archives (1.4MB to download).
> > >>
> > >> [1/3] th-2020::php80-common-8.0.0-2.x86_64.rpm [1.4M (1.4M/s)]
> > >> [2/3] th-2020::php80-cli-8.0.0-2.x86_64.rpm [51.7K (51.7K/s)]
> > >> [3/3] th-2020::php80-program-8.0.0-2.x86_64.rpm [5.0K (5.0K/s)]
> > >> Executing pm-command.sh --upgrade -vh --root / --define
> > >> _check_dirname_deps 1...
> > >> error: failed to open /etc/mtab: No such file or directory
> > >> Preparing... ### [100%]
> > >> Repackaging...
> > >>  1:php72-program ### [100%]
> > >> Upgrading...
> > >>  1:php80-common ### [ 33%]
> > >>  2:php80-cli ### [ 67%]
> > >>  3:php80-program ### [100%]
> > >> poldek:/all-avail>/
> > >>
> > >>
> > >> But rpm-4 no longer allows / in Obsoletes:
> > >>
> > >> /Illegal char '/' (0x2f) in: Obsoletes: /usr/bin/php /
> > >>
> > >> Which makes this smooth transition no longer possible:
> > >>
> > >> /poldek:/all-avail> install php73-program-7.3.27-1.x86_64//
> > >> //Processing dependencies...//
> > >> //php73-program-7.3.27-1.x86_64 marks php73-cli-7.3.27-1.x86_64 (cap
> > >> php73-cli = 4:7.3.27-1)//
> > >> // php73-cli-7.3.27-1.x86_64 marks php73-common-7.3.27-1.x86_64 (cap
> > >> libphp_common-7.3.27.so()(64bit))//
> > >> //There are 3 packages to install (2 marked by dependencies)://
> > >> //A php73-cli-7.3.27-1.x86_64 php73-common-7.3.27-1.x86_64
> > >> php73-program-7.3.27-1.x86_64//
> > >> //This operation will use 4.2MB of disk space.//
> > >> //Need to get 1.2MB of archives.//
> > >> //php73-common-7.3.27-1.x86_64.rpm: digests OK//
> > >> //php73-cli-7.3.27-1.x86_64.rpm: digests OK//
> > >> //php73-program-7.3.27-1.x86_64.rpm: digests OK//
> > >> //Executing pm-command.sh --upgrade -vh --root / --define
> > >> _check_dirname_deps 0...//
> > >> //Verifying... # [100%]//
> > >> //Preparing... # [100%]//
> > >> //file /usr/bin/php from install of
> > 

Re: [packages/rust] bump required libgit2 version

[Jan Palus]

On 27.05.2021 17:05, Jan Rękorajski wrote:
> On Thu, May 27, 2021 at 4:19 PM atler  wrote:
> 
> > commit 1f9b856019ac20736ccec408a735866922e0748a
> > Author: Jan Palus 
> > Date:   Thu May 27 16:18:28 2021 +0200
> >
> > bump required libgit2 version
> >
> >  rust.spec | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> 
>  Please bump also rust to 1.52.1, there is some breakage in 1.52.0

Will do once 1.52.0 is finally built successfully. Mentioned breakage is
not that much concerning (shouldn't affect us):

"These problems only affect incremental builds, release builds with
Cargo should not be affected unless the user has explicitly opted into
incremental. Debug and check builds are affected"
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: rust on x32

[Jan Palus]

On 25.05.2021 10:17, Jan Rękorajski wrote:
> Hi,
> 
> Could someone with rust build chain knowlegde look at rust on x32?
> 
> My findings so far are that it does not build with target
> x86_64-...-gnux32, so we would have to build the compiler for x86_64 and
> just the stdlib for gnux32, the docs say that rust is a cross compiler by 
> default...
> so, should be doable even without pulling binary x32 stdlib for bootstrapping.
> 
> I'll give it a shot if no one beats me to it.

Working rust setup is currently hacked around on x32 builder which
consists of both rust.x32 and rust.x86_64 installed side by side. Few
remarks/thoughts:

- rust 1.47 on x32 built x86_64 compiler with target support for both
  x86_64 and x32 (two directories under /usr/lib/rustlib)

- rust 1.48 and higher appears to build x86_64 compiler with single
  target support: x32

- since parts of build process require building things for host (which
  is x86_64) it started to fail with "can't find crate for `std`" due to
  missing target for x86_64

- that's why installation of rust.x86_64 next to rust.x32 helped -- it
  provides x86_64 target support

- I haven't noticed that x32 patch was left commented out so I guess
  it's not required anymore?

As for solution not sure which one is least bad:

1. Just R: rust(x86-64) in rust(x86-x32)
2. Package just target support files and R: rust(x86-64) for the rest
3. Package target independently ie rust-target-x86_64 and require it in
   rust(x86-x32)
4. Other

Happy to pass over decision and implementation to somebody else :).
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/rust] - relax internal deps

[Jan Palus]

On 28.05.2021 12:30, baggins wrote:
> commit 89a1e043707dd595670e060055d7f14359d1f4d6
> Author: Jan Rękorajski 
> Date:   Fri May 28 12:29:33 2021 +0200
> 
> - relax internal deps
> 
>  rust.spec | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> ---
> @@ -204,7 +204,7 @@ Standardowa biblioteka Rusta.
>  Summary: Implementation of Language Server Protocol for Rust
>  Summary(pl.UTF-8):   Implementacja Language Server Protocol dla Rusta
>  Group:   Development/Tools
> -Requires:%{name}%{?_isa} = %{version}-%{release}
> +Requires:%{name} = %{version}-%{release}

Note that *.so in /usr/lib/rustlib/ are symlinks to %{_libdir}
so I suppose these should be packaged in rust-std as well in case of
relaxed deps.

Also *.so on x32 should probably be moved from /usr/libx32 to /usr/lib64
since they're not built for x32 ABI (no conflict with rust-std(x86-64)
thanks to unique hash in each filename).
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: TEST build ERRORS: expat.spec

[Jan Palus]

On 24.05.2021 10:12, PLD th-x86_64 builder wrote:

> Processing dependencies...
> There are 1 package to install:
> A docbook2X-0.8.8-6.x86_64
> This operation will use 1.3MB of disk space.
> docbook2X-0.8.8-6.x86_64.rpm: digests OK
> Need to get 291.2KB of archives. 
> docbook2X-0.8.8-6.x86_64.rpm: digests OK
> Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 
> 0...
> warning: 
> /root/.poldek-cache/ftp_ep09.pld-linux.org.dists.th.PLD.x86.64.RPMS/docbook2X-0.8.8-6.x86_64.rpm:
>  Header V4 DSA/SHA1 Signature, key ID e4f1bc2d: NOKEY
> error: Failed dependencies:
>   docbook2X is obsoleted by (installed) docbook-utils-0:0.6.14-5.noarch
> error: BR installation failed

Trying to use docbook-utils instead of docbook2X results in:

configure: error: Your local docbook2man was found to work with SGML rather
  than XML. Please install docbook2X and use variable DOCBOOK_TO_MAN to point
  configure to command docbook2x-man of docbook2X.
  Or use DOCBOOK_TO_MAN="xmlto man --skip-validation" if you have xmlto around.
  You can also configure using --without-docbook if you can do without a man
  page for xmlwf.

Does docbook-utils really _obsolete_ docbook2X? I think they've used to
have conflicting files but that's no longer the case.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: problem with firefox 88

[Jan Palus]

On 04.05.2021 21:10, Krzysztof Mrozowicz via pld-devel-en wrote:

W dniu 03.05.2021 o 22:22, Krzysztof Mrozowicz pisze:

W dniu 03.05.2021 o 22:11, Krzysztof Mrozowicz pisze:

Hi,
I just upgraded firefox to version 88 and discovered its interface 
doesn't respond to clicking and in the terminal I can see the 
following:


JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 
2304: Error: primed listener not re-registered
JavaScript error: resource://gre/modules/XULStore.jsm, line 66: 
Error: Can't find profile directory.


Am I only one with this issue?


On my other PLD instance, to which I connect via XRDP, the problem 
doesn't exist (and similar messages are displayed in the terminal). 
So maybe it's rather problem with the graphic driver than firefox...



Downgraded to version 87 and happy days.
Works for me. Did you try with fresh profile (firefox -ProfileManager), 
mozilla's binary (package mozilla-firefox-bin) and in case it still 
doesn't work stracing it?

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

Re: problem with firefox 88

[Jan Palus]

On 05.05.2021 12:50, Krzysztof Mrozowicz via pld-devel-en wrote:

W dniu 05.05.2021 o 11:35, Jan Palus pisze:

Downgraded to version 87 and happy days.
Works for me. Did you try with fresh profile (firefox 
-ProfileManager), mozilla's binary (package mozilla-firefox-bin) and 
in case it still doesn't work stracing it?


I tried with fresh profile - the same effect. It seems like FF is 
reacting for clicking, but doesn't "re-paint" the interface accordingly.
When I, let's say click "+" to open a new tab, then minimize the 
window and restore it, the new tab is there. Double-clicking on the 
window title (maximize/un-maximize) also refreshes the interface. 
Firefox 88 from mozilla-firefox-bin behaves the exact same way.


Would you mind telling me how to strace the program in a correct way, 
please? I did it few times in the past but always I was googling the 
method.
Ah ok, somehow I thought firefox hangs or fails to start for you. That's 
probably an effect of enabling WebRender by default for XFCE/KDE with 
Intel/AMD GPU so likely for you. Try disabling webrender in about:config 
(|gfx.webrender.force-disabled=true). Which GPU? If Intel are you using 
modesetting driver?

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

Re: problem with firefox 88

[Jan Palus]

On 05.05.2021 13:44, Krzysztof Mrozowicz via pld-devel-en wrote:

W dniu 05.05.2021 o 12:08, Jan Palus pisze:

On 05.05.2021 12:50, Krzysztof Mrozowicz via pld-devel-en wrote:

W dniu 05.05.2021 o 11:35, Jan Palus pisze:

Downgraded to version 87 and happy days.
Works for me. Did you try with fresh profile (firefox 
-ProfileManager), mozilla's binary (package mozilla-firefox-bin) 
and in case it still doesn't work stracing it?


I tried with fresh profile - the same effect. It seems like FF is 
reacting for clicking, but doesn't "re-paint" the interface 
accordingly.
When I, let's say click "+" to open a new tab, then minimize the 
window and restore it, the new tab is there. Double-clicking on the 
window title (maximize/un-maximize) also refreshes the interface. 
Firefox 88 from mozilla-firefox-bin behaves the exact same way.


Would you mind telling me how to strace the program in a correct 
way, please? I did it few times in the past but always I was 
googling the method.
Ah ok, somehow I thought firefox hangs or fails to start for you. 
That's probably an effect of enabling WebRender by default for 
XFCE/KDE with Intel/AMD GPU so likely for you. Try disabling 
webrender in about:config (|gfx.webrender.force-disabled=true). Which 
GPU? If Intel are you using modesetting driver?


Zwycięstwo! Setting up the gfx.webrender.force-disabled=true made the 
firefox usable again. Thanks Jan!


Regarding the modesetting, I don't remember if I was tweaking any X 
config about that. My hardware is:

CPU: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz
GPU: VGA compatible controller: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller (rev 09)


And xorg.log:

# grep modesetting Xorg.0.log
[    18.622] (==) Matched modesetting as autoconfigured driver 1
[    18.628] (II) LoadModule: "modesetting"
[    18.628] (II) Loading 
/usr/lib64/xorg/modules/drivers/modesetting_drv.so

[    18.629] (II) Module modesetting: vendor="X.Org Foundation"
[    18.632] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[    18.675] (WW) Falling back to old probe method for modesetting
[    18.682] (II) UnloadModule: "modesetting"
[    18.682] (II) Unloading modesetting
Not using modesetting on Intel is your real issue. Try to figure what's 
missing to make it work and webrender most likely will be fine in 
firefox. Anyway if you still have issues the discussion should be moved 
to pld-users-*

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

Re: sudo after upgrade

[Jan Palus]

On 02.02.2021 20:45, Andrzej Zawadzki wrote:
>Hi,
> 
>I've just upgrade to newest test and after restart I'm not at wheel
>group anymore
> 
>id zawada
>uid=1000(zawada) gid=1000(users) grupy=1000(users)
> 
>but:
> 
>cat /etc/group|grep zawada
>wheel::10:root,zawada
> 
>Bug or feature?

Encountered it on one machine as well... You have outdated
/etc/nsswitch.conf most likely with entry that breaks group membership
completely:

initgroups: [SUCCESS=continue] files
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: sudo after upgrade

[Jan Palus]

On 08.02.2021 14:46, Jan Palus wrote:
> On 02.02.2021 20:45, Andrzej Zawadzki wrote:
> >Hi,
> > 
> >I've just upgrade to newest test and after restart I'm not at wheel
> >group anymore
> > 
> >id zawada
> >uid=1000(zawada) gid=1000(users) grupy=1000(users)
> > 
> >but:
> > 
> >cat /etc/group|grep zawada
> >wheel::10:root,zawada
> > 
> >Bug or feature?
> 
> Encountered it on one machine as well... You have outdated
> /etc/nsswitch.conf most likely with entry that breaks group membership
> completely:
> 
> initgroups:   [SUCCESS=continue] files

There supposed to be "db" before [SUCCESS=continue] but it was stripped by us

glibc.spec:

sed -e 's#\([ \t]\)db\([ \t]\)#\1#g' nss/nsswitch.conf > 
$RPM_BUILD_ROOT%{_sysconfdir}/nsswitch.conf

hence if I understand it correctly: if db succeeded skip files, otherwise do 
files. Apparently
glibc 2.33 changed semantics of such broken entry and files are not
processed at all resulting in heavily crippled system (but hey, root
works fine ;) ).

Note that above sed is no longer necessary since at least glibc 2.31
which dropped "db" in default config:

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=4b7c74179c8928d971d370e1137d202f891a4cf5;hp=a289ea09ea843ced6e5277c2f2e63c357bc7f9a3
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/rpm] - x32 patch fixes

[Jan Palus]

On 23.03.2021 08:53, baggins wrote:
> commit b10d9d9e984edbf3157c9fee959c0868486a2f93
> Author: Jan Rękorajski 
> Date:   Tue Mar 23 08:52:27 2021 +0100
> 
> - x32 patch fixes
> 
>  x32.patch | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> ---
> diff --git a/x32.patch b/x32.patch
> index 38aa140..f7ab616 100644
> --- a/x32.patch
> +++ b/x32.patch
> -@@ -190,10 +201,14 @@
> -   # skip architectures for which we dont have full config parameters
> -   [ -z "$CANONARCH" ] && continue
> - 
> --  if [ "$OS" = "linux" ] && [ "$CANONCOLOR" = 3 ]; then
> -+  if [ "$OS" = "linux" ] && [ "$CANONARCH" = "x86_64" ]; then
> +@@ -190,6 +201,10 @@
> LIB=${LIB}64
> fi

This hunk should either be brought back or CANONCOLOR for x86_64 should
be reverted to 3 (it is still 7). Current end result on x86_64 is _lib=lib.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/rpm] - x32 patch fixes

[Jan Palus]

On 23.03.2021 14:44, Jan Rękorajski wrote:
> On Tue, Mar 23, 2021 at 1:59 PM Jan Palus  wrote:
> 
> > On 23.03.2021 08:53, baggins wrote:
> > > commit b10d9d9e984edbf3157c9fee959c0868486a2f93
> > > Author: Jan Rękorajski 
> > > Date:   Tue Mar 23 08:52:27 2021 +0100
> > >
> > > - x32 patch fixes
> > >
> > >  x32.patch | 10 +++---
> > >  1 file changed, 3 insertions(+), 7 deletions(-)
> > > ---
> > > diff --git a/x32.patch b/x32.patch
> > > index 38aa140..f7ab616 100644
> > > --- a/x32.patch
> > > +++ b/x32.patch
> > > -@@ -190,10 +201,14 @@
> > > -   # skip architectures for which we dont have full config parameters
> > > -   [ -z "$CANONARCH" ] && continue
> > > -
> > > --  if [ "$OS" = "linux" ] && [ "$CANONCOLOR" = 3 ]; then
> > > -+  if [ "$OS" = "linux" ] && [ "$CANONARCH" = "x86_64" ]; then
> > > +@@ -190,6 +201,10 @@
> > > LIB=${LIB}64
> > > fi
> >
> > This hunk should either be brought back or CANONCOLOR for x86_64 should
> > be reverted to 3 (it is still 7). Current end result on x86_64 is _lib=lib.
> >
> 
> Can you restore this hunk and rebuild rpm? I can't do it till evening :(
> 
> It should probably even be 'if [ "$OS" = "linux" ] && [ "$CANONARCH" =
> "x86_64"] || [ "$CANONCOLOR" = 3 ]; then'

Done. Looks like everything is back to normal.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/rpm-pld-macros] initial basic rust/cargo macros (2.003)

[Jan Palus]

On 30.03.2021 18:44, Elan Ruusamäe wrote:
> On 30.03.2021 14:06, atler wrote:
> 
> > commit 593b448d587953c0aa5cfb8484485fda26499d3c
> > Author: Jan Palus 
> > Date:   Tue Mar 30 12:59:03 2021 +0200
> > 
> >  initial basic rust/cargo macros (2.003)
> > 
> >   macros.pld  | 17 +
> 
> perhaps place the rust/cargo macros to a separate file?

Moved to its own file in 2.004.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [projects/template-specs] use %cargo_* macros

[Jan Palus]

On 30.03.2021 20:57, Jakub Bogusz wrote:
> On Tue, Mar 30, 2021 at 06:46:46PM +0300, Elan Ruusamäe wrote:
> [...]
> > >@@ -40,19 +41,17 @@ EOF
> > >  %build
> > >  export CARGO_HOME="$(pwd)/.cargo"
> > >  
> > >-cargo -v build \
> > >+%cargo_build \
> > >  %ifarch x32
> > >   --target x86_64-unknown-linux-gnux32 \
> > >  %endif
> > >-  --release \
> > >   --frozen
> > >  
> > >  %install
> > >  rm -rf $RPM_BUILD_ROOT
> > >  export CARGO_HOME="$(pwd)/.cargo"
> > >  
> > >-cargo -vv \
> > >-  install \
> > >+%cargo_install \
> > >   --frozen \
> > >   --path . \
> > >   --root $RPM_BUILD_ROOT%{_prefix}
> > 
> > 
> > why not include the crate based build options also into common macros?
> > 
> > 
> > also, in template-specs/rust.spec, there's comment for source0, creating 
> > crate, maybe an universal script could be provided by macros package?
> 
> I'd enhance %cargo_build at least by adding x32 --target option.

Good point, thanks. I didn't realize rustc on x32 does not compile to
x32 by default. Added in 2.004.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

chroot for armv6hl

[Jan Palus]

For anyone interested, PLD chroot is now available for armv6hl in
addition to aarch64. Both can be downloaded at:

https://github.com/jpalus/pld-linux-arm/releases

PLD has been happily powering my Raspberry Pi 2 and Zero for a while now.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: [packages/poldek] skip /usr/lib/.build-id when processing obsoletes

[Jan Palus]

On 16.03.2021 13:31, atler wrote:
> commit aba59b953581b330457d7e6f0ea3e1ab648f80a7
> Author: Jan Palus 
> Date:   Tue Mar 16 13:28:50 2021 +0100
> 
> skip /usr/lib/.build-id when processing obsoletes
> 
> fixes major performance regression when changing (downgrade, obsolete)
> package with build-id to one that doesn't
> 
>  poldek.spec  |  2 ++
>  skip-buildid-obsoletes.patch | 11 +++
>  2 files changed, 13 insertions(+)
...
> diff --git a/skip-buildid-obsoletes.patch b/skip-buildid-obsoletes.patch
> new file mode 100644
> index 000..1b2e7c1
> --- /dev/null
> +++ b/skip-buildid-obsoletes.patch
> @@ -0,0 +1,11 @@
> +--- poldek-0.42.2/install3/obsoletes.c.orig  2020-01-25 22:59:59.0 
> +0100
>  poldek-0.42.2/install3/obsoletes.c   2021-03-16 13:14:05.667576984 
> +0100
> +@@ -188,6 +188,8 @@
> + "/usr/share/doc/*",
> + "/usr/share/man/*.[0-9]",
> + "/usr/src/examples/*",
> ++"/usr/lib/.build-id",
> ++"/usr/lib/.build-id/*",
> + "*.desktop",
> + "*.mo",
> + "*.gz",

Note that it's just half of the solution, the other one is to fix
find-debuginfo.sh to exclude any dir ownership. Currently every binary
package built with rpm4 owns /usr/lib/.build-id and its subdirectories
while only symlinks should be owned. If someone is up for this please be
my guest.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

Re: ca-certs for https://git.php.net

[Jan Palus]

On 12.03.2021 10:40, Elan Ruusamäe wrote:
> $ curl https://git.php.net/repository/pecl/encryption/mcrypt.git
> curl: (60) SSL certificate problem: unable to get local issuer certificate
> More details here: https://curl.se/docs/sslcerts.html
> 
> curl failed to verify the legitimacy of the server and therefore could not
> establish a secure connection to it. To learn more about this situation and
> how to fix it, please visit the web page mentioned above.
> 
> 
> $ rpm -q ca-certificates curl-7.75.0
> ca-certificates-20210119-1.noarch
> curl-7.75.0-1.x86_64
> 
> 
> something off in our systems. this works fine on curl on macos brew

Works for me with same set of packages. Outdated ca-certificates.crt due
to ca-certificates-update + noreplace perhaps? Try with
ca-certificates-20210119-2.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en