March 2009 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Package: dumb Project: home:saigkill
by Sascha 'saigkill' Manns 10 Mar '09

10 Mar '09

Hello Mates, at this moment, i'm building dumb (a Music Library). A part of the RPMLint Warnings i've fixed. But a few Warnings are present. dumb.x86_64: W: executable-stack /usr/bin/dumbplay That i never heard. libdumb0_9_3.x86_64: W: shlib-policy-missing-lib This is strange. I've created an Subpackage with the *.so and RPMLint doesn't see it. libdumb0_9_3.x86_64: W: shlib-unversioned-lib libdumb-0.9.3.so libdumb0_9_3.x86_64: W: shlib-unversioned-lib libaldmb-0.9.3.so I think, this i can ignore. Versionformat x.x.x.so is compatible with the Guides. libdumb0_9_3.x86_64: W: unstripped-binary-or-object /usr/lib64/libaldmb-0.9.3.so libdumb0_9_3.x86_64: W: unstripped-binary-or-object /usr/lib64/libdumb-0.9.3.so I think i can place this in the rpmlintrc. -- Sincereley yours Sascha Manns openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Project-Blog: http://lizards.opensuse.org/author/saigkill Private-Blog: http://saschasbacktrace.blogspot.com DISCLAIMER: Please note that in accordance with the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. http://www.vorratsdatenspeicherung.de http://www.ccc.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 13

[opensuse-packaging] Re: [obs submit-request 7749] openSUSE:Factory:Contrib/qcad-free: created by pgajdos
by Michal Vyskocil 09 Mar '09

09 Mar '09

On Monday 09 of March 2009 15:48:29 Petr Gajdos wrote: > home:pgajdos:Contrib/qcad-free -> openSUSE:Factory:Contrib/qcad-free > > > https://build.opensuse.org/package/show?package=qcad-free&project=home:pgaj >dos:Contrib > https://build.opensuse.org/package/show?package=qcad-free&project=openSUSE: >Factory:Contrib What's the difference between existing qcad you maintain in Contrib and this new qcad-free? If you would like to rename an existing package, please follow an existing rules for it [1]. What's the origin of archive called qcad-free-090301.tar.*? I found only qcad- community-2.0.5.0-1-comunity.src.tar.gz [2] on ribbonsoft.com dowload page [3]. Google didn't helped me. [1] http://en.opensuse.org/Upgrade_Dependencies#Renaming_a_package [2] ftp://anonymous@ribbonsoft.com/archives/qcad/qcad-2.0.5.0-1- community.src.tar.gz [3] http://www.ribbonsoft.com/qcad_downloads.html Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 1

[opensuse-packaging] Fedora packaging Guidelines imported
by Michal Vyskocil 09 Mar '09

09 Mar '09

Hi all, I'd like to announce I have imported Fedora Packaging Guidelines [1] to openSUSE wiki [2]. I excluded following pages: http://fedoraproject.org/wiki/Packaging:FullExceptionList http://fedoraproject.org/wiki/Packaging:SugarActivityGuidelines http://fedoraproject.org/wiki/Packaging:GCJGuidelines http://fedoraproject.org/wiki/Packaging:Committee http://fedoraproject.org/wiki/Packaging:OldJPackagePolicy http://fedoraproject.org/wiki/Packaging:FontsSpecTemplate Which seemed that they are not important for openSUSE (or are empty in Fedora wiki like FullExceptionList), but I could add them later, if you missed them. I also renamed the page titles, unfortunately only them, so links are wrong. But every page must be reviewed before it should be used, so this is not a big problem. I'll start a work on merging the documentation to the Guidelines (volunteers are welcome :-)). You can just change the content and remove the part which differs from Fedora, but try to keep changes as smallest as possible to allow easy merging of changes between Fedora and SUSE. I'm planning to use a git repository to help track a changes between Fedora and SUSE, but it will be a lot of manual work (I expect). [1] https://fedoraproject.org/wiki/Packaging:Guidelines [2] http://en.opensuse.org/Packaging/Guidelines [3] http://en.opensuse.org/Packaging/Guidelines#Prepping_BuildRoot_For_.25insta… Best regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

6 13

[opensuse-packaging] Gcc 4.4 again
by Stephan Kulow 09 Mar '09

09 Mar '09

Hi, I disabled the staging repo and linked all packages that currently fail into a new project. So it should be easier for you now to verify if your package creates a problem. Just visit http://tinyurl.com/brslzp Right now there are ~130 packages. Note that some of them also fail with gcc 4.3, but we need to fix these too :) We still don't have a rush to use that compiler as default, but most failures are easily catched - so if someone is interested, just build against Factory:Gcc44 and do submitrequests against the devel project. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 1

[opensuse-packaging] rpmlint: shlib-policy-name-error only on i586
by Matthias Fehring 09 Mar '09

09 Mar '09

Hello list, on the following packages in the Build Service project KDE:Community, rpmlint complains about shlib-policy-name-error only on i586, on x86_64 this does not happen. I am a little bit confused about that... Both packages contain kicker applets. https://build.opensuse.org/package/show?package=KPrayertime&project=KDE:Com… https://build.opensuse.org/package/show?package=klipoquery&project=KDE:Comm… Best greetings Buschmann ---------------------------------------------------------------------------------- openSUSE Member - de.opensuse.org Sys-Op http://en.opensuse.org/User:Buschmann23

3 4

[opensuse-packaging] kqlives: Config question
by Sascha 'saigkill' Manns 08 Mar '09

