From krzysztof at mrozowicz.eu Mon May 3 23:11:33 2021 From: krzysztof at mrozowicz.eu (Krzysztof Mrozowicz) Date: Mon, 3 May 2021 22:11:33 +0100 Subject: problem with firefox 88 Message-ID: Hi, I just upgraded firefox to version 88 and discovered its interface doesn't respond to clicking and in the terminal I can see the following: JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2304: Error: primed listener not re-registered JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory. Am I only one with this issue? Best Regards Krzysztof From krzysztof at mrozowicz.eu Mon May 3 23:22:21 2021 From: krzysztof at mrozowicz.eu (Krzysztof Mrozowicz) Date: Mon, 3 May 2021 22:22:21 +0100 Subject: problem with firefox 88 In-Reply-To: References: Message-ID: W dniu 03.05.2021 o?22:11, Krzysztof Mrozowicz pisze: > Hi, > I just upgraded firefox to version 88 and discovered its interface > doesn't respond to clicking and in the terminal I can see the following: > > JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line > 2304: Error: primed listener not re-registered > JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: > Can't find profile directory. > > Am I only one with this issue? On my other PLD instance, to which I connect via XRDP, the problem doesn't exist (and similar messages are displayed in the terminal). So maybe it's rather problem with the graphic driver than firefox... From krzysztof at mrozowicz.eu Tue May 4 21:10:40 2021 From: krzysztof at mrozowicz.eu (Krzysztof Mrozowicz) Date: Tue, 4 May 2021 20:10:40 +0100 Subject: problem with firefox 88 In-Reply-To: References: Message-ID: W dniu 03.05.2021 o?22:22, Krzysztof Mrozowicz pisze: > W dniu 03.05.2021 o?22:11, Krzysztof Mrozowicz pisze: >> Hi, >> I just upgraded firefox to version 88 and discovered its interface >> doesn't respond to clicking and in the terminal I can see the following: >> >> JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line >> 2304: Error: primed listener not re-registered >> JavaScript error: resource://gre/modules/XULStore.jsm, line 66: >> Error: Can't find profile directory. >> >> Am I only one with this issue? > > On my other PLD instance, to which I connect via XRDP, the problem > doesn't exist (and similar messages are displayed in the terminal). So > maybe it's rather problem with the graphic driver than firefox... > Downgraded to version 87 and happy days. From atler at pld-linux.org Wed May 5 12:35:23 2021 From: atler at pld-linux.org (Jan Palus) Date: Wed, 5 May 2021 12:35:23 +0200 Subject: problem with firefox 88 In-Reply-To: References: Message-ID: <710e49ff-fede-b772-ca97-6ce2ecf40600@fastmail.com> On 04.05.2021 21:10, Krzysztof Mrozowicz via pld-devel-en wrote: > W dniu 03.05.2021 o?22:22, Krzysztof Mrozowicz pisze: >> W dniu 03.05.2021 o?22:11, Krzysztof Mrozowicz pisze: >>> Hi, >>> I just upgraded firefox to version 88 and discovered its interface >>> doesn't respond to clicking and in the terminal I can see the >>> following: >>> >>> JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line >>> 2304: Error: primed listener not re-registered >>> JavaScript error: resource://gre/modules/XULStore.jsm, line 66: >>> Error: Can't find profile directory. >>> >>> Am I only one with this issue? >> >> On my other PLD instance, to which I connect via XRDP, the problem >> doesn't exist (and similar messages are displayed in the terminal). >> So maybe it's rather problem with the graphic driver than firefox... >> > Downgraded to version 87 and happy days. Works for me. Did you try with fresh profile (firefox -ProfileManager), mozilla's binary (package mozilla-firefox-bin) and in case it still doesn't work stracing it? From krzysztof at mrozowicz.eu Wed May 5 12:50:26 2021 From: krzysztof at mrozowicz.eu (Krzysztof Mrozowicz) Date: Wed, 5 May 2021 11:50:26 +0100 Subject: problem with firefox 88 In-Reply-To: <710e49ff-fede-b772-ca97-6ce2ecf40600@fastmail.com> References: <710e49ff-fede-b772-ca97-6ce2ecf40600@fastmail.com> Message-ID: <25af9f90-ec27-b41e-54a1-6a137e8977b4@mrozowicz.eu> W dniu 05.05.2021 o?11:35, Jan Palus pisze: >> Downgraded to version 87 and happy days. > Works for me. Did you try with fresh profile (firefox > -ProfileManager), mozilla's binary (package mozilla-firefox-bin) and > in case it still doesn't work stracing it? > I tried with fresh profile - the same effect. It seems like FF is reacting for clicking, but doesn't "re-paint" the interface accordingly. When I, let's say click "+" to open a new tab, then minimize the window and restore it, the new tab is there. Double-clicking on the window title (maximize/un-maximize) also refreshes the interface. Firefox 88 from mozilla-firefox-bin behaves the exact same way. Would you mind telling me how to strace the program in a correct way, please? I did it few times in the past but always I was googling the method. -- Krzysiek From ed at yen.ipipan.waw.pl Wed May 5 12:55:05 2021 From: ed at yen.ipipan.waw.pl (Peri Noid) Date: Wed, 05 May 2021 12:55:05 +0200 Subject: problem with firefox 88 In-Reply-To: <25af9f90-ec27-b41e-54a1-6a137e8977b4@mrozowicz.eu> References: <710e49ff-fede-b772-ca97-6ce2ecf40600@fastmail.com> <25af9f90-ec27-b41e-54a1-6a137e8977b4@mrozowicz.eu> Message-ID: <2828011.IWBoPukajQ@laptok> Dnia ?roda, 5 maja 2021 12:50:26 CEST Krzysztof Mrozowicz via pld-devel-en pisze: [...] > I tried with fresh profile - the same effect. It seems like FF is > reacting for clicking, but doesn't "re-paint" the interface accordingly. > When I, let's say click "+" to open a new tab, then minimize the window > and restore it, the new tab is there. Double-clicking on the window > title (maximize/un-maximize) also refreshes the interface. Firefox 88 > from mozilla-firefox-bin behaves the exact same way. What graphics environment do you use? -- ?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" From krzysztof at mrozowicz.eu Wed May 5 13:06:55 2021 From: krzysztof at mrozowicz.eu (Krzysztof Mrozowicz) Date: Wed, 5 May 2021 12:06:55 +0100 Subject: problem with firefox 88 In-Reply-To: <2828011.IWBoPukajQ@laptok> References: <710e49ff-fede-b772-ca97-6ce2ecf40600@fastmail.com> <25af9f90-ec27-b41e-54a1-6a137e8977b4@mrozowicz.eu> <2828011.IWBoPukajQ@laptok> Message-ID: W dniu 05.05.2021 o?11:55, Peri Noid pisze: > Dnia ?roda, 5 maja 2021 12:50:26 CEST Krzysztof Mrozowicz via pld-devel-en > pisze: > [...] >> I tried with fresh profile - the same effect. It seems like FF is >> reacting for clicking, but doesn't "re-paint" the interface accordingly. >> When I, let's say click "+" to open a new tab, then minimize the window >> and restore it, the new tab is there. Double-clicking on the window >> title (maximize/un-maximize) also refreshes the interface. Firefox 88 >> from mozilla-firefox-bin behaves the exact same way. > What graphics environment do you use? XFCE-4.16. But the other PLD I have, that I use via XRDP also has XFCE and there is no problem on it. The difference between them two, that could be important, is that the remote PLD is installed purely from the repos, and my laptop has some packages built locally and installed for test before sent to the PLD GIT repos. So I think, stracing the firefox process may be a good thing to do. -- Krzysiek From jpalus at fastmail.com Wed May 5 13:08:32 2021 From: jpalus at fastmail.com (Jan Palus) Date: Wed, 5 May 2021 13:08:32 +0200 Subject: problem with firefox 88 In-Reply-To: <25af9f90-ec27-b41e-54a1-6a137e8977b4@mrozowicz.eu> References: <710e49ff-fede-b772-ca97-6ce2ecf40600@fastmail.com> <25af9f90-ec27-b41e-54a1-6a137e8977b4@mrozowicz.eu> Message-ID: On 05.05.2021 12:50, Krzysztof Mrozowicz via pld-devel-en wrote: > W dniu 05.05.2021 o?11:35, Jan Palus pisze: >>> Downgraded to version 87 and happy days. >> Works for me. Did you try with fresh profile (firefox >> -ProfileManager), mozilla's binary (package mozilla-firefox-bin) and >> in case it still doesn't work stracing it? >> > I tried with fresh profile - the same effect. It seems like FF is > reacting for clicking, but doesn't "re-paint" the interface accordingly. > When I, let's say click "+" to open a new tab, then minimize the > window and restore it, the new tab is there. Double-clicking on the > window title (maximize/un-maximize) also refreshes the interface. > Firefox 88 from mozilla-firefox-bin behaves the exact same way. > > Would you mind telling me how to strace the program in a correct way, > please? I did it few times in the past but always I was googling the > method. Ah ok, somehow I thought firefox hangs or fails to start for you. That's probably an effect of enabling WebRender by default for XFCE/KDE with Intel/AMD GPU so likely for you. Try disabling webrender in about:config (|gfx.webrender.force-disabled=true). Which GPU? If Intel are you using modesetting driver? | From krzysztof at mrozowicz.eu Wed May 5 13:44:48 2021 From: krzysztof at mrozowicz.eu (Krzysztof Mrozowicz) Date: Wed, 5 May 2021 12:44:48 +0100 Subject: problem with firefox 88 In-Reply-To: References: <710e49ff-fede-b772-ca97-6ce2ecf40600@fastmail.com> <25af9f90-ec27-b41e-54a1-6a137e8977b4@mrozowicz.eu> Message-ID: <11cfedf2-9e73-adc7-1ade-b366c8dd3666@mrozowicz.eu> W dniu 05.05.2021 o?12:08, Jan Palus pisze: > On 05.05.2021 12:50, Krzysztof Mrozowicz via pld-devel-en wrote: >> W dniu 05.05.2021 o?11:35, Jan Palus pisze: >>>> Downgraded to version 87 and happy days. >>> Works for me. Did you try with fresh profile (firefox >>> -ProfileManager), mozilla's binary (package mozilla-firefox-bin) and >>> in case it still doesn't work stracing it? >>> >> I tried with fresh profile - the same effect. It seems like FF is >> reacting for clicking, but doesn't "re-paint" the interface accordingly. >> When I, let's say click "+" to open a new tab, then minimize the >> window and restore it, the new tab is there. Double-clicking on the >> window title (maximize/un-maximize) also refreshes the interface. >> Firefox 88 from mozilla-firefox-bin behaves the exact same way. >> >> Would you mind telling me how to strace the program in a correct way, >> please? I did it few times in the past but always I was googling the >> method. > Ah ok, somehow I thought firefox hangs or fails to start for you. > That's probably an effect of enabling WebRender by default for > XFCE/KDE with Intel/AMD GPU so likely for you. Try disabling webrender > in about:config (|gfx.webrender.force-disabled=true). Which GPU? If > Intel are you using modesetting driver? Zwyci?stwo! Setting up the gfx.webrender.force-disabled=true made the firefox usable again. Thanks Jan! Regarding the modesetting, I don't remember if I was tweaking any X config about that. My hardware is: CPU: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz GPU: VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) And xorg.log: # grep modesetting Xorg.0.log [??? 18.622] (==) Matched modesetting as autoconfigured driver 1 [??? 18.628] (II) LoadModule: "modesetting" [??? 18.628] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [??? 18.629] (II) Module modesetting: vendor="X.Org Foundation" [??? 18.632] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [??? 18.675] (WW) Falling back to old probe method for modesetting [??? 18.682] (II) UnloadModule: "modesetting" [??? 18.682] (II) Unloading modesetting -- Krzysiek From ed at yen.ipipan.waw.pl Wed May 5 13:58:50 2021 From: ed at yen.ipipan.waw.pl (Peri Noid) Date: Wed, 05 May 2021 13:58:50 +0200 Subject: problem with firefox 88 In-Reply-To: <11cfedf2-9e73-adc7-1ade-b366c8dd3666@mrozowicz.eu> References: <11cfedf2-9e73-adc7-1ade-b366c8dd3666@mrozowicz.eu> Message-ID: <20213383.ZQWARVJmVU@laptok> Dnia ?roda, 5 maja 2021 13:44:48 CEST Krzysztof Mrozowicz via pld-devel-en pisze: [...] > Regarding the modesetting, I don't remember if I was tweaking any X > config about that. My hardware is: > CPU: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz > GPU: VGA compatible controller: Intel Corporation 2nd Generation Core > Processor Family Integrated Graphics Controller (rev 09) > > And xorg.log: > > # grep modesetting Xorg.0.log > [ 18.622] (==) Matched modesetting as autoconfigured driver 1 > [ 18.628] (II) LoadModule: "modesetting" > [ 18.628] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so > [ 18.629] (II) Module modesetting: vendor="X.Org Foundation" > [ 18.632] (II) modesetting: Driver for Modesetting Kernel Drivers: kms > [ 18.675] (WW) Falling back to old probe method for modesetting > [ 18.682] (II) UnloadModule: "modesetting" > [ 18.682] (II) Unloading modesetting So it looks like you have no modesetting driver kernel module loaded. -- ?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" From atler at pld-linux.org Wed May 5 14:00:43 2021 From: atler at pld-linux.org (Jan Palus) Date: Wed, 5 May 2021 14:00:43 +0200 Subject: problem with firefox 88 In-Reply-To: <11cfedf2-9e73-adc7-1ade-b366c8dd3666@mrozowicz.eu> References: <710e49ff-fede-b772-ca97-6ce2ecf40600@fastmail.com> <25af9f90-ec27-b41e-54a1-6a137e8977b4@mrozowicz.eu> <11cfedf2-9e73-adc7-1ade-b366c8dd3666@mrozowicz.eu> Message-ID: <998edea2-eb33-a022-8f95-72644a6c6360@fastmail.com> On 05.05.2021 13:44, Krzysztof Mrozowicz via pld-devel-en wrote: > W dniu 05.05.2021 o?12:08, Jan Palus pisze: >> On 05.05.2021 12:50, Krzysztof Mrozowicz via pld-devel-en wrote: >>> W dniu 05.05.2021 o?11:35, Jan Palus pisze: >>>>> Downgraded to version 87 and happy days. >>>> Works for me. Did you try with fresh profile (firefox >>>> -ProfileManager), mozilla's binary (package mozilla-firefox-bin) >>>> and in case it still doesn't work stracing it? >>>> >>> I tried with fresh profile - the same effect. It seems like FF is >>> reacting for clicking, but doesn't "re-paint" the interface >>> accordingly. >>> When I, let's say click "+" to open a new tab, then minimize the >>> window and restore it, the new tab is there. Double-clicking on the >>> window title (maximize/un-maximize) also refreshes the interface. >>> Firefox 88 from mozilla-firefox-bin behaves the exact same way. >>> >>> Would you mind telling me how to strace the program in a correct >>> way, please? I did it few times in the past but always I was >>> googling the method. >> Ah ok, somehow I thought firefox hangs or fails to start for you. >> That's probably an effect of enabling WebRender by default for >> XFCE/KDE with Intel/AMD GPU so likely for you. Try disabling >> webrender in about:config (|gfx.webrender.force-disabled=true). Which >> GPU? If Intel are you using modesetting driver? > > Zwyci?stwo! Setting up the gfx.webrender.force-disabled=true made the > firefox usable again. Thanks Jan! > > Regarding the modesetting, I don't remember if I was tweaking any X > config about that. My hardware is: > CPU: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz > GPU: VGA compatible controller: Intel Corporation 2nd Generation Core > Processor Family Integrated Graphics Controller (rev 09) > > And xorg.log: > > # grep modesetting Xorg.0.log > [??? 18.622] (==) Matched modesetting as autoconfigured driver 1 > [??? 18.628] (II) LoadModule: "modesetting" > [??? 18.628] (II) Loading > /usr/lib64/xorg/modules/drivers/modesetting_drv.so > [??? 18.629] (II) Module modesetting: vendor="X.Org Foundation" > [??? 18.632] (II) modesetting: Driver for Modesetting Kernel Drivers: kms > [??? 18.675] (WW) Falling back to old probe method for modesetting > [??? 18.682] (II) UnloadModule: "modesetting" > [??? 18.682] (II) Unloading modesetting Not using modesetting on Intel is your real issue. Try to figure what's missing to make it work and webrender most likely will be fine in firefox. Anyway if you still have issues the discussion should be moved to pld-users-* From krzysztof at mrozowicz.eu Wed May 5 19:53:38 2021 From: krzysztof at mrozowicz.eu (Krzysztof Mrozowicz) Date: Wed, 5 May 2021 18:53:38 +0100 Subject: problem with firefox 88 In-Reply-To: <998edea2-eb33-a022-8f95-72644a6c6360@fastmail.com> References: <710e49ff-fede-b772-ca97-6ce2ecf40600@fastmail.com> <25af9f90-ec27-b41e-54a1-6a137e8977b4@mrozowicz.eu> <11cfedf2-9e73-adc7-1ade-b366c8dd3666@mrozowicz.eu> <998edea2-eb33-a022-8f95-72644a6c6360@fastmail.com> Message-ID: <905399fc-a44b-c4d8-d0e3-be1c5aa21dff@mrozowicz.eu> # grep modesetting Xorg.0.log >> [??? 18.622] (==) Matched modesetting as autoconfigured driver 1 >> [??? 18.628] (II) LoadModule: "modesetting" >> [??? 18.628] (II) Loading >> /usr/lib64/xorg/modules/drivers/modesetting_drv.so >> [??? 18.629] (II) Module modesetting: vendor="X.Org Foundation" >> [??? 18.632] (II) modesetting: Driver for Modesetting Kernel Drivers: >> kms >> [??? 18.675] (WW) Falling back to old probe method for modesetting >> [??? 18.682] (II) UnloadModule: "modesetting" >> [??? 18.682] (II) Unloading modesetting > Not using modesetting on Intel is your real issue. Try to figure > what's missing to make it work and webrender most likely will be fine > in firefox. Anyway if you still have issues the discussion should be > moved to pld-users-* The solution was uninstalling of xorg-driver-video-intel. Now modesetting works OK. Thanks all for help! -- Krzysztof From baggins at pld-linux.org Thu May 6 22:36:10 2021 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Thu, 6 May 2021 22:36:10 +0200 Subject: pam 1.5 In-Reply-To: <5544c8fb-ff91-3527-0807-94bde26db693@pld-linux.org> References: <5544c8fb-ff91-3527-0807-94bde26db693@pld-linux.org> Message-ID: On Thu, 18 Feb 2021, Elan Ruusam?e wrote: > > On 17.02.2021 16:40, Elan Ruusam?e wrote: > > > > https://github.com/linux-pam/linux-pam/releases/tag/v1.5.0 > > > > > > * Removed deprecated pam_cracklib module, use pam_passwdqc (from > > passwdqc project) > > or pam_pwquality (from libpwquality project) instead. > > * Removed deprecated pam_tally and pam_tally2 modules, use > > pam_faillock instead. > > > > > > what's our action? > > > > 1. follow the flow and remove them as well? > > > > 2. alternatively could copy them from 1.4.0 tarball, so at least we > > don't lag behind because afraid to update to 1.5.x > > > > > > if someone really needs those removed modules, a separate .spec is > > more appropriate solution to the problem. > > > > there's also pam-pld-1.1.2-1.tar.gz included in pam.spec, there's no > info how that file was generated. > > could put the two new abandoned modules there as well. altho i feel > better to just create new tarball with tally and cracklib I would just drop them, my memory tells me pam_tally* were barely working at best and I don't see a problem moving from cracklib to passwdqc. The caveat is we would have to update all appropriate configs and add the package and all required deps. FYI pam-pld tarball comes from http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/pam/ -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From baggins at pld-linux.org Thu May 6 22:46:03 2021 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Thu, 6 May 2021 22:46:03 +0200 Subject: [packages/python-sympy] - up to 1.7.1, python 2 no longer supported In-Reply-To: <20210313211730.GA20612@mail> References: <3b26fa0f-fac3-84a1-7042-ef287b8d0331@pld-linux.org> <20210313211730.GA20612@mail> Message-ID: On Sat, 13 Mar 2021, Jakub Bogusz wrote: > On Fri, Mar 12, 2021 at 10:25:36AM +0100, Jan R?korajski wrote: > > On Fri, Mar 12, 2021 at 9:55 AM Elan Ruusam?e wrote: > > > > > > > > On 12.03.2021 00:32, baggins wrote: > > > > commit a7afb2642f193eb728569b130fd57bdc8acadd02 > > > > Author: Jan R?korajski > > > > Date: Thu Mar 11 23:32:30 2021 +0100 > > > > > > > > - up to 1.7.1, python 2 no longer supported > > > > > > > > python-sympy-nodisplay.patch | 25 ------------------------- > > > > python-sympy.spec | 8 +++----- > > > > 2 files changed, 3 insertions(+), 30 deletions(-) > > > > --- > > > > diff --git a/python-sympy.spec b/python-sympy.spec > > > > index cb6d2e4..6c9214c 100644 > > > > --- a/python-sympy.spec > > > > +++ b/python-sympy.spec > > > > @@ -2,20 +2,19 @@ > > > > # Conditional build: > > > > %bcond_without doc # HTML and PDF documentation > > > > %bcond_without tests # unit tests > > > > -%bcond_without python2 # CPython 2.x module > > > > +%bcond_with python2 # CPython 2.x module > > > > %bcond_without python3 # CPython 3.x module > > > > > > > > > > i agree with what qboosh has been doing in this cases: > > > > > > 1. git ssh copy python-foo to python3-foo > > > > > > 2. update python3-foo to be python3 only > > > > > > 3. update python3-foo to new version, stb > > > > > > 4. disable python3 from python-foo, relup, stb > > > > > > > And I very much do not agree with that. > > Python 2 must die. If upstream decides to drop python2 support, we should > > too, > > we should not keep old odd versions indefinitely[1]. This creates chaos > > because > > we end up with inconsistent mess. > > > > [1] We may, but only for a very strong reasons, ex. a ton of packages would > > break. > > Python 2 is dying, more and more (mostly very common) packages are dropping support, > but there are still/will be "long tails" of not ported single packages. > > Mainstream is slowly porting from gtk+ 3 to gtk 4 and we still have gtk+ 1. > > Ofc, there is no sense to keep all active forever, python2 packages can > fade out from the "loose" (non-required) ends. > > For the active cases - as we didn't go Fedora way with renaming all > python 2.x packages to python2-*, I see two possibilities: > > a) python-foo.spec with python2-only module/version of module or python2/3 modules > and python3-foo.spec with python3-only module/version of module > > b) python-foo.spec:master branch with python3-only module/version of module or python2/3 modules > and python-foo.spec:PYTHON2 branch with last supported python2 version > > I personally prefer a) because: > - we can build all active packages from repo heads (I am aware of just two > exceptions from this "rule": kernel.spec and php.spec) > > - in case of python3-only spec, we need only one package preamble > (b) case requires dummy base package and "-n python3-foo" subpackage) > > In case of b), in python3-only cases apidocs should be packaged as > "%package -n python3-*-apidocs", not "%package apidocs". I'm fine with a) as long as we make sure to mark the old python2 package in a way there is no confusion that it's dead and should ot be built. My problem is that it's hard to keep up with all those packages and having both python- and python3- packages gets confusing. > > it takes extra steps to do that, but i think it's worth the effort in > > > long term. > > > > > > it's weird to have python-foo to build python3-foo, > > > and the python3-foo will be cleaner without having to support two python > > > versions. > > > > > > > What we should do here is to just drop python2 from python-foo, what I'll > > do once > > the dust after current 3.9 / rpm deps rebuild settles. > > Keeping dead python2 boilerplate in spec (just with bcond off) after updating > to python3-only version makes no sense... > > > As for establishing some python2/3 packaging/migration policy - where to > Obsolete python-* packages after dropping python2 variants? In the new python3-* package? At least that is what I've been doing so far. P.S. All this mess because of one person's obsession with unicode :( -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From qboosh at pld-linux.org Sun May 9 21:10:40 2021 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 9 May 2021 21:10:40 +0200 Subject: glibc upgrade on builders + binaries colour with rpm.org [Re: ERRORS: COMMAND] In-Reply-To: References: Message-ID: <20210509191040.GA30345@mail> I tried: $ make-request -b 'th-x86_64 th-x32' -c 'poldek -n th-all -n th-ready-all -n th-test-all -Uvg glibc' But poldek failed with "Aborted"... how to perform glibc upgrade on th-x86_64 and th-x32? I want to upgrade because of messed colour of /usr/bin/iconv binary (to see if it helps, or there is something wrong with colour selection in rpm.org) - currently: th-x32 contains 64-bit /usr/bin/iconv th-x86_64 contains 32-bit /usr/bin/iconv which don't use host native iconv modules (but require iconv modules from matching binary ABI). On Sun, May 09, 2021 at 06:36:56PM +0000, PLD th-x86_64 builder wrote: > COMMAND (): FAILED [...] > > --- COMMAND:: > Build-Time: user:14.55s sys:4.78s real:19.36s (faults io:1 non-io:1378587) > > > > *** buildlog for COMMAND > Loading [pndir]th... > Loading [pndir]th... > Loading [pndir]th-i686... > Loading [pndir]th-x32... > Loading [pndir]th-ready... > Loading [pndir]th-ready... > Loading [pndir]th-i686-ready... > Loading [pndir]th-x32-ready... > Loading [pndir]th-test... > Loading [pndir]th-test... > Loading [pndir]th-i686-test... > Loading [pndir]th-x32-test... > 75168 packages read > warn: glibc: ambiguous name > glibc-2.33-4.i686: equal version installed, skipped > glibc-2.33-4.x32: equal version installed, skipped > glibc-2.33-4.x86_64: equal version installed, skipped > Processing dependencies... > glibc-2.33-4.i686 obsoleted by glibc-2.33-5.i686 > Aborted > Begin-PLD-Builder-Info > Build-Time: user:14.55s sys:4.78s real:19.36s (faults io:1 non-io:1378587) > > End-PLD-Builder-Info > -- Jakub Bogusz http://qboosh.pl/ From baggins at pld-linux.org Sun May 9 22:54:11 2021 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 9 May 2021 22:54:11 +0200 Subject: glibc upgrade on builders + binaries colour with rpm.org [Re: ERRORS: COMMAND] In-Reply-To: <20210509191040.GA30345@mail> References: <20210509191040.GA30345@mail> Message-ID: On Sun, 09 May 2021, Jakub Bogusz wrote: > I tried: > $ make-request -b 'th-x86_64 th-x32' -c 'poldek -n th-all -n th-ready-all -n th-test-all -Uvg glibc' > > But poldek failed with "Aborted"... how to perform glibc upgrade on > th-x86_64 and th-x32? > > I want to upgrade because of messed colour of /usr/bin/iconv binary (to > see if it helps, or there is something wrong with colour selection in rpm.org) > - currently: > th-x32 contains 64-bit /usr/bin/iconv > th-x86_64 contains 32-bit /usr/bin/iconv > which don't use host native iconv modules (but require iconv modules from > matching binary ABI). $ make-request -b th-x86_64 -t -c 'poldek -n th-test -n th-i686-test -n th-x32-test -n th-ready -n th-i686-ready -n th-x32-ready -n th -n th-i686 -n th-x32 --up' $ make-request -b th-x86_64 -t -c 'poldek -O "particle install = no" -n th-test -n th-i686-test -n th-x32-test -n th-test -n th-i686-ready -n th-x32-ready -n th -n th-i686 -n th-x32 -uvg glibc-2.33-5.i686 glibc-2.33-5.x32 glibc-2.33-5.x86_64 ldconfig-2.33-5.x86_64 glibc-devel-utils-2.33-5.x86_64 --force' without --force install fails with Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 0... Verifying... ######################################## Preparing... ######################################## file /sbin/glibc-postinst conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /sbin/sln conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/getconf conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/getent conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/iconv conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/locale conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/zdump conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/sbin/zic conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 Begin-PLD-Builder-Info For x32 it was: $ make-request -b th-x32 -t -c 'poldek -O "particle install = no" -n th-test -n th-i686-test -n th-x86_64-test -uvg glibc-2.33-5.i686 glibc-2.33-5.x32 glibc-2.33-5.x86_64 ldconfig-2.33-5.x32 --force' again, without --force fails with Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 0... Verifying... ######################################## Preparing... ######################################## file /usr/bin/mtrace from install of glibc-devel-utils-6:2.33-5.x86_64 conflicts with file from package glibc-devel-utils-6:2.33-4.x32 file /usr/bin/xtrace from install of glibc-devel-utils-6:2.33-5.x86_64 conflicts with file from package glibc-devel-utils-6:2.33-4.x32 file /usr/share/man/ja/man1/mtrace.1.gz from install of glibc-devel-utils-6:2.33-5.x86_64 conflicts with file from package glibc-devel-utils-6:2.33-4.x32 file /usr/share/man/ja/man1/sprof.1.gz from install of glibc-devel-utils-6:2.33-5.x86_64 conflicts with file from package glibc-devel-utils-6:2.33-4.x32 file /usr/share/man/man1/mtrace.1.gz from install of glibc-devel-utils-6:2.33-5.x86_64 conflicts with file from package glibc-devel-utils-6:2.33-4.x32 file /usr/share/man/man1/sprof.1.gz from install of glibc-devel-utils-6:2.33-5.x86_64 conflicts with file from package glibc-devel-utils-6:2.33-4.x32 file /sbin/glibc-postinst conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /sbin/sln conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/getconf conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/getent conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/iconv conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/locale conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/bin/zdump conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 file /usr/sbin/zic conflicts between attempted installs of glibc-6:2.33-5.i686 and glibc-6:2.33-5.x32 Begin-PLD-Builder-Info -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From glen at pld-linux.org Tue May 11 15:14:55 2021 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 11 May 2021 16:14:55 +0300 Subject: [packages/rpm-getdeps] - add note about missing BR returned and alternative tool In-Reply-To: References: <00a0315b05c27cce65bbc6a3213a6acc5da6155a_refs_heads_master@pld-linux.org> Message-ID: <0b526c81-592b-f7f5-014f-9240c550bc29@pld-linux.org> On 11.05.2021 13:27, adamg wrote: > %build > -%{__make} \ > +echo %{__make} \ > CC="%{__cc}" \ > RPMLDFLAGS="%{rpmldflags}" \ > RPMCFLAGS="%{rpmcflags}" remove the echo From glen at pld-linux.org Thu May 13 21:32:22 2021 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 13 May 2021 22:32:22 +0300 Subject: [packages/php] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti In-Reply-To: <45629e6e9bbed84edb75f9580aabea932a696556_refs_heads_master@pld-linux.org> References: <45629e6e9bbed84edb75f9580aabea932a696556_refs_heads_master@pld-linux.org> Message-ID: <7abe966b-82fc-34ca-dab4-3a9d2d30c8a0@pld-linux.org> On 13.05.2021 22:04, adamg wrote: > commit 45629e6e9bbed84edb75f9580aabea932a696556 > Author: Adam Go??biowski > Date: Thu May 13 15:03:01 2021 +0000 > > - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), > we have fully transitioned to rpm 4 by now, and there is no easy way > to match 4.16* (4.16.0, 4.16.1, etc) - at least not without some lua > scripting, so just drop this. there is a way to match: [~/rpm/packages/php(7.4.19) (PHP_7_4)?] ? grep -r _rpmversion ~/all-specs /home/users/glen/all-specs/php.spec:%if "%_rpmversion" != "4.16.0" /home/users/glen/all-specs/rpm.spec:%if "%{_rpmversion}" >= "4.12" && "%{_rpmversion}" < "5" /home/users/glen/all-specs/orc.spec:%if 0%{?ver_ge "%{_rpmversion}" "4.6"} /home/users/glen/all-specs/perl.spec:%if %{_ver_ge '%{_rpmversion}' '4.16'} && %{_ver_lt '%{_rpmversion}' '5'} /home/users/glen/all-specs/lightdm.spec:%if "%{_rpmversion}" >= "5" /home/users/glen/all-specs/acroread.spec:%if "%{_rpmversion}" >= "5.0" however, point of that guard was to wait for support to become available or someone implement a solution. the error being: error: line 466: Illegal char '/' (0x2f) in: Obsoletes: /usr/bin/php error: line 466: Only package names are allowed in Obsoletes: Obsoletes:??????? /usr/bin/php but as no such solution as provided, you need to update obsoletes to fill **all** package names that provide that file path. I refuse to do that myself as it's pretty stupid. > > php.spec | 3 --- > 1 file changed, 3 deletions(-) > --- > diff --git a/php.spec b/php.spec > index b1388c5..19ed4d3 100644 > --- a/php.spec > +++ b/php.spec > @@ -459,9 +459,6 @@ Summary: /usr/bin/php symlink > Summary(pl.UTF-8): Dowi?zanie symboliczne /usr/bin/php > Group: Development/Languages/PHP > Requires: %{name}-cli = %{epoch}:%{version}-%{release} > -%if "%_rpmversion" != "4.16.0" > -Obsoletes: /usr/bin/php > -%endif > Obsoletes: php-program < 4:5.3.28-7 > From adamg at pld-linux.org Sat May 15 11:38:34 2021 From: adamg at pld-linux.org (=?UTF-8?B?QWRhbSBHb8WCxJliaW93c2tp?=) Date: Sat, 15 May 2021 11:38:34 +0200 Subject: [packages/php] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti In-Reply-To: <7abe966b-82fc-34ca-dab4-3a9d2d30c8a0@pld-linux.org> References: <45629e6e9bbed84edb75f9580aabea932a696556_refs_heads_master@pld-linux.org> <7abe966b-82fc-34ca-dab4-3a9d2d30c8a0@pld-linux.org> Message-ID: <1e4cea34-dcec-7973-612b-27fc4b731a77@pld-linux.org> W dniu 2021-05-13 o?21:32, Elan Ruusam?e pisze: > point of that guard was to wait for support to become available or > someone implement a solution. > (...) > but as no such solution as provided, you need to update obsoletes to > fill **all** package names that provide that file path. > > I refuse to do that myself as it's pretty stupid. ugly, for sure, but unless we come up with another solution (patching rpm to support Obsoletes: /path), we will need to maintain 11 Obsoletes: lines per package ... From ngompa13 at gmail.com Sat May 15 11:52:04 2021 From: ngompa13 at gmail.com (Neal Gompa) Date: Sat, 15 May 2021 05:52:04 -0400 Subject: [packages/php] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti In-Reply-To: <1e4cea34-dcec-7973-612b-27fc4b731a77@pld-linux.org> References: <45629e6e9bbed84edb75f9580aabea932a696556_refs_heads_master@pld-linux.org> <7abe966b-82fc-34ca-dab4-3a9d2d30c8a0@pld-linux.org> <1e4cea34-dcec-7973-612b-27fc4b731a77@pld-linux.org> Message-ID: On Sat, May 15, 2021 at 5:38 AM Adam Go??biowski wrote: > > > W dniu 2021-05-13 o 21:32, Elan Ruusam?e pisze: > > > point of that guard was to wait for support to become available or > > someone implement a solution. > > (...) > > but as no such solution as provided, you need to update obsoletes to > > fill **all** package names that provide that file path. > > > > I refuse to do that myself as it's pretty stupid. > > ugly, for sure, but unless we come up with another solution (patching > rpm to support Obsoletes: /path), we will need to maintain 11 Obsoletes: > lines per package ... > What problem are you trying to solve here? I'm not sure I understand why you're doing this. -- ?????????/ Always, there's only one truth! From adamg at pld-linux.org Sat May 15 12:23:26 2021 From: adamg at pld-linux.org (=?UTF-8?B?QWRhbSBHb8WCxJliaW93c2tp?=) Date: Sat, 15 May 2021 12:23:26 +0200 Subject: [packages/php] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti In-Reply-To: References: <45629e6e9bbed84edb75f9580aabea932a696556_refs_heads_master@pld-linux.org> <7abe966b-82fc-34ca-dab4-3a9d2d30c8a0@pld-linux.org> <1e4cea34-dcec-7973-612b-27fc4b731a77@pld-linux.org> Message-ID: <6ad60723-b18e-edf4-745f-53cc492e2206@pld-linux.org> W dniu 2021-05-15 o?11:52, Neal Gompa pisze: > On Sat, May 15, 2021 at 5:38 AM Adam Go??biowski wrote: >> >> W dniu 2021-05-13 o 21:32, Elan Ruusam?e pisze: >> >>> point of that guard was to wait for support to become available or >>> someone implement a solution. >>> (...) >>> but as no such solution as provided, you need to update obsoletes to >>> fill **all** package names that provide that file path. >>> >>> I refuse to do that myself as it's pretty stupid. >> ugly, for sure, but unless we come up with another solution (patching >> rpm to support Obsoletes: /path), we will need to maintain 11 Obsoletes: >> lines per package ... >> > What problem are you trying to solve here? I'm not sure I understand > why you're doing this. Each of the php*-program packages provide /usr/bin/php symlink: /poldek:/all-avail> install phpcs////Processing dependencies...////phpcs-3.4.1-2.noarch: required "/usr/bin/php" is provided by the following packages:////a) php4-program-4.4.9-67.x86_64////b) php52-program-5.2.17-20130717.35.x86_64////c) php53-program-5.3.29-52.x86_64////d) php54-program-5.4.45-30.x86_64////e) php55-program-5.5.38-22.x86_64////f) php56-program-5.6.40-9.x86_64////g) php70-program-7.0.33-8.x86_64////h) php71-program-7.1.33-3.x86_64////i) php72-program-7.2.34-1.x86_64////j) php73-program-7.3.24-1.x86_64////k) php74-program-7.4.12-2.x86_64////l) php80-program-8.0.0-2.x86_64////Which one do you want to install ('Q' to abort)? [php4-program-4.4.9-67.x86_64]/ Prior to rpm switch, each of those packages also had Obsoletes: /usr/bin/php so that you could easily switch the provider of /usr/bin/php symlinkL /poldek:/all-avail> install php80-program-8.0.0-2.x86_64/// /Loading [pndir]th-2020-updates... Loading [pndir]th-2020-updates... Loading [pndir]th-2020... Loading [pndir]th-2020... 29952 packages read Processing dependencies... php80-program-8.0.0-2.x86_64 marks php80-cli-8.0.0-2.x86_64 (cap php80-cli = 4:8.0.0-2) ?php80-cli-8.0.0-2.x86_64 marks php80-common-8.0.0-2.x86_64 (cap /etc/php80) There are 3 packages to install (2 marked by dependencies): A php80-cli-8.0.0-2.x86_64? php80-common-8.0.0-2.x86_64 php80-program-8.0.0-2.x86_64 This operation will use 4.6MB of disk space. Need to get 1.4MB of archives (1.4MB to download). [1/3] th-2020::php80-common-8.0.0-2.x86_64.rpm [1.4M (1.4M/s)] [2/3] th-2020::php80-cli-8.0.0-2.x86_64.rpm [51.7K (51.7K/s)] [3/3] th-2020::php80-program-8.0.0-2.x86_64.rpm [5.0K (5.0K/s)] Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 1... error: failed to open /etc/mtab: No such file or directory Preparing... ########################################### [100%] Repackaging... ?? 1:php72-program ########################################### [100%] Upgrading... ?? 1:php80-common ########################################### [ 33%] ?? 2:php80-cli ########################################### [ 67%] ?? 3:php80-program ########################################### [100%] poldek:/all-avail>/ But rpm-4 no longer allows / in Obsoletes: /Illegal char '/' (0x2f) in: Obsoletes: /usr/bin/php / Which makes this smooth transition no longer possible: /poldek:/all-avail> install php73-program-7.3.27-1.x86_64// //Processing dependencies...// //php73-program-7.3.27-1.x86_64 marks php73-cli-7.3.27-1.x86_64 (cap php73-cli = 4:7.3.27-1)// //?php73-cli-7.3.27-1.x86_64 marks php73-common-7.3.27-1.x86_64 (cap libphp_common-7.3.27.so()(64bit))// //There are 3 packages to install (2 marked by dependencies):// //A php73-cli-7.3.27-1.x86_64 php73-common-7.3.27-1.x86_64? php73-program-7.3.27-1.x86_64// //This operation will use 4.2MB of disk space.// //Need to get 1.2MB of archives.// //php73-common-7.3.27-1.x86_64.rpm: digests OK// //php73-cli-7.3.27-1.x86_64.rpm: digests OK// //php73-program-7.3.27-1.x86_64.rpm: digests OK// //Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 0...// //Verifying... ################################# [100%]// //Preparing... ################################# [100%]// //??????? file /usr/bin/php from install of php73-program-4:7.3.27-1.x86_64 conflicts with file from package php74-program-4:7.4.19-1.1.x86_64// //??????? file /usr/share/man/man1/php.1 from install of php73-program-4:7.3.27-1.x86_64 conflicts with file from package php74-program-4:7.4.19-1.1.x86_64// //There were errors// //poldek:/all-avail>/ To keep what we had with rpm5 , we either need to patch rpm, or add 11 (as of today) Obsoletes: php${ver}-program? lines to each spec. From ngompa13 at gmail.com Sat May 15 15:26:13 2021 From: ngompa13 at gmail.com (Neal Gompa) Date: Sat, 15 May 2021 09:26:13 -0400 Subject: [packages/php] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti In-Reply-To: <6ad60723-b18e-edf4-745f-53cc492e2206@pld-linux.org> References: <45629e6e9bbed84edb75f9580aabea932a696556_refs_heads_master@pld-linux.org> <7abe966b-82fc-34ca-dab4-3a9d2d30c8a0@pld-linux.org> <1e4cea34-dcec-7973-612b-27fc4b731a77@pld-linux.org> <6ad60723-b18e-edf4-745f-53cc492e2206@pld-linux.org> Message-ID: On Sat, May 15, 2021 at 6:23 AM Adam Go??biowski wrote: > > > W dniu 2021-05-15 o 11:52, Neal Gompa pisze: > > On Sat, May 15, 2021 at 5:38 AM Adam Go??biowski wrote: > >> > >> W dniu 2021-05-13 o 21:32, Elan Ruusam?e pisze: > >> > >>> point of that guard was to wait for support to become available or > >>> someone implement a solution. > >>> (...) > >>> but as no such solution as provided, you need to update obsoletes to > >>> fill **all** package names that provide that file path. > >>> > >>> I refuse to do that myself as it's pretty stupid. > >> ugly, for sure, but unless we come up with another solution (patching > >> rpm to support Obsoletes: /path), we will need to maintain 11 Obsoletes: > >> lines per package ... > >> > > What problem are you trying to solve here? I'm not sure I understand > > why you're doing this. > > Each of the php*-program packages provide /usr/bin/php symlink: > > /poldek:/all-avail> install phpcs////Processing dependencies...////phpcs-3.4.1-2.noarch: required "/usr/bin/php" is provided by the > following packages:////a) php4-program-4.4.9-67.x86_64////b) php52-program-5.2.17-20130717.35.x86_64////c) php53-program-5.3.29-52.x86_64////d) php54-program-5.4.45-30.x86_64////e) php55-program-5.5.38-22.x86_64////f) php56-program-5.6.40-9.x86_64////g) php70-program-7.0.33-8.x86_64////h) php71-program-7.1.33-3.x86_64////i) php72-program-7.2.34-1.x86_64////j) php73-program-7.3.24-1.x86_64////k) php74-program-7.4.12-2.x86_64////l) php80-program-8.0.0-2.x86_64////Which one do you want to install ('Q' to abort)? > [php4-program-4.4.9-67.x86_64]/ > > > > Prior to rpm switch, each of those packages also had Obsoletes: /usr/bin/php so that you could easily switch the provider of /usr/bin/php symlinkL > /poldek:/all-avail> install php80-program-8.0.0-2.x86_64/// > > /Loading [pndir]th-2020-updates... > Loading [pndir]th-2020-updates... > Loading [pndir]th-2020... > Loading [pndir]th-2020... > 29952 packages read > Processing dependencies... > php80-program-8.0.0-2.x86_64 marks php80-cli-8.0.0-2.x86_64 (cap > php80-cli = 4:8.0.0-2) > php80-cli-8.0.0-2.x86_64 marks php80-common-8.0.0-2.x86_64 (cap > /etc/php80) > There are 3 packages to install (2 marked by dependencies): > A php80-cli-8.0.0-2.x86_64 php80-common-8.0.0-2.x86_64 > php80-program-8.0.0-2.x86_64 > This operation will use 4.6MB of disk space. > Need to get 1.4MB of archives (1.4MB to download). > > [1/3] th-2020::php80-common-8.0.0-2.x86_64.rpm [1.4M (1.4M/s)] > [2/3] th-2020::php80-cli-8.0.0-2.x86_64.rpm [51.7K (51.7K/s)] > [3/3] th-2020::php80-program-8.0.0-2.x86_64.rpm [5.0K (5.0K/s)] > Executing pm-command.sh --upgrade -vh --root / --define > _check_dirname_deps 1... > error: failed to open /etc/mtab: No such file or directory > Preparing... ########################################### [100%] > Repackaging... > 1:php72-program ########################################### [100%] > Upgrading... > 1:php80-common ########################################### [ 33%] > 2:php80-cli ########################################### [ 67%] > 3:php80-program ########################################### [100%] > poldek:/all-avail>/ > > > But rpm-4 no longer allows / in Obsoletes: > > /Illegal char '/' (0x2f) in: Obsoletes: /usr/bin/php / > > Which makes this smooth transition no longer possible: > > /poldek:/all-avail> install php73-program-7.3.27-1.x86_64// > //Processing dependencies...// > //php73-program-7.3.27-1.x86_64 marks php73-cli-7.3.27-1.x86_64 (cap > php73-cli = 4:7.3.27-1)// > // php73-cli-7.3.27-1.x86_64 marks php73-common-7.3.27-1.x86_64 (cap > libphp_common-7.3.27.so()(64bit))// > //There are 3 packages to install (2 marked by dependencies):// > //A php73-cli-7.3.27-1.x86_64 php73-common-7.3.27-1.x86_64 > php73-program-7.3.27-1.x86_64// > //This operation will use 4.2MB of disk space.// > //Need to get 1.2MB of archives.// > //php73-common-7.3.27-1.x86_64.rpm: digests OK// > //php73-cli-7.3.27-1.x86_64.rpm: digests OK// > //php73-program-7.3.27-1.x86_64.rpm: digests OK// > //Executing pm-command.sh --upgrade -vh --root / --define > _check_dirname_deps 0...// > //Verifying... ################################# [100%]// > //Preparing... ################################# [100%]// > // file /usr/bin/php from install of > php73-program-4:7.3.27-1.x86_64 conflicts with file from package > php74-program-4:7.4.19-1.1.x86_64// > // file /usr/share/man/man1/php.1 from install of > php73-program-4:7.3.27-1.x86_64 conflicts with file from package > php74-program-4:7.4.19-1.1.x86_64// > //There were errors// > //poldek:/all-avail>/ > > To keep what we had with rpm5 , we either need to patch rpm, or add 11 > (as of today) Obsoletes: php${ver}-program lines to each spec. RPM supports using Provides+Conflicts to represent this issue. Provides: php-interpreter Conflicts: php-interpreter When this is set, RPM knows that one and only one implementation providing "php-interpreter" is permitted and permits swapping them. -- ?????????/ Always, there's only one truth! From adamg at pld-linux.org Sat May 15 16:41:13 2021 From: adamg at pld-linux.org (=?UTF-8?B?QWRhbSBHb8WCxJliaW93c2tp?=) Date: Sat, 15 May 2021 16:41:13 +0200 Subject: [packages/php] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti In-Reply-To: References: <45629e6e9bbed84edb75f9580aabea932a696556_refs_heads_master@pld-linux.org> <7abe966b-82fc-34ca-dab4-3a9d2d30c8a0@pld-linux.org> <1e4cea34-dcec-7973-612b-27fc4b731a77@pld-linux.org> <6ad60723-b18e-edf4-745f-53cc492e2206@pld-linux.org> Message-ID: <6d294616-196b-30df-3ea9-0b3540ff5c1a@pld-linux.org> W dniu 2021-05-15 o?15:26, Neal Gompa pisze: > On Sat, May 15, 2021 at 6:23 AM Adam Go??biowski wrote: >> >> W dniu 2021-05-15 o 11:52, Neal Gompa pisze: >>> On Sat, May 15, 2021 at 5:38 AM Adam Go??biowski wrote: >>>> W dniu 2021-05-13 o 21:32, Elan Ruusam?e pisze: >>>> >>>>> point of that guard was to wait for support to become available or >>>>> someone implement a solution. >>>>> (...) >>>>> but as no such solution as provided, you need to update obsoletes to >>>>> fill **all** package names that provide that file path. >>>>> >>>>> I refuse to do that myself as it's pretty stupid. >>>> ugly, for sure, but unless we come up with another solution (patching >>>> rpm to support Obsoletes: /path), we will need to maintain 11 Obsoletes: >>>> lines per package ... >>>> >>> What problem are you trying to solve here? I'm not sure I understand >>> why you're doing this. >> Each of the php*-program packages provide /usr/bin/php symlink: >> >> /poldek:/all-avail> install phpcs////Processing dependencies...////phpcs-3.4.1-2.noarch: required "/usr/bin/php" is provided by the >> following packages:////a) php4-program-4.4.9-67.x86_64////b) php52-program-5.2.17-20130717.35.x86_64////c) php53-program-5.3.29-52.x86_64////d) php54-program-5.4.45-30.x86_64////e) php55-program-5.5.38-22.x86_64////f) php56-program-5.6.40-9.x86_64////g) php70-program-7.0.33-8.x86_64////h) php71-program-7.1.33-3.x86_64////i) php72-program-7.2.34-1.x86_64////j) php73-program-7.3.24-1.x86_64////k) php74-program-7.4.12-2.x86_64////l) php80-program-8.0.0-2.x86_64////Which one do you want to install ('Q' to abort)? >> [php4-program-4.4.9-67.x86_64]/ >> >> >> >> Prior to rpm switch, each of those packages also had Obsoletes: /usr/bin/php so that you could easily switch the provider of /usr/bin/php symlinkL >> /poldek:/all-avail> install php80-program-8.0.0-2.x86_64/// >> >> /Loading [pndir]th-2020-updates... >> Loading [pndir]th-2020-updates... >> Loading [pndir]th-2020... >> Loading [pndir]th-2020... >> 29952 packages read >> Processing dependencies... >> php80-program-8.0.0-2.x86_64 marks php80-cli-8.0.0-2.x86_64 (cap >> php80-cli = 4:8.0.0-2) >> php80-cli-8.0.0-2.x86_64 marks php80-common-8.0.0-2.x86_64 (cap >> /etc/php80) >> There are 3 packages to install (2 marked by dependencies): >> A php80-cli-8.0.0-2.x86_64 php80-common-8.0.0-2.x86_64 >> php80-program-8.0.0-2.x86_64 >> This operation will use 4.6MB of disk space. >> Need to get 1.4MB of archives (1.4MB to download). >> >> [1/3] th-2020::php80-common-8.0.0-2.x86_64.rpm [1.4M (1.4M/s)] >> [2/3] th-2020::php80-cli-8.0.0-2.x86_64.rpm [51.7K (51.7K/s)] >> [3/3] th-2020::php80-program-8.0.0-2.x86_64.rpm [5.0K (5.0K/s)] >> Executing pm-command.sh --upgrade -vh --root / --define >> _check_dirname_deps 1... >> error: failed to open /etc/mtab: No such file or directory >> Preparing... ########################################### [100%] >> Repackaging... >> 1:php72-program ########################################### [100%] >> Upgrading... >> 1:php80-common ########################################### [ 33%] >> 2:php80-cli ########################################### [ 67%] >> 3:php80-program ########################################### [100%] >> poldek:/all-avail>/ >> >> >> But rpm-4 no longer allows / in Obsoletes: >> >> /Illegal char '/' (0x2f) in: Obsoletes: /usr/bin/php / >> >> Which makes this smooth transition no longer possible: >> >> /poldek:/all-avail> install php73-program-7.3.27-1.x86_64// >> //Processing dependencies...// >> //php73-program-7.3.27-1.x86_64 marks php73-cli-7.3.27-1.x86_64 (cap >> php73-cli = 4:7.3.27-1)// >> // php73-cli-7.3.27-1.x86_64 marks php73-common-7.3.27-1.x86_64 (cap >> libphp_common-7.3.27.so()(64bit))// >> //There are 3 packages to install (2 marked by dependencies):// >> //A php73-cli-7.3.27-1.x86_64 php73-common-7.3.27-1.x86_64 >> php73-program-7.3.27-1.x86_64// >> //This operation will use 4.2MB of disk space.// >> //Need to get 1.2MB of archives.// >> //php73-common-7.3.27-1.x86_64.rpm: digests OK// >> //php73-cli-7.3.27-1.x86_64.rpm: digests OK// >> //php73-program-7.3.27-1.x86_64.rpm: digests OK// >> //Executing pm-command.sh --upgrade -vh --root / --define >> _check_dirname_deps 0...// >> //Verifying... ################################# [100%]// >> //Preparing... ################################# [100%]// >> // file /usr/bin/php from install of >> php73-program-4:7.3.27-1.x86_64 conflicts with file from package >> php74-program-4:7.4.19-1.1.x86_64// >> // file /usr/share/man/man1/php.1 from install of >> php73-program-4:7.3.27-1.x86_64 conflicts with file from package >> php74-program-4:7.4.19-1.1.x86_64// >> //There were errors// >> //poldek:/all-avail>/ >> >> To keep what we had with rpm5 , we either need to patch rpm, or add 11 >> (as of today) Obsoletes: php${ver}-program lines to each spec. > RPM supports using Provides+Conflicts to represent this issue. > > Provides: php-interpreter > Conflicts: php-interpreter > > When this is set, RPM knows that one and only one implementation > providing "php-interpreter" is permitted and permits swapping them. Nope, this does seem to not work like that: [adamg at pld-xcp-ng RPMS]$ rpm -q --provides php80-program php-interpreter php80-program = 4:8.0.6-1.2 php80-program(x86-64) = 4:8.0.6-1.2 [adamg at pld-xcp-ng RPMS]$ rpm -q --conflicts php80-program php-interpreter [adamg at pld-xcp-ng RPMS]$ rpm -qp --provides php74-program-7.4.19-1.2.x86_64.rpm php-interpreter php74-program = 4:7.4.19-1.2 php74-program(x86-64) = 4:7.4.19-1.2 [adamg at pld-xcp-ng RPMS]$ rpm -qp --conflicts php74-program-7.4.19-1.2.x86_64.rpm php-interpreter [adamg at pld-xcp-ng RPMS]$ rpm -Uhv php74-program-7.4.19-1.2.x86_64.rpm error: Failed dependencies: ??????? php-interpreter conflicts with php74-program-4:7.4.19-1.2.x86_64 ??????? php-interpreter conflicts with (installed) php80-program-4:8.0.6-1.2.x86_64 [adamg at pld-xcp-ng RPMS]$ From ngompa13 at gmail.com Sat May 15 17:44:06 2021 From: ngompa13 at gmail.com (Neal Gompa) Date: Sat, 15 May 2021 11:44:06 -0400 Subject: [packages/php] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti In-Reply-To: <6d294616-196b-30df-3ea9-0b3540ff5c1a@pld-linux.org> References: <45629e6e9bbed84edb75f9580aabea932a696556_refs_heads_master@pld-linux.org> <7abe966b-82fc-34ca-dab4-3a9d2d30c8a0@pld-linux.org> <1e4cea34-dcec-7973-612b-27fc4b731a77@pld-linux.org> <6ad60723-b18e-edf4-745f-53cc492e2206@pld-linux.org> <6d294616-196b-30df-3ea9-0b3540ff5c1a@pld-linux.org> Message-ID: On Sat, May 15, 2021 at 10:41 AM Adam Go??biowski wrote: > > > W dniu 2021-05-15 o 15:26, Neal Gompa pisze: > > On Sat, May 15, 2021 at 6:23 AM Adam Go??biowski wrote: > >> > >> W dniu 2021-05-15 o 11:52, Neal Gompa pisze: > >>> On Sat, May 15, 2021 at 5:38 AM Adam Go??biowski wrote: > >>>> W dniu 2021-05-13 o 21:32, Elan Ruusam?e pisze: > >>>> > >>>>> point of that guard was to wait for support to become available or > >>>>> someone implement a solution. > >>>>> (...) > >>>>> but as no such solution as provided, you need to update obsoletes to > >>>>> fill **all** package names that provide that file path. > >>>>> > >>>>> I refuse to do that myself as it's pretty stupid. > >>>> ugly, for sure, but unless we come up with another solution (patching > >>>> rpm to support Obsoletes: /path), we will need to maintain 11 Obsoletes: > >>>> lines per package ... > >>>> > >>> What problem are you trying to solve here? I'm not sure I understand > >>> why you're doing this. > >> Each of the php*-program packages provide /usr/bin/php symlink: > >> > >> /poldek:/all-avail> install phpcs////Processing dependencies...////phpcs-3.4.1-2.noarch: required "/usr/bin/php" is provided by the > >> following packages:////a) php4-program-4.4.9-67.x86_64////b) php52-program-5.2.17-20130717.35.x86_64////c) php53-program-5.3.29-52.x86_64////d) php54-program-5.4.45-30.x86_64////e) php55-program-5.5.38-22.x86_64////f) php56-program-5.6.40-9.x86_64////g) php70-program-7.0.33-8.x86_64////h) php71-program-7.1.33-3.x86_64////i) php72-program-7.2.34-1.x86_64////j) php73-program-7.3.24-1.x86_64////k) php74-program-7.4.12-2.x86_64////l) php80-program-8.0.0-2.x86_64////Which one do you want to install ('Q' to abort)? > >> [php4-program-4.4.9-67.x86_64]/ > >> > >> > >> > >> Prior to rpm switch, each of those packages also had Obsoletes: /usr/bin/php so that you could easily switch the provider of /usr/bin/php symlinkL > >> /poldek:/all-avail> install php80-program-8.0.0-2.x86_64/// > >> > >> /Loading [pndir]th-2020-updates... > >> Loading [pndir]th-2020-updates... > >> Loading [pndir]th-2020... > >> Loading [pndir]th-2020... > >> 29952 packages read > >> Processing dependencies... > >> php80-program-8.0.0-2.x86_64 marks php80-cli-8.0.0-2.x86_64 (cap > >> php80-cli = 4:8.0.0-2) > >> php80-cli-8.0.0-2.x86_64 marks php80-common-8.0.0-2.x86_64 (cap > >> /etc/php80) > >> There are 3 packages to install (2 marked by dependencies): > >> A php80-cli-8.0.0-2.x86_64 php80-common-8.0.0-2.x86_64 > >> php80-program-8.0.0-2.x86_64 > >> This operation will use 4.6MB of disk space. > >> Need to get 1.4MB of archives (1.4MB to download). > >> > >> [1/3] th-2020::php80-common-8.0.0-2.x86_64.rpm [1.4M (1.4M/s)] > >> [2/3] th-2020::php80-cli-8.0.0-2.x86_64.rpm [51.7K (51.7K/s)] > >> [3/3] th-2020::php80-program-8.0.0-2.x86_64.rpm [5.0K (5.0K/s)] > >> Executing pm-command.sh --upgrade -vh --root / --define > >> _check_dirname_deps 1... > >> error: failed to open /etc/mtab: No such file or directory > >> Preparing... ########################################### [100%] > >> Repackaging... > >> 1:php72-program ########################################### [100%] > >> Upgrading... > >> 1:php80-common ########################################### [ 33%] > >> 2:php80-cli ########################################### [ 67%] > >> 3:php80-program ########################################### [100%] > >> poldek:/all-avail>/ > >> > >> > >> But rpm-4 no longer allows / in Obsoletes: > >> > >> /Illegal char '/' (0x2f) in: Obsoletes: /usr/bin/php / > >> > >> Which makes this smooth transition no longer possible: > >> > >> /poldek:/all-avail> install php73-program-7.3.27-1.x86_64// > >> //Processing dependencies...// > >> //php73-program-7.3.27-1.x86_64 marks php73-cli-7.3.27-1.x86_64 (cap > >> php73-cli = 4:7.3.27-1)// > >> // php73-cli-7.3.27-1.x86_64 marks php73-common-7.3.27-1.x86_64 (cap > >> libphp_common-7.3.27.so()(64bit))// > >> //There are 3 packages to install (2 marked by dependencies):// > >> //A php73-cli-7.3.27-1.x86_64 php73-common-7.3.27-1.x86_64 > >> php73-program-7.3.27-1.x86_64// > >> //This operation will use 4.2MB of disk space.// > >> //Need to get 1.2MB of archives.// > >> //php73-common-7.3.27-1.x86_64.rpm: digests OK// > >> //php73-cli-7.3.27-1.x86_64.rpm: digests OK// > >> //php73-program-7.3.27-1.x86_64.rpm: digests OK// > >> //Executing pm-command.sh --upgrade -vh --root / --define > >> _check_dirname_deps 0...// > >> //Verifying... ################################# [100%]// > >> //Preparing... ################################# [100%]// > >> // file /usr/bin/php from install of > >> php73-program-4:7.3.27-1.x86_64 conflicts with file from package > >> php74-program-4:7.4.19-1.1.x86_64// > >> // file /usr/share/man/man1/php.1 from install of > >> php73-program-4:7.3.27-1.x86_64 conflicts with file from package > >> php74-program-4:7.4.19-1.1.x86_64// > >> //There were errors// > >> //poldek:/all-avail>/ > >> > >> To keep what we had with rpm5 , we either need to patch rpm, or add 11 > >> (as of today) Obsoletes: php${ver}-program lines to each spec. > > RPM supports using Provides+Conflicts to represent this issue. > > > > Provides: php-interpreter > > Conflicts: php-interpreter > > > > When this is set, RPM knows that one and only one implementation > > providing "php-interpreter" is permitted and permits swapping them. > > Nope, this does seem to not work like that: > > [adamg at pld-xcp-ng RPMS]$ rpm -q --provides php80-program > php-interpreter > php80-program = 4:8.0.6-1.2 > php80-program(x86-64) = 4:8.0.6-1.2 > [adamg at pld-xcp-ng RPMS]$ rpm -q --conflicts php80-program > php-interpreter > [adamg at pld-xcp-ng RPMS]$ rpm -qp --provides > php74-program-7.4.19-1.2.x86_64.rpm > php-interpreter > php74-program = 4:7.4.19-1.2 > php74-program(x86-64) = 4:7.4.19-1.2 > [adamg at pld-xcp-ng RPMS]$ rpm -qp --conflicts > php74-program-7.4.19-1.2.x86_64.rpm > php-interpreter > [adamg at pld-xcp-ng RPMS]$ rpm -Uhv php74-program-7.4.19-1.2.x86_64.rpm > error: Failed dependencies: > php-interpreter conflicts with php74-program-4:7.4.19-1.2.x86_64 > php-interpreter conflicts with (installed) > php80-program-4:8.0.6-1.2.x86_64 > [adamg at pld-xcp-ng RPMS]$ > It should be supported, it was introduced in RPM 4.9: https://rpm.org/wiki/Releases/4.9.0 Are we patching RPM in a way to break it? -- ?????????/ Always, there's only one truth! From atler at pld-linux.org Sat May 15 18:08:42 2021 From: atler at pld-linux.org (Jan Palus) Date: Sat, 15 May 2021 18:08:42 +0200 Subject: [packages/php] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti In-Reply-To: References: <45629e6e9bbed84edb75f9580aabea932a696556_refs_heads_master@pld-linux.org> <7abe966b-82fc-34ca-dab4-3a9d2d30c8a0@pld-linux.org> <1e4cea34-dcec-7973-612b-27fc4b731a77@pld-linux.org> <6ad60723-b18e-edf4-745f-53cc492e2206@pld-linux.org> <6d294616-196b-30df-3ea9-0b3540ff5c1a@pld-linux.org> Message-ID: <20210515160842.xrkr7kxfyf5eoxrr@pine> On 15.05.2021 11:44, Neal Gompa wrote: > On Sat, May 15, 2021 at 10:41 AM Adam Go??biowski wrote: > > > > > > W dniu 2021-05-15 o 15:26, Neal Gompa pisze: > > > On Sat, May 15, 2021 at 6:23 AM Adam Go??biowski wrote: > > >> > > >> W dniu 2021-05-15 o 11:52, Neal Gompa pisze: > > >>> On Sat, May 15, 2021 at 5:38 AM Adam Go??biowski wrote: > > >>>> W dniu 2021-05-13 o 21:32, Elan Ruusam?e pisze: > > >>>> > > >>>>> point of that guard was to wait for support to become available or > > >>>>> someone implement a solution. > > >>>>> (...) > > >>>>> but as no such solution as provided, you need to update obsoletes to > > >>>>> fill **all** package names that provide that file path. > > >>>>> > > >>>>> I refuse to do that myself as it's pretty stupid. > > >>>> ugly, for sure, but unless we come up with another solution (patching > > >>>> rpm to support Obsoletes: /path), we will need to maintain 11 Obsoletes: > > >>>> lines per package ... > > >>>> > > >>> What problem are you trying to solve here? I'm not sure I understand > > >>> why you're doing this. > > >> Each of the php*-program packages provide /usr/bin/php symlink: > > >> > > >> /poldek:/all-avail> install phpcs////Processing dependencies...////phpcs-3.4.1-2.noarch: required "/usr/bin/php" is provided by the > > >> following packages:////a) php4-program-4.4.9-67.x86_64////b) php52-program-5.2.17-20130717.35.x86_64////c) php53-program-5.3.29-52.x86_64////d) php54-program-5.4.45-30.x86_64////e) php55-program-5.5.38-22.x86_64////f) php56-program-5.6.40-9.x86_64////g) php70-program-7.0.33-8.x86_64////h) php71-program-7.1.33-3.x86_64////i) php72-program-7.2.34-1.x86_64////j) php73-program-7.3.24-1.x86_64////k) php74-program-7.4.12-2.x86_64////l) php80-program-8.0.0-2.x86_64////Which one do you want to install ('Q' to abort)? > > >> [php4-program-4.4.9-67.x86_64]/ > > >> > > >> > > >> > > >> Prior to rpm switch, each of those packages also had Obsoletes: /usr/bin/php so that you could easily switch the provider of /usr/bin/php symlinkL > > >> /poldek:/all-avail> install php80-program-8.0.0-2.x86_64/// > > >> > > >> /Loading [pndir]th-2020-updates... > > >> Loading [pndir]th-2020-updates... > > >> Loading [pndir]th-2020... > > >> Loading [pndir]th-2020... > > >> 29952 packages read > > >> Processing dependencies... > > >> php80-program-8.0.0-2.x86_64 marks php80-cli-8.0.0-2.x86_64 (cap > > >> php80-cli = 4:8.0.0-2) > > >> php80-cli-8.0.0-2.x86_64 marks php80-common-8.0.0-2.x86_64 (cap > > >> /etc/php80) > > >> There are 3 packages to install (2 marked by dependencies): > > >> A php80-cli-8.0.0-2.x86_64 php80-common-8.0.0-2.x86_64 > > >> php80-program-8.0.0-2.x86_64 > > >> This operation will use 4.6MB of disk space. > > >> Need to get 1.4MB of archives (1.4MB to download). > > >> > > >> [1/3] th-2020::php80-common-8.0.0-2.x86_64.rpm [1.4M (1.4M/s)] > > >> [2/3] th-2020::php80-cli-8.0.0-2.x86_64.rpm [51.7K (51.7K/s)] > > >> [3/3] th-2020::php80-program-8.0.0-2.x86_64.rpm [5.0K (5.0K/s)] > > >> Executing pm-command.sh --upgrade -vh --root / --define > > >> _check_dirname_deps 1... > > >> error: failed to open /etc/mtab: No such file or directory > > >> Preparing... ########################################### [100%] > > >> Repackaging... > > >> 1:php72-program ########################################### [100%] > > >> Upgrading... > > >> 1:php80-common ########################################### [ 33%] > > >> 2:php80-cli ########################################### [ 67%] > > >> 3:php80-program ########################################### [100%] > > >> poldek:/all-avail>/ > > >> > > >> > > >> But rpm-4 no longer allows / in Obsoletes: > > >> > > >> /Illegal char '/' (0x2f) in: Obsoletes: /usr/bin/php / > > >> > > >> Which makes this smooth transition no longer possible: > > >> > > >> /poldek:/all-avail> install php73-program-7.3.27-1.x86_64// > > >> //Processing dependencies...// > > >> //php73-program-7.3.27-1.x86_64 marks php73-cli-7.3.27-1.x86_64 (cap > > >> php73-cli = 4:7.3.27-1)// > > >> // php73-cli-7.3.27-1.x86_64 marks php73-common-7.3.27-1.x86_64 (cap > > >> libphp_common-7.3.27.so()(64bit))// > > >> //There are 3 packages to install (2 marked by dependencies):// > > >> //A php73-cli-7.3.27-1.x86_64 php73-common-7.3.27-1.x86_64 > > >> php73-program-7.3.27-1.x86_64// > > >> //This operation will use 4.2MB of disk space.// > > >> //Need to get 1.2MB of archives.// > > >> //php73-common-7.3.27-1.x86_64.rpm: digests OK// > > >> //php73-cli-7.3.27-1.x86_64.rpm: digests OK// > > >> //php73-program-7.3.27-1.x86_64.rpm: digests OK// > > >> //Executing pm-command.sh --upgrade -vh --root / --define > > >> _check_dirname_deps 0...// > > >> //Verifying... ################################# [100%]// > > >> //Preparing... ################################# [100%]// > > >> // file /usr/bin/php from install of > > >> php73-program-4:7.3.27-1.x86_64 conflicts with file from package > > >> php74-program-4:7.4.19-1.1.x86_64// > > >> // file /usr/share/man/man1/php.1 from install of > > >> php73-program-4:7.3.27-1.x86_64 conflicts with file from package > > >> php74-program-4:7.4.19-1.1.x86_64// > > >> //There were errors// > > >> //poldek:/all-avail>/ > > >> > > >> To keep what we had with rpm5 , we either need to patch rpm, or add 11 > > >> (as of today) Obsoletes: php${ver}-program lines to each spec. > > > RPM supports using Provides+Conflicts to represent this issue. > > > > > > Provides: php-interpreter > > > Conflicts: php-interpreter > > > > > > When this is set, RPM knows that one and only one implementation > > > providing "php-interpreter" is permitted and permits swapping them. > > > > Nope, this does seem to not work like that: > > > > [adamg at pld-xcp-ng RPMS]$ rpm -q --provides php80-program > > php-interpreter > > php80-program = 4:8.0.6-1.2 > > php80-program(x86-64) = 4:8.0.6-1.2 > > [adamg at pld-xcp-ng RPMS]$ rpm -q --conflicts php80-program > > php-interpreter > > [adamg at pld-xcp-ng RPMS]$ rpm -qp --provides > > php74-program-7.4.19-1.2.x86_64.rpm > > php-interpreter > > php74-program = 4:7.4.19-1.2 > > php74-program(x86-64) = 4:7.4.19-1.2 > > [adamg at pld-xcp-ng RPMS]$ rpm -qp --conflicts > > php74-program-7.4.19-1.2.x86_64.rpm > > php-interpreter > > [adamg at pld-xcp-ng RPMS]$ rpm -Uhv php74-program-7.4.19-1.2.x86_64.rpm > > error: Failed dependencies: > > php-interpreter conflicts with php74-program-4:7.4.19-1.2.x86_64 > > php-interpreter conflicts with (installed) > > php80-program-4:8.0.6-1.2.x86_64 > > [adamg at pld-xcp-ng RPMS]$ > > > > It should be supported, it was introduced in RPM 4.9: > https://rpm.org/wiki/Releases/4.9.0 > > Are we patching RPM in a way to break it? Just checked in fedora container and it behaves exactly the same way there. I've even rebuilt packages with fedora's rpmbuild to be sure. From ngompa13 at gmail.com Sat May 15 18:10:36 2021 From: ngompa13 at gmail.com (Neal Gompa) Date: Sat, 15 May 2021 12:10:36 -0400 Subject: [packages/php] - drop if clause introduced in commit 20dcadbb (guard clause for rpm 4.16), we have fully transiti In-Reply-To: <20210515160842.xrkr7kxfyf5eoxrr@pine> References: <45629e6e9bbed84edb75f9580aabea932a696556_refs_heads_master@pld-linux.org> <7abe966b-82fc-34ca-dab4-3a9d2d30c8a0@pld-linux.org> <1e4cea34-dcec-7973-612b-27fc4b731a77@pld-linux.org> <6ad60723-b18e-edf4-745f-53cc492e2206@pld-linux.org> <6d294616-196b-30df-3ea9-0b3540ff5c1a@pld-linux.org> <20210515160842.xrkr7kxfyf5eoxrr@pine> Message-ID: On Sat, May 15, 2021 at 12:08 PM Jan Palus wrote: > > On 15.05.2021 11:44, Neal Gompa wrote: > > On Sat, May 15, 2021 at 10:41 AM Adam Go??biowski wrote: > > > > > > > > > W dniu 2021-05-15 o 15:26, Neal Gompa pisze: > > > > On Sat, May 15, 2021 at 6:23 AM Adam Go??biowski wrote: > > > >> > > > >> W dniu 2021-05-15 o 11:52, Neal Gompa pisze: > > > >>> On Sat, May 15, 2021 at 5:38 AM Adam Go??biowski wrote: > > > >>>> W dniu 2021-05-13 o 21:32, Elan Ruusam?e pisze: > > > >>>> > > > >>>>> point of that guard was to wait for support to become available or > > > >>>>> someone implement a solution. > > > >>>>> (...) > > > >>>>> but as no such solution as provided, you need to update obsoletes to > > > >>>>> fill **all** package names that provide that file path. > > > >>>>> > > > >>>>> I refuse to do that myself as it's pretty stupid. > > > >>>> ugly, for sure, but unless we come up with another solution (patching > > > >>>> rpm to support Obsoletes: /path), we will need to maintain 11 Obsoletes: > > > >>>> lines per package ... > > > >>>> > > > >>> What problem are you trying to solve here? I'm not sure I understand > > > >>> why you're doing this. > > > >> Each of the php*-program packages provide /usr/bin/php symlink: > > > >> > > > >> /poldek:/all-avail> install phpcs////Processing dependencies...////phpcs-3.4.1-2.noarch: required "/usr/bin/php" is provided by the > > > >> following packages:////a) php4-program-4.4.9-67.x86_64////b) php52-program-5.2.17-20130717.35.x86_64////c) php53-program-5.3.29-52.x86_64////d) php54-program-5.4.45-30.x86_64////e) php55-program-5.5.38-22.x86_64////f) php56-program-5.6.40-9.x86_64////g) php70-program-7.0.33-8.x86_64////h) php71-program-7.1.33-3.x86_64////i) php72-program-7.2.34-1.x86_64////j) php73-program-7.3.24-1.x86_64////k) php74-program-7.4.12-2.x86_64////l) php80-program-8.0.0-2.x86_64////Which one do you want to install ('Q' to abort)? > > > >> [php4-program-4.4.9-67.x86_64]/ > > > >> > > > >> > > > >> > > > >> Prior to rpm switch, each of those packages also had Obsoletes: /usr/bin/php so that you could easily switch the provider of /usr/bin/php symlinkL > > > >> /poldek:/all-avail> install php80-program-8.0.0-2.x86_64/// > > > >> > > > >> /Loading [pndir]th-2020-updates... > > > >> Loading [pndir]th-2020-updates... > > > >> Loading [pndir]th-2020... > > > >> Loading [pndir]th-2020... > > > >> 29952 packages read > > > >> Processing dependencies... > > > >> php80-program-8.0.0-2.x86_64 marks php80-cli-8.0.0-2.x86_64 (cap > > > >> php80-cli = 4:8.0.0-2) > > > >> php80-cli-8.0.0-2.x86_64 marks php80-common-8.0.0-2.x86_64 (cap > > > >> /etc/php80) > > > >> There are 3 packages to install (2 marked by dependencies): > > > >> A php80-cli-8.0.0-2.x86_64 php80-common-8.0.0-2.x86_64 > > > >> php80-program-8.0.0-2.x86_64 > > > >> This operation will use 4.6MB of disk space. > > > >> Need to get 1.4MB of archives (1.4MB to download). > > > >> > > > >> [1/3] th-2020::php80-common-8.0.0-2.x86_64.rpm [1.4M (1.4M/s)] > > > >> [2/3] th-2020::php80-cli-8.0.0-2.x86_64.rpm [51.7K (51.7K/s)] > > > >> [3/3] th-2020::php80-program-8.0.0-2.x86_64.rpm [5.0K (5.0K/s)] > > > >> Executing pm-command.sh --upgrade -vh --root / --define > > > >> _check_dirname_deps 1... > > > >> error: failed to open /etc/mtab: No such file or directory > > > >> Preparing... ########################################### [100%] > > > >> Repackaging... > > > >> 1:php72-program ########################################### [100%] > > > >> Upgrading... > > > >> 1:php80-common ########################################### [ 33%] > > > >> 2:php80-cli ########################################### [ 67%] > > > >> 3:php80-program ########################################### [100%] > > > >> poldek:/all-avail>/ > > > >> > > > >> > > > >> But rpm-4 no longer allows / in Obsoletes: > > > >> > > > >> /Illegal char '/' (0x2f) in: Obsoletes: /usr/bin/php / > > > >> > > > >> Which makes this smooth transition no longer possible: > > > >> > > > >> /poldek:/all-avail> install php73-program-7.3.27-1.x86_64// > > > >> //Processing dependencies...// > > > >> //php73-program-7.3.27-1.x86_64 marks php73-cli-7.3.27-1.x86_64 (cap > > > >> php73-cli = 4:7.3.27-1)// > > > >> // php73-cli-7.3.27-1.x86_64 marks php73-common-7.3.27-1.x86_64 (cap > > > >> libphp_common-7.3.27.so()(64bit))// > > > >> //There are 3 packages to install (2 marked by dependencies):// > > > >> //A php73-cli-7.3.27-1.x86_64 php73-common-7.3.27-1.x86_64 > > > >> php73-program-7.3.27-1.x86_64// > > > >> //This operation will use 4.2MB of disk space.// > > > >> //Need to get 1.2MB of archives.// > > > >> //php73-common-7.3.27-1.x86_64.rpm: digests OK// > > > >> //php73-cli-7.3.27-1.x86_64.rpm: digests OK// > > > >> //php73-program-7.3.27-1.x86_64.rpm: digests OK// > > > >> //Executing pm-command.sh --upgrade -vh --root / --define > > > >> _check_dirname_deps 0...// > > > >> //Verifying... ################################# [100%]// > > > >> //Preparing... ################################# [100%]// > > > >> // file /usr/bin/php from install of > > > >> php73-program-4:7.3.27-1.x86_64 conflicts with file from package > > > >> php74-program-4:7.4.19-1.1.x86_64// > > > >> // file /usr/share/man/man1/php.1 from install of > > > >> php73-program-4:7.3.27-1.x86_64 conflicts with file from package > > > >> php74-program-4:7.4.19-1.1.x86_64// > > > >> //There were errors// > > > >> //poldek:/all-avail>/ > > > >> > > > >> To keep what we had with rpm5 , we either need to patch rpm, or add 11 > > > >> (as of today) Obsoletes: php${ver}-program lines to each spec. > > > > RPM supports using Provides+Conflicts to represent this issue. > > > > > > > > Provides: php-interpreter > > > > Conflicts: php-interpreter > > > > > > > > When this is set, RPM knows that one and only one implementation > > > > providing "php-interpreter" is permitted and permits swapping them. > > > > > > Nope, this does seem to not work like that: > > > > > > [adamg at pld-xcp-ng RPMS]$ rpm -q --provides php80-program > > > php-interpreter > > > php80-program = 4:8.0.6-1.2 > > > php80-program(x86-64) = 4:8.0.6-1.2 > > > [adamg at pld-xcp-ng RPMS]$ rpm -q --conflicts php80-program > > > php-interpreter > > > [adamg at pld-xcp-ng RPMS]$ rpm -qp --provides > > > php74-program-7.4.19-1.2.x86_64.rpm > > > php-interpreter > > > php74-program = 4:7.4.19-1.2 > > > php74-program(x86-64) = 4:7.4.19-1.2 > > > [adamg at pld-xcp-ng RPMS]$ rpm -qp --conflicts > > > php74-program-7.4.19-1.2.x86_64.rpm > > > php-interpreter > > > [adamg at pld-xcp-ng RPMS]$ rpm -Uhv php74-program-7.4.19-1.2.x86_64.rpm > > > error: Failed dependencies: > > > php-interpreter conflicts with php74-program-4:7.4.19-1.2.x86_64 > > > php-interpreter conflicts with (installed) > > > php80-program-4:8.0.6-1.2.x86_64 > > > [adamg at pld-xcp-ng RPMS]$ > > > > > > > It should be supported, it was introduced in RPM 4.9: > > https://rpm.org/wiki/Releases/4.9.0 > > > > Are we patching RPM in a way to break it? > > Just checked in fedora container and it behaves exactly the same way > there. I've even rebuilt packages with fedora's rpmbuild to be sure. Oh, now I understand, you're not supposed to be able to use rpm -Uvh for it, because that's *upgrading*. You need to trigger an installation + removal in the same transaction (ie. "dnf swap" or "dnf install --allowerasing"). -- ?????????/ Always, there's only one truth! From atler at pld-linux.org Mon May 24 12:34:04 2021 From: atler at pld-linux.org (Jan Palus) Date: Mon, 24 May 2021 12:34:04 +0200 Subject: TEST build ERRORS: expat.spec In-Reply-To: References: <00f8fa86-5257-4b0d-b36d-a1f58fce7d75@pld.src.builder> Message-ID: <20210524103404.uzviiiqt77ucjm4i@pine> On 24.05.2021 10:12, PLD th-x86_64 builder wrote: .... > Processing dependencies... > There are 1 package to install: > A docbook2X-0.8.8-6.x86_64 > This operation will use 1.3MB of disk space. > docbook2X-0.8.8-6.x86_64.rpm: digests OK > Need to get 291.2KB of archives. > docbook2X-0.8.8-6.x86_64.rpm: digests OK > Executing pm-command.sh --upgrade -vh --root / --define _check_dirname_deps 0... > warning: /root/.poldek-cache/ftp_ep09.pld-linux.org.dists.th.PLD.x86.64.RPMS/docbook2X-0.8.8-6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID e4f1bc2d: NOKEY > error: Failed dependencies: > docbook2X is obsoleted by (installed) docbook-utils-0:0.6.14-5.noarch > error: BR installation failed Trying to use docbook-utils instead of docbook2X results in: configure: error: Your local docbook2man was found to work with SGML rather than XML. Please install docbook2X and use variable DOCBOOK_TO_MAN to point configure to command docbook2x-man of docbook2X. Or use DOCBOOK_TO_MAN="xmlto man --skip-validation" if you have xmlto around. You can also configure using --without-docbook if you can do without a man page for xmlwf. Does docbook-utils really _obsolete_ docbook2X? I think they've used to have conflicting files but that's no longer the case. From baggins at pld-linux.org Tue May 25 10:17:02 2021 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Tue, 25 May 2021 10:17:02 +0200 Subject: rust on x32 Message-ID: Hi, Could someone with rust build chain knowlegde look at rust on x32? My findings so far are that it does not build with target x86_64-...-gnux32, so we would have to build the compiler for x86_64 and just the stdlib for gnux32, the docs say that rust is a cross compiler by default... so, should be doable even without pulling binary x32 stdlib for bootstrapping. I'll give it a shot if no one beats me to it. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From glen at pld-linux.org Thu May 27 11:10:51 2021 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 27 May 2021 12:10:51 +0300 Subject: [packages/criu] reduce %{arm} applicability to armv7* In-Reply-To: <08b7a2abdfe17018095842d807c4b8745bc9561f_refs_heads_master@pld-linux.org> References: <3c9ca18c24cb913bee7148fe401d93540e484bd2_refs_heads_master@pld-linux.org> <08b7a2abdfe17018095842d807c4b8745bc9561f_refs_heads_master@pld-linux.org> Message-ID: <25182728-ad71-6195-4ca0-bfd1186cee95@pld-linux.org> On 26.05.2021 22:55, atler wrote: > commit 08b7a2abdfe17018095842d807c4b8745bc9561f > Author: Jan Palus > Date: Wed May 26 21:52:32 2021 +0200 > > reduce %{arm} applicability to armv7* > [snip] > -ExclusiveArch: %{x8664} %{arm} aarch64 ppc64 > +ExclusiveArch: %{x8664} armv7l armv7hl armv7hnl aarch64 ppc64 > BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n) > maybe good time to introduce %{arm6} and %{arm7} macros aside %{arm} macro? From j.rekorajski at gmail.com Thu May 27 17:05:18 2021 From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=) Date: Thu, 27 May 2021 17:05:18 +0200 Subject: [packages/rust] bump required libgit2 version In-Reply-To: <1f9b856019ac20736ccec408a735866922e0748a_refs_heads_master@pld-linux.org> References: <56b25e8bc40446e475e5ce1cd636fa945f156bf1_refs_heads_master@pld-linux.org> <1f9b856019ac20736ccec408a735866922e0748a_refs_heads_master@pld-linux.org> Message-ID: On Thu, May 27, 2021 at 4:19 PM atler wrote: > commit 1f9b856019ac20736ccec408a735866922e0748a > Author: Jan Palus > Date: Thu May 27 16:18:28 2021 +0200 > > bump required libgit2 version > > rust.spec | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > Please bump also rust to 1.52.1, there is some breakage in 1.52.0 -- Jan R?korajski | SysAdm | PLD/Linux | http://www.pld-linux.org/ bagginspld-linux.org From atler at pld-linux.org Thu May 27 17:25:42 2021 From: atler at pld-linux.org (Jan Palus) Date: Thu, 27 May 2021 17:25:42 +0200 Subject: [packages/rust] bump required libgit2 version In-Reply-To: References: <56b25e8bc40446e475e5ce1cd636fa945f156bf1_refs_heads_master@pld-linux.org> <1f9b856019ac20736ccec408a735866922e0748a_refs_heads_master@pld-linux.org> Message-ID: <20210527152542.grjdu2sxpexyjgvi@pine> On 27.05.2021 17:05, Jan R?korajski wrote: > On Thu, May 27, 2021 at 4:19 PM atler wrote: > > > commit 1f9b856019ac20736ccec408a735866922e0748a > > Author: Jan Palus > > Date: Thu May 27 16:18:28 2021 +0200 > > > > bump required libgit2 version > > > > rust.spec | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > Please bump also rust to 1.52.1, there is some breakage in 1.52.0 Will do once 1.52.0 is finally built successfully. Mentioned breakage is not that much concerning (shouldn't affect us): "These problems only affect incremental builds, release builds with Cargo should not be affected unless the user has explicitly opted into incremental. Debug and check builds are affected" From atler at pld-linux.org Fri May 28 00:44:56 2021 From: atler at pld-linux.org (Jan Palus) Date: Fri, 28 May 2021 00:44:56 +0200 Subject: rust on x32 In-Reply-To: References: Message-ID: <20210527224456.fhobii5fagvyaqt6@kalarepa> On 25.05.2021 10:17, Jan R?korajski wrote: > Hi, > > Could someone with rust build chain knowlegde look at rust on x32? > > My findings so far are that it does not build with target > x86_64-...-gnux32, so we would have to build the compiler for x86_64 and > just the stdlib for gnux32, the docs say that rust is a cross compiler by default... > so, should be doable even without pulling binary x32 stdlib for bootstrapping. > > I'll give it a shot if no one beats me to it. Working rust setup is currently hacked around on x32 builder which consists of both rust.x32 and rust.x86_64 installed side by side. Few remarks/thoughts: - rust 1.47 on x32 built x86_64 compiler with target support for both x86_64 and x32 (two directories under /usr/lib/rustlib) - rust 1.48 and higher appears to build x86_64 compiler with single target support: x32 - since parts of build process require building things for host (which is x86_64) it started to fail with "can't find crate for `std`" due to missing target for x86_64 - that's why installation of rust.x86_64 next to rust.x32 helped -- it provides x86_64 target support - I haven't noticed that x32 patch was left commented out so I guess it's not required anymore? As for solution not sure which one is least bad: 1. Just R: rust(x86-64) in rust(x86-x32) 2. Package just target support files and R: rust(x86-64) for the rest 3. Package target independently ie rust-target-x86_64 and require it in rust(x86-x32) 4. Other Happy to pass over decision and implementation to somebody else :). From atler at pld-linux.org Fri May 28 13:59:29 2021 From: atler at pld-linux.org (Jan Palus) Date: Fri, 28 May 2021 13:59:29 +0200 Subject: [packages/rust] - relax internal deps In-Reply-To: <89a1e043707dd595670e060055d7f14359d1f4d6_refs_heads_master@pld-linux.org> References: <89a1e043707dd595670e060055d7f14359d1f4d6_refs_heads_master@pld-linux.org> Message-ID: <20210528115929.ljamux4adzmurvig@pine> On 28.05.2021 12:30, baggins wrote: > commit 89a1e043707dd595670e060055d7f14359d1f4d6 > Author: Jan R?korajski > Date: Fri May 28 12:29:33 2021 +0200 > > - relax internal deps > > rust.spec | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > --- > @@ -204,7 +204,7 @@ Standardowa biblioteka Rusta. > Summary: Implementation of Language Server Protocol for Rust > Summary(pl.UTF-8): Implementacja Language Server Protocol dla Rusta > Group: Development/Tools > -Requires: %{name}%{?_isa} = %{version}-%{release} > +Requires: %{name} = %{version}-%{release} Note that *.so in /usr/lib/rustlib/ are symlinks to %{_libdir} so I suppose these should be packaged in rust-std as well in case of relaxed deps. Also *.so on x32 should probably be moved from /usr/libx32 to /usr/lib64 since they're not built for x32 ABI (no conflict with rust-std(x86-64) thanks to unique hash in each filename).