openSUSE Packaging July 2011

packaging@lists.opensuse.org

40 participants
29 discussions

[opensuse-packaging] To getent or not to getent

by Jan Engelhardt

Heya, some packages in the openSUSE distribution do this (or equivalent) in their %post section: %post getent passwd user >/dev/null || useradd user || : darix says this is against policy (what a killer argument), but closely looking at what is happening, getent is just what is desired. If getent were not used, useradd would throw a warning whenever the user already exists, which would be the case on all upgrade attempts of such packages. So people slap in useradd user 2>/dev/null || : instead, but that hides real errors that do not stem from a preexisting user. So, with getent, one can check whether the user already exists and not call useradd if so; otherwise do create the user, and NOT drop any stderr messages. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 11 months

[opensuse-packaging] Detailed changes

by Stephan Kulow

Hi, As there were some discussions about how detailed the changelog should be, I repeat what I said before so everyone is on the same page: Version numbers are per se no information and we want to offer users an easy, standarized way to find out what changed. But it's not the packager's job to collect upstream NEWS. So if the upstream project does not offer a summary, then say so in the .changes file, so also the user knows. If the upstream project does not provide a summary but a detailed web page, then a link is fine too. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 11 months

[opensuse-packaging] perl-Goo-Canvas

by Sascha Manns

