openSUSE Packaging November 2012

packaging@lists.opensuse.org

66 participants
52 discussions

[opensuse-packaging] openSUSE Packaging Guidelines Update
by Andreas Jaeger 21 Nov '12

21 Nov '12

On the opensuse-packaging mailing list, we've recently formed a team that will take care of the packaging guidelines and introduced a small process to change them: http://en.opensuse.org/openSUSE:Packaging_guidelines_change_process As part of that process, we're announcing regularly the changes to the packaging guidelines. Since this is a first such announcement, it is not a complete change but just points out a few things from the past few months. In the future, we will send out this email once a month. The Packaging guidelines can be found at http://en.opensuse.org/openSUSE:Packaging_guidelines . List of changes =============== 1) New Lua Guidelines 2) Reworked font guidelines 3) Documenting changes in packages 4) Teams involved, contact Details ======= 1) New Lua Guidelines We now have guidelines for lua: http://en.opensuse.org/openSUSE:Packaging_Lua. 2) Reworked font guidelines The packaging of fonts has been completely changed, and is documented at http://en.opensuse.org/openSUSE:Packaging_Fonts 3) Documenting changes in packages The openSUSE review team is now also enforcing proper documenting changes in packages: First, the .changes entry (rpm changelog) surves two purposes: - News for the user - History tracking of packaging changes (often referenced in bugs to verify if a user has the latest packaging bugfixes). 3.1) Information about updates A simple "Update to version x.y.z" is, as before, not accepted. There should be some buzz around the update for the user; some major reasons to the upgrade should be listed. Changes on the package itself should be mentioned in a way that any other contributor to the same package can follow traces of why something is the way it is. Commonly, Added (build)dependencies are interesting to be seen, special hacks to make something work in a particular way [..]: Always consider that package maintenance is a distributed task and various contributors need to be able to step up at will. 3.2) Documenting patch life cycle The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed) The main appeal is to the devel project maintainers / reviewers, to keep out for those rules, to live according to them, as it is frustrating for everybody if a package needs to be declined by the openSUSE Factory Review team: - The dev prj maintainer is the one getting the 'decline' (as it was usually a forwarded request), which often leaves the 'fixing' to the devel project maintainers, where the 'originator' of the fix would have been willing to actually do that... Note: The review team is not enforcing the usage of patch markup unless the package already follows this convention. 4) Teams involved, contact I mentioned two teams previously, these are the openSUSE review team (details at http://en.opensuse.org/openSUSE:OpenSUSE_review_team) and the team taking care of the guidelines (details at http://en.opensuse.org/openSUSE:Packaging_guidelines_change_process#Team_me…). You can reach both via the openSUSE-packaging mailing list. On behalf of the teams, Andreas -- Andreas Jaeger 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,HRB16746 (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 To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 12

[opensuse-packaging] mysterious failing of package build
by Detlef Steuer 20 Nov '12

20 Nov '12

Hi! I hope this is the correct list to ask such questions. In project devel:languages:R:devel/R I'm trying to build packages for the next upstream version of R. There are some changes in upstream, but I don't understand why all files are declared [ 2007s] Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/abuild/rpmbuild/BUILDROOT/R-base-2.16.0-1.1.x86_64 error: Installed (but unpackaged) file(s) found: [ 2014s] /etc/ld.so.conf.d/R.conf [ 2014s] /usr/bin/R [ 2014s] /usr/bin/Rscript [ 2014s] /usr/lib64/R/COPYING [ 2014s] /usr/lib64/R/NEWS [ 2014s] /usr/lib64/R/NEWS.pdf [ 2014s] /usr/lib64/R/SVN-REVISION [ 2014s] /usr/lib64/R/bin/BATCH [ 2014s] /usr/lib64/R/bin/COMPILE [ 2014s] /usr/lib64/R/bin/INSTALL [ 2014s] /usr/lib64/R/bin/LINK [ 2014s] /usr/lib64/R/bin/R [ 2014s] /usr/lib64/R/bin/REMOVE [ 2014s] /usr/lib64/R/bin/Rcmd [ 2014s] /usr/lib64/R/bin/Rd2pdf [ 2014s] /usr/lib64/R/bin/Rdconv [ 2014s] /usr/lib64/R/bin/Rdiff [ 2014s] /usr/lib64/R/bin/Rprof [ 2014s] /usr/lib64/R/bin/Rscript .... and so on. For me these files are definitly included in the spec. (And the spec works e.g. devel:languages:R:base, part of factory) It should fail at the end for some newly added translation changes, but not for each and every file. Any hint very appreciated! (And of course any hints to improvements of the spec in general) Detlef -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 3

