Can packages in 11.4 standard or update repositories build against packages provided in the tumbleweed update repository.? I've filed
bnc#696826 about 11.4's lv2core-devel's lv2config being unable to function due to a lack of package python-redland. The LV2 plugin system
cannot be used at all if the package can't build against lv2core and slv2, I submitted new packages lv2core, slv2 and an updated redland
package that included the python bindings before 11.4's release, lv2core is in the 11.4 distribution but slv2 is still in review, here is
it's history :
62079 State:declined By:autobuild When:2011-02-18T16:30:51
submit: multimedia:libs/slv2 -> openSUSE:Factory note: obsoleted by submitreq 62078
From: plater(new)
Descr: Removed conflict for libslv2-8
62078 State:review By:coolo When:2011-03-28T16:14:46
submit: multimedia:libs/slv2 -> openSUSE:Factory
From: plater(new) -> saschpe(review)
Descr: Removed conflict for libslv2-8
60049 State:declined By:autobuild When:2011-02-18T16:30:43
submit: multimedia:libs/slv2 -> openSUSE:Factory
From: plater(new)
Descr: Add slv2-0.6.6-licencefix.patch to remove file with conflicting
GPLv2 statement in the header.
See bnc#669117 and slv upstream drobillad #630
59638 State:declined By:autobuild When:2011-02-04T17:25:01
submit: multimedia:libs/slv2 -> openSUSE:Factory
From: plater(new)
Descr: New package slv2 is a library to make the use of LV2 plugins as
simple as possible for applications.slv2 is free software (GPL v2
or later) written in C99 using the Redland RDF toolkit, and is
known to work on GNU/Linux and Mac OS X. This package is the
other part of the slv2 lv2core needed for openSUSE packages to
use the LV2 plugin system and compliments submit request sr#59624
the home url for this package is
http://drobilla.net/software/slv2/ apart from the url and licence
all of the other relevant information is contained in submit
request id 59624
and this is sr#62078 the last request which is still open :
Request #62078:
submit: multimedia:libs/slv2(r5) -> openSUSE:Factory/slv2
Message:
Removed conflict for libslv2-8
State: review 2011-03-28T16:14:46 coolo
Comment: run checker
Review: new darix None None None Please decide
accepted None factory-auto 2011-03-29T16:16:48 coolo Builds for all Factory repos found
Output of check script (non-fatal):
History: review 2011-03-18T10:39:07 saschpe
new 2011-02-18T16:18:50 plater
This last request effectively blocks slv from even going into factory. There was a comment made in a reply during one of my many emails
pleading for slv2 to be accepted that it was a duplicate of a Packman package and I replied that it's purpose was to enable multimedia
applications to build with support for LV2 plugins and openSUSE packages cannot build against Packman packages.
I'm busy updating qtractor from 0.7.8 to 0.7.9 the earlier version would have been in 11.4 had slv2 been present and now it seems that
version 0.7.9 is also going to be blocked.
Reference threads :
http://lists.opensuse.org/opensuse-factory/2011-02/msg00678.htmlhttp://lists.opensuse.org/opensuse-factory/2011-02/msg00004.htmlhttp://lists.opensuse.org/opensuse-factory/2011-01/msg00377.html
I originally created the lv2core and slv2 packages when a user requested LV2 plugin support for ardour which isn't in the main distribution
but he was happy with the result and this verifies that there isn't anything wrong with the package. Maybe I violated an openSUSE rule
inadvertently but if nobody explains what it was I may do it again. I'm passionate about openSUSE multimedia and I feel that it presents an
important face of openSUSE.
Regards
Dave Plater
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hello,
If I want to add a start parameter permanently to syslog-ng, is this the
right place to do it?
# cat syslog-ng.sysconfig
## Type: string
## Default: ""
## Config: ""
## ServiceRestart: syslog
#
# Parameters for Syslog New-Generation - see syslog-ng(8)
#
SYSLOG_NG_PARAMS=""
As in this case, I could simply add: "--module-path
/lib/syslog-ng:/usr/lib/syslog-ng" to SYSLOG_NG_PARAMS, which would
remove a harmless, but ugly warning message on start.
Bye,
CzP
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hello,
I look for some more people who want to try our hopefully soon to be
applied new source processing method for openSUSE:Factory and the maintenance
updates to :Update projects.
It should work good already, so you do not need to be brave ;)
You may know that currently all package source submissions to Factory and
friends get SUSE in-house be reviewed, re-validated and reformated.
You can see this in the additional "autobuild" commits in the openSUSE:Factory
commits.
We plan to do following changes in future:
* We would like to do these steps out there and as soon as possible in future.
This means in best case before any packager is commiting his changes the validating
and reformating is done already. This avoids any possible merge problems,
unnecessary commits and extra turn around times.
* these services can be code stream specific (unlike current osc_source_validator).
That means we will be able to do better checks in future for Factory then for
maintenance updates (where we need to stay compatible). And we do not need to take
care about non-SUSE code streams, eg. Fedora or MeeGo people can still work and submit
their changes to their projects or write their own services.
* In addition to existing checks, we want to track where upstream sources (tar balls)
are comming from. So far we had the download_url source service, which downloaded files
and stored them with _service: prefix what not everybody liked.
The new and project wide working "download_files" service is just validate the URL's
from the spec file. The new osc will commit these files as usual files and the server
is just validating this.
(People with low upstream bandwidth can still decide to skip the commit, the server
will store it with prefix again.)
So, if everybody is using this current osc & source service stack, the source services will
be used to do these steps, but there will be no _service* file(s) in your package sources.
And the last really SUSE in-house part of Factory development would be the legal review db,
really everything else would be out there in build.o.o...
How to test this ?
==================
First of all you need the new services and a new osc installed. Please add the proper
openSUSE:Tools project repo and install
zypper in obs-service-download_files obs-service-format_spec_file obs-service-source_validator
In addition to that please install "osc" from openSUSE:Tools:Unstable project. If you do not
like to add the repo, just run
osc getbinaries openSUSE:Tools:Unstable osc $YOUR_REPO $YOUR_ARCH
and install the osc package manually.
To activate this for your entire devel project (it would work also per package) do
# osc co $YOUR_DEVEL_PROJECT _project
# cd $YOUR_DEVEL_PROJECT/_project
# cat > _service <<EOF
<services>
<service name="format_spec_file" mode="trylocal"/>
<service name="download_files" mode="trylocal"/>
<service name="source_validator" mode="trylocal"/>
</services>
EOF
# osc addremove
# osc ci -m "activate factory default source services"
Afterwards these services running on "osc build" and "osc commit" actions,
if not disabled via CLI switch. Reformated spec files will be uploaded directly
and in case of validation errors, osc will abort before commit/build'ing.
What happens to people with old osc version (0.130 and before) or just using the
webui after activating these services ?
Nothing. The services will run on the server only.
=> The source state will turn into "broken" if a validation error exists.
=> if tar ball is missing/different or spec file is different formated they
will be visible with _service:* prefix again.
How to get rid of them again ? Just anyone with a current osc stack will
merge these changes automatically on next commit and the server side generated
files will disappear again.
If this testing phase works out fine, we will of course make a maintenance update
for all these packages, so everybody should have a current stack.
I have activated this already for the openSUSE:Tools* projects and everything seems
to work. And I found out that 3 out of 3 random packages from openSUSE:Factory contain
broken Source: $URL lines ;)
Feel free to branch any openSUSE:Tools package into your branch and try to edit it.
With the new osc you will use these local services automatically.
--
Adrian Schroeter
SUSE Linux Products GmbH
email: adrian(a)suse.de
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
I've submitted the updated version of Banshee (2.0.1) to Factory today
and also banshee-community-extensions (which wasn't a part of
Factory). If the community extensions package isn't attractive to
factory, then feel free to decline it, though it would be somehow
interesting to be available also on Factory.
banshee-1 : SR 71891
banshee-community-extensions: SR 71890
NM
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
I just downloaded the Factory KDE LiveCD (which contains 12.1 M1), and
I can't log in. I haven't even installed it yet, but when I press
enter to login, the screen flashes and I get the login screen again.
I also *did* do a seperate install from the NET iso and I get the same issue.
I'll check for existing bug reports, but I don't think the coming M1
is testable :(
Steve
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi,
Whatever is now in Factory will be Milestone 1 even though the final images
are still building. There are quite some ugly bugs in it, but it's testable
software and we have a complete set of ISOs.
There is quite a lot of difference against 11.4, I tried to produce the diff
out of the wiki and I found 819 version updates - including packages with so
small names like rpm, perl or gcc, but also with long names like kernel-source
and gnome-shell.
I hope you can make use out of it, be warned though: it's only a starting
point for further development, not perfectly stable.
Greetings, Stephan
Hello,
Is this a known Problem ?
I update today my server SLES 11 SP1 with the new XEN Packages after this it
is not possible to boot ?
The mkinitrd don't write the correct menu.lst , on boot the xen......gz is not
found ?
I have a second Problem after reboot my extra boot Partition is no more found
on a Raid1 System? (md-UUIE Problem)
--
mit freundlichen Grüßen / best Regards,
Günther J. Niederwimmer
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org