February 2007 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] mingw cross-toolchain
by Robert Schiele 13 Mar '07

13 Mar '07

Hello! I have packaged a cross-toolchain for Windows machines based on the latest releases of the mingw gcc port. You can find everything at http://pi3.informatik.uni-mannheim.de/~schiele/suse/. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."

5 12

[opensuse-packaging] New Functionality: Ports for SuSEfirewall added via packages
by Lukas Ocilka 05 Mar '07

05 Mar '07

Hi, A new functionality "Ports for SuSEfirewall added via packages" (FATE #300687) has been added to YaST in openSUSE 10.3. Of course, this functionality needed to be implemented in SuSEfirewall2 first (since openSUSE 10.2 thanks to Ludwig). So what is it all about and why am I writing about it to this mailing-list? In older versions of YaST Firewall, there was a hard-coded list of so called "Known Services" (e.g., Samba Server or DNS Server) with defined ports to be open in firewall but this list didn't reflect the current state of installed packages and it was a pain to add a new service there. What the current solution offers? * Only installed services are offered in YaST Firewall to be open. * Abstraction layer for SuSEfirewall2 that increases the security. * Solved conflicting services - lighthttpd vs. apache2, nfs vs. nis. * No need for hard-coded and not-maintained static list. More detailed information: http://en.opensuse.org/SuSEfirewall2/Service_Definitions_Added_via_Packages Some of you have been already assigned to a bugzilla enhancement, that requests adding such configuration file into your packages and more will probably come. PS: Just a small change for using these services in YaST. Using the hard-coded list is an obsolete functionality but still remains the same, for using the new definition of services, you need to identify the service by "service:${service-id}". Thanks & Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

2 1

[opensuse-packaging] .la files and dependencies, again
by andreas.hanke＠gmx-topmail.de 27 Feb '07

27 Feb '07

Hi, I just had a look on popt (which packages it has a dependency on, which packages depend on it) and was again astonished by the impact its .la file (/usr/lib/libpopt.la) has. Only very few packages really require popt (rpm and libgnome, to name a few). But the .la file infects all packages above them in the dependency chain so that they will also depend on popt even if they don't have to. This happens to affect mostly GNOME packages... The following packages currently have dependencies on popt-devel although they don't #include <popt.h>: gnome-bluetooth-devel gstreamer010-devel libgnomeui-devel libzypp-devel orbit2-devel Why? Because of a libtool dependency check that completely ignores the fact that these dependencies are generated by the .la files. The .la files are not storing actual dependencies, they are generating new ones. Just as an example: # grep popt /usr/lib/libzypp.la dependency_libs=' /usr/lib/libxml2.la -lcurl /usr/lib/libidn.la -lssl -lcrypto /usr/lib/librpm.la /usr/lib/librpmdb.la /usr/lib/librpmio.la -ldl -lpthread -lz -lbz2 /usr/lib/libpopt.la /usr/lib/libgobject-2.0.la /usr/lib/libdbus-glib-1.la /usr/lib/libgobject-2.0.la /usr/lib/libglib-2.0.la -lnsl /usr/lib/libglib-2.0.la -lrt /usr/lib/libhal-storage.la /usr/lib/libhal.la /usr/lib/libhal.la /usr/lib/libdbus-1.la /usr/lib/libdbus-1.la -lboost_regex -lboost_filesystem -lutil' But: # rpm -ql libzypp-devel | xargs grep popt\\.h (no matches) # ldd -u -r /usr/bin/zypper Unused direct dependencies: /usr/lib/libpopt.so.0 In fact there is no need to link zypp-based programs to popt because zypp does not expose it, but libtool adds it anyway just because /usr/lib/librpm.la has it. In short, .la files always contain as many dependencies as possible. These dependencies were not present if the packages were not installing their .la files. Another flaw with this approach is that it's a one-way thing. Dependencies are added if needed, but never removed. Example: Some time ago, a package really used popt, so the check told you to add "Requires: popt-devel" to the -devel package. Later, the package stops using popt, but the check doesn't notice that and the dependency will stay forevermore. This is especially annoying if the authors of this package spent resources into getting rid of that dependency. # rpm -ql libnotify-devel | grep \\.la /usr/lib/libnotify.la # grep popt /usr/lib/libnotify.la (no matches) # rpm -ql libnotify-devel | xargs grep popt\\.h (no matches) And now the worst thing: # rpm -ql libnotify | xargs grep popt /usr/share/doc/packages/libnotify/ChangeLog: - Patch by M.S. to switch notify-send to use GOption instead of popt, /usr/share/doc/packages/libnotify/NEWS: * Patch by M.S. to switch notify-send to use GOption instead of popt, But it happily requires popt-devel anyway: # rpm -q --requires libnotify-devel | grep popt popt-devel There is no way to get rid of these again other than manually looking at the packages and manually trying to find out why the dependencies have been added and if they are still needed. ARGH! Andreas Hanke -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 36

[opensuse-packaging] Adding grub2 ?
by Jerone Young 26 Feb '07

26 Feb '07

I have a patch for grub2 that allows it to coexist with grub1 install. What are the possibilities of getting grub2 included into Suse 10.3? --------------------------------------------------------------------- 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] msp430 cross-toolchain
by Robert Schiele 23 Feb '07

