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
remmina not working after llvm upgrade
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? -- 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: 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
itstool 2.0.7 vs [packages/mate-utils] up to 1.26.1
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)
--
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: 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
GitHub key needs an update
With each push following is logged from github mirror sync: remote: Pushing to github mirror... remote: @@@ remote: @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ remote: @@@ remote: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! remote: Someone could be eavesdropping on you right now (man-in-the-middle attack)! remote: It is also possible that a host key has just been changed. remote: The fingerprint for the RSA key sent by the remote host is remote: SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s. remote: Please contact your system administrator. remote: Add correct host key in /home/services/git/.ssh/known_hosts to get rid of this message. remote: Offending RSA key in /home/services/git/.ssh/known_hosts:1 remote: Host key for github.com has changed and you have requested strict checking. remote: Host key verification failed. remote: fatal: Could not read from remote repository. remote: remote: Please make sure you have the correct access rights remote: and the repository exists. remote: ...done That's expected and GitHub host key needs an update, see: https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
PLD Linux script for installation
Hi, There was once a script to install PLD from another linux distribution but it seems dead now . I am requesting that such new script will be of great help because installation from a rescue CD is very difficult and tricky. Thanks, -- 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: [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
compileall.compile_dir(..., workers=2) fails in carme (vserver guest)
this fails on carme. anything can be done with this? ➔ python3 -c "import compileall; import sys; compileall.compile_dir(sys.argv[1], workers=2)" /usr/share/empty/ Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.10/compileall.py", line 102, in compile_dir with ProcessPoolExecutor(max_workers=workers) as executor: File "/usr/lib64/python3.10/concurrent/futures/process.py", line 657, in __init__ self._call_queue = _SafeQueue( File "/usr/lib64/python3.10/concurrent/futures/process.py", line 168, in __init__ super().__init__(max_size, ctx=ctx) File "/usr/lib64/python3.10/multiprocessing/queues.py", line 43, in __init__ self._rlock = ctx.Lock() File "/usr/lib64/python3.10/multiprocessing/context.py", line 68, in Lock return Lock(ctx=self.get_context()) File "/usr/lib64/python3.10/multiprocessing/synchronize.py", line 162, in __init__ SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx) File "/usr/lib64/python3.10/multiprocessing/synchronize.py", line 57, in __init__ sl = self._semlock = _multiprocessing.SemLock( FileNotFoundError: [Errno 2] No such file or directory - https://github.com/kovidgoyal/kitty/issues/6050#issuecomment-1440513909 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
ruby packages building from .gem
How is it supposed to work (taking ruby-ffi.spec as example)?
.gem itself is tar archive containing metadata.gz and data.tar.gz.
But rpm uses "gem unpack", which unpacks data.tar.gz from inside.
And build fails with:
+ cd ffi-1.9.25
+ /usr/lib/rpm/gem_helper.rb spec
/usr/lib/rpm/gem_helper.rb:77:in `open': No such file or directory @ rb_sysopen
- metadata.gz (Errno::ENOENT)
from /usr/lib/rpm/gem_helper.rb:77:in `'
What's wrong here, how to fix it properly/nice?
I can fix the build by adding `%{__tar} xf %{SOURCE0} metadata.gz`
but I wouldn't call it nice.
--
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/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
lists test
123... -- 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 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
rust on carme-x32
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. -- 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
x32 builder has network access
Noticed during build of kodi-addon-inputstream-adaptive that contrary to x86_64 and i686, x32 builder downloaded external sources successfully: [ 2%] Performing download step (download, verify and extract) for 'bento4' cd /tmp/B.77a99ah0/BUILD/inputstream.adaptive-20.3.2-Nexus/build/bento4/src && /usr/bin/cmake -P /tmp/B.77a99ah0/BUILD/inputstream.adaptive-20.3.2-Nexus/build/bento4/src/bento4-stamp/download-bento4.cmake -- Downloading... dst='/tmp/B.77a99ah0/BUILD/inputstream.adaptive-20.3.2-Nexus/build/download/1.6.0-639-5-Nexus.tar.gz' timeout='none' inactivity timeout='none' -- Using src='https://github.com/xbmc/Bento4/archive/refs/tags/1.6.0-639-5-Nexus.tar.gz' -- Downloading... done ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
PLD Th 2022 snapshot released
2022 snapshot of PLD/Linux Th has been released. It is available on ftp://ftp.pld-linux.org/dists/th/2022/PLD/ and as poldek sources th-2022. The main highlights of this release are: kernels 6.1.1, 5.15.85, 5.10.161, 5.4.228, 4.19.269, 4.14.302, 4.9.336 and 4.4.302 (4.4 and 4.9 have vserver enabled) RPM 4.17.1.1 OpenSSL 3.0.7 GCC 12.2.0 LLVM 15.0.5 glibc 2.36 GNOME 42 KDE5 5.101 / 22.12 XFCE 4.18 -- 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: 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
udev-core R >= 4.15
udev-core change: -Requires: uname(release) >= 3.13 +Requires: uname(release) >= 4.15 Is this true requirement? I mean docs say: " README: say kernel 4.15 is the minimum recommended After various long discussions (https://lists.freedesktop.org/archives/systemd-devel/2022-March/047587.html, https://lwn.net/Articles/889610/), there is no clear answer what the minimum version should be. Bumping the version above 3.15 doesn't allow us to make any significant simplifications (unless we went *much* higher). In particular, even renameat2() is not fully supported with latest kernel versions, e.g. nfs still doesn't have it. And the bpf stuff is optional anyway. So let's just say that 4.15 is what we recommend, because it provides fairly complete cgroups-v2, but without any removals of compat in the code." and "+Kernel versions below 4.15 have significant gaps in functionality and +are not recommended for use with this version of systemd. Taint flag +'old-kernel' will be set. Systemd will most likely still function, but +upstream support and testing are limited." so looks like it should work on older kernels but there could be problems. Is there really some problem with udev-core that needs forcing >= 4.15? (I'm still using vserver 4.9 kernels) -- 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 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
push failure
first try pushing to mozilla-firefox-bin failed with: error: remote unpack failed: unable to create temporary object directory To ssh://git.pld-linux.org/packages/mozilla-firefox-bin ! [remote rejected] master -> master (unpacker error) error: failed to push some refs to 'ssh://git.pld-linux.org/packages/mozilla-firefox-bin' second attempt succeeded though. ___ 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
pfa-signpkg resets tty echo after failed password input:
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 ___ 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
freshness report not fresh
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? ___ 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
%_usrlibrpm macro gone
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?
___
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
glibc 2.36 *.o files debug extraction broken
In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack section: (before installing) $ objdump -h ../BUILD/glibc-2.36.debuginfo/builddir/csu/crtn.o ../BUILD/glibc-2.36.debuginfo/builddir/csu/crtn.o: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0034 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0034 2**0 ALLOC 3 .note.gnu.property 0044 0034 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .init 0005 0078 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 5 .fini 0005 007d 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .note.GNU-stack 0082 2**0 CONTENTS, READONLY 7 .debug_line 005a 0084 2**0 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS 8 .debug_info 0022 00d9 2**0 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS 9 .debug_abbrev 0012 00fb 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 10 .debug_aranges 0028 0110 2**3 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS 11 .debug_str004f 0133 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 12 .debug_ranges 0020 0184 2**3 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS (after) /home/users/qboosh/tmp/glibc-2.36-i686-root-qboosh.debuginfo/usr/lib/crtn.o: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0034 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0034 2**0 ALLOC 3 .note.gnu.property 0044 0034 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .init 0005 0078 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 5 .fini 0005 007d 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .gnu_debuglink 0020 0084 2**2 CONTENTS, READONLY With debuginfo packages disabled, .note.GNU-stack section is still present. It results in binaries executable stack and linker features misdetection due to new warning: /usr/bin/ld: warning: /usr/lib/gcc/i686-pld-linux/11.3.0/../../../crtn.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker affecting e.g. gjs: Compiler for C++ supports link arguments -Bsymbolic-functions: NO meson.build:78:12: ERROR: Problem encountered: -Bsymbolic-functions not supported, configure with -Dbsymbolic_functions=false or gcab: Compiler for C supports link arguments -Wl,-z,relro: NO Compiler for C supports link arguments -Wl,-z,now: NO + missing symbol versioning 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? -- 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: 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
Unable to install some old? packages
# rpm --initdb --root=/pld # rpm --import --root=/pld PLD-3.0-Th-GPG-key.asc # poldek --root=/pld -uv filesystem ... Processing dependencies... filesystem-4.1-15.x86_64 marks FHS-3.0-7.x86_64 (cap FHS >= 3.0) There are 2 packages to install (1 marked by dependencies): A FHS-3.0-7.x86_64 filesystem-4.1-15.x86_64 Need to get 83.4KB of archives (83.4KB to download). [1/2] th::FHS-3.0-7.x86_64.rpm [50.4K (50.4K/s)] [2/2] th::filesystem-4.1-15.x86_64.rpm [33.0K (33.0K/s)] FHS-3.0-7.x86_64.rpm: digests OK filesystem-4.1-15.x86_64.rpm: digests OK Executing pm-command.sh --upgrade -vh --root /home/users/jan/pld --define _check_dirname_deps 0... Verifying... # [100%] Preparing... # [100%] package filesystem-4.1-15.x86_64 does not verify: no digest Any idea what else is needed? Without importing gpg key it works fine, but why it doesn't with gpg key? ___ 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
Qt packaging
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). -- 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.
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
RFC: shell completions policy change?
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.
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
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
[no subject]
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? Thanks , ___ 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
KDE - all form test
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
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
Our sip and probably PyQt5 are broken
While trying to build new calibre I found out that our sip is quite broken. It wants the files in /usr/lib64/python3.10/site-packages/PyQt5/bindings while we install in /usr/share/sip/PyQt5 and then building calibre fails with: SIPing 3 files... /usr/bin/python3 -c from sipbuild.tools.build import main; main(); --verbose --no-make --qmake /usr/bin/qmake-qt5 Querying qmake about your Qt installation... /usr/bin/qmake-qt5 -query These bindings will be built: pictureflow. Generating the pictureflow bindings... -c: Q_PID is undefined The only reference I found is calibre author screaming at broken sip packagig: http://www.mobileread.mobi/forums/showthread.php?p=4132792 I'll try to figure out what's going on, but I wouldn't mind if someone beats me to it :) -- 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 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
mongodb and framewave will be dropped from th
Hi, Both mongodb and framewave are antique and require python2 scons for building, thus do not build anymore. Both have no direct dependencies, so drop should be painless. 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. -- 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 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
pam broken
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? list of packages updated: Mon Jun 6 15:56:35 2022 glibc-2.35-7.x86_64 Mon Jun 6 15:56:35 2022 mibs-net-snmp-5.9.1-3.noarch Mon Jun 6 15:56:35 2022 rpm-base-4.16.1.3-18.x86_64 Mon Jun 6 15:56:36 2022 glibc-misc-2.35-7.x86_64 Mon Jun 6 15:56:36 2022 iconv-2.35-7.x86_64 Mon Jun 6 15:56:36 2022 ldconfig-2.35-7.x86_64 Mon Jun 6 15:56:36 2022 less-590-1.x86_64 Mon Jun 6 15:56:36 2022 libxcrypt-4.4.27-1.x86_64 Mon Jun 6 15:56:36 2022 nss-softokn-freebl-3.78-1.x86_64 Mon Jun 6 15:56:37 2022 elfutils-libelf-0.187-2.x86_64 Mon Jun 6 15:56:37 2022 iptables-libs-1.8.7-1.x86_64 Mon Jun 6 15:56:37 2022 libicu-70.1-1.x86_64 Mon Jun 6 15:56:37 2022 libnftnl-1.2.1-1.x86_64 Mon Jun 6 15:56:37 2022 libseccomp-2.5.4-1.x86_64 Mon Jun 6 15:56:37 2022 libsepol-3.1-1.x86_64 Mon Jun 6 15:56:37 2022 lm_sensors-libs-3.5.0-2.x86_64 Mon Jun 6 15:56:37 2022 sqlite3-libs-3.38.5-1.x86_64 Mon Jun 6 15:56:38 2022 libnet-1.2-1.x86_64 Mon Jun 6 15:56:38 2022 libtasn1-4.18.0-1.x86_64 Mon Jun 6 15:56:38 2022 libuv-1.44.1-1.x86_64 Mon Jun 6 15:56:38 2022 lua54-libs-5.4.4-1.x86_64 Mon Jun 6 15:56:38 2022 nspr-4.33-1.x86_64 Mon Jun 6 15:56:39 2022 elfutils-0.187-2.x86_64 Mon Jun 6 15:56:39 2022 iptables-1.8.7-1.x86_64 Mon Jun 6 15:56:39 2022 libselinux-3.1-2.x86_64 Mon Jun 6 15:56:39 2022 nss-3.78-1.x86_64 Mon Jun 6 15:56:39 2022 pam-pam_cracklib-1.4.0-5.x86_64 Mon Jun 6 15:56:39 2022 pam-pam_tally-1.4.0-5.x86_64 Mon Jun 6 15:56:39 2022 perl-libs-5.34.1-1.x86_64 Mon Jun 6 15:56:39 2022 rpm-lib-4.16.1.3-18.x86_64 Mon Jun 6 15:56:39 2022 sqlite3-3.38.5-1.x86_64 Mon Jun 6 15:56:40 2022 openssl-3.0.3-1.x86_64 Mon Jun 6 15:56:40 2022 openssl-tools-3.0.3-1.x86_64 Mon Jun 6 15:56:40 2022 perl-dirs-5.34.0-1.x86_64 Mon Jun 6 15:56:40 2022 python-2.7.18-5.x86_64 Mon Jun 6 15:56:40 2022 python-libs-2.7.18-5.x86_64 Mon Jun 6 15:56:40 2022 rpm-4.16.1.3-18.x86_64 Mon Jun 6 15:56:40 2022 shadow-4.8.1-2.x86_64 Mon Jun 6 15:56:41 2022 heimdal-libs-7.7.0-3.x86_64 Mon Jun 6 15:56:41 2022 libevent-2.1.12-2.x86_64 Mon Jun 6 15:56:41 2022 libssh2-1.10.0-2.x86_64 Mon Jun 6 15:56:41 2022 nagios-nrpe-4.0.3-4.x86_64 Mon Jun 6 15:56:41 2022 open-vm-tools-11.3.0-3.x86_64 Mon Jun 6 15:56:41 2022 openslp-2.0.0-6.x86_64 Mon Jun 6 15:56:41 2022 openssh-9.0p1-2.x86_64 Mon Jun 6 15:56:41 2022 poldek-libs-0.42.2-11.x86_64 Mon Jun 6 15:56:41 2022 python-modules-2.7.18-5.x86_64 Mon Jun 6 15:56:41 2022 rabbitmq-c-0.11.0-2.x86_64 Mon Jun 6 15:56:41 2022 rpm-pld-macros-2.017-1.noarch Mon Jun 6 15:56:41 2022 wget-1.21.3-1.x86_64 Mon Jun 6 15:56:42 2022 bacula-common-11.0.6-1.x86_64 Mon Jun 6 15:56:42 2022 cyrus-sasl-2.1.27-2.x86_64 Mon Jun 6 15:56:42 2022 cyrus-sasl-libs-2.1.27-2.x86_64 Mon Jun 6 15:56:42 2022 mailx-12.4-8.x86_64 Mon Jun 6 15:56:42 2022 net-snmp-libs-5.9.1-3.x86_64 Mon Jun 6 15:56:42 2022 openldap-libs-2.4.59-2.x86_64 Mon Jun 6 15:56:42 2022 openssh-clients-9.0p1-2.x86_64 Mon Jun 6 15:56:42 2022 poldek-0.42.2-11.x86_64 Mon Jun 6 15:56:43 2022 net-snmp-5.9.1-3.x86_64 Mon Jun 6 15:56:43 2022 net-snmp-agent-libs-5.9.1-3.x86_64 Mon Jun 6 15:56:43 2022 openldap-2.4.59-2.x86_64 Mon Jun 6 15:56:43 2022 openssh-server-ldap-9.0p1-2.x86_64 Mon Jun 6 15:56:44 2022 openldap-backend-bdb-2.4.59-2.x86_64 Mon Jun 6 15:56:44 2022 openldap-backend-mdb-2.4.59-2.x86_64 Mon Jun 6 15:56:44 2022 openldap-servers-2.4.59-2.x86_64 Mon Jun 6 15:56:45 2022 bacula-fd-11.0.6-1.x86_64 Mon Jun 6 15:56:45 2022 openldap-backend-monitor-2.4.59-2.x86_64 Mon Jun 6 15:56:45 2022 openldap-overlay-syncprov-2.4.59-2.x86_64 Mon Jun 6 15:56:45 2022 perl-base-5.34.1-1.x86_64 Mon Jun 6 15:56:45 2022 ruby-2.6.10-2.x86_64 Mon Jun 6 15:56:45 2022 systemd-libs-250.5-1.x86_64 Mon Jun 6 15:56:45 2022 systemd-units-250.5-1.x86_64 Mon Jun 6 15:56:50 2022 ntpd-4.2.8p15-1.x86_64 Mon Jun 6 15:56:51 2022 openssh-server-9.0p1-2.x86_64 Mon Jun 6 15:56:51 2022 postfix-3.6.6-1.x86_64 Mon Jun 6 15:56:52 2022 nagios-plugins-libs-2.3.3-2.x86_64 Mon Jun 6 15:56:52 2022 p11-kit-0.24.1-1.x86_64 Mon Jun 6 15:56:52 2022 pcp-libs-5.3.6-3.x86_64 Mon Jun 6 15:56:52 2022 perl-Scalar-List-Utils-1.56-2.x86_64 Mon Jun 6 15:56:52 2022 perl-modules-5.34.1-1.x86_64 Mon Jun 6 15:56:52 2022 syslog-ng-libs-3.36.1-1.x86_64 Mon Jun 6 15:56:53 2022 syslog-ng-3.36.1-1.x86_64 Mon Jun 6 15:56:55 2022 nagios-plugin-check_mailq-2.3.3-2.noarch Mon Jun 6 15:56:55 2022 perl-Encode-3.0801-5.34.1.1.x86_64 Mon Jun 6 15:56:55 2022 sysstat-12.5.4-1.x86_64 Mon Jun 6 15:56:57 2022 ruby-bigdecimal-1.4.1-2.6.10.2.x86_64 Mon Jun 6 15:56:57 2022 ruby-io-console-0.4.7-2.6.10.2.x86_64 Mon Jun 6 15:56:57 2022 ruby-irb-1.0.0-2.6.10.2.noarch Mon Jun 6 15:56:57 2022 ruby-modules-2.6.10-2.x86_64 Mon