Hello Mates, atm i'm trying to fix an error in https://build.opensuse.org/package/show?package=perl-Goo- Canvas&project=home%3Asaigkill%3Abranches%3Adevel%3Alanguages%3Aperl The same error comes in devel:languages.perl The Log (extract): + cd Goo-Canvas-0.06 + /usr/bin/perl Makefile.PL INSTALLDIRS=vendor Package goocanvas was not found in the pkg-config search path. Perhaps you should add the directory containing `goocanvas.pc' to the PKG_CONFIG_PATH environment variable No package 'goocanvas' found at Makefile.PL line 52 *** can not find package goocanvas *** check that it is properly installed and available in PKG_CONFIG_PATH at Makefile.PL line 52 But the goocanvas-devel package includes a *.pc: %files devel %defattr(-, root, root) %{_includedir}/%{name}-2.0/ %{_libdir}/pkgconfig/*.pc %{_libdir}/*.so %doc %{_datadir}/gtk-doc/html/goocanvas2/ So i don't understand what OBS means? Can anyone help me there? -- 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

10 years, 11 months

[opensuse-packaging] openSUSE:11.3:Update and openSUSE:11.4:Update re-setup

by Adrian Schröter

Hi, in preparation to switch to OBS 2.3 maintenance functionality, I will re-setup the projects for the released updates for 11.3 and 11.4 distribution now. This may affect you packagers today, because all the packages inside will be removed and reimported. So, people who build against :Update (which is not default), may see temporary problems or rebuild triggers. However, this will *NOT* affect any users just installing the updates to their system. We will generate the official Update stream afterwards out of these projects, but we will validate first that the result is correct before we redirect the users to the new repository (won't happen this week). In theory the projects should contain the same packages after the re-import, but I discovered already that our old in-house mechanism did it not always correctly. So there will be some minor changes. bye adrian PS: In case of any urgent trouble, there are the "openSUSE:11.3:Update:Old" & 11.4 projects, which contain the current content of :Update but some corrections. -- Adrian Schroeter SUSE Linux Products GmbH 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

10 years, 11 months

[opensuse-packaging] New namespace for KDE apps maintained by upstream

by Javier Llorente

Hi everyone, After some discussion in #opensuse-kde, darix has created the KDE:Apps namespace for KDE apps maintained by their upstream, so that they can serve fresh packages for all distributions supported by the Build Service (which includes openSUSE, SUSE Linux Enterprise, Fedora, RHEL, Debian and Ubuntu). As the first to join in, we warmly welcome the kmymoney project! Got questions? Feel free to contact the openSUSE/KDE Team on the mailing list opensuse-kde(a)opensuse.org or in IRC: #opensuse-kde (irc.freenode.net). Greetings, -- Javier Llorente

10 years, 11 months

[opensuse-packaging] python-ipaddr anyone?

by Claudio Freire

Hi there packagers. I've been packaging python-ipaddr [1] in OBS [2] since we have another project that requires it as a dependency, and I was surprised to find no trace of that module in OBS. Not even in home: projects. Before submitting it for devel:languages:python (and perhaps inclusion in Factory), I was wondering: 1. Was it never included in openSUSE, or was it pulled out for some reason? 2. Is there any special handling of licensing? The project releases under the Apache 2.0 license, do I have to include a license file in the package or something like that? (I checked similar packages in OBS, I couldn't find such a thing, but I remember discussions about this topic on the list). Thanks in advance to anyone who can share some knowledge :-) [1] http://code.google.com/p/ipaddr-py/ [2] https://build.opensuse.org/package/show?package=python-ipaddr&project=home%… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 11 months

[opensuse-packaging] HAL and related

by Ilya Chernykh

First of all I want to ask whether hal will be available under 12.1 or it is to be decided? My second question is as follows. As you know, hal is depreciated and people who prepare 12.1 want to remove dependency on hal from different packages. For instance they want to remove it from kdebase3-runtime which will be included in 12.1. But hal is necessary for normal function of KDE3 so we, who use KDE3 as a desktop want hal functions to be enabled. That's why my question. Is it possible to build a package with hal if hal is available in the repository and without hal otherwise? How to properly organize the check on whether the package exists in the repo at the buildtime? Or may be another solution based on an option constant defined in the project's properties is better? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 11 months

[opensuse-packaging] Newbie's questions about perl-Net-Z3950-ZOOM

by Andi Sugandi

Hi Packagers, I'm trying[0] atm to package perl-Net-Z3950-ZOOM[1] which I just already realized today that (afaik) the module had been provided[2] perl-Net-Z3950 from d:l:p by seeing its spec file[1]. [..] %{perl_vendorarch}/Net/Z3950/ZOOM.pm Should perl-Net-Z3950-ZOOM be deleted from OBS because of it? If I want to learn how to package and use OBS, so why my perl-Net-Z3950-ZOOM's build process still fails.[3] Thanks in advance. [0] http://lists.opensuse.org/opensuse-buildservice/2011-07/msg00048.html [1] https://build.opensuse.org/package/show?package=perl-Net-Z3950-ZOOM&project… [2] https://build.opensuse.org/package/view_file?file=perl-Net-Z3950.spec&packa… [3] https://build.opensuse.org/project/monitor?blocked=0&building=0&dispatching… Best regards, -- Andi Sugandi. openSUSE-id Team, openSUSE Community Member. https://connect.opensuse.org/pg/profile/andisugandi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 11 months

[opensuse-packaging] Fwd: [systemd-devel] [RFC] Preset Files

by Andreas Jaeger

I'd like to hear some feedback on the proposal below so that we can pass it on to the systemd developers, Andreas ---------- Forwarded Message ---------- Subject: [systemd-devel] [RFC] Preset Files Date: Tuesday, July 05, 2011, 21:21:03 From: Lennart Poettering <lennart(a)poettering.net> To: systemd Mailing List <systemd-devel(a)lists.freedesktop.org> Heya, many of you probably saw Frederic's rpm macros suggested here. This got Kay and me thinking about implementing something like "presets" in systemd, and before we go and implement that we'd like to hear your opinions on it. This would go hand in hand with Frederic's macros, and both would be included in the upstream systemd package. So what's a "preset" supposed to be? Distributions have different policies on enabling services by default. On Fedora services should default to off, with a small number of exceptions. On Debian OTOH all services are enabled by default. Fedora spins in turn are based on the default Fedora settings but might end up enabling a few services not enabled on the unflavoured Fedora. In general, on desktop systems (i.e. without an educated admin) a default of "enable what is installed" probably makes sense, while many seasoned admins will probably opt more towards the other extreme: "I, the admin am king, and I am the only one enabling services here!". Both approaches of course are valid approaches. Now, traditionally whether a service was enabled or not on most distros was encoded in the packages themselves (i.e. in chkconfig in lines in the scriptlets, or something equivalent), which makes it very difficult to apply spin-specific or admin-specific rules on top. This is information that should not be encoded in the packages, but in some external database. And this is what "presets" are supposed to be. Something like a long list that tells systemd which services to enable by default and which ones not to enable. It's a bit like a SUSE pattern or a Fedora comps, except that it lists services that shall be enabled instead of package that shall be installed. More specifically this is how it should work: We'd have a directory /lib/systemd/system.preset/. By default it would be empty (or not even exist), which for simplicity reasons would mean "enable everything installed" (i.e. the Debian policy). Then, if distros or spins want to change what is enabled by default, they'd drop in a file (or multiple, which might be useful for a desktop spin and a graphical design spin where the latter is a superset of the former) in that directory. The file would be a trivial text file with lines like this: <snip> disable avahi-daemon.service enable cups.service disable * </snip> Then, we'd add a new command to "systemctl" called "systemctl preset". It would be equivalent to a "systemctl enable" if the unit file passed is listed in any of the preset files on lines prefixed with "enable", or be like a "systemctl disable" if it is listed with a prefix of "disable". Simple globbing would be supported. If no entry is found "systemctl preset" would be synonymous with "systemctl enable". If "systemctl preset" is passed with unit names, those units would be enable/disabled as listed in the preset file. If no argument is passed all units would be reset to the preset defaults. (another long-sought feature...) A few more things to note: - systemd would not ship any preset file by default (and probably not even the directory), this is left to distributions. Most likely the distributions would ship a preset file in some spin-specific RPM, which would conflict with the the RPMs for other spins. - The RPM post macro would always call "systemctl preset" for the units passed, and never anything else. - If an admin wants to manually change "enable-by-default" to "disable-by-default" (or vice versa) he could just drop his own file with "disable *" (or "enable *") into /etc/systemd/system.preset/ and override the vendor/spin settings. - One nice thing is that this would be dead simple to implement (just 10 lines of code or so), and would practically not be visible on systems who don't need any distro spin crack... ;-) - This would kinda bring back the ability that some SysV implementations had with encoding the default enable/disable state for a service somewhere. Some distros had that in the SysV header. With this we now have it independently of the init scripts. - The reason why we'd implement "enable-by-default" instead of "disable-by-default" if no preset file is around is simply the idea that having to install stuff that is not needed is already a failure in itself, and ideally people who want to disable a service would just "rpm -e" it. Anyway, this of course requires some buy-in from the distributions, so I'd like to ask the distro maintainers for comments on this. Do you think this would be useful to you? Any other suggestions, ideas? Note that even if we implement this in systemd (which is very likely) it is of course up to the distros to make use of this. If they still want to enable (or disable) all services unconditionally then they can still do so in RPM scrips, but we'd of course greatly welcome if distros would support this new scheme instead of cooking their own. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel(a)lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ----------------------------------------- -- Andreas Jaeger, Program Manager openSUSE aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 11 months

[opensuse-packaging] pack check error for SLE help

by Robert Schweikert

HI, I get an error for the opennebula package for the SLE target as follows: ... checking filelist The following directories from opennebula-2.2.1-11.1.x86_64.rpm are already part of the filesystem RPM: /etc/init.d The spec file contains the following? %files %defattr(-,root,root,-) %doc LICENSE NOTICE README %config %{_sysconfdir}/* %{_datadir}/one/hooks/* %{_bindir}/* /usr/lib/one/* /var/lib/one/* /etc/init.d/one %dir /usr/lib/one %dir /var/lib/one %dir %{_datadir}/one %dir %{_datadir}/one/hooks How do I go about fixing this problem? Project: Virtualization:Cloud:OpenNebula Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 11 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging July 2011