November 2007 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Errors during the erase of Hipo
by Vincenzo Barranco 26 Nov '07

26 Nov '07

Hi, I tried to do the rpm of Hipo ( http://www.gnome.org/projects/hipo/ ), wich i've inserted in the Buildservice on my home project (http://download.opensuse.org/repositories/home:/barravince112/) and if i would remove this package the pc says to me that is impossible, look at there: linux-xxxx:/home/barravince # rpm -e hipo-0.5-6.1 /var/tmp/rpm-tmp.42486: line 1: fg: no job control error: %postun(hipo-0.5-6.1.i586) scriptlet failed, exit status 1 What can it be? Best Regards Vincenzo --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 4

[opensuse-packaging] glibc 2.7 in Beta testing
by Stephan Kulow 26 Nov '07

26 Nov '07

Hi! Petr checked in glibc 2.7 into autobuild and we see build failures in quite some packages that look like this one: In function 'int open(const char*, int, ...)', inlined from 'void NCurses::RedirectToLog()' at NCurses.cc:587: /usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments I think the error is speaking for itself, in case it does not: this is about int open(const char *pathname, int flags); int open(const char *pathname, int flags, mode_t mode); So please fix the code, for most cases 0666 or 0600 should be the right choice. BTW: as far as I can tell, glibc 2.6 did not have a default value, so the code in question should be buggy and can't have worked before. Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] Requires in -devel packages
by Adrian Schröter 25 Nov '07

25 Nov '07

Hi, while OBS reconfiguration and brief internal discussion, I figured out that we do use Requires: in -devel packages inconsistend atm. A -devel package should Require: all other packages what provides header files or other stuff needed at compile time. It should NOT require a compiler package like gcc or gcc-c++. Also not Require the SUSE only alias like c_compiler or c++-compiler. I know that our packages are inconsistend in this regard atm. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) 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

6 6

[opensuse-packaging] Qt Eclipse Integration
by Nikolay Derkach 23 Nov '07

23 Nov '07

Hi, I recently tried Qt Eclipse Integration and I have to say it works pretty well here except for Designer. Since Eclipse in 10.3 works only with Java 6, integration of Qt Designer is broken - it turned out that qt-eclipse-integration 1.0.0 requires Java 5 to work properly (http://lists.trolltech.com/qt-interest/2007-07/msg00707.html) I suppose there are some people familiar with Eclipse plugin packaging, so is it possible to make a workaround for the above mentioned bug? And yes, I'm searching for volunteers who want to package this eclipse plugin :) Qt Eclipse Integration can be downloaded from here: http://trolltech.com/developer/downloads/qt/eclipse-integration-download -- Regards, Nikolay Derkach --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] libSieve, wherefore art thou?
by tabris 23 Nov '07

23 Nov '07

It seems that libSieve dropped out of OpenSuSE 10.3 (but was in OpenSuSE 10.2), and I can find no note in google or the changelog as to why. Any takers?

3 3

[opensuse-packaging] commoncpp2 looking for a new maintainer
by Ralf Haferkamp 22 Nov '07

22 Nov '07

Hi, anybody interested in taking over the autobuild maintainership for the CommonC++ packages? I am not able to take care of this well enough any longer. It seems to be used by some VOIP packages, otherwise I'd probably file a drop request. -- Ralf --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] automatic BuildRequires and Requires
by Stanislav Brabec 21 Nov '07

21 Nov '07

Hallo. I am just starting to work on my idea of automatic generating of devel BuildRequires and Requires. The goal is: - Increase quality of packages preventing unwanted failed checks and consequent building of feature stripped packages. - Drop obsolete dependencies (now added manually, removed after bug report) 1) As I wrote in past, I created a pkg-buildrequires package, which should help with automatic generating of BuildRequires. 2) Next idea would be automatic creating of devel Requires/Provides using information provided by pkg-config files. 1) Package pkg-buildrequires with a simple documentation is available for download from OBS home:sbrabec. https://build.opensuse.org/package/show?project=home%3Asbrabec&package=pkg-… I just started to experiment with pkg-buildrequires it in OBS GNOME:UNSTABLE repository with it. https://build.opensuse.org/project/show?project=GNOME%3AUNSTABLE There is still a lot of failures, but low level packages (glib2, cairo, pango) are already built using pkg-buildrequires. It creates BuildRequires automatically in following form compatible with RPM: BuildRequires: list of packages added manually #BEGIN pkg-buildrequires # Created by pkg-buildrequires. Do not edit by hand. BuildRequires: list of packages added by pkg-buildrequires %define pkg_buildrequires_checksum b49abeb28e08721413a59a3d53324613 %define pkg_buildrequires_unknown_checksum cb977b8752a03a75a077316c2efdd439 #END pkg-buildrequires One checksum includes all needed packages. If the list changes, special type of failure will happen. It can be detected, BuildRequires automatically updated and package built again. Second (optional) checksum sums list of all failed pkg-config checks and its presence should confirm, that packager reviewed all failed checks and confirms, that it is correct. If this number changes, user will be notified to take manual action (i. e. add missing package, rebuild and update values). Currently I have no idea, how to do it better and still stay RPM compatible (i. e. in one step). 2) Second idea would require modification of %find_provides and %find_requires to provide/require symbols like PC(libIDL-2.0), which could create devel dependency chain automatically. I see no chance to convert these symbols to package names - if you are building two devel packages from one spec file, there is no way to generate dependencies between them - script does not know file lists of other sub-packages. I plan to extend my experiments in GNOME:UNSTABLE with this (not yet written) script. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

