openSUSE Packaging November 2008

packaging@lists.opensuse.org

29 participants
18 discussions

by Olaf Hering

These packages look for a new maintainer. * compat-neon024 * cvs2svn * fxload * libavc1394 * libavc1394-0 * libavc1394-devel * libdc1394 * libdc1394-22 * libdc1394-devel * libdc1394_control12 * libdc1394_control12-devel * libraw1394 * libraw1394-8 * libraw1394-devel * libusb * libusb-devel * ltrace * ncpfs * ncpfs-devel * netatalk * netatalk-devel * netconsole-tools * quickcam * quickcam-KMP * sitecopy * subversion * subversion-devel * subversion-perl * subversion-python * subversion-server * subversion-tools * subversion-doc * usbutils * viewvc I think there are knobs in the pdb to change the maintainer and the home project, Just pick them up as needed. Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 2 months

[opensuse-packaging] Request to add packages to OSS

by Jasem Mutlaq

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

12 years, 2 months

[opensuse-packaging] Tips & Tricks: desktop files

by Stephan Kulow

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

12 years, 2 months

[opensuse-packaging] Why is this build a failure??

by Susanne Oberhauser

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

12 years, 2 months

[opensuse-packaging] installation order with libzypp

by Wolfgang Rosenauer

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

12 years, 2 months

[opensuse-packaging] Conventions for summary/description/group of devel packages?

by Vincent Untz

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

12 years, 2 months

[opensuse-packaging] Projects

by Joop Boonen

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

12 years, 2 months

[opensuse-packaging] Splitting up splashy, circular dependency

by Holger Macht

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

12 years, 2 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging November 2008