08 Mar '09

Project: home:saigkill Package: kqlives Hello Mates, does anyone know, what this checks? { echo "$as_me:$LINENO: checking for dumb_exit in -ldumb" >&5 echo $ECHO_N "checking for dumb_exit in -ldumb... $ECHO_C" >&6; } if test "${ac_cv_lib_dumb_dumb_exit+set}" = set; then echo $ECHO_N "(cached) $ECHO_C" >&6 I've added my libdumb-devel, but this Check fails. Has anyone an Tip? -- Sincereley yours Sascha Manns openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Project-Blog: http://lizards.opensuse.org/author/saigkill Private-Blog: http://saschasbacktrace.blogspot.com DISCLAIMER: Please note that in accordance with the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. http://www.vorratsdatenspeicherung.de http://www.ccc.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 4

[opensuse-packaging] requires vs recommends for lang packages
by Vincent Untz 06 Mar '09

06 Mar '09

Hey, The current policy when using lang package is to do: Requires: %{name}-lang = %{version} I don't think "Requires" is true. "Recommends" is much more appropriate I think, since the package works fine without the corresponding lang package. (There might be a few packages where this isn't true, but those are exceptions). Opinions? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 5

[opensuse-packaging] 11-check-pkgconfig-deps issues
by Cristian Rodríguez 06 Mar '09

06 Mar '09

Hi ;-) 11-check-pkgconfig-deps has some issues, that causes increasing package dependency bloat. let say we have packages X, Y, Z where Z is being checked by this script. Z : Requires Y that provides Y.pc Y: Requires X that provides X.pc when Z is checked, it complains that there is a missing Require on X which is not really correct,and will led packagers to add X as a dependency of Z and on.. and on.. and on... over the whole dependency tree..thing that will of course end in a unfixable mess as time passes, as dependencies are always added but never removed in this case,even when some intermediate package doesn't use a particular library or component anymore. The second issue, is that this script does not account Requires.private that should be taken in consideration _only_ when the package contains static libraries, the really bad news is that pkgconfig is utterly broken handling Requires.private and doesnt really do the right thing either :-( Fixing this issues will make this check a bit more useful, but will still let a lot of stuff to be fixed, including most pkgconfig scripts that are frequently broken as well :-| -- "If this is the best God can do, I am not impressed" -George Carlin (1937-2008) Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/

4 10

[opensuse-packaging] Changelogs need changes?
by anicka＠suse.cz 05 Mar '09

05 Mar '09

Hello! I would like to discuss here one aspect of our changelog policy. Unlike other distributions, we have an unusual rule for our RPM changelogs (.changes file): when updating to the new version, we must process an upstream changelog and copy the most important things to RPM changelog. I would like to discuss this policy and its problems and benefits. When this policy became effective, I have heard about two reasons for doing it: 1. Maintainer who does the update is aware of the changes in upstream. 2. We have easily accessible information about upstream changes. As for the first plus, yes: Maintainer is really pretty well aware of all the information because he not only reads the changelog, but he also spents a great amount of time copying it, pasting it, trying to shrink it as most as possible, reformatting it and so one. I do not want to speak for other packagers (their stories might follow), but I have spent countless hours tweaking my scripts for automagical processing the changelogs and although it saved me loads of time, it is the only thing I regularly have to fix manually during my otherwise automatical perl module updates. It is boring and IMHO completely useless work that costs us lots of time that we could spend on hacking something useful. As for the second plus, I am not aware that anyone uses this information. AFAIK we have no tool to present it to our users in a neat way. It is even not a part of the package metadata, so if you want to get it, you must get the complete package - and if you got the package, you can equally easily see upstream changelog with the same information, that you could get from the changelog. Sure, you might say that we should use RPM changelogs just for the most important changes to save our users time of searching for them. But a brief look at our packages shows that we are not doing it and usually we even cannot do it - how to pick up the most important changes from 30 minor bugfixes? How to pick them from a loads of new features in a new major version? We can either duplicate the changelog (usually unfeasible) or randomly pick up some news (this is my most usual choice) to make our policy happy. In fact, when you are interested in upstream changes, in almost every case it is more useful to take a look to upstream changelog because it is complete and better structured. When you are interested in specfile changes instead, you cannot just read them, you have to skip tons of useless information from upstream changelog - in fact, even when there is no upstream changelog, it would be better to maintain some as a patch than to pollute RPM changelog with a noise. I think that we spent countless hours of time working on something that no one is interested in. Even its very presence might be annoying in some cases. Should we really continue doing it? Would not be better to just go back several years and start to do it like others do it? Reference: http://en.opensuse.org/SUSE_Package_Conventions/Changelogs#11.4_Sourcecode_… Anicka -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

9 24

[opensuse-packaging] Please do not bypass the devel projects
by Vincent Untz 05 Mar '09

05 Mar '09

Hi, We just got 7 packages in GNOME:Factory that broke because the project.diff files don't apply anymore: the packages were all updated in Factory. It's not the first time it happens, and I'm sure each time it happens, the person doesn't think it will break anything. But sometimes it does :/ Don't get me wrong: I'm really happy to see people contributing to the packages the GNOME team maintains, and especially when it comes to cleaning up things -- it makes the world a better place. But it'd be really nice to submit all updates to GNOME:Factory first. I think Mozilla:Factory was hit by this issue in the past too, and I'd guess other projects too. So, please, think about the pain that people feel when they have to handle those manual merges, and use the devel projects. Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 28