Re: [opensuse-packaging] How to deal with Python .pyc and .pyo files?
by dsfagdf 19 Nov '07

19 Nov '07

Johannes Meixner napsal(a): > > By the way: > > Isn't there a general problem with "python files strewn > all over the system"? Well, yes, that's why i wrote it's bad packaging. But it's a minor problem. Python will work with it (unless the misplaced thing is a python module, in which case python won't be able to find and import it without some hassle) and ordinary user will not notice. This might change when Python is accepted into LSB, because there will probably be some restriction on .py files placement. > How does Python deal with .py files from whatever personal > Python projects in user's home directories? > The user has write access so that he gets .pyc or .pyo files > stored where his .py files are. > What happens if the system admin upgrades to a new major > version of Python? I'm not entirely sure about this, but i think that python will complain and recompile the bytecode files in question. Sadly, i don't have an old enough python anywhere nearby, so i can't test the assumption now. > I think the same problem (perhaps even in a worse shape) > exists for whatever third-party Python stuff which gets > installed somewhere under /opt/ or /usr/local/. > Think about proprietary third-party software which cannot > be changed and which exists for more than one SLES version. Oldest python we support is version 2.2.1 in SLES8, and all new versions since that are at least backwards compatible. So if anyone has a third-party software for python 1.5, too bad for them. But i think that third party vendors would provide python2 compatible packages by now. > I don't know if the Python license allows to have proprietary > Python stuff but I think you understand the basic idea behind. > http://www.python.org/doc/1.5.1p1/tut/node43.html > seems to indicate that at least semi-proprietary Python stuff > can exist because it reads: > --------------------------------------------------------------- > It is possible to have a file called "spam.pyc" (or "spam.pyo" > when -O is used) without a module "spam.py" in the same module. > This can be used to distribute a library of Python code in a > form that is moderately hard to reverse engineer. > --------------------------------------------------------------- > There could be even "binary-only" third-party Python stuff > where no .py files exist. > What happens if a system upgrade (e.g. SLES N -> SLES N+1) > upgrades Python to a new major version? The software will no longer work. Users would need to either keep the older python around, or ask the vendor to recompile the package. But the bytecode files will not be deleted. >> But even more important is that regular user doesn't have write access >> to wherever the .py files are stored. You would need to run each python >> program as root first, otherwise python would need to compile the >> sources every time the program is run. > > This has another consequence: > It doesn't help not to provide .pyc or .pyo files in the RPM > to avoid problems with outdated .pyc or .pyo files if the > Python major version changes because when root runs whatever > .py files, the matching .pyc or .pyo files are created in any case. Right. > > >>> I am no Python expert at all and I would be happy if a Python expert >>> could provide some background information. >> is this background sufficient? ;e) > > Yes, it is perfect and I am happy. glad to read that. regards jan matejek --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] update and renaming blocxx package according to Shared_Library_Packaging_Policy
by Michael Calmer 19 Nov '07

19 Nov '07

Hi, we updated the blocxx package to version 2.1.0 . With this update we also renamed the package to follow the Shared Library Packaging Policy. blocxx-devel => libblocxx-devel blocxx => libblocxx6 Compat package: libblocxx4 Documentation package still has the old name: blocxx-doc The Requires/Obsolets are set correctly, so that everyting should still build. (Tested in BETA since a week now.) But if your package Requires/BuildRequires blocxx/blocxx-devel please change this to libblocxx6/libblocxx-devel the next time when you touch your package. Thanks. -- MFG Michael Calmer -------------------------------------------------------------------------- Michael Calmer SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg T: +49 (0) 911 74053 0 F: +49 (0) 911 74053575 - e-mail: Michael.Calmer(a)suse.com -------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

1 0

[opensuse-packaging] SUSE Linux 10.0 coming to a close
by Marcus Meissner 19 Nov '07

19 Nov '07

Hi, This mail is interesting only for SUSE packagers. Starting after Novell Bug 342146 security issues reported are no longer to be fixed for SUSE Linux 10.0 unless specifically requested by the security team. Existing bugs (<= 342146) still need to be fixed for 10.0. Ciao, Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0