Hi,
I'm the upstream developer of libindi (http://indi.sf.net), and this library
is recommended for KStars in KDE 4.2 in order to add telescope control
functionality. Packages for OpenSUSE 11 and Factory are maintained in my
home project here:
https://build.opensuse.org/project/show?project=home%3Amutlaqja
The packages are:
+ libindi
+ libapogee
+ libfli
+ libnova
+ libcfitsio3
+ sbig
+ indi-sbig
+ indi-apogee
How can I request these packages to be added to the official OSS repo?
Best Regards,
Jasem Mutlaq
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
If you have a Factory package that you also package in a
backports repo, then there is the problem that the
suse_update_desktop_file will erase translations not
known to the old distribution.
First let me explain the way Factory translates:
1. spec files have %suse_update_desktop_file, which will
a) mark the desktop file for the translation process
b) update the desktop files against desktop-translations
2. collect-desktop-files is built against all packages
with desktop files, this will collect all _upstream_ translations
from the desktop files
3. Karl is updating the lcn SVN to merge the openSUSE translations
with the upstream translations (upstream translations win)
4. Karl submits new desktop-translations to start the process over
So this works for Factory pretty well and allows openSUSE to
a) update the translations - unknown translations can be
filled up
b) update translations by an online update - translations unknown
will be erased from the desktop files to allow GNOME and KDE to
look into dekstop_translations.mo file
But this creates a problem with backports as way more translations
will be unknown and hurting more than it helps.
Now my tip: osc linkpac home:coolo update-desktop-files <myproject>
and make sure it's disabled for Factory. This version is patched
not to care about translations, so you get 100% the upstream translations
and not less.
Greetings, Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
I don't understand why this build is a failure on Factory:
# osc rresults openSUSE:Tools obs-server
..
openSUSE_11.0 i586 succeeded
openSUSE_Factory i586 failed: https://api.opensuse.org/build/openSUSE:Tools/openSUSE_Factory/i586/obs-ser…
..
Any pointers appreciated.
S.
--
Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business
OPS Engineering Maxfeldstraße 5
Processes and Infrastructure Nürnberg
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
I currently have an issue with installation ordering of packages.
I had to move a gconf schema file from package A to package B.
Now that fails when A and B gets upgraded after this change because A
gets installed after B and the uninstall scripts of A remove the gconf
schema after package B would install the schema.
On RPM level I think I can fix that by PreReq like this:
Package A contains
Requires: package B
Package B contains
PreReq: package A
I think RPM would handle that correctly but zypper doesn't as it force
installs the packages.
How can I fix that? The gconf stuff is handled in the spec with the
existing macros as documented. (%posttrans)
Thanks,
Wolfgang
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
Looking at the packaging conventions, I didn't see any information for
creating devel packages, which is something rather... common :-) (or
maybe I missed the page about this)
It looks to me like all packages use different conventions for this,
while a standard pattern for summary and description would make sense.
Eg, a standard summary could be "Development files and libraries for
$package" and a standard description could be "Headers and libraries for
developing applications that use $something."
Also, right now, it's not clear to me if the group of the devel package
should be the same as the non-devel package or something like
Development/Libraries.
Any opinion?
Thanks,
Vincent
--
Les gens heureux ne sont pas pressés.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
All,
I was looking via: http://software.opensuse.org/search trough different
packages in OBS. I saw that there quite a few duplicate projects. Some
with identical new versions and some with old versions.
I saw there are also quite a few overlaps with the fwbuilder package that
I also have in OBS.
So I'm wondering if there is a way to consolidate packages in groups so
that more people can put effort in building packages and bundle their
knowledge to get the best out of it. Currently a lot of people put a lot
of time in "duplicate" packages.
I'm wondering wouldn't it be better to start for for instance fwbuilder a
security project that can be maintained by joined effort of people? In
that way more package can be maintained in OBS I think?
If this option if feaseble what is the best way to accomplish this?
The project ofcourse needs to be created. Shall the individual OBS builder
contact the other OBS builder?
Regards,
Joop Boonen.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
I need to split of branding packages from splashy:
splashy-branding-upstream
splashy-branding-openSUSE
splashy-branding-SLED
The core splashy package requires a branding package to be
functional. However, the splashy-branding packages need a tool
(splashy_config) to set the actual theme when installed (%post), which is
in the core splashy package.
So, does anyone has a hint how to solve this?
Thanks,
Holger
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org