Hello Mates,
actually i'm working on Goo-Canvas for perl. The Buildlog is located there:
http://bit.ly/pfHLuW.
In short it says:
+ xargs -0 -r rmdir
+ find /usr/src/packages/BUILDROOT/perl-Goo-
Canvas-0.06-11.1.i386/usr/lib/perl5/vendor_perl/5.14.1/i586-linux-thread-
multi/auto -depth -type d -print0
rmdir: failed to remove `/usr/src/packages/BUILDROOT/perl-Goo-
Canvas-0.06-11.1.i386/usr/lib/perl5/vendor_perl/5.14.1/i586-linux-thread-
multi/auto/Goo/Canvas': Directory not empty
After this cut follows 3 directories more.
Anyone knows, how to fix it?
Greetings
Sascha
--
Sincerely Yours
Sascha Manns
open-slx Community & Support Agent
openSUSE Membership Comitee
openSUSE Marketing Team
Web: http://saigkill.homelinux.net
German Community Portal: http://community.open-slx.de
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
I would like to inform you that the Chromium webbrowser will be moved within
the next few days to it's new development project network:chromium.
This will mean that the package will no longer be residing in the Contrib
projects nor in my home proejct (home:rwooninck:chromium).
Today I have send the last update to openSUSE:xxxx:Contrib for Chromium which
should resolve the latest issue with regards to a missing sandbox client. As
soon as this is published, I will disable the build of this project in Contrib
and 1 week later(if there are no objections) the package will be removed from
the Contrib repo's.
Any other updates will be done in the network:chromium repo, where Chromium is
build for openSUSE versions 11.3, 11.4, Factory and Tumbleweed.
The ultimate target would be to submit Chromium to Factory.
Regards
Raymond
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi:
I just got this:
The following NEW package is going to be installed:
libGLEW1_6
The following package is going to be REMOVED:
libGLEW1_5
Just a quick reminder, libfoo$SOVERSION does NOT "Obsoletes"
libfoo($SOVERSION-n)
#rpm -q --obsoletes libGLEW1_6-1.6.0-2.1
libGLEW1_5
by adding this "Obsoletes" you will be breaking one of the main
advantanges of library packaging policy.
Cheers.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi all,
We submitted an update of python-gobject to Factory.
The new version, 2.90.2 is now based PURELY on the gobject-introspection
based bindings and is not compatible to code relying on the old
bindings.
This link explains it better than I could ever write it:
http://www.j5live.com/2011/08/14/announce-pygobject-2-90-1-released-3-0-pre…
As this is of course a big change for Factory and the time to a final
release is getting shorter, we do not expact everybody to change their
codes (just yet).
So we also submitted the 'old' version to Factory as python-gobject2
(the new version will become 3.0 when it's fully ready).
python-gobject2 is not yet available in Factory (as of now), but that is
likely to change in the not to distant future (SR pending).
A big amount of packages might have turned into 'Unresolvable' after
this change, as they were (still) BuildRequiring python-gobject2-devel
(which in turn was a virtual symbol provided) or they are BuildRequiring
pkgconfig(pygobject-2.0). For those packages, the virtue is patiance:
simply wait and the problem will get sorted for you with the 'old'
version being checked in.
The ones BuildRequiring python-gobject-devel will need to verify if
their code does what it is supposed to to. Failures to build or start
might hint that the other bindings are required.
I hopes not to many started debugging their new build Failures or
expansion errors yet.
Best regards,
Dominique
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
I've written a successful prototype that does the following:
* generates a completely functional .spec file based on the
metadata of java artifacts (POM) that is available at Maven
Central (http://repo1.maven.org/maven2/)
* does *NOT* build from source but, instead, simply takes the
.jar file from Maven Central and installs it into %{_javadir}
(including the usual symlinks)
* optionally also creates a subpackage with the source jar from
Maven Central (very useful for IDEs such as Eclipse)
* all that including dependencies, as far as they're declared in
the POM file
* written in Perl (hey, it's a prototype ;)), just one file, no
exotic dependencies
The script is there:
https://gitorious.org/pbleser/pbleser/blobs/master/pom2spec
Here's an example on how to run it:
1) pull the script and chmod it:
cd ~/bin
wget https://gitorious.org/pbleser/pbleser/blobs/raw/master/pom2spec
chmod +x pom2spec
2) go to your OBS sandbox and create a new package:
osc mkpac log4j-log4j-1_2_15
3) generate the .spec file, passing groupId artifactId and
version:
pom2spec log4j log4j 1.2.15
(if you don't specify the version, pom2spec will give you a list
of possible versions, i.e. those that are available in Maven
Central)
4) well, obviously, build it ;)
osc build ...
===== The longer story...
First of all, I guess that everyone knows by now that the
packaging situation around Java libraries (and, hence,
applications (desktop and server) that depend on those
libraries) is ... let's say... suboptimal.
It is very complex to build those from source as the build
systems that are typically used for Java projects (Ant, Maven,
Gradle, Ant+Ivy, ...) have a dependency management of their own
that is quite difficult to integrate with RPM packaging.
Stephen Shaw has been putting a lot of effort into doing it
properly since some time and while he's made a lot of progress
already, I think we're still far away from having a useful set
of common Java libraries (there are gazillions of open source
Java libraries and frameworks out there).
Hence, I believe that having them as "bad" RPMs (because they're
not built from source but just install the already compiled .jar
files from Maven Central (hence upstream)) is better than not
having them _at all_.
Of course, starting from there, we should still continue to
improve our tool set and experience with building Java packages
from source, in order to replace at least some of those "bad"
RPMs with "good" ones.
The drawback is that we cannot add our own patches to the
upstream sources, for obvious reasons.
But the advantage of this approach is that it is very easy to
build the RPMs. And, to be honest, I don't think that, in the
past or in the future, we often need to add patches to portable
Java source code that haven't been included upstream already.
Sure, that doesn't work well with the typical policy for the
distribution updates (backport patches instead of version bumps)
but hey... better than nothing, don't you think ?
===== Now the interactive part...
While writing the pom2spec script, a few questions or, rather, a
need for some decisions, appeared.
We probably can all agree that we should add Provides in those
Java library packages in the same fashion as with Perl packages,
along the lines of this:
Provides: java(${groupId}:${artifactId}) = ${version}
e.g.:
Provides: java(org.springframework:spring-beans) = 2.5.6.SEC02
(the g:a and g:a:v notation is very commonly used in
Java/Maven/Gradle/...)
That would make it easier, more portable and clearly more
future-proof in dependencies (Requires).
But what I'm not sure about, at this point, is how to name the
packages themselves.
I believe we should use fully qualified ${groupId}-${artifactId}
names, e.g.:
Name: org.springframework.spring-beans
^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^
${groupId} ${artifactId}
That (${ŋroupId}:${artifactId}) already is a unique and
canonical name as of Maven Central, which is what 90%+ Java
projects on the planet use (either through Maven, or Ant+Ivy,
or Gradle, or ...).
But that's too long for Joliet. Is that still an issue ?
Another thing is that I believe that it would make our life
easier if we also included the ${version} in the %{NAME} of the
package, in order to be able to install several different
versions of libraries side-by-side.
That way we can always reflect upstream's dependencies as
defined in their POM file (e.g.
org.springframework:spring-beans:2.5.6.SEC02 requiring
log4j:log4j:1.2.15).
Example:
Name: org.springframework.spring-beans-2_5_6_SEC02
Version: 2.5.6.SEC02
Yes, that's a pretty long package name alright.
That would also mean dropping the symlink that drops the
%{version} in %{_javadir}.
Feedback please :)
(And thanks for reading this far, I know this email is way too
long, but I wanted to give enough background :)).
cheers
--
-o) Pascal Bleser
/\\ http://opensuse.org -- we haz green
_\_v http://fosdem.org -- we haz conf
Hi all,
First, sorry for x-posting, but the topic addresses really both.
I just prepared updates of gnome-menus in GNOME:Factory. Nothing special
so far.
Unfortunately, gnome-menus 3.1.5 is ABI and API incompatible to the
existing gnome-menus (v 3.0.1) which we currently have in Factory. And
as there are more consumers than only GNOME packages, I feel you should
all be aware of the upcoming change. Especially as some packages might
fail a build with the update if o precautions are taken.
In order to avoid any big disruption, I submitted gnome-menus 3.0.1 as a
new package, gnome-menus-legacy, to openSUSE:Factory. This will provide
a devel package and the shared library, so that your app will keep on
working.
Of course, the -devel package has a different name, and as such it
depends on your .spec file if there is work needed from your side or
not.
If you have a BuildRequires: gnome-menus-devel, then you do have to act
and change this to BuildRequires: pkgconfig(libgnome-menu).
This will ensure that even though the package is renamed, you get the
right -devel file on your system.
for the end user, gnome-menu 3.1.5 and 3.0.1 have differen library names
and as such are parallel installable. The other subpackages are weirdly
named but are not important for your packages. An update of those willt
ransparently happen (gnome-menus-editor for example).
A full list of package in Factory depending on gnome-menus can be found
in https://bugzilla.novell.com/show_bug.cgi?id=712674
Best regards,
Dominique
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
I'm trying to upgrade Sleuthkit which I found in home:toganm:security
But the Specfile is out of date compared to the latest tar.gz file and
giving a Badness of 10,000 due to a naming issue with a library.
Per the changelog, the specfile originally came from Fedora, so I
thought I'd take a look at it and see if they've already fixed it.
Where do I look for that?
fyi: My version of the package is at:
home:gregfreemyer:Tools-for-forensic-boot-cd > sleuthkit
Thanks
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello everyone,
please remind me, what's the way to build against packman stuff like
ffmpeg (i.e. libav* etc.)?
If there isn't already, there are so many cross-dependancies, I think
there should be at least a "use-for-build"-only repo in the OBS (or as
a link to the PM OBS?), which probably would need some coordination
with the packman guys, but as some personnel is shared ...
-dnh
--
There are two major products that come out of Berkeley:
LSD and UNIX. We don't believe this to be a coincidence.
-- Jeremy S. Anderson
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi guys,
your friendly (Factory) reviewing team would like to see more packages honor
our not-so-new shared / static library policy [1],[2]. It has been around for
ages, but we still have quite a bunch of offending packages in Factory. First
of all this is only a gentle reminder, but we would like to enforce the policy
for new packages more than we did so far. We believe that this is a wanted and
very necessary step in order to increase the quality of our packages.
The topic has already been cooking for a while and most packagers already do
an awesome job on that front and we want to encourage everyone to fix the
remaining bits. This means we don't like to see (and probably won't accept)
the following rpmlint filters in Factory submissions anymore:
- shlib-policy-missing-suffix
- shlib-policy-name-error
- shlib-policy-missing-lib
- shlib-fixed-dependency
- shlib-policy-nonversioned-dir
- shlib-legacy-policy-name-error
- shlib-policy-excessive-dependency
So, if your package has one of those, please read the docs on how to fix it
(or ask the list). Some good random examples on how it can be done (there are
plenty of others):
- openSUSE:Factory / gtkmm2
- openSUSE:Factory / librelp
Of course, there are always exceptions, thus this isn't set in stone. If a
package has to deviate from the policy, make sure to document why (if in
doubt, ask the list). A suitable place is the rpmlintrc file in your package
(it's Python, thus #commenting works).
Remember, the more text you throw at the reviewers in your spec / changes /
rpmlintrc files, the more likely it is that they understand the cause (but the
easier it may be for them to fend it off :-). Happy packaging!
Footnotes:
[1] http://en.opensuse.org/openSUSE:Shared_library_packaging_policy
[2] http://en.opensuse.org/openSUSE:Packaging_guidelines#Static_Libraries
--
Mit freundlichen Grüßen,
Sascha Peilicke