All,
I am working with the GEBC source and updating some of the autoconf/automake
files. Generating the files, I need to run
automake --add-missing
after autoconf to generate the missing ./compile file. I'd like to simply move
the --add-missing option into the configure.ac file (or similar) to avoid
having the separate call to automake. Current the only automake call in
configure.ac is:
AM_INIT_AUTOMAKE(gebc,1.07)
Where can I add the option so that autoconf generates any of the missing
files needed? The automake documentation describes AC_CONFIG_AUX_DIR as being
able to specify the default directory for the common files as described:
https://www.gnu.org/software/automake/manual/html_node/automake-Invocation.…https://www.gnu.org/software/automake/manual/html_node/Optional.html#Option…
But I'm still confused on whether and what I need to add to make this
happen? (I'm in no way an autotools expert). Anybody see an easy fix here?
--
David C. Rankin, J.D.,P.E.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello,
i'm trying [0] to convert the spec from [1] to allow having multiple
packages of godot [2] with different versions installed.
The first solution implements parallel installations where the user can
choose between multiple versions from his gui menu. These are not
affected by the following issue.
The second approach uses update-alternatives to manage different
installed branches and the admin has to configure which godot version
should (only) appear in the menu.
Therefore .desktop files of different versions managed by
update-alternatives are not installed directly in /usr/share/applications .
Otherwise each installed entry will show up in the menu.
Only one file exists at [3] and this is a link to [4],
managed by update-alternatives.
Problem is:
If admin switches version of godot with update-alternatives,
[3] is still the same link and no update of the desktop-files database
cache seems to be triggered.
Consequently the user will still see the previous .desktop file, what
might become critical if different .desktop files of godot start to
diverge between branches.
Does someone has an idea how to solve this?
Is there another packaged application with desktop files managed by
update-alternatives I can look at?
[0] https://build.opensuse.org/package/show/home:cunix:godot/godot
[1] https://build.opensuse.org/package/show/games/godot
[2] https://godotengine.org/
[3] /usr/share/applications/org.godotengine.Godot.desktop
[4] /etc/alternatives/org.godotengine.Godot.desktop
All the best,
cunix
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi all,
I've written a small utility that checks for files, symlinks and
directories on your system that are installed in the system directories
but are not owned by any package.
https://github.com/AdamMajer/rpmorphan
To compile this, all you need is rpm-devel and gcc.
Running on my Leap 15.1 system, it found quite a number of symlinks and
directories and files that are not owned by any package. For example,
/usr/lib64/libreoffice/share/config/images_sifr.zip
is installed by not owned by any libreoffice packages. There are also
number of files that install symlinks with update-alternatives but do
not actually own these symlinks. The correct method is to install these
as %ghost entries in the %files section.
More interestingly, rpm itself doesn't own its own files either.
/usr/lib/sysimage/rpm/.rpm.lock
/usr/lib/sysimage/rpm/Basenames
/usr/lib/sysimage/rpm/Conflictname
/usr/lib/sysimage/rpm/Dirnames
/usr/lib/sysimage/rpm/Enhancename
...
Overall, I've had 8592 orphaned files out of 231008 in my rpm database.
This means close to one in 25 files is not tracked!
Feedback welcome
- Adam
--
Adam Majer - amajer(a)suse.de
SUSE Software Solutions Germany GmbH
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
ppc has a limited list of packages defined in Factory:PowerPC prjconf
file (1) and scala package is in this list.
I do not know the rational for presence of a package in this list.
But looking at jobhistory it took hours to build scala for ppc !
compared to ppc64/ppc64le (2)
This is increasing the process completion of Factory:PowerPC project.
Could we remove scala package from ppc build ?
(1) https://build.opensuse.org/projects/openSUSE:Factory:PowerPC/prjconf
(2) jobhistory:
===
$osc jobhist openSUSE:Factory:PowerPC/scala standard ppc
time package reason code build time
2019-05-05 20:33:06 scala new build succeeded 1d 4h 13m 24s
2019-06-23 12:10:55 scala new build succeeded 17h 52m 0s
2019-07-31 09:38:04 scala new build succeeded 18h 0m 31s
2019-09-05 22:01:25 scala rebuild counter failed 6h 53m 51s
2019-12-03 11:47:13 scala source change failed 5m 52s
===
$osc jobhist openSUSE:Factory:PowerPC/scala standard ppc64le
time package reason code build time
2019-03-29 00:46:41 scala new build succeeded 1h 9m 47s
2019-06-22 19:36:49 scala new build succeeded 43m 34s
2019-07-30 17:10:08 scala new build succeeded 54m 20s
2019-09-05 19:11:14 scala rebuild counter succeeded 43m 43s
2019-12-03 12:06:41 scala source change failed 1m 36s
2019-12-04 14:04:52 scala source change succeeded 29m 56s
===
--
Michel Normand
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hey,
I hope you find our new osc 0.167 release helpful (only in openSUSE:Tools project atm).
It should help you a lot when building inside of KVM environments, or
if you want to do a local build for arm/s390/ppc/riscv on your x86_64
workstation
Find details here:
https://openbuildservice.org/2019/12/05/osc-build-improvements/
Also CentOS 8 people should be happy to hear that local builds
using rpms out of RedHat's rpm-md modules are working now.
bye
adrian
--
Adrian Schroeter <adrian(a)suse.de>
Build Infrastructure Project Manager
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
(HRB 247165, AG München), Geschäftsführer: Felix Imendörffer
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org