[opensuse-packaging] Packaging of AppArmor profiles
by Christian Boltz 20 Nov '12

20 Nov '12

Hello, a short discussion with Marcus at the conference brought up an issue with packaging AppArmor profiles: When a package containing an AppArmor profile is installed or updated, the profile is not (re)loaded. This means it will only become active when the admin actively reloads the profiles or when the machine is rebooted. Until then, either the previous profile is used (update case) or the application will run unprotected (if a new profile was installed). This mail is a first draft on how to handle this. Instead of re-inventing the wheel ;-) I asked upstream (which is basically Ubuntu) and got the information that they use this debhelper: http://bazaar.launchpad.net/~ubuntu-core- dev/apparmor/master/files/head:/debian/debhelper/ The most interesting part is probably postinst-apparmor, which can be the base for a %post macro. (IMHO creating the local/ sniplet shouldn't be part of that macro. Maybe we should create a separate macro for it, but that's a minor issue.) I propose the following macro to be used in %post: (untested ;-) %apparmor_profile_post() \ # Reload the profile, including any abstraction updates \ if aa-status --enabled 2>/dev/null; then \ apparmor_parser -r -T -W "/etc/apparmor.d/%1" || true \ fi This will (re)load the profile if both apparmor-utils (aa-status) and apparmor-parser are installed and apparmor is enabled. Otherwise it will just fail silently. Usage in %post: %apparmor_profile_post usr.sbin.foo (where "usr.sbin.foo" is the filename of the profile in /etc/apparmor.d) Another question is directory ownership of /etc/apparmor.d/ and the availability of the abstractions and tunables (which are used by nearly every apparmor profile). The easiest way would be to add Requires: apparmor-profiles to every package shipping an apparmor profile. Note that apparmor-profiles contains some profiles itsself, which would then also become active (unless someone disables them manually). Do you think this is a problem? (If yes, I can split the abstractions and tunables into a separate package.) And a final question: Into which package should I put the rpm macro? (This package will then also be needed in BuildRequires:) libapparmor-devel doesn't sound right because most packages don't need libapparmor, and I also don't like the idea of creating an apparmor- devel just for this file. Remaining candidates are apparmor-profiles[1] and apparmor-parser. apparmor-profiles[1] would have the advantage to also solve the "unpackaged directory" warnings for /etc/apparmor.d/ (Unless someone doesn't like to have the rpm macro in the apparmor- profiles[1] package, it's my favorite for now ;-) Maybe I'll also create another macro %apparmor_requires containing the Requires: and BuildRequires:, but that's a technical detail ;-) (In this case, the more interesting question is where the %apparmor_requires macro should be packaged - storing it in an apparmor package would cause a chicken-egg problem ;-) As usual: feedback welcome ;-) Regards, Christian Boltz [1] or apparmor-abstractions if we decide to split the abstractions into a separate package -- F: Word? Was ist das? A: Das ist wohl das Programm, das ursrpünglich einmal Text heißen sollte. Da es aber für längere Dokumente ungeeignet ist, wurde es umbenannt. Inzwischen kann es aber bereits 97 Wörter verwalten. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] Base:System "cleanup"
by Stephan Kulow 20 Nov '12

20 Nov '12

Hi, As I heard more and more conflicting complaints about Base:System I decided to go and do something about it. The complaints were either "I get too many mails about it, so I stopped caring" or "I can't care right now, but I don't want other people to work on my requests". As Base:System is just too large to follow one policy, but it's still about the most important devel project we have for the distribution, I think extra care is to be taken. So I did two things (in the light, but not following Robert's words 100%): - Reduced the list of project maintainers of Base:System *dramatically*, leaving still enough of people to be sure there are maintainers around to review things like adding new packages. - Added package bugowners also as maintainers to their packages. - Added the top 3 contributors to a package also as maintainer - unless the contribution is a single commit to the package. So if you find yourself now in or out a package you care or not care, please either just email me or file an add_role request. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] Where did source services disappear in Web interface?
by Andrey Borzenkov 19 Nov '12