23 Feb '07

Hello! For those interested: I have packaged a cross-toolchain for msp430 based systems including the firmware for the ESB, ECR, and eGate platform. You can find everything at http://pi3.informatik.uni-mannheim.de/~schiele/suse/. Read more details at http://www.nabble.com/RPM-packages-of-the-current-toolchain-p8105657.html and http://lists.spline.inf.fu-berlin.de/mailman/private/scatterweb/2006-Decemb… Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."

1 1

[opensuse-packaging] Remove project "Xgl"
by Matthias Hopf 23 Feb '07

23 Feb '07

Could some admin please remove the project "Xgl"? It's apparently dead, was never active, and xgl can be found "officially" in X11:XGL. Thanks Matthias -- Matthias Hopf <mhopf(a)suse.de>, SuSE R&D, Zimmer 3.2.06, Tel. 74053-715 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 2

[opensuse-packaging] lbuild and kernel-syms
by Jan Engelhardt 20 Feb '07

20 Feb '07

Heya, rebuilding kernel-syms.spec through lbuild 0.0_svnr1043m gives the following interesting bits: installing kernel-bigsmp-2.6.18.6-jen43 Setting up /lib/modules/2.6.18.6-jen43-bigsmp /var/tmp/rpm-tmp.456: line 76: /sbin/depmod: No such file or directory installing kernel-default-2.6.18.6-jen43 Setting up /lib/modules/2.6.18.6-jen43-default /var/tmp/rpm-tmp.68149: line 76: /sbin/depmod: No such file or directory installing kernel-desktop-2.6.18.6-jen43 Setting up /lib/modules/2.6.18.6-jen43-desktop /var/tmp/rpm-tmp.19390: line 76: /sbin/depmod: No such file or directory installing kernel-xen-2.6.18.6-jen43 Setting up /lib/modules/2.6.18.6-jen43-xen /var/tmp/rpm-tmp.56418: line 76: /sbin/depmod: No such file or directory installing kernel-xenpae-2.6.18.6-jen43 Setting up /lib/modules/2.6.18.6-jen43-xenpae /var/tmp/rpm-tmp.55113: line 76: /sbin/depmod: No such file or directory ... installing module-init-tools-3.2.2-62 ... error: File not found by glob: /var/tmp/kernel-syms-2.6.18.6-build/lib/modules/*/modules.alias Guess what, module-init-tools got installed too late. How to fix? -`J' -- --------------------------------------------------------------------- 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] /usr/share/gtk-doc
by Bernhard Walle 20 Feb '07

20 Feb '07

Hello, /usr/share/gtk-doc doesn't belong to a package. Shouldn't it belong to gnome-filesystem since /opt/gnome/share/gtk-doc belongs to that package and GNOME will be moved to /usr in 10.2? It's to fix build errors in some Xfce packages. Thanks. Regards, Bernhard

3 3

[opensuse-packaging] Odd locales breaking the build
by Joe Shaw 15 Feb '07

15 Feb '07

Hi, I need some guidance on best practices. In a recent release of my package, a new translation was added that is pretty uncommon (Dzongkha - dz). Because we don't have this in the list of locales in the filesystem package, the build is breaking: beagle-0.2.16.1-0.3.i586.rpm: directories not owned by a package: - /usr/share/locale/dz - /usr/share/locale/dz/LC_MESSAGES What/where is the right place to fix this? Thanks, Joe --------------------------------------------------------------------- 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] cleaning the buildroot correctly
by Marcus Meissner 15 Feb '07

15 Feb '07

Hi, darix asked me to post this ;) Quite some time ago we had the discussion how the buildroot should be created in a secure way in %install. BAD: %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/usr/... or make install Why? RPM_BUILD_ROOT is within /var/tmp and you just opened a trivial race condition to a local attacker on your machine to take over your account (or event root if you build as root). It is better not to "rm -rf $RPM_BUILD_ROOT" in %install at all (and rely on %clean to do it). If you want to clean it, better do: %install rm -rf $RPM_BUILD_ROOT mkdir $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/usr ... or make install In this case the "mkdir $RPM_BUILD_ROOT" would fail and the build would abort if an attacker tries to replace the buildroot by his own symlink. (or similar ;) Ciao, Marcus -- Working, but not speaking for the following german company: SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 5