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
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
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
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
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
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
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
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
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
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