openSUSE Packaging September 2010

packaging@lists.opensuse.org

46 participants
36 discussions

[opensuse-packaging] obs cheat sheet
by Andreas Jaeger 13 Sep '10

13 Sep '10

I've created a cheat sheet for OBS, you can download the pdf from http://en.opensuse.org/File:Obs-cheat-sheet.pdf If you want the odt or have correction, please email me. The file is supposed to be printed on two sides of a paper - and then cut the paper to A5 ;) Hope this is usefull, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj(a){novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

1 0

[opensuse-packaging] Package Descriptions
by Karl Eichwalder 13 Sep '10

13 Sep '10

By now, package descriptions are rather bewildered, and there is doubt about there formatting. Time ago, they were maintained in a separate database (PDB) and exported for yast and .spec files as needed. Now, we parse the .spec files to create something suitable for yast. Because many a lot \n\n (AKA empty lines) are gone, paragraphs and list items (= lines starting with "* ") run into one paragraph. How do we want to proceed with the package description formatting? -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 3

[opensuse-packaging] /usr/lib/rpm/brp-rootfs
by Peter Czanik 13 Sep '10

13 Sep '10

Hello, Is there any way to temporarily disable this check: + /usr/lib/rpm/brp-rootfs binary /sbin/syslog-ng is linked against libraries in /usr or /opt libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f0baa96b000) This is a know bug in syslog-ng 3.2 alpha, it will be fixed later on, but I'd like to go on with packaging and testing and not to wait another month or two... Bye, CzP -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 3

[opensuse-packaging] new subpackages in virtualbox-ose package
by Michal Šebeň 10 Sep '10

10 Sep '10

Hi all, I created for virtualbox-ose package three new subpackages : python-virtualbox-ose,virtualbox-ose-devel and virtualbox-ose-qt see bug report from Vincent: https://bugzilla.novell.com/show_bug.cgi?id=636858 - so now if you want to use vboxgtk (GUI interface written in python+GTK) you don't have to install qt dependent part (use zypper addlock virtualbox-ose-qt in this case) as I don't want to confuse users,and I suppose they expect QT interface after installation of virtualbox-ose package, so as a dependency between virtualbox-ose and virtualbox-ose-qt I used "Recommends" keyword (this should handle also update from 11.3 to 11.4): Name: virtualbox-ose ... Recommends: %{name}-qt = %version ... So by default virtualbox-ose installation will trigger also installation of virtualbox-ose-qt .... If someone comes with better idea how to split qt subpackage without confusing users I would be glad :) you could find modified package in Virtualization repo bye Michal -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 4

[opensuse-packaging] Package Markup / Package Tagging
by Dominique Leuenberger 10 Sep '10

10 Sep '10

Fellow packagers, I would like to start a discussion, hopefully resulting in a packaging policy regarding patches in our packages. Very often it is difficult to see in a package, when a patch was added, when it was modified, when disabled, and when deleted. In order to address all those questions, and some more, we would like to globally introduce (for Factory it might become mandatory; autobuild team is considering to enforce the rule), a new policy about this. It mainly consists of one additional line per patch added, the so-called patch markup line, in the .spec file. It looks similar to: # PATCH-FIX-UPSTREAM <packagename>-<whatdoIfix>.patch <bufrefs> <who> -- Description of the patch, possible source. The line is as simple as: - Type of Patch - Patch filename - Whom to address in case of questions re: the patch And a short description. This does not yet address the entire lifecycle of the patch. For this, every touched patch needs to be mentioned, by filename, in the .changes file. - Added patch-super1.patch - Rebased patch-super2.patch - Disabled patch-super1.patch due to API break. NEEDS REBASE - Drop patch-super1.patch, upstream fixed. Thanks to this, an entire story / life of any given patch file can be followed. A patch accidentally dropped is less likely to happen like this. Patches, that are flagged for rebase can be automatically identified and reported on. There is a wiki page explaining the various Types of patches at http://old-en.opensuse.org/Packaging/Patches Looking forward to have a lively, factical discussion going on around this subject. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

20 49

[opensuse-packaging] Can someone add me to devel:languages:perl?
by Stefan Seyfried 09 Sep '10

09 Sep '10

See $SUBJECT, I found a sponsor who needs some of the d:l:p modules (and some more, which will be of course contributed back). I found that most of the packages there are in a pitiable state, so I'd like to give them some love. So would someone add <person userid="seife" role="maintainer"/> please? Thanks, -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 5

[opensuse-packaging] Do we really need the gpm package (general purpose mouse for console)
by Andreas Jaeger 09 Sep '10

09 Sep '10

Does it still make sense to ship this package and compile our packages against it or should it get dropped? It's build required by the following packages: aalib brltty dialog installation-images loki_setup xemacs emacs ncurses vim mc and thus gets installed on each and every system. -- Andreas Jaeger, Program Manager openSUSE, aj(a){novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 7

