Re: remmina not working after llvm upgrade
On 26.05.2023 02:18, Jan Palus wrote: On 25.05.2023 15:41, Krzysztof Mrozowicz via pld-devel-en wrote: Dnia 2023-05-25, o godz. 14:59:56 Jan Palus [1] napisal/(a): Yes, that's after reboot. Could be Mesa, it's upgraded too.. Do you mind sharing output (remmina.strace) of: strace -o remmina.strace -f -e '/open.*' -z remmina I observe a similar problem on my computer. The strace file can be found at [2]https://pastebin.com/KuXzXaYP Thank you both for sharing strace output. Can you try upgrading SPIRV-LLVM-Translator* spirv-tools* and Mesa* and see if it helps? Works Thanks! Now I can log into my favorite OS ;-) -- Andrzej Zawadzki References 1. mailto:at...@pld-linux.org 2. https://pastebin.com/KuXzXaYP ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: remmina not working after llvm upgrade
On 25.05.2023 15:41, Krzysztof Mrozowicz via pld-devel-en wrote: > Dnia 2023-05-25, o godz. 14:59:56 > Jan Palus napisał(a): > > > > > > >Yes, that's after reboot. Could be Mesa, it's upgraded too.. > > > > Do you mind sharing output (remmina.strace) of: > > > > strace -o remmina.strace -f -e '/open.*' -z remmina > > I observe a similar problem on my computer. The strace file can be > found at https://pastebin.com/KuXzXaYP Thank you both for sharing strace output. Can you try upgrading SPIRV-LLVM-Translator* spirv-tools* and Mesa* and see if it helps? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: remmina not working after llvm upgrade
Dnia 2023-05-25, o godz. 14:59:56 Jan Palus napisał(a): > > > >Yes, that's after reboot. Could be Mesa, it's upgraded too.. > > Do you mind sharing output (remmina.strace) of: > > strace -o remmina.strace -f -e '/open.*' -z remmina I observe a similar problem on my computer. The strace file can be found at https://pastebin.com/KuXzXaYP Regards -- Krzysiek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: remmina not working after llvm upgrade
On 25.05.2023 13:14, Andrzej Zawadzki wrote: >On 25.05.2023 12:35, Jan Palus wrote: > > On 25.05.2023 12:04, Andrzej Zawadzki wrote: > >Hi! > >$ remmina >** Message: 11:54:59.423: Remmina does not log all output statements. >Turn on more verbose output by using "G_MESSAGES_DEBUG=all" as an >environment variable. >More info available on the Remmina wiki at: >[1][1]https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging >Load modules from /usr/lib64/remmina/plugins >Remmina plugin glibsecret (type=Secret) has been registered, but is not >yet initialized/activated. The initialization order is 2000. >The glibsecret secret plugin has been initialized and it will be your >default secret plugin >(org.remmina.Remmina:9625): Gtk-WARNING **: 11:55:00.227: >gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem >: CommandLine Error: Option 'use-dbg-addr' registered more than once! >LLVM ERROR: inconsistency in registered CommandLine options >Aborted (core dumped) >Rebuild needed? > > Works fine for me. I doubt Remmina has anything to do with LLVM > directly so rebuild wouldn't change anything. Judging by Google results > this could possibly be coming from a Mesa driver. Did you restart your > GUI session (X/Wayland) after an upgrade to make sure new driver is > running? > >Yes, that's after reboot. Could be Mesa, it's upgraded too.. Do you mind sharing output (remmina.strace) of: strace -o remmina.strace -f -e '/open.*' -z remmina ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: remmina not working after llvm upgrade
On 25.05.2023 12:35, Jan Palus wrote: On 25.05.2023 12:04, Andrzej Zawadzki wrote: Hi! $ remmina ** Message: 11:54:59.423: Remmina does not log all output statements. Turn on more verbose output by using "G_MESSAGES_DEBUG=all" as an environment variable. More info available on the Remmina wiki at: [1][1]https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging Load modules from /usr/lib64/remmina/plugins Remmina plugin glibsecret (type=Secret) has been registered, but is not yet initialized/activated. The initialization order is 2000. The glibsecret secret plugin has been initialized and it will be your default secret plugin (org.remmina.Remmina:9625): Gtk-WARNING **: 11:55:00.227: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem : CommandLine Error: Option 'use-dbg-addr' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options Aborted (core dumped) Rebuild needed? Works fine for me. I doubt Remmina has anything to do with LLVM directly so rebuild wouldn't change anything. Judging by Google results this could possibly be coming from a Mesa driver. Did you restart your GUI session (X/Wayland) after an upgrade to make sure new driver is running? Yes, that's after reboot. Could be Mesa, it's upgraded too.. -- Andrzej Zawadzki References 1. https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: remmina not working after llvm upgrade
On 25.05.2023 12:04, Andrzej Zawadzki wrote: >Hi! > >$ remmina >** Message: 11:54:59.423: Remmina does not log all output statements. >Turn on more verbose output by using "G_MESSAGES_DEBUG=all" as an >environment variable. >More info available on the Remmina wiki at: >[1]https://gitlab.com/Remmina/Remmina/-/wikis/Usage/Remmina-debugging >Load modules from /usr/lib64/remmina/plugins >Remmina plugin glibsecret (type=Secret) has been registered, but is not >yet initialized/activated. The initialization order is 2000. >The glibsecret secret plugin has been initialized and it will be your >default secret plugin >(org.remmina.Remmina:9625): Gtk-WARNING **: 11:55:00.227: >gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem >: CommandLine Error: Option 'use-dbg-addr' registered more than once! >LLVM ERROR: inconsistency in registered CommandLine options >Aborted (core dumped) >Rebuild needed? Works fine for me. I doubt Remmina has anything to do with LLVM directly so rebuild wouldn't change anything. Judging by Google results this could possibly be coming from a Mesa driver. Did you restart your GUI session (X/Wayland) after an upgrade to make sure new driver is running? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: itstool 2.0.7 vs [packages/mate-utils] up to 1.26.1
On 10.05.2023 17:58, Jakub Bogusz wrote:
> On Wed, May 10, 2023 at 10:07:32AM +0200, atler wrote:
> > commit 8aa16867d2911b7b77adf7d0041e2b455f560fc9
> > Author: Jan Palus
> > Date: Wed May 10 10:07:19 2023 +0200
> >
> > up to 1.26.1
> >
> > mate-utils.spec | 4 ++--
>
> It (usually) fails for me with itstool 2.0.7. With itstool 2.0.6 it succeeded.
>
>
> ```
> if ! test -d "pt/"; then mkdir "pt/"; fi
> if test -d "C"; then d="../"; else
> d="/home/comp/rpm/BUILD/mate-utils-1.26.1/gsearchtool/help/"; fi; \
> mo="pt/pt.mo"; \
> if test -f "${mo}"; then mo="../${mo}"; else
> mo="/home/comp/rpm/BUILD/mate-utils-1.26.1/gsearchtool/help/${mo}"; fi; \
> (cd "pt/" && itstool -m "${mo}" ${d}/C/index.docbook ${d}/C/legal.xml) && \
> touch "pt/pt.stamp"
> Memory fault
> ```
>
> or
>
> ```
> if ! test -d "pt/"; then mkdir "pt/"; fi
> if test -d "C"; then d="../"; else
> d="/home/comp/rpm/BUILD/mate-utils-1.26.1/gsearchtool/help/"; fi; \
> mo="pt/pt.mo"; \
> if test -f "${mo}"; then mo="../${mo}"; else
> mo="/home/comp/rpm/BUILD/mate-utils-1.26.1/gsearchtool/help/${mo}"; fi; \
> (cd "pt/" && itstool -m "${mo}" ${d}/C/index.docbook ${d}/C/legal.xml) && \
> touch "pt/pt.stamp"
> Traceback (most recent call last):
> File "/usr/bin/itstool", line 1647, in
> doc.merge_translations(translations, opts.lang, strict=opts.strict)
> File "/usr/bin/itstool", line 1016, in merge_translations
> lcnode.setProp(attr, origlang)
> File "/usr/lib/python3.10/site-packages/libxml2.py", line 3640, in setProp
> if ret is None:raise treeError('xmlSetProp() failed')
> libxml2.treeError: xmlSetProp() failed
> ```
>
> (sometimes it succeeds)
Actually I was seeing the same with itstool 2.0.6 and found multiple
reports about the very issue with main one being (with root cause
somewhat identified dating back to 2.0.4):
https://github.com/itstool/itstool/issues/36
Upgraded to 2.0.7 only because noticed there is a newer version and
sadly none of the changes between 2.0.6 and 2.0.7 seems to either
improve or regress memory issues.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On Fri, Jul 22, 2022 at 11:03:54AM +0200, Jan Rękorajski wrote: > Can someone explain why are we using split sources/packages for Qt? Beside build time and space requirements, I see one more reason now: rebuilding after dependent package soname change is more painful. Current case: jasper 3.x. Split case: just qt5-qtimageformats.spec to rebuild Monolithic case: whole qt6.spec to rebuild -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: GitHub key needs an update
On 24.03.2023 12:42, Jan Palus wrote: That's expected and GitHub host key needs an update, see: https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/ Updated. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | 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] Add _metainfodir, rev 2.023
On 22.02.2023 21:38, Jan Palus wrote:
On 22.02.2023 19:55, glen wrote:
commit fa6a978633bd3fbae3c510fb6299ddb67af8da00
Author: Elan Ruusamäe
Date: Wed Feb 22 20:54:40 2023 +0200
Add _metainfodir, rev 2.023
- https://src.fedoraproject.org/rpms/redhat-rpm-config/c/67e46b630d5d0bc74188b2ea5aa36eff5117ddc9?branch=f27
...
--- a/macros.pld
+++ b/macros.pld
@@ -25,6 +25,8 @@
%_lispdir %{_datadir}/emacs/site-lisp
%_initddir%{_sysconfdir}/rc.d/init.d
+%_metainfodir %{_datadir}/appdata
Shouldn't this point to non-legacy %{_datadir}/metainfo instead?
https://freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location
changed:
-
https://github.com/pld-linux/rpm-pld-macros/commit/d242d4da01feb055dbbc7187712e200e07022488
___
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] Add _metainfodir, rev 2.023
On 22.02.2023 19:55, glen wrote:
> commit fa6a978633bd3fbae3c510fb6299ddb67af8da00
> Author: Elan Ruusamäe
> Date: Wed Feb 22 20:54:40 2023 +0200
>
> Add _metainfodir, rev 2.023
>
> -
> https://src.fedoraproject.org/rpms/redhat-rpm-config/c/67e46b630d5d0bc74188b2ea5aa36eff5117ddc9?branch=f27
...
> --- a/macros.pld
> +++ b/macros.pld
> @@ -25,6 +25,8 @@
> %_lispdir%{_datadir}/emacs/site-lisp
> %_initddir %{_sysconfdir}/rc.d/init.d
>
> +%_metainfodir%{_datadir}/appdata
Shouldn't this point to non-legacy %{_datadir}/metainfo instead?
https://freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location
Perhaps _appdatadir for legacy locations.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/texlive/TEXLIVE_20080816] fix "sh: syntax error: unexpected '('" during file processing
On 30.01.2023 14:26, atler wrote: -%define_noautoreq 'perl(path_tre)' +%define_noautoreq perl\\(path_tre\\) just use _noautoreq_perl ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: lists test
W dniu wt., 7.02.2023 o 21:37 Arkadiusz Miśkiewicz via pld-devel-en < pld-devel-en@lists.pld-linux.org> napisał(a): > 123... Nope, doesn't work. -- Łukasz [Deejay1] Jernaś ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: lists test
Dnia wtorek, 7 lutego 2023 21:37:29 CET Arkadiusz Miśkiewicz via pld-devel-en pisze: > 123... Seems to work. -- Łukasz Maśko_o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafrykańskie słowo oznaczające "Nie umiem zainstalować Debiana" ___ 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 carme-x32
On 20.01.2023 22:04, Jakub Bogusz wrote: On Thu, Jan 19, 2023 at 09:14:51AM +0100, Arkadiusz Miśkiewicz via pld-devel-en wrote: On 18.01.2023 16:08, Jakub Bogusz wrote: Could rust be installed on carme-x32? I'd like to (try to) fix mozjs102 build (required for new gjs), but I cannot install rust myself because of x86_64 packages requirements. Should be available now. I need cargo as well (requires 64-bit curl, libgit2 and openssl libs). Installed. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | 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: rust on carme-x32
On Thu, Jan 19, 2023 at 09:14:51AM +0100, Arkadiusz Miśkiewicz via pld-devel-en wrote: > On 18.01.2023 16:08, Jakub Bogusz wrote: > >Could rust be installed on carme-x32? > > > >I'd like to (try to) fix mozjs102 build (required for new gjs), but > >I cannot install rust myself because of x86_64 packages requirements. > > > > > > Should be available now. I need cargo as well (requires 64-bit curl, libgit2 and openssl libs). -- Jakub Boguszhttp://qboosh.pl/ ___ 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 carme-x32
On 18.01.2023 16:08, Jakub Bogusz wrote: Could rust be installed on carme-x32? I'd like to (try to) fix mozjs102 build (required for new gjs), but I cannot install rust myself because of x86_64 packages requirements. Should be available now. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | 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: x32 builder has network access
On 18.01.2023 16:48, Jakub Bogusz wrote: > On Wed, Jan 18, 2023 at 01:02:34PM +0100, Arkadiusz Miśkiewicz via > pld-devel-en wrote: > > On 18.01.2023 09:56, Jan Palus wrote: > > >On 18.01.2023 07:54, Arkadiusz Miśkiewicz via pld-devel-en wrote: > > >>On 17.01.2023 12:23, Jan Palus wrote: > > >>>Noticed during build of kodi-addon-inputstream-adaptive that contrary to > > >>>x86_64 and i686, x32 builder downloaded external sources successfully: > > >> > > >>bind was installed there and seems that even if there is no access to > > >>/etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53 > > >> > > >>Uninstalled. > > >> > > >>The best would be to change UID of "builder" user used inside of chroot > > >>and drop all outgoing packets coming from it at iptables level. > > > > > >Or perhaps modify pld-builder to make each rpmbuild invocation in a new > > >network namespace via `unshare -n -c`. That would effectively cut whole > > >network for the process. > > > > We can try that... commited. > > i686 and x86_64 say: > "unshare: unshare failed: Operation not permitted" Unfortunately it appears it's not possible to create user namespaces in a chroot: EPERM (since Linux 3.9) CLONE_NEWUSER was specified in flags and the caller is in a chroot environment (i.e., the caller's root directory does not match the root directory of the mount namespace in which it resides). ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: x32 builder has network access
On Wed, Jan 18, 2023 at 01:02:34PM +0100, Arkadiusz Miśkiewicz via pld-devel-en wrote: > On 18.01.2023 09:56, Jan Palus wrote: > >On 18.01.2023 07:54, Arkadiusz Miśkiewicz via pld-devel-en wrote: > >>On 17.01.2023 12:23, Jan Palus wrote: > >>>Noticed during build of kodi-addon-inputstream-adaptive that contrary to > >>>x86_64 and i686, x32 builder downloaded external sources successfully: > >> > >>bind was installed there and seems that even if there is no access to > >>/etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53 > >> > >>Uninstalled. > >> > >>The best would be to change UID of "builder" user used inside of chroot > >>and drop all outgoing packets coming from it at iptables level. > > > >Or perhaps modify pld-builder to make each rpmbuild invocation in a new > >network namespace via `unshare -n -c`. That would effectively cut whole > >network for the process. > > We can try that... commited. i686 and x86_64 say: "unshare: unshare failed: Operation not permitted" Still waiting for x32 (seems busy with openjdks). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: x32 builder has network access
On 18.01.2023 09:56, Jan Palus wrote: On 18.01.2023 07:54, Arkadiusz Miśkiewicz via pld-devel-en wrote: On 17.01.2023 12:23, Jan Palus wrote: Noticed during build of kodi-addon-inputstream-adaptive that contrary to x86_64 and i686, x32 builder downloaded external sources successfully: bind was installed there and seems that even if there is no access to /etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53 Uninstalled. The best would be to change UID of "builder" user used inside of chroot and drop all outgoing packets coming from it at iptables level. Or perhaps modify pld-builder to make each rpmbuild invocation in a new network namespace via `unshare -n -c`. That would effectively cut whole network for the process. We can try that... commited. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | 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: x32 builder has network access
On 18.01.2023 07:54, Arkadiusz Miśkiewicz via pld-devel-en wrote: > On 17.01.2023 12:23, Jan Palus wrote: > > Noticed during build of kodi-addon-inputstream-adaptive that contrary to > > x86_64 and i686, x32 builder downloaded external sources successfully: > > bind was installed there and seems that even if there is no access to > /etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53 > > Uninstalled. > > The best would be to change UID of "builder" user used inside of chroot > and drop all outgoing packets coming from it at iptables level. Or perhaps modify pld-builder to make each rpmbuild invocation in a new network namespace via `unshare -n -c`. That would effectively cut whole network for the process. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: x32 builder has network access
On 17.01.2023 12:23, Jan Palus wrote: Noticed during build of kodi-addon-inputstream-adaptive that contrary to x86_64 and i686, x32 builder downloaded external sources successfully: bind was installed there and seems that even if there is no access to /etc/resolv.conf glibc fallbacks to querying 127.0.0.1:53 Uninstalled. The best would be to change UID of "builder" user used inside of chroot and drop all outgoing packets coming from it at iptables level. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | 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: udev-core R >= 4.15
On 22.12.2022 11:49, Arkadiusz Miśkiewicz via pld-devel-en wrote: > udev-core change: > > -Requires: uname(release) >= 3.13 > +Requires: uname(release) >= 4.15 > > > Is this true requirement? This R: was updated purely based on very first entry in release notes for 251: Backwards-incompatible changes: * The minimum kernel version required has been bumped from 3.13 to 4.15, and CLOCK_BOOTTIME is now assumed to always exist. If it actually works with lower kernel versions feel free to adjust. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: DISTFILES: qt6: ERRORS: qt-everywhere-src-6.3.2.tar.xz
On 30.10.2022 18:08, Jan Palus wrote: On 24.10.2022 09:17, Jan Palus wrote: On 24.10.2022 09:13, atler wrote: Request by: atler wget -nv --no-iri --user-agent=PLD/distfiles -O ./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz https://download.qt.io/official_releases/qt/6.3/6.3.2/single/qt-everywhere-src-6.3.2.tar.xz: Cannot write to ???./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz??? (Success). Can someone have a look what's that about? Noticed it before for larger sources like firefox but usually retry succeeded. qt6 on the other hand fails consistently. Also fails with `dropin` script after transferring ~264M: firefox-106.0.2.source.tar.xz54% 264MB 5.1MB/s 00:42 ETA scp: write remote "./firefox-106.0.2.source.tar.xz": Failure scp: failed to upload file firefox-106.0.2.source.tar.xz to . dropin is on cvs and there was no free space there. Added some. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | 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: DISTFILES: qt6: ERRORS: qt-everywhere-src-6.3.2.tar.xz
On 24.10.2022 09:17, Jan Palus wrote: > On 24.10.2022 09:13, atler wrote: > > Request by: atler > > > > wget -nv --no-iri --user-agent=PLD/distfiles -O > > ./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz > > > > https://download.qt.io/official_releases/qt/6.3/6.3.2/single/qt-everywhere-src-6.3.2.tar.xz: > > Cannot write to > > ???./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz??? > > (Success). > > Can someone have a look what's that about? Noticed it before for larger > sources like firefox but usually retry succeeded. qt6 on the other hand > fails consistently. Also fails with `dropin` script after transferring ~264M: firefox-106.0.2.source.tar.xz54% 264MB 5.1MB/s 00:42 ETA scp: write remote "./firefox-106.0.2.source.tar.xz": Failure scp: failed to upload file firefox-106.0.2.source.tar.xz to . ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: DISTFILES: qt6: ERRORS: qt-everywhere-src-6.3.2.tar.xz
On 24.10.2022 09:13, atler wrote: > Request by: atler > > wget -nv --no-iri --user-agent=PLD/distfiles -O > ./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz > > https://download.qt.io/official_releases/qt/6.3/6.3.2/single/qt-everywhere-src-6.3.2.tar.xz: > Cannot write to > ???./tmp/c988e5de-3fbe-4f8d-9c0e-892a6cc71ea2/bc928a9897698ec397b11c3dbff40e53/qt-everywhere-src-6.3.2.tar.xz??? > (Success). Can someone have a look what's that about? Noticed it before for larger sources like firefox but usually retry succeeded. qt6 on the other hand fails consistently. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: pfa-signpkg resets tty echo after failed password input:
> On 20. Oct 2022, at 15:37, Elan Ruusamäe wrote: > > > > pldth@ep09-pld SRPMS/.metadata$ pfa-signpkg test *pecl* > Checking signatures of 164 files from 17 packages > 164/164 > /home/pld/admins/th/ftp/test/x86_64/debuginfo/php82-pecl-xmlrpc-debugsource-1.0.0-1.RC3.1.x86_64.rpm > Total 164 files to sign > Enter signing password: > Signing 164 files > /home/pld/admins/th/ftp/test/SRPMS/RPMS/php80-pecl-redis-5.3.7-1.src.rpm: > gpg: signing failed: Bad passphrase > gpg: signing failed: Bad passphrase > error: gpg exec failed (2) > /home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm: > Enter passphrase: lala Also aborted sign leaves temp files around: pldth@ep09-pld SRPMS/.metadata$ pfa-signpkg test *pecl* Checking signatures of 164 files from 17 packages 164/164 /home/pld/admins/th/ftp/test/x86_64/debuginfo/php82-pecl-xmlrpc-debugsource-1.0.0-1.RC3.1.x86_64.rpm Total 164 files to sign Enter signing password: Signing 164 files /home/pld/admins/th/ftp/test/SRPMS/RPMS/php80-pecl-redis-5.3.7-1.src.rpm: /home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm: File '/home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm.sig' exists. Overwrite? (y/N) y And then it seems it’s stuck, no idea what’s going on: pldth@ep09-pld SRPMS/.metadata$ lsp gpg www USER PID LXC PGRP STARTED TT VSZ RSS STAT CMD pldth28850 -28847 Thu Oct 20 15:37:55 2022 pts/5 8920 5124 SL+ gpg --no-verbose --no-armor --no-secmem-warning -u e4f1bc2d -sbo /home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm.sig - pldth@ep09-pld SRPMS/.metadata$ l /home/pld/admins/th/ftp/test/x86_64/debuginfo/*.sig -rw-r--r-- 1 pldth pldth 0 Oct 20 15:36 /home/pld/admins/th/ftp/test/x86_64/debuginfo/php80-pecl-redis-debuginfo-5.3.7-1.x86_64.rpm.sig ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python3-git-filter-repo] - new, separated from git-filter-repo.spec (now with python metadata, required for e.g. b4)
On Mon, Oct 17, 2022 at 09:14:27PM +0300, Elan Ruusamäe wrote: > wth. how is this any good? > > just add the -n python3-git-filter-repo to main git-filter-repo package! > > with your package split and the require-line in old spec, you force us > to keep two .spec files up todate with each release of git-filter-repo, > additionally deal with sending to builders, and in proper order as well. > > why? github package doesn't contain metadata for python package (or data to generate them). pypi package doesn't contain docs for git side. Alternative solution could be single spec with both sources. But I didn't know the direction in which the distribution of this package would evolve, the last release so far was almost year ago. Now I see there is 2.38.0, I'll check it in few days. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python3-git-filter-repo] - new, separated from git-filter-repo.spec (now with python metadata, required for e.g. b4)
wth. how is this any good?
just add the -n python3-git-filter-repo to main git-filter-repo package!
with your package split and the require-line in old spec, you force us
to keep two .spec files up todate with each release of git-filter-repo,
additionally deal with sending to builders, and in proper order as well.
why?
On 08.10.2022 21:51, qboosh wrote:
commit 61919f8f6ee682327311dfb153d2fb5474d1e622
Author: Jakub Bogusz
Date: Sat Oct 8 20:51:52 2022 +0200
- new, separated from git-filter-repo.spec (now with python metadata,
required for e.g. b4)
python3-git-filter-repo.spec | 53
1 file changed, 53 insertions(+)
---
diff --git a/python3-git-filter-repo.spec b/python3-git-filter-repo.spec
new file mode 100644
index 000..b402d05
--- /dev/null
+++ b/python3-git-filter-repo.spec
@@ -0,0 +1,53 @@
+Summary: Quickly rewrite git repository history
+Summary(pl.UTF-8): Szybkie przepisywanie historii repozytorium
+Name: python3-git-filter-repo
+Version: 2.34.0
+Release: 1
+License: MIT
+Group: Libraries/Python
+#Source0Download: https://pypi.org/simple/git-filter-repo/
+Source0:
https://files.pythonhosted.org/packages/source/g/git-filter-repo/git-filter-repo-%{version}.tar.gz
+# Source0-md5: 14825e3c78de704a0244092600bf1fdc
+URL: https://pypi.org/project/git-filter-repo/
+BuildRequires: python3-modules >= 1:3.5
+BuildRequires: python3-setuptools
+BuildRequires: python3-setuptools_scm
+BuildRequires: rpm-pythonprov
+BuildRequires: rpmbuild(macros) >= 1.714
+Requires: git-core >= 2.24.0
+Requires: python3-modules >= 1:3.5
+Conflicts: git-filter-repo < 2.34.0-2
+BuildArch: noarch
+BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n)
+
+%description
+git filter-repo is a versatile tool for rewriting history.
+
+%description -l pl.UTF-8
+git filter-repo to wszechstronne narzędzie do przepisywania historii.
+
+%prep
+%setup -q -n git-filter-repo-%{version}
+
+# fix #!/usr/bin/env python -> #!/usr/bin/python:
+%{__sed} -i -e '1s,/usr/bin/env python3,%{__python3},' git_filter_repo.py
+
+%build
+%py3_build
+
+%install
+rm -rf $RPM_BUILD_ROOT
+
+%py3_install
+
+%{__rm} $RPM_BUILD_ROOT%{_bindir}/git-filter-repo
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(644,root,root,755)
+%doc README.md
+%{py3_sitescriptdir}/git_filter_repo.py
+%{py3_sitescriptdir}/__pycache__/git_filter_repo.cpython-*.py[co]
+%{py3_sitescriptdir}/git_filter_repo-%{version}-py*.egg-info
gitweb:
http://git.pld-linux.org/gitweb.cgi/packages/python3-git-filter-repo.git/commitdiff/61919f8f6ee682327311dfb153d2fb5474d1e622
___
pld-cvs-commit mailing list
pld-cvs-com...@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: freshness report not fresh
On Sat, 24 Sep 2022, Jan Palus wrote: > For some time now freshness report at > http://ep09.pld-linux.org/~pldth/qa.php?q=freshness does not seem to be > updated. Can someone have a look? Fixed. Leftover lock in SPECS repo :/ -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.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: %_usrlibrpm macro gone
On Mon, Sep 19, 2022 at 6:08 PM Elan Ruusamäe wrote:
>
> rpm-4.17.1.1-1.x86_64
>
> dokuwiki* packages don’t build due that:
>
> ```
>
> + %{_usrlibrpm}/dokuwiki-find-lang.sh
> /home/users/glen/tmp/dokuwiki-20180422c-x86_64-root-glen dokuwiki.lang
> /home/users/glen/tmp/rpm-tmp.oRtxaL[82]: %{_usrlibrpm}/dokuwiki-find-lang.sh:
> inaccessible or not found
> ```
>
> What’s the replacement? Should it be restored instead?
>
%_rpmconfigdir is the official macro that points to /usr/lib/rpm.
--
真実はいつも一つ！/ Always, there's only one truth!
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: KDE - all form test
On 14.09.2022 10:29, Andrzej Zawadzki wrote: >On 14.09.2022 01:40, Krzysztof Mrozowicz via pld-devel-en wrote: > > Dnia 2022-09-13, o godz. 16:15:06 > Andrzej Zawadzki [1] napisal/(a): > > >Qt 5.15.6 - similar problem. For example kwallet doesn't work with >NetworkManager. > >Downgrade help, so looks like after Qt upgrade rebuild off all kde5 >packages will help. > > I sent all ka5 and kp5 packages to rebuild. They should be done over > the night. Kf5 were done earlier today due to their update. > > >Works now. > >But... should KDE be strictly dependent on the Qt version? > >Second time when Qt update broke my KDE environment. Ideally KDE should not have strict Qt version dependency as I suppose Qt should not be breaking compatibility between patch releases. That's the theory though. For example keepassxc was broken after upgrade as well due to some missing symbol related to qt concurrent. Either Qt broke ABI compatibility or keepassxc misused Qt API, whichever is more likely. I didn't bother to investigate deeper. Unless someone investigates what and why is broken in KDE and rebuilds just affected packages, I suppose the best way forward is indeed rebuild everything each time Qt is upgraded. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: KDE - all form test
Dnia 2022-09-14, o godz. 10:29:58 Andrzej Zawadzki napisał(a): > Works now. > > But... should KDE be strictly dependent on the Qt version? > > Second time when Qt update broke my KDE environment. As a non-programmer, I'm guessing that KDE expects that all its components will be build with the same QT version. The problem is that the particular components, ka5, kf5, kp5 appear for upgrades at different times, so if between upgrading let's say kf5 packages and kp5 packages the QT version gets changed, then the problem occurs. I guess every QT5 upgrade should trigger rebuilding of all ka5, kf5 and kp5 packages... -- Krzysiek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: KDE - all form test
On 14.09.2022 01:40, Krzysztof Mrozowicz via pld-devel-en wrote: Dnia 2022-09-13, o godz. 16:15:06 Andrzej Zawadzki [1] napisal/(a): Qt 5.15.6 - similar problem. For example kwallet doesn't work with NetworkManager. Downgrade help, so looks like after Qt upgrade rebuild off all kde5 packages will help. I sent all ka5 and kp5 packages to rebuild. They should be done over the night. Kf5 were done earlier today due to their update. Works now. But... should KDE be strictly dependent on the Qt version? Second time when Qt update broke my KDE environment. -- Andrzej Zawadzki References 1. mailto:zawa...@gmail.com ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: KDE - all form test
Dnia 2022-09-13, o godz. 16:15:06 Andrzej Zawadzki napisał(a): >Qt 5.15.6 - similar problem. For example kwallet doesn't work with >NetworkManager. > >Downgrade help, so looks like after Qt upgrade rebuild off all kde5 >packages will help. I sent all ka5 and kp5 packages to rebuild. They should be done over the night. Kf5 were done earlier today due to their update. -- Krzysiek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: KDE - all form test
On 1.07.2022 19:22, Peri Noid wrote: Dnia piatek, 1 lipca 2022 14:31:04 CEST Andrzej Zawadzki pisze: OK Qt5 was to fresh. I found in logs: *plasmashell[2012]: Cannot mix incompatible Qt library (5.15.4) with this library (5.15.5)* Hmm, rebuild is needed? I did a full downgrade of Qt5 to 5.15.4 and it works - so yes, the problem is somewhere there. We're still missing some of Qt5 packets in thre 5.15.5 version to be able to upgrade everything to this version. At least now. Hi! Qt 5.15.6 - similar problem. For example kwallet doesn't work with NetworkManager. Downgrade help, so looks like after Qt upgrade rebuild off all kde5 packages will help. -- Andrzej Zawadzki ___ 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-build-tools] builder: don't bother going back to original $(pwd) at the end of script
> On 31. Aug 2022, at 13:21, Jan Rękorajski wrote: > > On Wed, Aug 31, 2022 at 11:41 AM Arkadiusz Miśkiewicz via pld-devel-en > wrote: >> >> On 31.08.2022 11:27, Jan Rękorajski wrote: >>> Where will it land now? If you want to protect against landing in >>> non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"' >>> I really prefer to be staying in the same directory where I launched >>> the script in. >> >> Do you include (via source/dot) this script in some other script? > > No, command line. > My common workflow is cd $package; hack spec; builder ... (often with > --short-circuit) and back to hacking. So the working dir restore is irrelevant. As it’s in builder script, doesn’t affect any external shell. ___ 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-build-tools] builder: don't bother going back to original $(pwd) at the end of script
On Wed, Aug 31, 2022 at 11:41 AM Arkadiusz Miśkiewicz via pld-devel-en wrote: > > On 31.08.2022 11:27, Jan Rękorajski wrote: > > Where will it land now? If you want to protect against landing in > > non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"' > > I really prefer to be staying in the same directory where I launched > > the script in. > > Do you include (via source/dot) this script in some other script? No, command line. My common workflow is cd $package; hack spec; builder ... (often with --short-circuit) and back to hacking. -- Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ bagginspld-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-build-tools] builder: don't bother going back to original $(pwd) at the end of script
On 31.08.2022 11:27, Jan Rękorajski wrote: Where will it land now? If you want to protect against landing in non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"' I really prefer to be staying in the same directory where I launched the script in. Do you include (via source/dot) this script in some other script? -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | 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-build-tools] builder: don't bother going back to original $(pwd) at the end of script
On 31.08.2022 11:27, Jan Rękorajski wrote:
> Where will it land now? If you want to protect against landing in
> non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
> I really prefer to be staying in the same directory where I launched
> the script in.
I considered doing `test -d` but since this new old $PWD doesn't affect
any other command I've just dropped it entirely. I will bring it back
with test then.
> On Wed, Aug 31, 2022 at 12:59 AM atler wrote:
> >
> > commit b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
> > Author: Jan Palus
> > Date: Wed Aug 31 00:55:46 2022 +0200
> >
> > builder: don't bother going back to original $(pwd) at the end of script
> >
> > no real use for it as far as I can tell and ditching it avoids error if
> > original working directory does not exist anymore (because ie it
> > happened to be $RPM_BUILD_ROOT)
> >
> > builder.sh | 1 -
> > 1 file changed, 1 deletion(-)
> > ---
> > diff --git a/builder.sh b/builder.sh
> > index 058d0de..68bb875 100755
> > --- a/builder.sh
> > +++ b/builder.sh
> > @@ -2756,6 +2756,5 @@ esac
> > if [ -f "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES" -a
> > "$REMOVE_BUILD_REQUIRES" != "" ]; then
> > rm "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES"
> > fi
> > -cd "$__PWD"
> >
> > # vi:syntax=sh:ts=4:sw=4:noet
> >
> >
> > gitweb:
> >
> > http://git.pld-linux.org/gitweb.cgi/packages/rpm-build-tools.git/commitdiff/b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
> >
> > ___
> > pld-cvs-commit mailing list
> > pld-cvs-com...@lists.pld-linux.org
> > http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
>
>
>
> --
> Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
> bagginspld-linux.org
> ___
> pld-devel-pl mailing list
> pld-devel...@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
___
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-build-tools] builder: don't bother going back to original $(pwd) at the end of script
Where will it land now? If you want to protect against landing in
non-existing directory you can use '[ -d "$__PWD" ] && cd "$__PWD"'
I really prefer to be staying in the same directory where I launched
the script in.
On Wed, Aug 31, 2022 at 12:59 AM atler wrote:
>
> commit b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
> Author: Jan Palus
> Date: Wed Aug 31 00:55:46 2022 +0200
>
> builder: don't bother going back to original $(pwd) at the end of script
>
> no real use for it as far as I can tell and ditching it avoids error if
> original working directory does not exist anymore (because ie it
> happened to be $RPM_BUILD_ROOT)
>
> builder.sh | 1 -
> 1 file changed, 1 deletion(-)
> ---
> diff --git a/builder.sh b/builder.sh
> index 058d0de..68bb875 100755
> --- a/builder.sh
> +++ b/builder.sh
> @@ -2756,6 +2756,5 @@ esac
> if [ -f "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES" -a "$REMOVE_BUILD_REQUIRES"
> != "" ]; then
> rm "`pwd`/.${SPECFILE}_INSTALLED_PACKAGES"
> fi
> -cd "$__PWD"
>
> # vi:syntax=sh:ts=4:sw=4:noet
>
>
> gitweb:
>
> http://git.pld-linux.org/gitweb.cgi/packages/rpm-build-tools.git/commitdiff/b1e8c12b2d66e7aadd9bb2c0d1acfc612d50aa22
>
> ___
> pld-cvs-commit mailing list
> pld-cvs-com...@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
--
Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
bagginspld-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: glibc 2.36 *.o files debug extraction broken
On 16.08.2022 21:53, Jakub Bogusz wrote: > On Tue, Aug 16, 2022 at 09:28:58PM +0200, Jan Palus wrote: > > On 16.08.2022 20:31, Jakub Bogusz wrote: > > > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack > > > section: > > > > ... > > > > > For now only i686 builds are affected because x86_64 and x32 glibc-devel > > > packages > > > haven't been updated on builders. > > > > > > > > > Any guesses what changed? > > > > I believe to be responsible for this, specifically with this debugedit > > commit: > > > > commit bd392272c04d608257eb999670d85261d5125d93 > > Author: Jan Palus > > Date: Tue Jun 7 11:39:01 2022 > > > > bring back patch from rpm 4.16 for no exe bit when searching debuginfo; > > rel 2 > > > > which now considers non-executable object file matching pattern > > found in `find-debuginfo`: ^\(.*\):[ ]*.*ELF.*, not stripped.* > > > > Which in turn causes object file to be passed to `eu-strip` directly > > responsible for stripping .note.GNU-stack section. > > > > Fix proposals: > > > > 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared > > object\) > > 2. modify macros to invoke `find-debuginfo` with `--keep-section > > .note.GNU-stack` > > 3. both 1 and 2 > > I think it would be safer to revert to not touching *.o files (by > default). For the time being implemented 1. not to regress packages initial fix was done for. > BTW, why find-debuginfo removes .note.GNU-stack from *.o and doesn't remove > from *.a/*.so? To be precise it's eu-strip that find-debuginfo invokes. Regarding actual question these are two different things: object files (*.o) hold information for linker in .note.GNU-stack section of ELF file. Linker uses this information when creating shared objects (*.so) or executables to construct GNU_STACK program header in output ELF file. GNU_STACK is in turn used by kernel. eu-strip does not touch ELF program headers at all so it's plain copy. It only operates on ELF sections. So that's why executable/so files are not affected. (note that mentioned archives (*.a) are not considered for debuginfo extraction). I see a comment in elfutils strip code that intention was to keep all ELF notes, which while implemented, does not affect .note.GNU-stack. Most notes appear to be of type SHT_NOTE (that's what implementation relies on) however .note.GNU-stack is of type SHT_PROGBITS (ref elf(5)). I will raise a question to elfutils whether this is intended. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: glibc 2.36 *.o files debug extraction broken
On Tue, Aug 16, 2022 at 09:28:58PM +0200, Jan Palus wrote: > On 16.08.2022 20:31, Jakub Bogusz wrote: > > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack > > section: > > ... > > > For now only i686 builds are affected because x86_64 and x32 glibc-devel > > packages > > haven't been updated on builders. > > > > > > Any guesses what changed? > > I believe to be responsible for this, specifically with this debugedit > commit: > > commit bd392272c04d608257eb999670d85261d5125d93 > Author: Jan Palus > Date: Tue Jun 7 11:39:01 2022 > > bring back patch from rpm 4.16 for no exe bit when searching debuginfo; > rel 2 > > which now considers non-executable object file matching pattern > found in `find-debuginfo`: ^\(.*\):[ ]*.*ELF.*, not stripped.* > > Which in turn causes object file to be passed to `eu-strip` directly > responsible for stripping .note.GNU-stack section. > > Fix proposals: > > 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared > object\) > 2. modify macros to invoke `find-debuginfo` with `--keep-section > .note.GNU-stack` > 3. both 1 and 2 I think it would be safer to revert to not touching *.o files (by default). BTW, why find-debuginfo removes .note.GNU-stack from *.o and doesn't remove from *.a/*.so? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: glibc 2.36 *.o files debug extraction broken
On 16.08.2022 20:31, Jakub Bogusz wrote: > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack > section: ... > For now only i686 builds are affected because x86_64 and x32 glibc-devel > packages > haven't been updated on builders. > > > Any guesses what changed? I believe to be responsible for this, specifically with this debugedit commit: commit bd392272c04d608257eb999670d85261d5125d93 Author: Jan Palus Date: Tue Jun 7 11:39:01 2022 bring back patch from rpm 4.16 for no exe bit when searching debuginfo; rel 2 which now considers non-executable object file matching pattern found in `find-debuginfo`: ^\(.*\):[ ]*.*ELF.*, not stripped.* Which in turn causes object file to be passed to `eu-strip` directly responsible for stripping .note.GNU-stack section. Fix proposals: 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared object\) 2. modify macros to invoke `find-debuginfo` with `--keep-section .note.GNU-stack` 3. both 1 and 2 Comments welcome. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On 08.08.2022 23:34, Jan Rękorajski wrote: > On Mon, 08 Aug 2022, Jan Palus wrote: > > > On 08.08.2022 08:32, Jan Rękorajski wrote: > > > On Fri, 22 Jul 2022, Jan Palus wrote: > > > > > > > On 22.07.2022 11:03, Jan Rękorajski wrote: > > > > > Can someone explain why are we using split sources/packages for Qt? > > > > > > > > > > I want to add Qt6 and building from the monolythic source is s > > > > > much > > > > > easier. No need for bootstrap, no intertwined build dependencies, just > > > > > configure -> build -> build docs -> install. > > > > > > > > > > And unless there is a _very_ good reason to use split sources I'm > > > > > just going > > > > > to add a single qt6 package that builds everything (we can still > > > > > subpackage > > > > > bineries as we want them). > > > > > > > > As long as each component is bcondized and there are no "to the exact > > > > release" dependencies then I guess it's fine. Doing qtwebengine (and all > > > > the other components) rebuild each time qtbase needs a small packaging > > > > adjustment would be tough on arm, though I'd understand if nobody cared > > > > about my use case. > > > > > > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours > > > with qtwebengine. > > > > > > I don't know how it looks on arm, but IMHO no-webengine bcond should be > > > enough? > > > > Multiply it by ~4 and it's roughly result for arm. The first part I > > mean, qtwebengine is so heavy that I build it in AWS. > > > > Anyway no worries, if needed I can add more bconds myself. And thanks a > > lot for working on qt6! > > Thanks, it's a slow and painful process, and we'll end up with less > granularity, at least at the beginning. What I want now, is a MVP to be able > to build current calibre :/ > > Out of curiosity, would webengine even build on arm? What I see it > building is full blown blink/chromium engine. And this thing has lots > of fancy dependencies, both software and hardware. Just to be clear when I said "arm" I really meant "aarch64", 32-bit version of qtwebengine is of not much interest to me. And at least qtwebengine 5.x builds just fine for aarch64 and using it daily as my primary web browsing engine. I don't expect qt6 to be much different but haven't tried to build it so far. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On Mon, 08 Aug 2022, Jan Palus wrote: > On 08.08.2022 08:32, Jan Rękorajski wrote: > > On Fri, 22 Jul 2022, Jan Palus wrote: > > > > > On 22.07.2022 11:03, Jan Rękorajski wrote: > > > > Can someone explain why are we using split sources/packages for Qt? > > > > > > > > I want to add Qt6 and building from the monolythic source is s much > > > > easier. No need for bootstrap, no intertwined build dependencies, just > > > > configure -> build -> build docs -> install. > > > > > > > > And unless there is a _very_ good reason to use split sources I'm just > > > > going > > > > to add a single qt6 package that builds everything (we can still > > > > subpackage > > > > bineries as we want them). > > > > > > As long as each component is bcondized and there are no "to the exact > > > release" dependencies then I guess it's fine. Doing qtwebengine (and all > > > the other components) rebuild each time qtbase needs a small packaging > > > adjustment would be tough on arm, though I'd understand if nobody cared > > > about my use case. > > > > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours > > with qtwebengine. > > > > I don't know how it looks on arm, but IMHO no-webengine bcond should be > > enough? > > Multiply it by ~4 and it's roughly result for arm. The first part I > mean, qtwebengine is so heavy that I build it in AWS. > > Anyway no worries, if needed I can add more bconds myself. And thanks a > lot for working on qt6! Thanks, it's a slow and painful process, and we'll end up with less granularity, at least at the beginning. What I want now, is a MVP to be able to build current calibre :/ Out of curiosity, would webengine even build on arm? What I see it building is full blown blink/chromium engine. And this thing has lots of fancy dependencies, both software and hardware. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.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: Qt packaging
On 08.08.2022 08:32, Jan Rękorajski wrote: > On Fri, 22 Jul 2022, Jan Palus wrote: > > > On 22.07.2022 11:03, Jan Rękorajski wrote: > > > Can someone explain why are we using split sources/packages for Qt? > > > > > > I want to add Qt6 and building from the monolythic source is s much > > > easier. No need for bootstrap, no intertwined build dependencies, just > > > configure -> build -> build docs -> install. > > > > > > And unless there is a _very_ good reason to use split sources I'm just > > > going > > > to add a single qt6 package that builds everything (we can still > > > subpackage > > > bineries as we want them). > > > > As long as each component is bcondized and there are no "to the exact > > release" dependencies then I guess it's fine. Doing qtwebengine (and all > > the other components) rebuild each time qtbase needs a small packaging > > adjustment would be tough on arm, though I'd understand if nobody cared > > about my use case. > > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours > with qtwebengine. > > I don't know how it looks on arm, but IMHO no-webengine bcond should be > enough? Multiply it by ~4 and it's roughly result for arm. The first part I mean, qtwebengine is so heavy that I build it in AWS. Anyway no worries, if needed I can add more bconds myself. And thanks a lot for working on qt6! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On Mon, 08 Aug 2022, Neal Gompa wrote: > On Mon, Aug 8, 2022 at 2:32 AM Jan Rękorajski wrote: > > > > On Fri, 22 Jul 2022, Jan Palus wrote: > > > > > On 22.07.2022 11:03, Jan Rękorajski wrote: > > > > Can someone explain why are we using split sources/packages for Qt? > > > > > > > > I want to add Qt6 and building from the monolythic source is s much > > > > easier. No need for bootstrap, no intertwined build dependencies, just > > > > configure -> build -> build docs -> install. > > > > > > > > And unless there is a _very_ good reason to use split sources I'm just > > > > going > > > > to add a single qt6 package that builds everything (we can still > > > > subpackage > > > > bineries as we want them). > > > > > > As long as each component is bcondized and there are no "to the exact > > > release" dependencies then I guess it's fine. Doing qtwebengine (and all > > > the other components) rebuild each time qtbase needs a small packaging > > > adjustment would be tough on arm, though I'd understand if nobody cared > > > about my use case. > > > > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours > > with qtwebengine. > > > > I don't know how it looks on arm, but IMHO no-webengine bcond should be > > enough? > > > > The reason most distros don't use the monolithic source is that it's a > pain to apply patches to it. Qt doesn't actually get developed that > way, and backporting fixes is more of a pain if you use the monolithic > build. Well, we don't have resources to play with backporting changes. Besides I saw have ex. Fedora packages qt and it is IMO a joke. They don't build docs, they don't build internal deps, so yeah, it's easy, but it's half of the functionality. I'd rather have a package without the backports, but with all bells and whistles, that is easy to build, rather than either build pain on half baked. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.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: Qt packaging
On Mon, Aug 8, 2022 at 2:32 AM Jan Rękorajski wrote: > > On Fri, 22 Jul 2022, Jan Palus wrote: > > > On 22.07.2022 11:03, Jan Rękorajski wrote: > > > Can someone explain why are we using split sources/packages for Qt? > > > > > > I want to add Qt6 and building from the monolythic source is s much > > > easier. No need for bootstrap, no intertwined build dependencies, just > > > configure -> build -> build docs -> install. > > > > > > And unless there is a _very_ good reason to use split sources I'm just > > > going > > > to add a single qt6 package that builds everything (we can still > > > subpackage > > > bineries as we want them). > > > > As long as each component is bcondized and there are no "to the exact > > release" dependencies then I guess it's fine. Doing qtwebengine (and all > > the other components) rebuild each time qtbase needs a small packaging > > adjustment would be tough on arm, though I'd understand if nobody cared > > about my use case. > > FYI build time on builders is 1.5 hour without qtwebengine and 7 hours > with qtwebengine. > > I don't know how it looks on arm, but IMHO no-webengine bcond should be > enough? > The reason most distros don't use the monolithic source is that it's a pain to apply patches to it. Qt doesn't actually get developed that way, and backporting fixes is more of a pain if you use the monolithic build. -- 真実はいつも一つ！/ Always, there's only one truth! ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Qt packaging
On Fri, 22 Jul 2022, Jan Palus wrote: > On 22.07.2022 11:03, Jan Rękorajski wrote: > > Can someone explain why are we using split sources/packages for Qt? > > > > I want to add Qt6 and building from the monolythic source is s much > > easier. No need for bootstrap, no intertwined build dependencies, just > > configure -> build -> build docs -> install. > > > > And unless there is a _very_ good reason to use split sources I'm just going > > to add a single qt6 package that builds everything (we can still subpackage > > bineries as we want them). > > As long as each component is bcondized and there are no "to the exact > release" dependencies then I guess it's fine. Doing qtwebengine (and all > the other components) rebuild each time qtbase needs a small packaging > adjustment would be tough on arm, though I'd understand if nobody cared > about my use case. FYI build time on builders is 1.5 hour without qtwebengine and 7 hours with qtwebengine. I don't know how it looks on arm, but IMHO no-webengine bcond should be enough? -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.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: Qt packaging
On 22.07.2022 11:03, Jan Rękorajski wrote: > Can someone explain why are we using split sources/packages for Qt? > > I want to add Qt6 and building from the monolythic source is s much > easier. No need for bootstrap, no intertwined build dependencies, just > configure -> build -> build docs -> install. > > And unless there is a _very_ good reason to use split sources I'm just going > to add a single qt6 package that builds everything (we can still subpackage > bineries as we want them). As long as each component is bcondized and there are no "to the exact release" dependencies then I guess it's fine. Doing qtwebengine (and all the other components) rebuild each time qtbase needs a small packaging adjustment would be tough on arm, though I'd understand if nobody cared about my use case. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: RFC: shell completions policy change?
On 14.07.2022 16:38, Jakub Bogusz wrote:
> As more and more packages are getting bash/zsh completions, separate
> completions packages are becoming useless (harder to find, even not
> suggested).
>
> My proposal:
> 1) add %{bash_compdir}, %{zsh_compdir} and maybe %{fish_compdir} (and upper
> level) dirs to filesystem package and package bash/zsh[/fish] completion
> files just with commands (existing bash-/zsh-[/fish-] packages to be merged
> and
> obsoleted). [preferred]
> Fortunately completion files don't have shebangs, which would generate
> bash/zsh dependencies.
Never had an issue with finding completions but I'm all for less
subpackages so +1.
> 2) at least add Suggests for completions packages in packages with
> commands to complete
>
>
> --
> Jakub Boguszhttp://qboosh.pl/
> ___
> pld-devel-en mailing list
> pld-devel-en@lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: RFC: shell completions policy change?
On Thu, 14 Jul 2022, Jakub Bogusz wrote:
> As more and more packages are getting bash/zsh completions, separate
> completions packages are becoming useless (harder to find, even not
> suggested).
>
> My proposal:
> 1) add %{bash_compdir}, %{zsh_compdir} and maybe %{fish_compdir} (and upper
> level) dirs to filesystem package and package bash/zsh[/fish] completion
> files just with commands (existing bash-/zsh-[/fish-] packages to be merged
> and
> obsoleted). [preferred]
> Fortunately completion files don't have shebangs, which would generate
> bash/zsh dependencies.
+1
Yes, it's a pain to find those subpackages.
--
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.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: RFC: shell completions policy change?
On 14.07.2022 16:38, Jakub Bogusz wrote:
As more and more packages are getting bash/zsh completions, separate
completions packages are becoming useless (harder to find, even not suggested).
My proposal:
1) add %{bash_compdir}, %{zsh_compdir} and maybe %{fish_compdir} (and upper
level) dirs to filesystem package and package bash/zsh[/fish] completion
files just with commands (existing bash-/zsh-[/fish-] packages to be merged and
obsoleted). [preferred]
Fortunately completion files don't have shebangs, which would generate
bash/zsh dependencies.
+1
2) at least add Suggests for completions packages in packages with
commands to complete
-1
--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | 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: your mail
My bad , I meant PLD English section My mind is stuck with poldek so I wrote poldek by mistake On Tue, Jul 12, 2022, 7:44 PM Saleem Ceann Khan Marwat wrote: > Sorry if I posted it in wrong place but I thought I posted it in poldek > English section > > And strangely now there is no more kernel 5.18 available on th , it has > disappeared from packages available for upgrade > > So I'm currently on 5.17 > > Thanks > > On Tue, Jul 12, 2022, 7:41 PM Jan Palus wrote: > >> On 12.07.2022 19:26, Saleem Ceann Khan Marwat wrote: >> > Thanks but that did not help either >> > >> > as can be seen from this log >> > poldek:/all-avail> upgrade * >> > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package >> > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package >> > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package >> > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held >> package >> > Nothing to do >> > poldek:/all-avail> install kernel-5.18.5-1.x86_64 >> > kernel-drm-5.18.5-1.x86_64 kernel-headers-5.18.5-1.x86_64 >> > kernel-sound-alsa-5.18.5-1.x86_64 >> > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package >> > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package >> > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package >> > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held >> package >> > Nothing to do >> > poldek:/all-avail> install kernel-5.18.5-1.x86_64 >> > >> > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package >> > Nothing to do >> >> And please do post such questions on pld-users-en. Thanks. >> >> > On Fri, Jul 8, 2022 at 2:32 PM Jan Rękorajski >> > wrote: >> > >> > > On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat >> > > wrote: >> > > > >> > > > Hello, >> > > > >> > > > I am having issue with kernel upgrade to 5.18 due to held packages >> > > > >> > > > I tried --nodeps --force but still can not upgrade any of the kernel >> > > > related packages. >> > > > >> > > > How to fix this? >> > > >> > > Use install instead of upgrade for held (kernel in this case) >> packages. >> > > >> > > The hold in poldek was added to prevent a case when a new kernel would >> > > have problems starting. Upgrade could possibly leave you without a >> > > working kernel. >> > > Hold will not prevent uninstalling, but make sure that new kernel >> > > boots before doing so :) >> > > >> > > -- >> > > Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ >> > > bagginspld-linux.org >> > > ___ >> > > pld-devel-en mailing list >> > > pld-devel-en@lists.pld-linux.org >> > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en >> > > >> > >> > >> > -- >> > Dr.Saleem Khan Marwat >> > Abbottabad >> > Khyber-Pakhtunkhwa >> > Pakistan >> > Cell # +92333-5393854 >> > WhatsApp # +92333-5393854 >> > Email: drmar...@gmail.com >> > Web: http://saleem-khan.blogspot.com >> > Registered GNU/Linux User # 413133 >> > Since Aug 2003 >> > ___ >> > pld-devel-en mailing list >> > pld-devel-en@lists.pld-linux.org >> > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en >> ___ >> pld-devel-en mailing list >> pld-devel-en@lists.pld-linux.org >> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en >> > ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: your mail
Sorry if I posted it in wrong place but I thought I posted it in poldek English section And strangely now there is no more kernel 5.18 available on th , it has disappeared from packages available for upgrade So I'm currently on 5.17 Thanks On Tue, Jul 12, 2022, 7:41 PM Jan Palus wrote: > On 12.07.2022 19:26, Saleem Ceann Khan Marwat wrote: > > Thanks but that did not help either > > > > as can be seen from this log > > poldek:/all-avail> upgrade * > > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package > > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package > > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package > > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held > package > > Nothing to do > > poldek:/all-avail> install kernel-5.18.5-1.x86_64 > > kernel-drm-5.18.5-1.x86_64 kernel-headers-5.18.5-1.x86_64 > > kernel-sound-alsa-5.18.5-1.x86_64 > > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package > > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package > > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package > > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held > package > > Nothing to do > > poldek:/all-avail> install kernel-5.18.5-1.x86_64 > > > > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package > > Nothing to do > > And please do post such questions on pld-users-en. Thanks. > > > On Fri, Jul 8, 2022 at 2:32 PM Jan Rękorajski > > wrote: > > > > > On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat > > > wrote: > > > > > > > > Hello, > > > > > > > > I am having issue with kernel upgrade to 5.18 due to held packages > > > > > > > > I tried --nodeps --force but still can not upgrade any of the kernel > > > > related packages. > > > > > > > > How to fix this? > > > > > > Use install instead of upgrade for held (kernel in this case) packages. > > > > > > The hold in poldek was added to prevent a case when a new kernel would > > > have problems starting. Upgrade could possibly leave you without a > > > working kernel. > > > Hold will not prevent uninstalling, but make sure that new kernel > > > boots before doing so :) > > > > > > -- > > > Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ > > > bagginspld-linux.org > > > ___ > > > pld-devel-en mailing list > > > pld-devel-en@lists.pld-linux.org > > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > > > > > > > > > -- > > Dr.Saleem Khan Marwat > > Abbottabad > > Khyber-Pakhtunkhwa > > Pakistan > > Cell # +92333-5393854 > > WhatsApp # +92333-5393854 > > Email: drmar...@gmail.com > > Web: http://saleem-khan.blogspot.com > > Registered GNU/Linux User # 413133 > > Since Aug 2003 > > ___ > > pld-devel-en mailing list > > pld-devel-en@lists.pld-linux.org > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: your mail
On 12.07.2022 19:26, Saleem Ceann Khan Marwat wrote: > Thanks but that did not help either > > as can be seen from this log > poldek:/all-avail> upgrade * > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held package > Nothing to do > poldek:/all-avail> install kernel-5.18.5-1.x86_64 > kernel-drm-5.18.5-1.x86_64 kernel-headers-5.18.5-1.x86_64 > kernel-sound-alsa-5.18.5-1.x86_64 > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held package > Nothing to do > poldek:/all-avail> install kernel-5.18.5-1.x86_64 > > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package > Nothing to do And please do post such questions on pld-users-en. Thanks. > On Fri, Jul 8, 2022 at 2:32 PM Jan Rękorajski > wrote: > > > On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat > > wrote: > > > > > > Hello, > > > > > > I am having issue with kernel upgrade to 5.18 due to held packages > > > > > > I tried --nodeps --force but still can not upgrade any of the kernel > > > related packages. > > > > > > How to fix this? > > > > Use install instead of upgrade for held (kernel in this case) packages. > > > > The hold in poldek was added to prevent a case when a new kernel would > > have problems starting. Upgrade could possibly leave you without a > > working kernel. > > Hold will not prevent uninstalling, but make sure that new kernel > > boots before doing so :) > > > > -- > > Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ > > bagginspld-linux.org > > ___ > > pld-devel-en mailing list > > pld-devel-en@lists.pld-linux.org > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > > > > > -- > Dr.Saleem Khan Marwat > Abbottabad > Khyber-Pakhtunkhwa > Pakistan > Cell # +92333-5393854 > WhatsApp # +92333-5393854 > Email: drmar...@gmail.com > Web: http://saleem-khan.blogspot.com > Registered GNU/Linux User # 413133 > Since Aug 2003 > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: your mail
On 12.07.2022 19:26, Saleem Ceann Khan Marwat wrote: > Thanks but that did not help either > > as can be seen from this log > poldek:/all-avail> upgrade * > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held package > Nothing to do > poldek:/all-avail> install kernel-5.18.5-1.x86_64 > kernel-drm-5.18.5-1.x86_64 kernel-headers-5.18.5-1.x86_64 > kernel-sound-alsa-5.18.5-1.x86_64 > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package > error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package > error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package > error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held package > Nothing to do > poldek:/all-avail> install kernel-5.18.5-1.x86_64 > > error: kernel-5.18.5-1.x86_64: refusing to upgrade held package > Nothing to do You may try `just-install` alias in interactive session or `--nohold` command line parameter but I strongly recommend `man poldek` and `man poldek.conf` instead. > On Fri, Jul 8, 2022 at 2:32 PM Jan Rękorajski > wrote: > > > On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat > > wrote: > > > > > > Hello, > > > > > > I am having issue with kernel upgrade to 5.18 due to held packages > > > > > > I tried --nodeps --force but still can not upgrade any of the kernel > > > related packages. > > > > > > How to fix this? > > > > Use install instead of upgrade for held (kernel in this case) packages. > > > > The hold in poldek was added to prevent a case when a new kernel would > > have problems starting. Upgrade could possibly leave you without a > > working kernel. > > Hold will not prevent uninstalling, but make sure that new kernel > > boots before doing so :) > > > > -- > > Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ > > bagginspld-linux.org > > ___ > > pld-devel-en mailing list > > pld-devel-en@lists.pld-linux.org > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > > > > > -- > Dr.Saleem Khan Marwat > Abbottabad > Khyber-Pakhtunkhwa > Pakistan > Cell # +92333-5393854 > WhatsApp # +92333-5393854 > Email: drmar...@gmail.com > Web: http://saleem-khan.blogspot.com > Registered GNU/Linux User # 413133 > Since Aug 2003 > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re:
Thanks but that did not help either as can be seen from this log poldek:/all-avail> upgrade * error: kernel-5.18.5-1.x86_64: refusing to upgrade held package error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held package Nothing to do poldek:/all-avail> install kernel-5.18.5-1.x86_64 kernel-drm-5.18.5-1.x86_64 kernel-headers-5.18.5-1.x86_64 kernel-sound-alsa-5.18.5-1.x86_64 error: kernel-5.18.5-1.x86_64: refusing to upgrade held package error: kernel-drm-5.18.5-1.x86_64: refusing to upgrade held package error: kernel-headers-5.18.5-1.x86_64: refusing to upgrade held package error: kernel-sound-alsa-5.18.5-1.x86_64: refusing to upgrade held package Nothing to do poldek:/all-avail> install kernel-5.18.5-1.x86_64 error: kernel-5.18.5-1.x86_64: refusing to upgrade held package Nothing to do On Fri, Jul 8, 2022 at 2:32 PM Jan Rękorajski wrote: > On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat > wrote: > > > > Hello, > > > > I am having issue with kernel upgrade to 5.18 due to held packages > > > > I tried --nodeps --force but still can not upgrade any of the kernel > > related packages. > > > > How to fix this? > > Use install instead of upgrade for held (kernel in this case) packages. > > The hold in poldek was added to prevent a case when a new kernel would > have problems starting. Upgrade could possibly leave you without a > working kernel. > Hold will not prevent uninstalling, but make sure that new kernel > boots before doing so :) > > -- > Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ > bagginspld-linux.org > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > -- Dr.Saleem Khan Marwat Abbottabad Khyber-Pakhtunkhwa Pakistan Cell # +92333-5393854 WhatsApp # +92333-5393854 Email: drmar...@gmail.com Web: http://saleem-khan.blogspot.com Registered GNU/Linux User # 413133 Since Aug 2003 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re:
On Thu, Jul 7, 2022 at 7:46 PM Saleem Ceann Khan Marwat wrote: > > Hello, > > I am having issue with kernel upgrade to 5.18 due to held packages > > I tried --nodeps --force but still can not upgrade any of the kernel > related packages. > > How to fix this? Use install instead of upgrade for held (kernel in this case) packages. The hold in poldek was added to prevent a case when a new kernel would have problems starting. Upgrade could possibly leave you without a working kernel. Hold will not prevent uninstalling, but make sure that new kernel boots before doing so :) -- Jan Rękorajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ bagginspld-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: KDE - all form test
Dnia piątek, 1 lipca 2022 14:31:04 CEST Andrzej Zawadzki pisze: > OK Qt5 was to fresh. I found in logs: > > > *plasmashell[2012]: Cannot mix incompatible Qt library (5.15.4) with this > library (5.15.5)* > > Hmm, rebuild is needed? I did a full downgrade of Qt5 to 5.15.4 and it works - so yes, the problem is somewhere there. We're still missing some of Qt5 packets in thre 5.15.5 version to be able to upgrade everything to this version. At least now. -- Łukasz Maśko_o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafrykańskie słowo oznaczające "Nie umiem zainstalować Debiana" ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: KDE - all form test
On 01.07.2022 14:31, Andrzej Zawadzki wrote: > OK Qt5 was to fresh. I found in logs: > > > *plasmashell[2012]: Cannot mix incompatible Qt library (5.15.4) with this > library (5.15.5)* > Hmm, rebuild is needed? `rpm -qa 'Qt5*' | grep -F 5.15.4` will likely be the reason. Needs upgrade to 5.15.5 as well. > On Fri, Jul 1, 2022 at 2:19 PM Łukasz Maśko wrote: > > >From which version did you upgrade? Works without major problems for > >me. > >-- > >Pozdrawiam. Åukasz MaÅko > > > >1 lip 2022 14:04 Andrzej Zawadzki napisaÅ(a): > > > > Hi! > > My KDE is broken after upgrade (plasma-shell, basically useless). > > How > > this looks on yours computers? ;-) > > -- > > Andrzej > > ___ > > pld-devel-en mailing list > > pld-devel-en@lists.pld-linux.org > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > > ___ > > pld-devel-en mailing list > > pld-devel-en@lists.pld-linux.org > > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > > > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: KDE - all form test
OK Qt5 was to fresh. I found in logs: *plasmashell[2012]: Cannot mix incompatible Qt library (5.15.4) with this library (5.15.5)* Hmm, rebuild is needed? On Fri, Jul 1, 2022 at 2:19 PM Łukasz Maśko wrote: >From which version did you upgrade? Works without major problems for >me. >-- >Pozdrawiam. Åukasz MaÅko > >1 lip 2022 14:04 Andrzej Zawadzki napisaÅ(a): > > Hi! > My KDE is broken after upgrade (plasma-shell, basically useless). > How > this looks on yours computers? ;-) > -- > Andrzej > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > ___ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en > ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: KDE - all form test
From which version did you upgrade? Works without major problems for me. -- Pozdrawiam. �ukasz Ma�ko 1 lip 2022 14:04 Andrzej Zawadzki napisa�(a): Hi! My KDE is broken after upgrade (plasma-shell, basically useless). How this looks on yours computers? ;-) -- Andrzej ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/php-dirs] Rel 2; base on /etc/php directories since these always exist (while binaries are optional)
On 29.06.2022 18:38, Elan Ruusamäe wrote: > On 24.06.2022 11:42, arekm wrote: > >> commit 8b8822b9a17c06cd1d3f0b803e6a9830c962353e >> Author: Arkadiusz Miśkiewicz >> Date: Fri Jun 24 10:42:47 2022 +0200 >> >> Rel 2; base on /etc/php directories since these always exist >> (while binaries are optional) > yet /etc/phpXY may be just some *.rpmsave or *~ files from removed > installation Which shouldn't be a problem for that script as it checks other things, too. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | 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/php-dirs] Rel 2; base on /etc/php directories since these always exist (while binaries are optional)
On 24.06.2022 11:42, arekm wrote: commit 8b8822b9a17c06cd1d3f0b803e6a9830c962353e Author: Arkadiusz Miśkiewicz Date: Fri Jun 24 10:42:47 2022 +0200 Rel 2; base on /etc/php directories since these always exist (while binaries are optional) yet /etc/phpXY may be just some *.rpmsave or *~ files from removed installation ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: mongodb and framewave will be dropped from th
On Mon, 13 Jun 2022, Elan Ruusamäe wrote: > On 12.06.2022 20:09, Jan Rękorajski wrote: > > > Please don't think about updating mongodb past 4.0.3, as any later > > version uses very restrictive license that's risky and we don't > > want it in PLD. > > i'm sure people have discovered docker for deploying such servers. > > please consider adding that license note to the .spec as well, perhaps > linking to this thread. You are welcome to do the update then. I'm not going to spend my scarce time at updating package that was neglected for the past 10 years. Just make sure to add a license warning in %post (something like we have for vserver in kernel.spec). -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.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: mongodb and framewave will be dropped from th
On 12.06.2022 20:09, Jan Rękorajski wrote: Please don't think about updating mongodb past 4.0.3, as any later version uses very restrictive license that's risky and we don't want it in PLD. i'm sure people have discovered docker for deploying such servers. please consider adding that license note to the .spec as well, perhaps linking to this thread. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/ka5-messagelib] - excluding x32
Dnia 2022-06-12, o godz. 20:38:18
Jan Palus napisał(a):
> On 12.06.2022 11:09, mrozowik wrote:
> > commit 7b38363a6951facd5787b69e5afe2001cc3b6380
> > Author: Krzysztof Mrozowicz
> > Date: Sun Jun 12 09:09:12 2022 +
> >
> > - excluding x32
> >
> > ka5-messagelib.spec | 1 +
> > 1 file changed, 1 insertion(+)
> > ---
> > diff --git a/ka5-messagelib.spec b/ka5-messagelib.spec
> > index a07f2e5..5361af7 100644
> > --- a/ka5-messagelib.spec
> > +++ b/ka5-messagelib.spec
> > @@ -71,6 +71,7 @@ BuildRequires:rpmbuild(macros) >= 1.164
> > BuildRequires: shared-mime-info
> > BuildRequires: tar >= 1:1.22
> > BuildRequires: xz
> > +ExclusiveArch: i686 %{x8664}
>
> I suppose more appropriate would be ExcludeArch: x32 here.
Good point, thanks. I'll change it before the next kde update.
--
Krzysiek
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/ka5-messagelib] - excluding x32
On 12.06.2022 11:09, mrozowik wrote:
> commit 7b38363a6951facd5787b69e5afe2001cc3b6380
> Author: Krzysztof Mrozowicz
> Date: Sun Jun 12 09:09:12 2022 +
>
> - excluding x32
>
> ka5-messagelib.spec | 1 +
> 1 file changed, 1 insertion(+)
> ---
> diff --git a/ka5-messagelib.spec b/ka5-messagelib.spec
> index a07f2e5..5361af7 100644
> --- a/ka5-messagelib.spec
> +++ b/ka5-messagelib.spec
> @@ -71,6 +71,7 @@ BuildRequires: rpmbuild(macros) >= 1.164
> BuildRequires: shared-mime-info
> BuildRequires: tar >= 1:1.22
> BuildRequires: xz
> +ExclusiveArch: i686 %{x8664}
I suppose more appropriate would be ExcludeArch: x32 here.
___
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] - add basic support for boolean deps, rel 10
On Wed, 8 Jun 2022 at 20:56, Jan Rękorajski wrote: > Poldek code be tricky. I admit I don't have good insight into ins and > outs of it. > > This should be fixed in rel 13. > > > And regarding hacking, what's the ownership status for poldek? Any chance on > > broader write access to upstream repo? > > I have not heard from the author for a long time :( > Maybe we should fork it and keep it in our git under projects/ ? > > Author in CC. It looks like I can give you write access to the upstream repository as well, just send me your github username. -- Marcin Banasiak ___ 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] - add basic support for boolean deps, rel 10
On Wed, 08 Jun 2022, Jan Palus wrote: > On 20.05.2022 22:22, Jan Rękorajski wrote: > > On Fri, 20 May 2022, baggins wrote: > > > > > commit 2d94f8f7056fbe16b90a171b66282cae45b9070b > > > Author: Jan Rękorajski > > > Date: Fri May 20 17:13:44 2022 +0200 > > > > > > - add basic support for boolean deps, rel 10 > > > > > > > > > https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html > > > > > > Only Requires are supported, 'with' and 'without' don't check if > > > the dependency is satisfied by the same package, 'or' could be > > > improved > > > to do lazy evaluation. > > > > If anyone feels like doing some hacking, feel free to build up on this. > > > > And, of course, please test. > > Regarding testing looks like I'm not able to install python3-packaging > now: > > poldek:/all-avail> install python3-packaging > ... > Processing dependencies... > ((python3.10dist(pyparsing) < 3.0.5 or python3.10dist(pyparsing) > 3.0.5) > with python3.10dist(pyparsing) >= 2.0.2) required by python3-packaging > error: python3-packaging-21.3-4.noarch: req python3.10dist(pyparsing) < > 3.0.5 not found > python3-packaging-21.3-4.noarch marks python3-pyparsing-3.0.7-3.noarch > (cap python3.10dist(pyparsing) > 3.0.5) > There are 2 packages to install (1 marked by dependencies): > A python3-packaging-21.3-4.noarch python3-pyparsing-3.0.7-3.noarch > This operation will use 1.4MB of disk space. > Need to get 277.3KB of archives (277.3KB to download). > > error: 1 unresolved dependency > There were errors Poldek code be tricky. I admit I don't have good insight into ins and outs of it. This should be fixed in rel 13. > And regarding hacking, what's the ownership status for poldek? Any chance on > broader write access to upstream repo? I have not heard from the author for a long time :( Maybe we should fork it and keep it in our git under projects/ ? Author in CC. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.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/poldek] - add basic support for boolean deps, rel 10
On 20.05.2022 22:22, Jan Rękorajski wrote: > On Fri, 20 May 2022, baggins wrote: > > > commit 2d94f8f7056fbe16b90a171b66282cae45b9070b > > Author: Jan Rękorajski > > Date: Fri May 20 17:13:44 2022 +0200 > > > > - add basic support for boolean deps, rel 10 > > > > > > https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html > > > > Only Requires are supported, 'with' and 'without' don't check if > > the dependency is satisfied by the same package, 'or' could be improved > > to do lazy evaluation. > > If anyone feels like doing some hacking, feel free to build up on this. > > And, of course, please test. Regarding testing looks like I'm not able to install python3-packaging now: poldek:/all-avail> install python3-packaging ... Processing dependencies... ((python3.10dist(pyparsing) < 3.0.5 or python3.10dist(pyparsing) > 3.0.5) with python3.10dist(pyparsing) >= 2.0.2) required by python3-packaging error: python3-packaging-21.3-4.noarch: req python3.10dist(pyparsing) < 3.0.5 not found python3-packaging-21.3-4.noarch marks python3-pyparsing-3.0.7-3.noarch (cap python3.10dist(pyparsing) > 3.0.5) There are 2 packages to install (1 marked by dependencies): A python3-packaging-21.3-4.noarch python3-pyparsing-3.0.7-3.noarch This operation will use 1.4MB of disk space. Need to get 277.3KB of archives (277.3KB to download). error: 1 unresolved dependency There were errors So if I'm reading it right packaging needs any pyparsing version but 3.0.5? Let's install it manually: poldek:/all-avail> install python3-pyparsing warn: python3-pyparsing: ambiguous name Processing dependencies... There are 1 package to install: A python3-pyparsing-3.0.7-3.noarch This operation will use 1.1MB of disk space. Need to get 209.3KB of archives (209.3KB to download). th::python3-pyparsing-3.0.7-3.noarch.rpm [209.3K (209.3K/s)] python3-pyparsing-3.0.7-3.noarch.rpm: digests OK Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 0... warning: /root/.poldek-cache/https_ftp.th.pld-linux.org.dists.th.PLD.noarch.RPMS/python3-pyparsing-3.0.7-3.noarch.rpm: Header V4 DSA/SHA1 Signature, key ID e4f1bc2d: NOKEY Verifying... # [100%] Preparing... # [100%] Updating / installing... 1:python3-pyparsing-3.0.7-3# [100%] And try again: poldek:/all-avail> install python3-packaging Processing dependencies... ((python3.10dist(pyparsing) < 3.0.5 or python3.10dist(pyparsing) > 3.0.5) with python3.10dist(pyparsing) >= 2.0.2) required by python3-packaging error: python3-packaging-21.3-4.noarch: req python3.10dist(pyparsing) < 3.0.5 not found There are 1 package to install: A python3-packaging-21.3-4.noarch This operation will use 280.3KB of disk space. Need to get 68.0KB of archives (68.0KB to download). error: 1 unresolved dependency rpm is happy though: # rpm -Uvh python3-packaging-21.3-4.noarch.rpm warning: python3-packaging-21.3-4.noarch.rpm: Header V4 DSA/SHA1 Signature, key ID e4f1bc2d: NOKEY Verifying... # [100%] Preparing... # [100%] Updating / installing... 1:python3-packaging-21.3-4 # [100%] And regarding hacking, what's the ownership status for poldek? Any chance on broader write access to upstream repo? ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: pam broken
On Tue, Jun 07, 2022 at 01:03:41PM +0300, Elan Ruusamäe wrote: > On 06.06.2022 19:37, Jakub Bogusz wrote: > >On Mon, Jun 06, 2022 at 06:48:47PM +0300, Elan Ruusamäe wrote: > >>Jun 6 18:27:31 ldap2 sudo: PAM unable to > >>dlopen(/lib64/security/pam_unix.so): /lib64/libnsl.so.2: undefined symbol: > >>key_secretkey_is_set, version TIRPC_0.3.2 > >>Jun 6 18:27:31 ldap2 sudo: PAM adding faulty module: > >>/lib64/security/pam_unix.so > >> > >> > >>anyone wants to fix missing dependency error? > >rpm -q libtirpc? > > > Thu Nov 2 17:11:07 2017 libtirpc-1.0.1-1.x86_64 So it's libtirpc that's broken; key_secretkey_is_set export has been fixed in 1.0.3 - I bumped libnsl dependency on libtirpc. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: pam broken
On 06.06.2022 19:37, Jakub Bogusz wrote: On Mon, Jun 06, 2022 at 06:48:47PM +0300, Elan Ruusamäe wrote: Jun 6 18:27:31 ldap2 sudo: PAM unable to dlopen(/lib64/security/pam_unix.so): /lib64/libnsl.so.2: undefined symbol: key_secretkey_is_set, version TIRPC_0.3.2 Jun 6 18:27:31 ldap2 sudo: PAM adding faulty module: /lib64/security/pam_unix.so anyone wants to fix missing dependency error? rpm -q libtirpc? Thu Nov 2 17:11:07 2017 libtirpc-1.0.1-1.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: pam broken
On Mon, Jun 06, 2022 at 06:48:47PM +0300, Elan Ruusamäe wrote: > Jun 6 18:27:31 ldap2 sudo: PAM unable to > dlopen(/lib64/security/pam_unix.so): /lib64/libnsl.so.2: undefined symbol: > key_secretkey_is_set, version TIRPC_0.3.2 > Jun 6 18:27:31 ldap2 sudo: PAM adding faulty module: > /lib64/security/pam_unix.so > > > anyone wants to fix missing dependency error? rpm -q libtirpc? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages missing on carme (x86_64)
On 24.05.2022 13:00, Jan Palus wrote: > $ rpm -q git-core sudo > package git-core is not installed > package sudo is not installed installed again -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | 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/poldek] - add basic support for boolean deps, rel 10
On Fri, 20 May 2022, baggins wrote: > commit 2d94f8f7056fbe16b90a171b66282cae45b9070b > Author: Jan Rękorajski > Date: Fri May 20 17:13:44 2022 +0200 > > - add basic support for boolean deps, rel 10 > > > https://rpm-software-management.github.io/rpm/manual/boolean_dependencies.html > > Only Requires are supported, 'with' and 'without' don't check if > the dependency is satisfied by the same package, 'or' could be improved > to do lazy evaluation. If anyone feels like doing some hacking, feel free to build up on this. And, of course, please test. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.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: DiscoverNotifier - Segmentation fault
On 17.05.2022 20:44, Witold Filipczyk wrote: Dnia Tue, May 17, 2022 at 03:10:44PM +0200, Peri Noid napisal/(a): Dnia wtorek, 17 maja 2022 10:47:35 CEST Andrzej Zawadzki pisze: Hi, after upgrade. Do we need rebuild with newer libraries? Application: Powiadomienia Odkrywcy (DiscoverNotifier), signal: Segmentation fault [...] I have the same. I siply killed the DiscoverNotifier process for now, I don't need it since it seems no to do anything useful. plasma-discover, running from command line, display these errors? Maybe on builders is older version of flatpak-devel. Hi, that's result: $ plasma-discover qrc:/qml/DiscoverWindow.qml:116:19: QML Shortcut: Shortcut: Only binding to one of multiple key bindings associated with 15. Use 'sequences: [ ]' to bind to all of them. qrc:/qml/Feedback.qml:2:1: module "org.kde.userfeedback" is not installed kf.kio.core: Malformed JSON protocol file for protocol: "trash" , number of the ExtraNames fields should match the number of ExtraTypes fields qrc:/qml/DiscoverPage.qml:42:37: QML Shortcut: Shortcut: Only binding to one of multiple key bindings associated with 15. Use 'sequences: [ ]' to bind to all of them. (process:88545): flatpak-WARNING **: 10:46:40.462: Unable to create FlatpakInstallation for system: While opening repository /var/lib/flatpak/repo: opening repo: opendir(/var/lib/flatpak/repo): Nie ma takiego pliku ani katalogu Failed to call flatpak_get_system_installations: No system installations found (process:88545): OSTree-CRITICAL **: 10:46:40.463: ostree_repo_open: assertion 'error == NULL || *error == NULL' failed Failed to setup flatpak installations: While opening repository /home/users/zawada/.local/share/flatpak/repo: opening repo: No system installations found org.kde.plasma.libdiscover: Discarding invalid backend "flatpak-backend" org.kde.plasma.libdiscover: Couldn't find a category for "fwupd-backend" [1]file:///usr/lib64/qt5/qml/org/kde/kirigami.2/private/PrivateActionTo olButton.qml:74:5: QML Binding: Binding loop detected for property "value" [2]file:///usr/lib64/qt5/qml/org/kde/kirigami.2/AbstractApplicationWind ow.qml:282:5: QML Binding: Not restoring previous value because restoreMode has not been set. This behavior is deprecated. You have to import QtQml 2.15 after any QtQuick imports and set the restoreMode of the binding to fix this warning. In Qt < 6.0 the default is Binding.RestoreBinding. In Qt >= 6.0 the default is Binding.RestoreBindingOrValue. took really long to fetch KNSBackend(0x2c77ca0, name = "/usr/share/knsrcfiles/icons.knsrc") took really long to fetch KNSBackend(0x2c82440, name = "/usr/share/knsrcfiles/ksplash.knsrc") took really long to fetch KNSBackend(0x2c84050, name = "/usr/share/knsrcfiles/xcursor.knsrc") took really long to fetch KNSBackend(0x2c8f280, name = "/usr/share/knsrcfiles/wallpaperplugin.knsrc") took really long to fetch KNSBackend(0x2c88da0, name = "/usr/share/knsrcfiles/gtk_themes.knsrc") took really long to fetch KNSBackend(0x2c8aca0, name = "/usr/share/knsrcfiles/colorschemes.knsrc") took really long to fetch KNSBackend(0x2c92c20, name = "/usr/share/knsrcfiles/comic.knsrc") took really long to fetch KNSBackend(0x2c9ff60, name = "/usr/share/knsrcfiles/kwinswitcher.knsrc") took really long to fetch KNSBackend(0x2c94840, name = "/usr/share/knsrcfiles/wallpaper.knsrc") took really long to fetch KNSBackend(0x2c28850, name = "/usr/share/knsrcfiles/systemmonitor-presets.knsrc") took really long to fetch KNSBackend(0x2c98660, name = "/usr/share/knsrcfiles/systemmonitor-faces.knsrc") took really long to fetch KNSBackend(0x2c9c8a0, name = "/usr/share/knsrcfiles/lookandfeel.knsrc") took really long to fetch KNSBackend(0x2c96b90, name = "/usr/share/knsrcfiles/kfontinst.knsrc") took really long to fetch KNSBackend(0x2c9a800, name = "/usr/share/knsrcfiles/window-decorations.knsrc") took really long to fetch KNSBackend(0x2c86980, name = "/usr/share/knsrcfiles/sddmtheme.knsrc") took really long to fetch KNSBackend(0x2ca0310, name = "/usr/share/knsrcfiles/konsole.knsrc") took really long to fetch KNSBackend(0x2cafd60, name = "/usr/share/knsrcfiles/plasmoids.knsrc") took really long to fetch KNSBackend(0x2cb9ef0, name = "/usr/share/knsrcfiles/wallpaper-mobile.knsrc") took really long to fetch KNSBackend(0x2c7b370, name = "/usr/share/knsrcfiles/krunner.knsrc") took really long to fetch KNSBackend(0x2cbdd10, name = "/usr/share/knsrcfiles/kwineffect.knsrc") took really long to fetch KNSBackend(0x2cc1110, name = "/usr/share/knsrcfiles/kwinscripts.knsrc") took really long to fetch KNSBackend(0x2cd22e0, name = "/usr/share/knsrcfiles/plasma-themes.knsrc") took really long to fetch KNSBackend(0x2cbf030, name = "/usr/share/knsrcfiles/servicemenu.knsrc")
Re: DiscoverNotifier - Segmentation fault
On 17.05.2022 15:10, Peri Noid wrote: Dnia wtorek, 17 maja 2022 10:47:35 CEST Andrzej Zawadzki pisze: Hi, after upgrade. Do we need rebuild with newer libraries? Application: Powiadomienia Odkrywcy (DiscoverNotifier), signal: Segmentation fault [...] I have the same. I siply killed the DiscoverNotifier process for now, I don't need it since it seems no to do anything useful. +1 - useless ;-) -- Andrzej Zawadzki ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: DiscoverNotifier - Segmentation fault
Dnia Tue, May 17, 2022 at 03:10:44PM +0200, Peri Noid napisał(a): > Dnia wtorek, 17 maja 2022 10:47:35 CEST Andrzej Zawadzki pisze: > >Hi, > > > >after upgrade. > > > >Do we need rebuild with newer libraries? > > > >Application: Powiadomienia Odkrywcy (DiscoverNotifier), signal: > >Segmentation fault > [...] > I have the same. I siply killed the DiscoverNotifier process for now, I don't > need it since it seems no to do anything useful. plasma-discover, running from command line, display these errors? Maybe on builders is older version of flatpak-devel. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: DiscoverNotifier - Segmentation fault
Dnia wtorek, 17 maja 2022 10:47:35 CEST Andrzej Zawadzki pisze: >Hi, > >after upgrade. > >Do we need rebuild with newer libraries? > >Application: Powiadomienia Odkrywcy (DiscoverNotifier), signal: >Segmentation fault [...] I have the same. I siply killed the DiscoverNotifier process for now, I don't need it since it seems no to do anything useful. -- Łukasz Maśko_o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafrykańskie słowo oznaczające "Nie umiem zainstalować Debiana" ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/neovim] move desktop/icon files to desktop subpackage; rel 2
On 10.05.2022 01:03, atler wrote: commit 6c39e61955036084b011122dddf58627b2c0d9c8 Author: Jan Palus Date: Tue May 10 00:01:43 2022 +0200 move desktop/icon files to desktop subpackage; rel 2 avoids gui deps on headless systems +%package desktop +Summary: Desktop files for Neovim +Group: Applications/Editors/Vim +Requires(post,postun): desktop-file-utils +Requires(post,postun): gtk-update-icon-cache +Requires(post,postun): hicolor-icon-theme +BuildArch: noarch + +%description desktop +Desktop files for Neovim. must depend on base package. desktop file without binary is useless. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/phonon-qt5] - initial version, copy of phonon repo
On Sun, 15 May 2022, Krzysztof Mrozowicz via pld-devel-en wrote: > Dnia 2022-05-15, o godz. 16:28:16 > Jan Rękorajski napisał(a): > > > On Sat, 14 May 2022, mrozowik wrote: > > > > > commit 0b8c3fb5a1bd048461aa4623ca1114928e5737eb > > > Author: Krzysztof Mrozowicz > > > Date: Sat May 14 13:10:01 2022 + > > > > > > - initial version, copy of phonon repo > > > > You should have done this with 'ssh g...@git.pld-linux.org copy phonon > > phonon-qt5' to keep the history. > > > > Please do so next time. > > Well, I tried. I received a message (from what I remember) that either I > don't have permissions to run the copy command, or the repo > already exists. When I checked, the repo was there, totally empty, so I > used it. Ah, ok, copy won't work if the destination is already there, even if it's empty. What does make sense as it could destroy previous incarnation history. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.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/phonon-qt5] - initial version, copy of phonon repo
Dnia 2022-05-15, o godz. 16:28:16 Jan Rękorajski napisał(a): > On Sat, 14 May 2022, mrozowik wrote: > > > commit 0b8c3fb5a1bd048461aa4623ca1114928e5737eb > > Author: Krzysztof Mrozowicz > > Date: Sat May 14 13:10:01 2022 + > > > > - initial version, copy of phonon repo > > You should have done this with 'ssh g...@git.pld-linux.org copy phonon > phonon-qt5' to keep the history. > > Please do so next time. Well, I tried. I received a message (from what I remember) that either I don't have permissions to run the copy command, or the repo already exists. When I checked, the repo was there, totally empty, so I used it. -- Krzysiek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/phonon-qt5] - initial version, copy of phonon repo
On Sat, 14 May 2022, mrozowik wrote: > commit 0b8c3fb5a1bd048461aa4623ca1114928e5737eb > Author: Krzysztof Mrozowicz > Date: Sat May 14 13:10:01 2022 + > > - initial version, copy of phonon repo You should have done this with 'ssh g...@git.pld-linux.org copy phonon phonon-qt5' to keep the history. Please do so next time. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.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 missing in github mirror
On 04.05.2022 15:21, Jan Palus wrote: It appears that some packages are not mirrored to github. Completely missing or tree empty (some of them missing due to notorious dns issues): synced some of them with: [~/relup] ➔ for a in `cat /tmp/pkgs `; do (./builder -g -ns $a && cd $a && git co -b hg-temp-mirror && git push -u origin hg-temp-mirror && cd ..); done [~/relup] ➔ for a in `cat /tmp/pkgs `; do (cd $a && git push -u origin --delete hg-temp-mirror && cd ..); done some got error: remote: fatal: Could not read from remote repository. this one is weird, it had no HEAD before? remote: To ssh://github.com/pld-linux/gnome-desktop-testing remote: ! [remote rejected] hg-temp-mirror (refusing to delete the current branch: refs/heads/hg-temp-mirror) remote: error: failed to push some refs to 'ssh://github.com/pld-linux/gnome-desktop-testing' remote: ...done ___ 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] pass args from %systemd_service_{enable,disable} to %systemd_{post,preun}; rel 2
On 26.04.2022 21:02, atler wrote:
commit 1820298a2883170393ed481ce681e66198884809
Author: Jan Palus
Date: Tue Apr 26 20:01:38 2022 +0200
pass args from %systemd_service_{enable,disable} to %systemd_{post,preun};
rel 2
rpm-macros.patch | 4 ++--
systemd.spec | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/systemd.spec b/systemd.spec
index a703c84..2c61be6 100644
--- a/systemd.spec
+++ b/systemd.spec
@@ -29,7 +29,7 @@ Summary(pl.UTF-8):systemd - zarządca systemu i usług dla
Linuksa
Name: systemd
# Verify ChangeLog and NEWS when updating (since there are
incompatible/breaking changes very often)
Version: 250.4
-Release: 1
+Release: 2
Epoch:1
License: GPL v2+ (udev), LGPL v2.1+ (the rest)
Group:Base
diff --git a/rpm-macros.patch b/rpm-macros.patch
index 6926763..43dd90d 100644
--- a/rpm-macros.patch
+++ b/rpm-macros.patch
@@ -66,8 +66,8 @@
+ {{SYSTEMD_UPDATE_HELPER_PATH}} system-reload || : \
+%{nil}
+
-+%systemd_service_enable %systemd_post
-+%systemd_service_disable %systemd_preun
++%systemd_service_enable() %systemd_post $*
++%systemd_service_disable() %systemd_preun $*
+
+%systemd_service_start() \
+ [ -d /run/systemd/system ] && /bin/systemctl start %{*} || : \
shouldn't you use rpm args, %{*}, rather shell args, $* like
%systemd_service_start()?
also when using shell args, always use "$@" to preserve spaces
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: python (3.10) dirs
On Tue, 26 Apr 2022, Jan Rękorajski wrote: > On Tue, 26 Apr 2022, Jakub Bogusz wrote: > > > On Tue, Apr 19, 2022 at 01:56:04AM +0200, Jan Rękorajski wrote: > > > On Tue, 19 Apr 2022, Jan Rękorajski wrote: > > > > > > > On Mon, 18 Apr 2022, Jakub Bogusz wrote: > > > > > > > > > After recent python3.10 changes meson started to use /usr/share for > > > > > purelib, but automake's pythondir is broken now: > > > > > > > > > > pythondir (platform-indepdendent) is wrong: > > > > > > > > > > $ python2 -c "import sys; from distutils import sysconfig; > > > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > > > > /usr/share/python2.7/site-packages > > > > > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > > > > /usr/lib/python3.10/site-packages > > > > > > > > > > pyexecdir is OK: > > > > > > > > > > $ python2 -c "import sys; from distutils import sysconfig; > > > > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > > > > /usr/lib64/python2.7/site-packages > > > > > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > > > > /usr/lib64/python3.10/site-packages > > > > > > > > What package version do you have? Python3 shows /usr/share for me: > > > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; > > > > rpm -q python3 > > > > :1: DeprecationWarning: The distutils package is deprecated and > > > > slated for removal in Python 3.12. Use setuptools or check PEP 632 for > > > > potential alternatives > > > > :1: DeprecationWarning: The distutils.sysconfig module is > > > > deprecated, use sysconfig instead > > > > /usr/share/python3.10/site-packages > > > > python3-3.10.4-5.x86_64 > > > > > > > > On a side note, distutils is deprecated... > > > > > > The problematic dir seems to be coming from > > > /usr/share/python3.10/site-packages/distutils-precedence.pth > > > from python3-setuptools-62.0.0-1.noarch. Plain python should return > > > 'share' there. > > > > It's automake's standard AM_PATH_PYTHON that refers to distutils. > > > > Maybe we should rework revert-debian-python-hacks.patch ... > > Maybe I just fixed this in python3-setuptools-62.0.0-2 with a ~1 liner More to the point, python3 has all paths as we want them, but if you install python3-setuptool it will override stdlib sysconfig with its own implementation. And that was what was broken. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.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: python (3.10) dirs
On Tue, 26 Apr 2022, Jakub Bogusz wrote: > On Tue, Apr 19, 2022 at 01:56:04AM +0200, Jan Rękorajski wrote: > > On Tue, 19 Apr 2022, Jan Rękorajski wrote: > > > > > On Mon, 18 Apr 2022, Jakub Bogusz wrote: > > > > > > > After recent python3.10 changes meson started to use /usr/share for > > > > purelib, but automake's pythondir is broken now: > > > > > > > > pythondir (platform-indepdendent) is wrong: > > > > > > > > $ python2 -c "import sys; from distutils import sysconfig; > > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > > > /usr/share/python2.7/site-packages > > > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > > > /usr/lib/python3.10/site-packages > > > > > > > > pyexecdir is OK: > > > > > > > > $ python2 -c "import sys; from distutils import sysconfig; > > > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > > > /usr/lib64/python2.7/site-packages > > > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > > > /usr/lib64/python3.10/site-packages > > > > > > What package version do you have? Python3 shows /usr/share for me: > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; > > > rpm -q python3 > > > :1: DeprecationWarning: The distutils package is deprecated and > > > slated for removal in Python 3.12. Use setuptools or check PEP 632 for > > > potential alternatives > > > :1: DeprecationWarning: The distutils.sysconfig module is > > > deprecated, use sysconfig instead > > > /usr/share/python3.10/site-packages > > > python3-3.10.4-5.x86_64 > > > > > > On a side note, distutils is deprecated... > > > > The problematic dir seems to be coming from > > /usr/share/python3.10/site-packages/distutils-precedence.pth > > from python3-setuptools-62.0.0-1.noarch. Plain python should return 'share' > > there. > > It's automake's standard AM_PATH_PYTHON that refers to distutils. > > Maybe we should rework revert-debian-python-hacks.patch ... Maybe I just fixed this in python3-setuptools-62.0.0-2 with a ~1 liner -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.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: python (3.10) dirs
On Tue, Apr 19, 2022 at 01:56:04AM +0200, Jan Rękorajski wrote: > On Tue, 19 Apr 2022, Jan Rękorajski wrote: > > > On Mon, 18 Apr 2022, Jakub Bogusz wrote: > > > > > After recent python3.10 changes meson started to use /usr/share for > > > purelib, but automake's pythondir is broken now: > > > > > > pythondir (platform-indepdendent) is wrong: > > > > > > $ python2 -c "import sys; from distutils import sysconfig; > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > > /usr/share/python2.7/site-packages > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > > /usr/lib/python3.10/site-packages > > > > > > pyexecdir is OK: > > > > > > $ python2 -c "import sys; from distutils import sysconfig; > > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > > /usr/lib64/python2.7/site-packages > > > > > > $ python3 -c "import sys; from distutils import sysconfig; > > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > > /usr/lib64/python3.10/site-packages > > > > What package version do you have? Python3 shows /usr/share for me: > > > > $ python3 -c "import sys; from distutils import sysconfig; > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; rpm > > -q python3 > > :1: DeprecationWarning: The distutils package is deprecated and > > slated for removal in Python 3.12. Use setuptools or check PEP 632 for > > potential alternatives > > :1: DeprecationWarning: The distutils.sysconfig module is > > deprecated, use sysconfig instead > > /usr/share/python3.10/site-packages > > python3-3.10.4-5.x86_64 > > > > On a side note, distutils is deprecated... > > The problematic dir seems to be coming from > /usr/share/python3.10/site-packages/distutils-precedence.pth > from python3-setuptools-62.0.0-1.noarch. Plain python should return 'share' > there. It's automake's standard AM_PATH_PYTHON that refers to distutils. Maybe we should rework revert-debian-python-hacks.patch ... -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: python (3.10) dirs
On Tue, 19 Apr 2022, Jan Rękorajski wrote: > On Mon, 18 Apr 2022, Jakub Bogusz wrote: > > > After recent python3.10 changes meson started to use /usr/share for > > purelib, but automake's pythondir is broken now: > > > > pythondir (platform-indepdendent) is wrong: > > > > $ python2 -c "import sys; from distutils import sysconfig; > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > /usr/share/python2.7/site-packages > > > > $ python3 -c "import sys; from distutils import sysconfig; > > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > > /usr/lib/python3.10/site-packages > > > > pyexecdir is OK: > > > > $ python2 -c "import sys; from distutils import sysconfig; > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > /usr/lib64/python2.7/site-packages > > > > $ python3 -c "import sys; from distutils import sysconfig; > > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > > /usr/lib64/python3.10/site-packages > > What package version do you have? Python3 shows /usr/share for me: > > $ python3 -c "import sys; from distutils import sysconfig; > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; rpm > -q python3 > :1: DeprecationWarning: The distutils package is deprecated and > slated for removal in Python 3.12. Use setuptools or check PEP 632 for > potential alternatives > :1: DeprecationWarning: The distutils.sysconfig module is deprecated, > use sysconfig instead > /usr/share/python3.10/site-packages > python3-3.10.4-5.x86_64 > > On a side note, distutils is deprecated... The problematic dir seems to be coming from /usr/share/python3.10/site-packages/distutils-precedence.pth from python3-setuptools-62.0.0-1.noarch. Plain python should return 'share' there. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.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: python (3.10) dirs
On Mon, 18 Apr 2022, Jakub Bogusz wrote: > After recent python3.10 changes meson started to use /usr/share for > purelib, but automake's pythondir is broken now: > > pythondir (platform-indepdendent) is wrong: > > $ python2 -c "import sys; from distutils import sysconfig; > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > /usr/share/python2.7/site-packages > > $ python3 -c "import sys; from distutils import sysconfig; > sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" > /usr/lib/python3.10/site-packages > > pyexecdir is OK: > > $ python2 -c "import sys; from distutils import sysconfig; > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > /usr/lib64/python2.7/site-packages > > $ python3 -c "import sys; from distutils import sysconfig; > sys.stdout.write(sysconfig.get_python_lib(1,0,prefix='/usr'))" > /usr/lib64/python3.10/site-packages What package version do you have? Python3 shows /usr/share for me: $ python3 -c "import sys; from distutils import sysconfig; sys.stdout.write(sysconfig.get_python_lib(0,0,prefix='/usr'))" ; echo ; rpm -q python3 :1: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives :1: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead /usr/share/python3.10/site-packages python3-3.10.4-5.x86_64 On a side note, distutils is deprecated... -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.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: Problem with qscintilla/Qt5 linking(?)
On 09.04.2022 10:57, Jan Rękorajski wrote:
> On Fri, 08 Apr 2022, Jan Palus wrote:
>
> > On 08.04.2022 09:53, Jan Palus wrote:
> > > On 08.04.2022 09:01, Jan Rękorajski wrote:
> > > >
> > > > Python 3.10.4 (main, Apr 1 2022, 09:00:14) [GCC 11.2.0 20220208
> > > > (release)] on linux
> > > > Type "help", "copyright", "credits" or "license" for more information.
> > > > >>> from PyQt5 import Qsci
> > > > Traceback (most recent call last):
> > > > File "", line 1, in
> > > > ImportError: /usr/lib64/python3.10/site-packages/PyQt5/Qsci.so:
> > > > undefined symbol: _ZTI11QsciPrinter
> > > >
> > > > As far as I can see the symbol is there, recompiling qscintilla2 does
> > > > not fix it.
> > > >
> > > > Could someone more versed in the linker(?) take a look at it?
> > >
> > > Unfortunately it has not much to do with linking, but rather with qmake.
> > >
> > > Above symbol is defined in libqscintilla2_qt5.so which is not linked to
> > > the
> > > module, that's the reason for undefined symbol:
> > >
> > > x86_64-pld-linux-g++ -Wl,--as-needed -Wl,--no-copy-dt-needed-entries
> > > -Wl,-z,relro -Wl,-z,combreloc -Wl,--version-script=Qsci.exp -Wl,-O1
> > > -shared -o libQsci.so sipQscipart0.o sipQscipart1.o sipQscipart2.o
> > > -L/tmp/B.ldcyigur/BUILD/QScintilla-2.11.6/build-qt5/Qt4Qt5
> > > /usr/lib64/libQt5PrintSupport.so /usr/lib64/libQt5Widgets.so
> > > /usr/lib64/libQt5Gui.so /usr/lib64/libQt5Core.so -lGL -lpthread
> > >
> > > I guess linking to libqscintilla2_qt5.so should come from:
> > >
> > > Python/configure.py:
> > > qmake = {'CONFIG': 'qscintilla2'...
> > >
> > > but perhaps due to the way we build python module it can't find newly
> > > built qscintilla2? No idea.
> > >
> > > A brute force workaround is to BR: qscintilla2-qt5-devel so it finds
> > > system config.
> >
> > Fixed in 2.11.6-2.
>
> Thanks, I wonder how that symbol was defined if our rpm post-checks didn't
> catch it's missing.
One reason for sure is that we don't consider files not matching *.so.*
glob:
printf "Searching for shared objects with unresolved symbols..."; \
for f in $(find $RPM_BUILD_ROOT -type f -name '*.so.*' -print);
and the other reason is likely related to why we don't consider *.so --
these are usually plugins which happen to have plenty of unresolved
symbols which are only resolved at runtime (provided by "loader"). Like
ie python binary extensions which are rarely linked to libpython and
hence would require special handling.
___
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 qscintilla/Qt5 linking(?)
On Fri, 08 Apr 2022, Jan Palus wrote:
> On 08.04.2022 09:53, Jan Palus wrote:
> > On 08.04.2022 09:01, Jan Rękorajski wrote:
> > >
> > > Python 3.10.4 (main, Apr 1 2022, 09:00:14) [GCC 11.2.0 20220208
> > > (release)] on linux
> > > Type "help", "copyright", "credits" or "license" for more information.
> > > >>> from PyQt5 import Qsci
> > > Traceback (most recent call last):
> > > File "", line 1, in
> > > ImportError: /usr/lib64/python3.10/site-packages/PyQt5/Qsci.so: undefined
> > > symbol: _ZTI11QsciPrinter
> > >
> > > As far as I can see the symbol is there, recompiling qscintilla2 does
> > > not fix it.
> > >
> > > Could someone more versed in the linker(?) take a look at it?
> >
> > Unfortunately it has not much to do with linking, but rather with qmake.
> >
> > Above symbol is defined in libqscintilla2_qt5.so which is not linked to the
> > module, that's the reason for undefined symbol:
> >
> > x86_64-pld-linux-g++ -Wl,--as-needed -Wl,--no-copy-dt-needed-entries
> > -Wl,-z,relro -Wl,-z,combreloc -Wl,--version-script=Qsci.exp -Wl,-O1 -shared
> > -o libQsci.so sipQscipart0.o sipQscipart1.o sipQscipart2.o
> > -L/tmp/B.ldcyigur/BUILD/QScintilla-2.11.6/build-qt5/Qt4Qt5
> > /usr/lib64/libQt5PrintSupport.so /usr/lib64/libQt5Widgets.so
> > /usr/lib64/libQt5Gui.so /usr/lib64/libQt5Core.so -lGL -lpthread
> >
> > I guess linking to libqscintilla2_qt5.so should come from:
> >
> > Python/configure.py:
> > qmake = {'CONFIG': 'qscintilla2'...
> >
> > but perhaps due to the way we build python module it can't find newly built
> > qscintilla2? No idea.
> >
> > A brute force workaround is to BR: qscintilla2-qt5-devel so it finds system
> > config.
>
> Fixed in 2.11.6-2.
Thanks, I wonder how that symbol was defined if our rpm post-checks didn't
catch it's missing.
--
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.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: Problem with qscintilla/Qt5 linking(?)
On 08.04.2022 09:53, Jan Palus wrote:
> On 08.04.2022 09:01, Jan Rękorajski wrote:
> >
> > Python 3.10.4 (main, Apr 1 2022, 09:00:14) [GCC 11.2.0 20220208 (release)]
> > on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> from PyQt5 import Qsci
> > Traceback (most recent call last):
> > File "", line 1, in
> > ImportError: /usr/lib64/python3.10/site-packages/PyQt5/Qsci.so: undefined
> > symbol: _ZTI11QsciPrinter
> >
> > As far as I can see the symbol is there, recompiling qscintilla2 does
> > not fix it.
> >
> > Could someone more versed in the linker(?) take a look at it?
>
> Unfortunately it has not much to do with linking, but rather with qmake.
>
> Above symbol is defined in libqscintilla2_qt5.so which is not linked to the
> module, that's the reason for undefined symbol:
>
> x86_64-pld-linux-g++ -Wl,--as-needed -Wl,--no-copy-dt-needed-entries
> -Wl,-z,relro -Wl,-z,combreloc -Wl,--version-script=Qsci.exp -Wl,-O1 -shared
> -o libQsci.so sipQscipart0.o sipQscipart1.o sipQscipart2.o
> -L/tmp/B.ldcyigur/BUILD/QScintilla-2.11.6/build-qt5/Qt4Qt5
> /usr/lib64/libQt5PrintSupport.so /usr/lib64/libQt5Widgets.so
> /usr/lib64/libQt5Gui.so /usr/lib64/libQt5Core.so -lGL -lpthread
>
> I guess linking to libqscintilla2_qt5.so should come from:
>
> Python/configure.py:
> qmake = {'CONFIG': 'qscintilla2'...
>
> but perhaps due to the way we build python module it can't find newly built
> qscintilla2? No idea.
>
> A brute force workaround is to BR: qscintilla2-qt5-devel so it finds system
> config.
Fixed in 2.11.6-2.
___
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 qscintilla/Qt5 linking(?)
On 08.04.2022 09:01, Jan Rękorajski wrote:
>
> Python 3.10.4 (main, Apr 1 2022, 09:00:14) [GCC 11.2.0 20220208 (release)]
> on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from PyQt5 import Qsci
> Traceback (most recent call last):
> File "", line 1, in
> ImportError: /usr/lib64/python3.10/site-packages/PyQt5/Qsci.so: undefined
> symbol: _ZTI11QsciPrinter
>
> As far as I can see the symbol is there, recompiling qscintilla2 does
> not fix it.
>
> Could someone more versed in the linker(?) take a look at it?
Unfortunately it has not much to do with linking, but rather with qmake.
Above symbol is defined in libqscintilla2_qt5.so which is not linked to the
module, that's the reason for undefined symbol:
x86_64-pld-linux-g++ -Wl,--as-needed -Wl,--no-copy-dt-needed-entries
-Wl,-z,relro -Wl,-z,combreloc -Wl,--version-script=Qsci.exp -Wl,-O1 -shared -o
libQsci.so sipQscipart0.o sipQscipart1.o sipQscipart2.o
-L/tmp/B.ldcyigur/BUILD/QScintilla-2.11.6/build-qt5/Qt4Qt5
/usr/lib64/libQt5PrintSupport.so /usr/lib64/libQt5Widgets.so
/usr/lib64/libQt5Gui.so /usr/lib64/libQt5Core.so -lGL -lpthread
I guess linking to libqscintilla2_qt5.so should come from:
Python/configure.py:
qmake = {'CONFIG': 'qscintilla2'...
but perhaps due to the way we build python module it can't find newly built
qscintilla2? No idea.
A brute force workaround is to BR: qscintilla2-qt5-devel so it finds system
config.
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: gitlab on cvs machine
On 29.03.2022 18:20, Arkadiusz Miśkiewicz via pld-devel-en wrote: Hi. Is gitlab on cvs machine used by anyone for anything? It only eats resources otherwise. I'm still having some ideas to setup it for merge request workflows. you can stop the containers for now, don't remove the data. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: opnjdk* jar broken on x86_64
On 30.03.2022 12:53, Jan Rękorajski wrote: > Any ideas how the below could broke? > Same thing works on i686 and x32. > > I installed i686 jar on x86_64 builder to unblock libreoffice and > openjdk11 rebilds for now. > > Tested with openjdk11 and openjdk12: > > Notice that the original CRC is not what jar put in the archive. > > [builder2@ymir ~]$ S=/home/users/builder2/rpm/BUILD/libreoffice-7.2.0.3 && > I=$S/instdir && W=$S/workdir && mkdir -p > $W/JavaClassSet/Jar/unoloader/META-INF && echo Manifest-Version: 1.0 > > $W/JavaClassSet/Jar/u > noloader/META-INF/MANIFEST.MF && echo "Solar-Version: 7.2.0.3" >> > $W/JavaClassSet/Jar/unoloader/META-INF/MANIFEST.MF && cat > $S/ridljar/source/unoloader/com/sun/star/lib/unoloader/manifest >> > $W/JavaClassSet/J > ar/unoloader/META-INF/MANIFEST.MF && mkdir -p $I/program/classes/ && cd > $W/JavaClassSet/Jar/unoloader && jar cfm $I/program/classes/unoloader.jar > $W/JavaClassSet/Jar/unoloader/META-INF/MANIFEST.MF META-INF com > && cd $W/JavaClassSet/Jar/unoloader/ && jar uf > $I/program/classes/unoloader.jar module-info.class > java.util.zip.ZipException: invalid entry CRC (expected 0x85cff2ff but got > 0x341ef68c) > at > java.base/java.util.zip.ZipInputStream.readEnd(ZipInputStream.java:410) > at > java.base/java.util.zip.ZipInputStream.read(ZipInputStream.java:199) > at > java.base/java.io.FilterInputStream.read(FilterInputStream.java:107) > at jdk.jartool/sun.tools.jar.Main.copy(Main.java:1248) > at jdk.jartool/sun.tools.jar.Main.update(Main.java:977) > at jdk.jartool/sun.tools.jar.Main.run(Main.java:366) > at jdk.jartool/sun.tools.jar.Main.main(Main.java:1680) https://github.com/madler/zlib/issues/613 working on reproducer. as a workaround please downgrade zlib to 1.2.11 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: [packages/mpd] - add systemd user service startup, rel 2
On 09.01.2022 22:57, baggins wrote:
> commit 361f865ee1be0363de3c94ee9e89132084fa38fc
> Author: Jan Rękorajski
> Date: Sun Jan 9 22:56:39 2022 +0100
>
> - add systemd user service startup, rel 2
>
> mpd.spec | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
> ---
> diff --git a/mpd.spec b/mpd.spec
> index 523fd45..adacc57 100644
> --- a/mpd.spec
> +++ b/mpd.spec
> @@ -289,6 +289,7 @@ for f in mpd.log; do
> done
> /sbin/chkconfig --add mpd
> %systemd_post %{name}.service %{name}.socket
> +%systemd_user_post %{name}.service %{name}.socket
>
> %post icons
> %update_icon_cache hicolor
A word of warning: %systemd_user_post eventually leads to enabling units
globally by default which effectively means user has no chance of
disabling service on her/his own. It's still possible to mask service
completely but socket activated user services are simply not possible
(for which service should be disabled). Personally I pretty much hate it
as a default but I will get by with:
/etc/systemd/user-preset/99-default.preset:
disable *
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