19 Nov '12

I cannot find source services configuration in new web interface anymore. Are they no more supported? TIA -andrey -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 3

[opensuse-packaging] Fwd: [sleuthkit-users] Framework on Linux / OS X
by Greg Freemyer 19 Nov '12

19 Nov '12

Question from upstream package (tsk) about managing a config data directory. See their email below, but it asks about how they should manage configuring multiple possible config data locations. (ie. "/etc/tsk" or "~/.tsk" or even "~/.tsk; /etc/tsk"). Upstream is proposing either having a hardcoded value in the source which is updated prior to compiling OR alternatively to use a environment variable. I assume the answer in order of preference is: 1) Have the hardcoded default value and let ./configure override it by modifying the source. (I'm not enough of an autotools guy to do that, but I assume it can be done.) 2) Environmental variables are preferred if and only if each user has their own config data location and it can't be a standard like ~/.tsk Before I send that back to upstream, can someone confirm I have it right. Thanks Greg ---------- Forwarded message ---------- From: Brian Carrier <carrier(a)sleuthkit.org> Date: Fri, Nov 16, 2012 at 5:31 PM Subject: Re: [sleuthkit-users] Framework on Linux / OS X To: Greg Freemyer <greg.freemyer(a)gmail.com> Cc: "sleuthkit-users(a)lists.sourceforge.net users" <sleuthkit-users(a)lists.sourceforge.net> To the packagers in the audience, how do most programs deal with the fact that the configuration data (that is needed by an executable) could be installed in a different location (/usr/share/tsk versus ~carrier/tsk/share/tsk)? Do they have the Makefiles/configure scripts add a string into a header file and hard code the path in during the compiling phase? Environment variables? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] introducing new file types
by Denny Beyer 16 Nov '12

16 Nov '12

Dear packagers, please share your thoughts on the following issue: A package comes with it's own filetypes. How do I get the correct filetype association? - So, when clicking on the file, this program will be opened? The new filetypes are *.cademia and *.cademia_macro . Besides it's own file format, it should also be associated with *.dxf files, which I've done already. The wiki doesn't cover that topic, so I ask here. Package: cademia in Project: home:cademia or Project: home:lumnis Thanks! Denny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] Factory Status (2012/11/11)
by Cristian Morales Vega 14 Nov '12

14 Nov '12

I am going to change the approach a bit here. For packages failing for more than 14 days I am going to open bug reports and link them here. For the rest (7 to 14 days) I will continue as usual. Name Devel Project User Status - perl-Digest-Whirlpool devel:languages:perl coolo Fails for 10 days: memory corruption: 0x0957942e - python-slumber devel:languages:python saschpe Fails for 10 days: python changes (New upstream version 0.5.1 available) - python3-distribute openSUSE:Factory jimfunk Fails for 8 days: Installed (but unpackaged) file(s) found - CodeAnalyst devel:tools suravee Fails for 8 days: binutils update (libbfd) Name Devel Project Bug report Status - elilo Base:System bnc#789159 Fails for 107 days: undefined reference to `__stack_chk_fail_local' (New upstream version 3.14 available) - selinux-policy security:SELinux bnc#789160 Fails for 89 days: error(s) encountered while parsing configuration (Different changes in devel project (since 6 months)) - compiz X11:Compiz bnc#789161 Fails for 59 days: kwin changes - kdegraphics3 KDE:KDE3 bnc#789162 Fails for 57 days: gphoto update (Current sources were declined: request 138654) - xerces-j2-bootstrap openSUSE:Factory bnc#789163 Fails for 48 days: temporary failure - hawk network:ha-clustering:Factory bnc#789165 Fails for 48 days: cannot load such file -- gettext/tools/rgettext (rails 2 vs rails 3?) - grub Base:System bnc#789168 Fails for 41 days: error: 'stdscr' undeclared (first use in this function) (New upstream version 1.96 available) - trustedgrub security bnc#789169 Fails for 41 days: error: 'stdscr' undeclared (first use in this function) - libsyncml0 mobile:synchronization:FACTORY bnc#789170 Fails for 41 days: error: 'g_mutex_new' is deprecated - irc-otr server:irc bnc#789175 Fails for 38 days: error: too few arguments to function 'otrl_message_receiving' - psi network bnc#789178 Fails for 38 days: error: 'OtrlMessageAppOps' has no member named 'notify' (Current sources were declined: request 138463) - tasks GNOME:Apps Fails for 38 days: "Only <libecal/libecal.h> should be included directly. - libopensync-plugin-evolution2 mobile:synchronization:FACTORY Fails for 38 days: Only <libebook/libebook.h> should be included directly. - planner GNOME:Apps Fails for 38 days: error: libedataserver/e-source-list.h: No such file or directory - gnome-do-plugins GNOME:Apps Fails for 38 days: Type `FlickrNet.FoundUser' does not contain a definition for `Username' - qutim KDE:Distro:Factory Fails for 38 days: libotr update - f-spot GNOME:Apps Fails for 38 days: The type or namespace name `Licenses' could not be found - python3-numpy openSUSE:Factory Fails for 37 days: 'PyUnicodeObject' has no member named 'length - python3-progressbar openSUSE:Factory Fails for 37 days: 'format' in __slots__ conflicts with class variable - python3-Sphinx openSUSE:Factory Fails for 37 days: No module named 'rst' - libgdiplus0 Mono:Factory Fails for 30 days: https://bugzilla.novell.com/show_bug.cgi?id=778506 (Different changes in devel project (since 2 months)) - uwsgi server:http Fails for 27 days: broken erlang - libreoffice LibreOffice:Factory Fails for 25 days: UTF8.h: No such file or directory (Request 140733 to openSUSE:Factory) - sgmltool Publishing Fails for 23 days: bison update - branding-basedonopensuse system:install:head Fails for 22 days: gdmflexiserver conflicts - ibus-rime M17N Fails for 18 days: undefined reference to `RimeSetupLogging' - libsmi network:utilities Fails for 18 days: bison/flex update - dosemu Emulators Fails for 18 days: bison/flex update - openttd-opengfx games Fails for 18 days: broken test suite (Different sources in devel project (since 17 days)) - crawl games Fails for 16 days: pngs can't be opened I will create the rest of bug reports when I have time. I don't want to delay the email any more. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

