Hi folks,
recently, a lot of PHP packages have been either converted from PEAR
format to composer or offered in both format. Some new software has been
composer-only right from the start.
As far as I know, we only have tools for automatically dealing with PEAR
format packages.
This is going to get worse as the most widely used 3rd party pear server
software, pirum, has been deprecated in favor of composer.
This renders more and more pear based installations useless.
http://pirum.sensiolabs.org/https://twitter.com/fabpot/status/434256189258735616
Do you know how other distributions handle this?
Is there any effort for (semi)automatic composer->rpm conversion tools?
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang(a)b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi,
The filesystem package was changed to provide /var/run only as a symlink
to /run instead of doing two mounts of the same file system.
This has one (and only one AFAICS) consequence: %ghost entries in
packages need to move to /run - as packaging behind symlinks is
forbidden by policy.
In doubt you can easily remove this %ghost entry - their only use
case is reporting something for rpm -qf, which is of doubtful use
as most packages create a directory with their name and leave the
content unreported for -qf.
All other uses of /var/run will continue to work, so don't touch them
unless you have a very good reason to do so.
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
This is the error in a nutshell:
$ gst-inspect /usr/lib64/gstreamer-0.10/libgstdc1394.so
(gst-inspect-0.10:31127): GStreamer-WARNING **: Failed to load plugin
'/usr/lib64/gstreamer-0.10/libgstdc1394.so':
/usr/lib64/gstreamer-0.10/libgstdc1394.so: undefined symbol:
dc1394_iso_release_all
Could not load plugin file: Opening module failed:
/usr/lib64/gstreamer-0.10/libgstdc1394.so: undefined symbol:
dc1394_iso_release_all
Looking at the sources for libdc1394-22 in openSUSE 13.1, I can find
dc1394_iso_release_all in iso.h, so it's *there*, but not exported in
the final shared object. My guess is that it's an issue with how it's
packaged or compiled.
Thanks,
~Damien
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I am breaking part of the open-iscsi package for openSUSE:Factory into
two new sub-packages: open-isns, and iscsiuio.
What do I have to do to get these two new sub-packages added to the list
of packages that get delivered as part of the OS? I'm assuming just
generating two new sets of RPMs will not mean that they are
automatically available for installation.
--
Lee Duncan
SUSE Labs
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello All,
I'm updating the packaging for Java:packages/antlr on SLES and it's
failing because its coming back as a noarch package, however
'BuildArch: noarch' is not set in the main package or python component
of the package.
I'm truly at a lose as to what's causing this, can anyone shed some light?
%package -n python-%{name}
Summary: ANother Tool for Language Recognition (python runtime)
Group: Development/Tools/Other
Requires: antlr
%py_requires
https://build.opensuse.org/package/show/home:deadpoint:branches:Java:packag…https://build.opensuse.org/package/live_build_log/home:deadpoint:branches:J…
[ 155s] antlr-devel: "/usr/lib64/libantlr.a" is not allowed in a
noarch package.
[ 156s] python-antlr: "/usr/lib64/python2.6/site-packages/antlr" is
not allowed in a noarch package.
[ 156s] python-antlr:
"/usr/lib64/python2.6/site-packages/antlr/__init__.py" is not allowed
in a noarch package.
[ 156s] python-antlr:
"/usr/lib64/python2.6/site-packages/antlr/__init__.pyc" is not allowed
in a noarch package.
[ 156s] python-antlr:
"/usr/lib64/python2.6/site-packages/antlr/antlr.py" is not allowed in
a noarch package.
[ 156s] python-antlr:
"/usr/lib64/python2.6/site-packages/antlr/antlr.pyc" is not allowed in
a noarch package.
--
Later,
Darin
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
You may have noticed it already, build.o.o is back.
The storage system works well again, no data is lost.
--
Adrian Schroeter
email: adrian(a)suse.de
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hey,
we are currently experiencing some problems with our SAN storage :-/
Trying to fix it ASAP, stay tuned for updates.
Henne
--
Henne Vogelsang
http://www.opensuse.org
Everybody has a plan, until they get hit.
- Mike Tyson
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I'm working on bnc #868699, and for the fix I need to deliver
- 2 updated packages, already present in 13.1
- 2 new packages, not present in 13.1
I was able to add the 2 update packages to my update project, but I
can't do that for the pakages which are not present in 13.1 :
$ osc branch -M openSUSE:13.1:Update php5-pear-channel-symfony2
Server returned an error: HTTP Error 404: Not Found
$ osc maintained php5-pear-channel-symfony2
BuildService API error: no packages found by search criteria
I tried to create the package manually, and the directory is
submitted, but not the local files. The failure is on the osc side:
$ osc commit
Traceback (most recent call last):
File "/usr/bin/osc", line 26, in <module>
r = babysitter.run(osccli)
File "/usr/lib/python2.7/site-packages/osc/babysitter.py", line 60, in run
return prg.main(argv)
File "/usr/lib/python2.7/site-packages/osc/cmdln.py", line 343, in main
return self.cmd(args)
File "/usr/lib/python2.7/site-packages/osc/cmdln.py", line 366, in cmd
retval = self.onecmd(argv)
File "/usr/lib/python2.7/site-packages/osc/cmdln.py", line 484, in onecmd
return self._dispatch_cmd(handler, argv)
File "/usr/lib/python2.7/site-packages/osc/cmdln.py", line 1214, in
_dispatch_cmd
return handler(argv[0], opts, *args)
File "/usr/lib/python2.7/site-packages/osc/commandline.py", line
4382, in do_commit
if any(pac.is_link_to_different_project() for pac in pacs):
File "/usr/lib/python2.7/site-packages/osc/commandline.py", line
4382, in <genexpr>
if any(pac.is_link_to_different_project() for pac in pacs):
File "/usr/lib/python2.7/site-packages/osc/core.py", line 1568, in
is_link_to_different_project
orgprj = self.get_local_origin_project()
File "/usr/lib/python2.7/site-packages/osc/core.py", line 1563, in
get_local_origin_project
root = ET.fromstring(self.get_local_meta())
File "<string>", line 124, in XML
TypeError: must be string or read-only buffer, not None
Right now I'm at a loss how to proceed. Is it possible to add new
packages as part of an update?
Thanks,
Robert
--
http://robert.muntea.nu/
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
with systemd we nowadays handle enabling services by default via the
systemd-preset-* packages. But AFAICS this really only handles automatic
enablement of the service (== systemctl enable). The service are still not
running after that. For that I still need to either reboot a call systemctl
start manually. Is that really the expected behavior? If yes, what is the
correct way to automatically have a service started after installation.
Currently I am looking at open-iscsi which has iscsid.socket and iscsi.service
listed in /usr/lib/systemd/system-preset/90-default-openSUSE.preset. Both are
correctly enable after installation, but only started after reboot.
--
Ralf
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Dear listmembers,
the package I am maintaining triggers an error message of rpmlint (restricted
to the distributinon SLE11_SP3):
tgif.src:71: W: invalid-suse-version-check 1140
The specfile contains a comparison of %suse_version against a suse release
that does not exist. Please double check.
I started with 1130 and a somewhat different terminating condition, but no
help. IMHO both 1130 and 1140 are valid release numbers - or do I
misunderstand something important here? The warning is restricted to
SLE11_SP3, other distributions are perfectly fine in this regard.
Thank you for looking into this,
take care
Dieter Jurzitza
--
-----------------------------------------------------------
|
\
/\_/\ |
| ~x~ |/-----\ /
\ /- \_/
^^__ _ / _ ____ /
<°°__ \- \_/ | |/ | |
|| || _| _| _| _|
if you really want to see the pictures above - use some font
with constant spacing like courier! :-)
-----------------------------------------------------------
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org