Dear listmembers, I am maintaining an application where I have to run two subsequent compilation processes to care for different screen resolutions. Now, here is my question: I have to apply a patch after the completion of th first compilation and after moving the first binary apart. Unfortunately I cannot do that from the very begin. There is a declaration Patch14: ABCD.patch but I cannot do a %patch14 in the %prep section because this would cause this patch to be effective from the start. Currently I am doing a patch -p0 < ../../SOURCES/ABCD.patch after the first build and after having moved the first binary away but within the %install section of the spec file. However I assume this is not the way it should be ... I mean, this works but I hope there is a more elegant way to get this done within the spec file. Any hints for me? Thank you very much, take care Dieter -- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe
On Wed, Jan 06, 2021 at 04:44:48PM +0100, Dr.-Ing. Dieter Jurzitza wrote:
Dear listmembers, I am maintaining an application where I have to run two subsequent compilation processes to care for different screen resolutions.
Now, here is my question: I have to apply a patch after the completion of th first compilation and after moving the first binary apart. Unfortunately I cannot do that from the very begin.
There is a declaration
Patch14: ABCD.patch
but I cannot do a %patch14 in the %prep section because this would cause this patch to be effective from the start.
Currently I am doing a
patch -p0 < ../../SOURCES/ABCD.patch
after the first build and after having moved the first binary away but within the %install section of the spec file. However I assume this is not the way it should be ... I mean, this works but I hope there is a more elegant way to get this done within the spec file.
Any hints for me?
You can reference the patch using %PATCH14 in the spec file. Otherwise it is okay to call patch itself there. patch -p0 < %PATCH14 Ciao, Marcus
Hello Marcus, sorry, no luck: make[1]: Leaving directory '/home/fred/rpmbuild/BUILD/tgif-QPL-4.2.5/po/ru' + /usr/lib/rpm/find-lang.sh /home/fred/rpmbuild/BUILDROOT/tgif-4.2.5- lp152.250.45.x86_64 tgif + cd .. + patch -p0 /var/tmp/rpm-tmp.WvFBLq: line 40: %Patch14: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.WvFBLq (%install) (the code in the spec - file was patch -p0 < %Patch14 as per your recommendation) seems as if the variable "%Patch14" is not accessible from within the %install section? Thanks again, take care Dieter Am Mittwoch, 6. Januar 2021, 17:04:01 CET schrieb Marcus Meissner:
On Wed, Jan 06, 2021 at 04:44:48PM +0100, Dr.-Ing. Dieter Jurzitza wrote:
Dear listmembers, I am maintaining an application where I have to run two subsequent compilation processes to care for different screen resolutions.
Now, here is my question: I have to apply a patch after the completion of th first compilation and after moving the first binary apart. Unfortunately I cannot do that from the very begin.
There is a declaration
Patch14: ABCD.patch
but I cannot do a %patch14 in the %prep section because this would cause this patch to be effective from the start.
Currently I am doing a
patch -p0 < ../../SOURCES/ABCD.patch
after the first build and after having moved the first binary away but within the %install section of the spec file. However I assume this is not the way it should be ... I mean, this works but I hope there is a more elegant way to get this done within the spec file.
Any hints for me?
You can reference the patch using %PATCH14 in the spec file. Otherwise it is okay to call patch itself there. patch -p0 < %PATCH14
Ciao, Marcus
-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe
On Wed 06 Jan 2021 05:16:47 PM CST, Dr.-Ing. Dieter Jurzitza wrote:
Hello Marcus, sorry, no luck:
make[1]: Leaving directory '/home/fred/rpmbuild/BUILD/tgif-QPL-4.2.5/po/ru' + /usr/lib/rpm/find-lang.sh /home/fred/rpmbuild/BUILDROOT/tgif-4.2.5- lp152.250.45.x86_64 tgif + cd .. + patch -p0 /var/tmp/rpm-tmp.WvFBLq: line 40: %Patch14: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.WvFBLq (%install)
(the code in the spec - file was patch -p0 < %Patch14 as per your recommendation)
seems as if the variable "%Patch14" is not accessible from within the %install section? <snip>
Hi Sources are available via %{S:nn} , perhaps %{P:14} will work.... -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) Tumbleweed 20210104 | GNOME Shell 3.38.2 | 5.10.4-1-default Intel DQ77MK MB | Xeon E3-1245 V2 X8 @ 3.40 GHz | Intel/Nvidia up 1 day 14:55, 2 users, load average: 4.12, 2.24, 1.65
Hello Malcolm, you made my day :-). Thank you for this hint, this works like a charm (however I'd say that this is not intuitive, but anyway). Thanks guys for helping, have a great start into the new year, take care Dieter Am Mittwoch, 6. Januar 2021, 17:44:48 CET schrieb Malcolm:
On Wed 06 Jan 2021 05:16:47 PM CST, Dr.-Ing. Dieter Jurzitza wrote:
Hello Marcus, sorry, no luck:
make[1]: Leaving directory '/home/fred/rpmbuild/BUILD/tgif-QPL-4.2.5/po/ru' + /usr/lib/rpm/find-lang.sh /home/fred/rpmbuild/BUILDROOT/tgif-4.2.5- lp152.250.45.x86_64 tgif + cd .. + patch -p0 /var/tmp/rpm-tmp.WvFBLq: line 40: %Patch14: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.WvFBLq (%install)
(the code in the spec - file was patch -p0 < %Patch14 as per your recommendation)
seems as if the variable "%Patch14" is not accessible from within the %install section?
<snip>
Hi Sources are available via %{S:nn} , perhaps %{P:14} will work....
-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe
Hi Dieter, On 06.01.21 17:16, Dr.-Ing. Dieter Jurzitza wrote:
+ patch -p0 /var/tmp/rpm-tmp.WvFBLq: line 40: %Patch14: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.WvFBLq (%install)
(the code in the spec - file was patch -p0 < %Patch14 as per your recommendation)
Marcus recommended %PATCH14
seems as if the variable "%Patch14" is not accessible from within the %install
I think there is no "%Patch14" variable available anywhere. Case matters ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 1/6/21 4:44 PM, Dr.-Ing. Dieter Jurzitza wrote:
Dear listmembers, I am maintaining an application where I have to run two subsequent compilation processes to care for different screen resolutions.
Now, here is my question: I have to apply a patch after the completion of th first compilation and after moving the first binary apart. Unfortunately I cannot do that from the very begin.
Make 3 different binary packages. One for each resolution and then the common one (the current binary package) that depends on the 2 special cases. The user just installs the main one and pulls in the 2 special cases. Maybe you can use _multibuild for various @BUILD_FLAVOR@ You could also name the actual package so we don't have to guess. - Adam
Hello Adam, thank you for your suggestion. However, I solved the issue differently: - I am building "tgif" standard resolution first and save the binary to tgif.Stdres - I am building "tgif" high resolution second and save the binary to tgif.Highres both tgif.Stdres and tgif.Highres are part of the original package. As a default a symlink tgif -> tgif.Stdres is generated. During installation of the package the installation scriptlett determins the resolution of the display. Depending on this information both the link /usr/ bin/tgif and the geometry - settings in /usr/share/X11/app-defaults/Tgif are adjusted accordingly. If the user decides to switch to a different display (having a different resolution) at any time he ca run a script called tgif-reconf. During this call the settings are adjusted - if the resolution reaches beyond 3000 points horizontally it switches to the high-res version. I consider this quite user-friendly, I hope my assumption is true, though :-) Take care Dieter Am Dienstag, 12. Januar 2021, 09:34:16 CET schrieb Adam Majer:
On 1/6/21 4:44 PM, Dr.-Ing. Dieter Jurzitza wrote:
Dear listmembers, I am maintaining an application where I have to run two subsequent compilation processes to care for different screen resolutions.
Now, here is my question: I have to apply a patch after the completion of th first compilation and after moving the first binary apart. Unfortunately I cannot do that from the very begin.
Make 3 different binary packages. One for each resolution and then the common one (the current binary package) that depends on the 2 special cases. The user just installs the main one and pulls in the 2 special cases.
Maybe you can use _multibuild for various @BUILD_FLAVOR@
You could also name the actual package so we don't have to guess.
- Adam
-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe
On 12.01.21 19:53, Dr.-Ing. Dieter Jurzitza wrote:
Hello Adam, thank you for your suggestion. However, I solved the issue differently:
- I am building "tgif" standard resolution first and save the binary to tgif.Stdres - I am building "tgif" high resolution second and save the binary to tgif.Highres
both tgif.Stdres and tgif.Highres are part of the original package. As a default a symlink tgif -> tgif.Stdres is generated.
During installation of the package the installation scriptlett determins the resolution of the display. Depending on this information both the link /usr/ bin/tgif and the geometry - settings in /usr/share/X11/app-defaults/Tgif are adjusted accordingly.
This (crazy ;-) hack only works if the user is logged in on the display that's used later to use the program. It does not work if you change to VT 1, log in as root and do "zypper in tgif" or "zypper dup", which is what I do often to avoid problems with crashing X servers during package updates leaving the update in a half-installed state. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Hello Stephan, if no X-server is running you will get standard resolution and standard configuration. If the X-server is "dead" the very same will happen. But this is a theoretical approach anyway as the program is not usable in this case. And no "ordinary" user will switch to the plain console mode IMHO any more. I would speculate that the "ordinary" user might even not be aware of keys like Strg-Alt-Fx ... If you want to know the gory details -> take a look into the spec file. Anyone having an idea on how to better support the user - tell me :-) By the way: if you run "tgif-reconf" afterwards (that said, being logged into a X-session) the appropriate settings matching your screen will get configured. At least such best-guess settings that provide an IMHO usable configuration to an unexperienced user. Anyone knowledgeable about direct editing of /usr/share/X11/app-defaults/Tgif and/or .Xdefaults-<HOSTNAME> can do so any time. But this will be a minority, I bet. Any suggestion on how to improve the behavior is very welcome. IMHO this is the best possible approach to support a user with not too much in-depth knowledge. Take care Dieter Am Mittwoch, 13. Januar 2021, 20:25:06 CET schrieb Stefan Seyfried:
On 12.01.21 19:53, Dr.-Ing. Dieter Jurzitza wrote:
Hello Adam, thank you for your suggestion. However, I solved the issue differently:
- I am building "tgif" standard resolution first and save the binary to tgif.Stdres - I am building "tgif" high resolution second and save the binary to tgif.Highres
both tgif.Stdres and tgif.Highres are part of the original package. As a default a symlink tgif -> tgif.Stdres is generated.
During installation of the package the installation scriptlett determins the resolution of the display. Depending on this information both the link /usr/ bin/tgif and the geometry - settings in /usr/share/X11/app-defaults/Tgif are adjusted accordingly.
This (crazy ;-) hack only works if the user is logged in on the display that's used later to use the program.
It does not work if you change to VT 1, log in as root and do "zypper in tgif" or "zypper dup", which is what I do often to avoid problems with crashing X servers during package updates leaving the update in a half-installed state.
-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe
Hello Andrew, thanks, this indeed would have worked - with one restriction: determining a "best guess" of the geometry settings will require additional efforts (like the way I did) in order to work properly. So, this would be a "yes and no" situation: yes, you can manage two (or more, but this does not apply here ...) different binaries and two different app- defaults - files. And no, it will not change the underlying problem that you need information regarding the screen size to determine appropriate parameters for the geometry setting in /usr/share/X11/app-defaults/Tgif .... and this is what IMHO had been questioned by Stefan .... Take care Dieter Am Mittwoch, 13. Januar 2021, 22:37:09 CET schrieb Andrew Daugherity:
On Jan 13, 2021, at 1:41 PM, Dr.-Ing. Dieter Jurzitza <dieter.jurzitza@t-online.de> wrote:
Anyone having an idea on how to better support the user - tell me :-)
Hmm, maybe the /etc/alternatives system would be useful here? There’s even a YaST module for managing it...
-Andrew
-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe
participants (6)
-
Adam Majer -
Andrew Daugherity -
Dr.-Ing. Dieter Jurzitza -
Malcolm -
Marcus Meissner -
Stefan Seyfried