Hi,
I am packaging the Perl binding for Augeas, but there is a problem
in that 11.3 includes a rather old version of the library, so the
binding only compiles on Factory.
(The same situation exists for
devel:languages:ruby:extensions/rubygem-ruby-augeas, SR 52828)
What makes most sense?
a) disable the binding for 11.3 and older
b) build for 11.3 (or even older) with a recent augeas, which
is in devel:libraries:c_c++. Is it possible to use a single package
from a different devel project? How?
c) for 11.3, use older perl-Config-Augeas which works with
augeas-0.5.0 (uh, I'd rather not)
> State of submit-request #52843 was changed by computersalat:
> new -> declined
>
> Comment:
> build failing for 11.3, please fix deps
> *** 'pkg-config' did find augeas version 0.5.0 but
> *** version 0.6.0 minimum is required
>
> https://build.opensuse.org/request/diff/52843
>
> Source
> project: home:mvidner
> package: perl-Config-Augeas
> revision: 1
>
> Target:
> project: devel:languages:perl
> package: perl-Config-Augeas
--
Martin Vidner, YaST developer
http://en.opensuse.org/User:Mvidner
Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi everyone,
yesterday I packaged the latest stable version of DokuWiki, and it built
well. However, I can't install it:
# zypper in dokuwiki
Loading repository data...
Reading installed packages...
Resolving package dependencies...
Problem: nothing provides /usr/bin/php needed by
dokuwiki-2010.11.07-4.1.noarch
Solution 1: do not install dokuwiki-2010.11.07-4.1.noarch
Solution 2: break dokuwiki by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c] (c):
"nothing provides /usr/bin/php" - that's right, and this dependancy is
introduced by the build system's auto dependency search :-(. That's
because the package contains some PHP cli scripts beginning with
"#!/usr/bin/php", so I know where the dependency comes from.
The package (spec file) requires apache2-mod_php5 and php5 >= 5.1.2, and
the latter package brings along /usr/bin/php - but not as a "provides",
obviously.
So - how can I package DokuWiki in a way that it is installable? Do I
have to package php5 on my own, just because I add a "Provides:
/usr/bin/php" in the spec file? Another workaround I found is to package
the cli scripts without the first line and to add the shebang line in
the %post section of the spec file, but I wouldn't like this, it might
turn out error prone...
Regards,
Werner
BTW, the package's page is
<https://build.opensuse.org/package/show?package=dokuwiki-stable&project=hom…>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAkzdHIQACgkQk33Krq8b42Pg1wCggfrV9eG8WV7QzlgZp7VD/v4o
rykAn2oeaJeI/k90Lg7r2T+CtY0LMCtB
=4xwA
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
I'm packaging mintmenu, which is pur python, and so should be a noarch
package. However, it needs to place a mintmenu.server file in
"%{_libdir}/bonobo/servers/". Since this expands differently on 32bit
vs. 64bit (and it needs to 64 bit systems don't pick it up if its in
"/usr/lib/bonobo/servers/", is it ok to leave the package as arch
dependent and ignore the rpmlint warnings?
Will
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello,
I'd like to push patch2mail towards factory and am now looking for a
fitting devel project.
patch2mail runs a small script using cron.daily and sends a mail to root
if one or more patches are available. It uses zypper --xmlout and a XSLT
file to make the output readable.
Would patch2mail be a candidate for the new "utilities" project? Or
would system:packagemanagement or system:packagemanager (BTW: to me it
looks like those two should be merged) be a better place? Or did I miss
the ultimative project? ;-)
FYI: Currently patch2mail lives in my home project and in Contrib.
Regards,
Christian Boltz
--
Planung ist der Ersatz des Zufalls durch den Irrtum.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello,
According to these logs this package has these results:
-fails on 11.3 [1]
-passed on 11.2 [2]
[1]
https://build.opensuse.org/package/rawlog?arch=x86_64&package=reiser4progs&…
[2]
https://build.opensuse.org/package/rawlog?arch=x86_64&package=reiser4progs&…
Last bits of each log. Note checking for libaal version = 1.0.5... 11.2
says 'yes' 11.3 says 'no'
[1]
checking size of off_t... 8
checking for aal_device_open in -laal... yes
checking aal/libaal.h usability... yes
checking aal/libaal.h presence... yes
checking for aal/libaal.h... yes
checking for libaal version = 1.0.5... no
+ make -j4 'CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables -Wall
-Wno-unused'
make: *** No targets specified and no makefile found. Stop.
error: Bad exit status from /var/tmp/rpm-tmp.cn1c0I (%build)
[2]
checking size of off_t... 8
checking for aal_device_open in -laal... yes
checking aal/libaal.h usability... yes
checking aal/libaal.h presence... yes
checking for aal/libaal.h... yes
checking for libaal version = 1.0.5... yes
checking for aal_device_open in -laal-minimal... yes
checking for aal/libaal.h... (cached) yes
checking for libaal-minimal version = 1.0.5... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating include/Makefile
config.status: creating include/aux/Makefile
config.status: creating include/misc/Makefile
config.status: creating include/reiser4/Makefile
What change to the .spec file would allow the package to compile on 11.3
platform ?.
spec file ->
https://build.opensuse.org/package/view_file?file=reiser4progs.spec&package…
Thanks Glenn
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
I just ran spec-cleaner on a minor/simple leaf package I maintain.
It did some nice cleanups.
One thing it didn't do and I don't know how to do is handle a
mysqlclient problem I have with 64-bit Fedora
My home package: home:gregfreemyer:Weather > open2300 now has the
spec-cleaner cleaned spec file
But I still get an error related 64-bit Fedora
/lib/mysql -lmysqlclient
/usr/bin/ld: cannot find -lmysqlclient
Can anyone tell what I need to fix, and is something that could be
added to spec-cleaner?
Greg
--
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
CNN/TruTV Aired Forensic Imaging Demo -
http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrie…
The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
Since a few days, I've got the following RPMlint error while building
my packages for Factory:
RPMLINT report:
===============
9 packages and 0 specfiles checked; 0 errors, 7 warnings.
Traceback (most recent call last):
File "rpmlint.py", line 364, in <module>
File "rpmlint.py", line 159, in main
File "rpmlint.py", line 219, in runChecks
File "BrandingPolicyCheck.py", line 108, in check
AttributeError: 'tuple' object has no attribute 'startswith'
System halted.
This does not occur when compiling the same packages for 11.3.
This issue is similar to the one reported here:
http://lists.opensuse.org/opensuse-buildservice/2009-09/msg00158.html
According to http://lists.opensuse.org/opensuse-buildservice/2009-10/msg00015.html
, rpmlint need to be fixed. Or maybe there is a trick to avoid this
error?
Thanks in advance for your help,
Regards,
R.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi, I've just come across a potential problem, I've put up with the fact
that when I update a package I have to explicitly tell zypper or yast to
update the debug package. Now I'm in the process of renaming rosegarden4
to it's correct name rosegarden and after a zypper dup -r homeproject
I've noticed that the old rosegarden4 debug rpms had remained installed
along with the new rosegarden ones.
I removed them but it prompted me to ask why debug rpms are no longer
linked to their parent package. If I remove a package the debug rpms
remain behind and debug packages tend to use a lot of disk space. In the
old days if one selected a debuginfo package it's matching debugsource
was pulled in and if one removed the parent package the debug rpms were
also removed.
What is the solution to this? A bug report? An enhancement request?
Regards
Dave P
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
All,
I've got a very simple package in my home project:
(home:gregfreemyer:Weather > Weathergraphs)
It is basically just some php files and a couple docs.
In my specfile, I currently have:
%install
mkdir -p $RPM_BUILD_ROOT/srv/www/htdocs/weathergraphs
install *.php $RPM_BUILD_ROOT/srv/www/htdocs/weathergraphs
chmod -x $RPM_BUILD_ROOT/srv/www/htdocs/weathergraphs/*.php
My specfile works with opensuse, but it's failing with both Fedora and Mandriva.
I assume the above is the culprit.
Can someone tell me the right way to do that.
Thanks
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi, the factory build log tail for home:plater:blender blender contains
this :
RPMLINT report:
===============
(none): W: error loading /opt/testing/share/rpmlint/rpmlint-mini.config,
skipping: 'module' object has no attribute 'rlwarn'
blender-devel.x86_64: W: non-standard-group Development/Libraries/C and C++
blender.x86_64: W: non-standard-group Productivity/Graphics/3D Editors
blender-doc.noarch: W: non-standard-group Documentation/HTML
blender.src: W: non-standard-group Productivity/Graphics/3D Editors
The value of the Group tag in the package is not valid. Valid groups are:
"Amusements/Games", "Amusements/Graphics", "Applications/Archiving",
"Applications/Communications", "Applications/Databases",
"Applications/Editors", "Applications/Emulators",
"Applications/Engineering",
"Applications/File", "Applications/Internet", "Applications/Multimedia",
"Applications/Productivity", "Applications/Publishing",
"Applications/System",
"Applications/Text", "Development/Debug", "Development/Debuggers",
"Development/Languages", "Development/Libraries", "Development/System",
"Development/Tools", "Documentation", "System Environment/Base", "System
Environment/Daemons", "System Environment/Kernel", "System
Environment/Libraries", "System Environment/Shells", "User
Interface/Desktops", "User Interface/X", "User Interface/X Hardware
Support".
blender.x86_64: W: no-manual-page-for-binary blender-sample
blender.x86_64: W: no-manual-page-for-binary blender-thumbnailer.py
Each executable in standard binary directories should have a man page.
It seems that a few rpm groups have gone missing.
Regards
Dave P
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org