openSUSE Packaging June 2009

packaging@lists.opensuse.org

43 participants
35 discussions

[opensuse-packaging] Build Service Project Cleanup Round

by Adrian Schröter

Hello, we got more than 6500 projects since the start of the opensuse.org Build Service instance (plus the projects which got removed again by their owners). These projects contain more than 13000 repositories, which get need to get in sync by our service. This takes obviously resources on the server side and quite a number of these projects are not touched since a while. So I assume they are not needed anymore. So I think it is a good idea to free the resources from these projects and give it to us active people :) This will basically affect all projects, where no source changes happened since 1 year or more. We have basically 961 "old projects" and further 2300 empty projects (no packages inside). A FAQ and a full list of "old projects" can be found here. Please speak up, when you think this is no propper approach or if you want to support this :) http://en.opensuse.org/Build_Service/Regular_Cleanup thanks adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years

[opensuse-packaging] Factory re-organization / Devel package of open-vm-tools

by Dominique Leuenberger

Hi everybody, I just verified where the devel package of open-vm-tools points, and the result is: </description> <devel package="open-vm-tools" project="Virtualization"/> <person userid="mlschroe" role="maintainer"/> </package> IIRC, so far we had it in Virtualization:VMware (Pavol could confirm for for sure if it's true or not). Is this change intentional? Does this mean that we now have 'first maintenance' in Virtualization:VMware (as we had so far) and we SR it against Virtualization every month (in average there is one release per month). Pavol, Michael, what's your intention/idea here? Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years

[opensuse-packaging] pre_checkin.sh and prepare_spec

by Marcus Rueckert

hi, in the past it was enough to copy your spec and tweak the name field. prepare_spec grabbed all other informations from the pdb and replaced the incorrect values for e.g. group/summary/description. this no longer happens and you have to take care in your pre_checkin.sh scripts or we need to find some kind of other replacement for this tracked under https://bugzilla.novell.com/show_bug.cgi?id=514928 with kind regards, darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years

[opensuse-packaging] looking for a workaround: library not found in configure script

by Werner Flamme

Hi, I try to package csync2 (http://oss.linbit.com/csync2/) and I got an annoying problem. When starting "osc build openSUSE_11.0 x86_64 csync2.spec" it starts to build the build-root and continues up to the %configure section. Here I get ---snip--- checking for SSL_new in -lgnutls-openssl... no configure: error: gnutls-openssl not found; install gnutls, gnutls-openssl and libtasn1 packages for your system or run configure with --disable-gnutls ---pins--- Hrmph. Nonsense. When I do (as root) "ln -s libgnutls-openssl.so.26 libgnutls-openssl.so" inside the %{_libdir}, everything works fine from then on (without using "ldconfig" manually). Unfortunately, I cannot put this line into the spec file since the package isn't built as root, and the "abuild" user has no rights to create the symlink. How can I work around this? Create a dummy package that creates the symlink in the %post section and that is required by the csync2 package? Regards, Werner -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years

[opensuse-packaging] Fixing --as-needed packages (was [opensuse-factory] status distribution)

by Cristian Morales Vega

coolo published a list of packages that fail to build with --as-needed at http://www.suse.de/~coolo/asneeded/ (see Factory ML for details), so I continue this in opensuse-packaging ML so people can say in which packages they are working and so... I take care of alsa-tools (fltk is the problematic package), ami and DirectFB. 2009/6/17 Cristian Rodríguez <crrodriguez(a)opensuse.org>: > While I certainly cannot promise fix all the broken packages, please tell > people to email me or this list if they have doubts about fixing this > problems, this issue has to be sorted out. Fixing fltk I also saw "fltk_gl" isn't linked against GL, so since I'm with it... it this a bug? The ld man says: "The reason that --allow-shlib-undefined is the default is that the shared library being specified at link time may not be the same as the one that is available at load time, so the symbols might actually be resolvable at load time." and the thing is that I don't know too much about openGL, but it's my understanding that there are multiple libraries (with different sonames?) implementing it (nVidia has one, ATI probably other...), I'm correct? If so, is the fltk_gl/openGL a case where it is really correct to allow undefined symbols? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years

[opensuse-packaging] Another side effect of opening factory

by Stephan Kulow

Hi, As we disable the package database, there is one rather important change that I only figured the importance of today: So far the spec files are rewritten to use the texts and attributes from the package database a) when checked in factory b) when building Both steps will be disabled in the future, we still will do some formatting, but we won't take any attributes (AFAIK) so the spec file contains the master information. So there are consequences out of this: 1) we have quite some spec files that haven't been checked in a while and as b) is disabled, they will use old informations when building. 2) we have quite some packages that are creating placeholders into summary and description and relying on a) to create useful spec files. This will no longer be the case. For 1) I did some scripting to find out where the differences are if I would sr all packages _NOW_ (while pdb is still active). The list of changes is impressive, but I will filter out less important cases (e.g. where only the changelog is affected - as this will still be reformated in the future): http://www.suse.de/~coolo/spec_patches/ We may end up checkin in these diffs without spamming opensuse-commit, just so you know if your branched package broke (IMO it's very unlikely it will as this affects mostly packages without active development). For 2) you need to act: if your spec file is generated from a vcs, then you need to merge texts and attributes back into the template. If you have a package using a script to generate the spec file, then you need to enhance the script. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years