9 12

[opensuse-packaging] OBS no longer show some packages
by Jiri Slaby 14 Nov '12

14 Nov '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Since the update, URLs like these no longer work: https://build.opensuse.org/package/show?package=psi+&project=network The plus symbols makes it defunct. (This is an URL what I got from OBS in network project when I searched for psi and clicked on that. thanks, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQnnnNAAoJEL0lsQQGtHBJJPAP/iguSz91KZIHV/2D5s0NwsnS 78DnIC8OvhgEwim+R6KccYTWjvTCKyxD5PxK2hBNu4sHg6sD3zq8umqXX1ZoPLoP 3lcosigX6RjbL/xM+jxQC+7p/7guAGpsmAs+0IWpnOpN9RBMCqzK2UHKhGgYvsxM W0YkCsvku8uw0TYy4poVplQRVWNES29cktrqKMsaogPlHpNh4aea+C8NyIt9UNMx EkK8zmoM+cYo1RAi/0Ecg4gl0RV6RKEurKEGfiQYcXk/IQeYvRZMfuYJt5+TkfXD Ji/eZtejzzKayGGZC78y9QW/7WehYIPBjVJjSVGf17gTvKMkUQkl/JQIwu0upcxZ 3NAZiQwa/xE2PA4bxWXoY27FYtsK/iM2NI0IviClg1SCYaCOXhZEj/3+zz0giX8X WXMbihL7yY0GS6UeIyVqsPQe/DK2KwSb6j5ZpvdoxxohYjb8vFyxAun936KSg6Np AXOsc/Y4JPh0RlKBULIKEIp+jzXL2CqUwEp8cp+m42X3G+OcMf7FNu+V1m/PFkkv LzxuahUpj3HVyRWKBFx7PbF/ga3W/Ac5J62G1UmfSqtGkfoWJbfh44QkhRlN33zl E1xQIcqS+zbHwflML93rXuHoaTVd2l5m5xNCbc9i2MnFpa5vwYigqFrNydHcrcxR TQ3ZyfBaecgBCEj2cI31 =qeHJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] debian build fails "no tar file" - what's wrong?
by Ralf Lang 14 Nov '12

14 Nov '12

https://build.opensuse.org/package/live_build_log?arch=x86_64&package=php5-… The build log says the project has no tar file but obviously the tgz file is present. What did I do wrong? -- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging November 2012