[opensuse-packaging] make 3.82 - how to fix failing packages
by Matthias Hopf 08 Sep '10

08 Sep '10

make 3.82 has changed with respect to internal behavior quite a bit, and is getting more strict regarding POSIX compliancy. Thus a number of packages fail. make 3.82 is currently tested in openSUSE:Factory:Staging. The following shows the majority of typical errors, and how to fix them: *** mixed implicit and normal rules. Stop. In previous versions of make it was sometimes not flagged as an error for explicit and pattern targets to appear in the same rule. Now it's always an error. Example: busybox: config %config: scripts_basic outputmakefile FORCE Either the recipe has to be duplicated for both config and %config, or something like %onfig has to be used. Which is more hacky. *** missing separator. Stop. - Recipes with spaces instead of TABs, which were silently ignored before. E.g. in at-spi: install-data-local: if test -z "$(DESTDIR)" ; then \ Spaces were always illegal as command separator - use TABs. - You have an action with a space in its names. You need to put the action in a variable, escaping no longer works. Or rename files with spaces (ugh!) and use underscores like every good citizen. Or make sure that autmatic variable expansion is behaving nicely. E.g. in package kvm: gpxe-0.9.9/src/bin/deps/drivers/net/sis190.c.d: DRIVER_SiS 190 = sis190 - Broken Makefiles like for f-spot: dnl $(TRANSLATOR_EXTRACTOR_ASSEMBLY): TranslatorExtractor.cs dnl if [ "x$(top_srcdir)" = "x$(top_builddir)" ]; then \ I do not know why this ever worked, but it's clearly not Makefile syntax. I assume that an m4 run is missed or automake behaved differently before. Comment out lines in Makefiles with '#' instead. - There are also more complex cases, e.g. for dmidecode see http://savannah.nongnu.org/bugs/?30827 *** No rule to make target *, needed by *. Stop. - Rules using archive members, A(M) syntax. Known regression, make Savannah bug #30612. (Hopefully) fixed make is submitted. The other package failures are probably not related to the make update. HTH Matthias -- Matthias Hopf <mhopf(a)suse.de>, SuSE R&D, Zimmer 2.2.6, Tel. 74053-715 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 2

Re: Rebase Was: Re: [opensuse-packaging] Package Markup / Package Tagging
by Dominique Leuenberger 04 Sep '10

04 Sep '10

>>> On 09/04/2010 at 8:13 PM, "Sascha 'saigkill' Manns" <samannsml(a)directbox.com> wrote: > Hi Dominique, > > Am Saturday 04 September 2010 19:09:53 "Dominique Leuenberger" > <Dominique.Leuenberger(a)tmf-group.com> wrote: >> >>> On 09/04/2010 at 6:33 PM, "Sascha 'saigkill' Manns" >> >>> <samannsml(a)directbox.com> >> > >> > Have we any specs who i can see how it shows in reality? >> >> You can have a look at various packages in GNOME:Factory for example. >> >> GDM in Factory has various patches that are tagged as an exampple >> >> https://build.opensuse.org/package/view_file?file=gdm.spec&package=gd >> m&project=openSUSE%3AFactory&srcmd5=c00cf0ae22daaf2184b6451f70096282 > For me it looks very good. I'll planning to do that in my Packages too. > What is the difference between FIX-UPSTREAM and FIX-OPENSUSE? FIX-UPSTREAM: The fix is interesting and relevant for the upstream maintainers and should, and hopefully has already been, forwarded to the project team of this very source code. FIX-OPENSUSE: Those fixes/changes are relevant for openSUSE users or are not what upstream is interested in. Look at it like this: - UPSTREAM mean we should be able to get rid of the patch once again, when this fix/feature was implemented upstream - OPENSUSE: We'll probably keep the patch forever. Generally a bad thing and a pain for package uupdates. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

Re: [opensuse-packaging] Re: Python 2.7 coming to Factory
by yersinia 03 Sep '10

03 Sep '10

> you can fix this in two ways: > a) relink /usr/bin/python to /usr/bin/python2.6 and use python2.7 only > explicitly > > b) create a file /usr/lib64/python2.7/site-packages/python2.6.pth, with > one line: > /usr/lib/python2.6/site-packages > (yes, that's /usr/lib even for 64bit machine) > this way, you'll force python 2.7 interpreter to look for missing bits > in python2.6 directories. > applications with binary modules will still be broken and you'll need to > run the old interpreter, but noarch applications should be ok. > c) Follow this http://www.rpm.org/wiki/PackagerDocs/MultipleVersions and https://fedoraproject.org/wiki/Packaging/EnvironmentModules for a different way : i am using, not completed yet, mostly of this for having python 2.7 AND python 2.4 in RHEL5 as asked from a my client. Regards -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging September 2010