[opensuse-packaging] as-needed

by Stephan Kulow

Hi, I just submitted 89 packages with a simple export SUSE_ASNEEDED=0 in the section that fails (mostly %build, but sometimes %install, sometimes both). All these 89 packages only had a _link in their devel project, so I dared to push it right away to O:F not to waste time. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years

[opensuse-packaging] cyclic repo dependencies (Gnome in first place)

by Adrian Schröter

Hi please fix your repo dependencies, the scheduler needs to break them anyway, but we might even block the entire projects later, since this could create endless build loops. (btw these were fixed several times and come back again always it seems) From scheduler log (printed some several thousand times): cycle: GNOME:Backports/openSUSE_11.1 -> GNOME:Factory/openSUSE_11.1 breaking with GNOME:Backports/openSUSE_11.1 -> GNOME:Factory/openSUSE_11.1 cycle: home:pikerhog:gnome/standard -> home:pikerhog:utils/standard breaking with home:pikerhog:gnome/standard -> home:pikerhog:utils/standard cycle: home:pikerhog:gnome/openSUSE_11.1 -> home:pikerhog:utils/openSUSE_11.1 breaking with home:pikerhog:gnome/openSUSE_11.1 -> home:pikerhog:utils/openSUSE_11.1 event project::server:mail -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years

[opensuse-packaging] Re: Fixing --as-needed packages (was [opensuse-factory] status distribution)

by Cristian Morales Vega

2009/6/18 Cristian Rodríguez <crrodriguez(a)opensuse.org>: > On 17/06/09 16:51, Cristian Morales Vega wrote: >> >> coolo published a list of packages that fail to build with --as-needed >> at http://www.suse.de/~coolo/asneeded/ (see Factory ML for details), >> so I continue this in opensuse-packaging ML so people can say in which >> packages they are working and so... >> >> I take care of alsa-tools (fltk is the problematic package), ami and >> DirectFB. > > I fixed several of the broken packages and coolo did as well. but there are > still many others. There is some easy way to see when a package has already been fixed? I'm creating patches with name %name-%version-as-needed.patch, but DirectFB will probably be fixed with just an update, without any patch. And I have still not submitted any, waiting for them to compile in the BS but is constantly "blocked" by other Factory packages being rebuilt since yesterday. Also, I have being putting an "export SUSE_ASNEEDED=1" line at the start of the %build section to make the test and then removing it. I suppose there is a more correct way, through BS config, but I have no idea of how it could work. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 years

[opensuse-packaging] Lang packages for shared libraries

by Vincent Untz

Hi, What's the proper way of naming a lang package that goes with a shared library following the shared library policy? Eg: the libgsasl source package has a libgsasl7 package. So far so good. But it has translations, so should the translations go in libgsasl-lang or libgsasl7-lang? 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

13 years

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging June 2009