March 2012 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Re: [opensuse-factory] Re: [opensuse-buildservice] How do I unmark packages as a devel project?
by Sascha Peilicke 08 Mar '12

08 Mar '12

On 03/07/2012 12:04 PM, Dave Plater wrote: > On 03/06/2012 02:14 PM, Sascha Peilicke wrote: >> On 02/26/2012 07:43 AM, Dave Plater wrote: >>> After continually getting multimedia packages that I was working on in >>> home:plater, messed up by other submissions I had the bright idea to >>> make the package the devel project of the multimedia:libs package. >>> Unfortunately I can't delete or "undevel" the package and with my >>> current situation I'm not on line enough to manage this either. >>> >>> The problem I attempted to address is a real problem though, there >>> should be a way for a maintainer to lock the package that he's working >>> on, especially before release when there's a lot of activity. >> >> The key here is communication and not ignorance, which you showed here: >> >> https://build.opensuse.org/stage/package/rdiff?linkrev=base&package=libconf… >> >> >> where you simply chopped a previous submission (by yours truly): >> >> https://build.opensuse.org/stage/package/rdiff?linkrev=base&package=libconf… >> >> >> The key concept here would have been called 'merging' and isn't really >> specific to OBS. But lets go on a bit, after 'working' on that package, >> you reopened a request to Factory >> (https://build.opensuse.org/request/show/106980) that was reasonably >> declined (see our packaging policies). It's rather funny that I wanted >> to do you a favor with just the above submission and fix your issues ;-) >> >> Long story short, I would really appreciate if you could stop pretending >> to be the one true source of wisdom > This comment really baffles me. > and try to collaborate with others >> (like me). >> >> And don't try to make your home project the devel project for any other >> project (please revert if you already did), otherwise I'll make mine a >> devel project of yours! > I find your language offensive, especially after having a forced absence > and still managing to work on bugs using a mobile phone during the period. > As I politely pointed out that I was unfamiliar with the new reopen > feature and the supersedeing. The correct response would be to enlighten > me, I still don't understand what the reopen button is, I have been > unable to read any list emails apart from bugzilla and the messages I > received from users concerning rosegarden, blender and lilypond. Ok, I'll try to respond correctly then, "Reopen" is for re-setting a request to state 'new' or 'review' when it was 'declined' before. This usually happens when someone makes a mistake and the decline reason was invalid. However, in your case, the decline reason given by darix was perfectly valid and you simply reopened the request without given any comment on why you did. So I accused you of being ignorant, and I admit I could have done this in a more diplomatic way. But to me it seems like being blunt didn't help either, or how do you explain your resubmission of libconfig (sr 108385)? Neither did you include darix' recommendations for improving the package nor did you fix your last commit to the package (where you erased my previous commit that fixed SLPP). So what do you expect this time? Here's what you should do: * Revert the package to revision 2 (the submission that was accepted by cartman) * Rebase your changes (from rev3) and commit them again * Read darix' decline message from sr#106980 * Read darix' decline message from sr#106980 again * Actually do what he recommended ;-) * Feel free to resubmit the package to Factory Until then, 'libconfig' won't enter Factory > I realise there are differences in communication between english and > germans, I have worked with Germans and I have both German and Austrian > friends, I try very hard to prevent misunderstanding but in this case I > think I failed. > > I'm still under very difficult circumstances, please understand that my > time spent replying to this email is precious but I'm not sure if you > could understand poverty and hardship like I do. My reply was not about your personal situation but about your general behavior in the OBS, please let's keep this stuff out of the discussion. -- Viele Grüße, Sascha Peilicke

1 0

[opensuse-packaging] How upstream version gets checked
by Dinar Valeev 08 Mar '12

08 Mar '12

Hi, I have following Factory reminder: http://s.kulow.org/fs-k0da All versions in the Facotry seems to be latest upstream versions. How to fix that? Thanks, Dinar -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 5

[opensuse-packaging] Should "Requires" force the required package to change repos?
by Greg Freemyer 08 Mar '12

08 Mar '12

All, I have a perl module packaged that has within it a sub-package which is an application. I have upgraded the package in my home directory. I have the perl module itself currently installed in my PC from the D:L:P project/repo. When I install the app from my home package I expected it to force the module to come from my home project as well. That's not happening, and I find it confusing. The project > package is home:gregfreemyer:Tools-for-forensic-boot-cd > perl-Image-ExifTool The key lines from the specfile are: === Name: perl-Image-ExifTool Version: 8.77 ... %package -n exiftool ... Requires: perl(Image::ExifTool) = %{version} === You can see the above Requires statement is working by looking at: https://build.opensuse.org/package/binary?arch=x86_64&filename=exiftool-8.7… You can see perl-Image-ExifTool provides version 8.77 here: https://build.opensuse.org/package/binary?arch=i586&filename=perl-Image-Exi… But when I install exiftool v8.77 I still have perl-Image-ExifTool v 8.65 installed. My only thought is maybe "Requires" won't cause perl(Image::ExifTool) to switch from the D:L:P repo to my home repo? Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Help on conditional dependencies wiki item
by Marguerite Su 07 Mar '12

07 Mar '12

(Sorry for the last no title mail...my network is unstable through VPN, so gmail doesn't notify me about that. sorry anyway.) Hi, all, (I don't know if it's right to post it here, but I think it must be someone among us who wrote the wiki page) I'm translating specfile_guide wiki to Chinese. But I can't understand the following: "If the spec file contains conditional dependencies selected based on presence of optional --with(out) foo arguments to rpmbuild, build the source RPM to be submitted with the default options, ie. so that none of these arguments are present in the rpmbuild command line. The reason is that those requirements get "serialized" into the resulting source RPM, ie. the conditionals no longer apply." it seems initial writer copied it from Fedora. can anyone help me understanding this? #1 I know what conditional dependencies are. #2 “build the source RPM to be submitted" why build before submission? if builds locally, why submit the SRPM instead of the whole project? #3 "are presented in the rpmbuild command line" where the rpmbuild command line is? I never see them on OBS, although I know I can "rpm -ba *.spec --with condition 1 --without condition 2" #4 I can't understand the sentence from "the reason" to the end. Can anyone give me some hints? or a plain English example? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] build-compare for KMP packages?
by Stefan Seyfried 06 Mar '12

06 Mar '12

Hi all, I'm trying to stop the daily virtualbox updates from the Virtualization repo (on every rebuild). One culprit is a "__DATE__, __TIME__" in VBoxSVC which I can patch out quite easily. Another one is: compare /.build.oldpackages/virtualbox-host-kmp-desktop-4.1.8_k3.1.9_1.4-28.15.x86_64.rpm /home/abuild/rpmbuild/RPMS/x86_64/virtualbox-host-kmp-desktop-4.1.8_k3.1.9_1.4-28.16.x86_64.rpm --- /tmp/tmp.8NI4XILsY7 2012-02-19 18:57:32.776000001 +0000 +++ /tmp/tmp.KDp84V0Y4m 2012-02-19 18:57:32.804000001 +0000 @@ -9,16 +9,16 @@ (none) 4.9.1.2 x86_64-suse-linux cpio lzma 5 -/bin/sh nvr=virtualbox-host-kmp-desktop-4.1.8_k3.1.9_1.4-28.15 +/bin/sh nvr=virtualbox-host-kmp-desktop-4.1.8_k3.1.9_1.4-28.16 wm2=/usr/lib/module-init-tools/weak-modules2 if [ -x $wm2 ]; then /bin/bash -${-/e/} $wm2 --add-kmp $nvr fi This seems to come from one of those whacko KMP macros. Can we just ignore these in build-compare? If the only difference is the build counter, then ignore it? Pretty please? -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- 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] how to disable build of noarch packages on certain architectures
by Petr Mladek 06 Mar '12

06 Mar '12

Hi, Dirk did the following submit request: dmueller(a)suse.com píše v Po 05. 03. 2012 v 21:27 +0000: > > openSUSE:Factory:ARM/libreoffice-l10n -> LibreOffice:Unstable/libreoffice-l10n > > > https://build.opensuse.org/request/show/108052 > > Description: - exclude from build on ARM > --- libreoffice-l10n.spec > +++ libreoffice-l10n.spec > @@ -63,10 +60,9 @@ > # FIXME: the l10n files includes some duplicated files > Source200: libreoffice-l10n-rpmlintrc > BuildRoot: %{_tmppath}/%{name}-%{version}-build > -#!ExclusiveArch: %ix86 x86_64 ppc > +ExclusiveArch: %ix86 x86_64 ppc > BuildArch: noarch It looked reasonable but it caused the following build error: + exec rpmbuild -ba --define '_srcdefattr (-,root,root)' --define 'disturl obs://build.opensuse.org/LibreOffice:Unstable/openSUSE_11.4/23e1ba7955fe2e7…' --eval %suse_insert_debug_package /usr/src/packages/SOURCES/libreoffice-l10n.spec error: Architecture is not included: noarch It seems that Fedora was in the same trap, see http://www.redhat.com/archives/fedora-maintainers/2007-May/msg00711.html I do not remember who suggested the commented out #!ExclusiveArch: I have added it few years ago (2009). I guess that it does not work. Otherwise, Dirk would not create the submit request. Is there any working solution, please? Best Regards, Petr -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] Is there any way to ship nosrc srpm only by OBS?
by Marguerite Su 06 Mar '12

06 Mar '12

Hi, all, Today I see a project "Mumble RPMs" http://mumble.knobgoblin.org.uk/ It aims to provide spec file, patches, desktop files for some commercial/proprietary/free-but-not-spdx-compatible licensed applications like Humble Indie Bundle games. It seems to be a patch work. it doesn't distribute purchased things, but splits one's own modifications out, license the modifications spdx-compatible, then distribute the modifications. I'm not sure about its mechanism (license issues). Can spec file/patches/desktop files be licensed using a different license (spdx-compatible) while the main and original distributive, well, things( sometimes it's source, sometimes it's binaries), are licensed using its own license? I'm interested in it because Commercial Companies who distribute its Linux-version software always show no patience and expertise. In many cases things they provide can not properly run on our Linux box. sometimes it's no sound, sometimes it uses an obsolete library, sometimes it is wrong about RPM groups or desktop file categories (they may choose Fedora as its RPM development environment, so no compatible to SuSE). then it requires end desktop users to modify them. But desktop users always have no ability to do so. Of course we can send patch directly to developers. But it will last forever until they release SP1. I think if the answer to my question is yes, we packagers can help a lot on this by providing a nosrc RPM like Mumble RPMs does. it is easier to throw a nosrc rpm and your purchased package to /usr/src/packages/source, unrpm it, move specfile to ../specs, then run rpm -ba, than modify system files like /home/marguerite/.frozenbyte/trine/config/blabla.txt or /usr/share/applications/trine.desktop which may be overwritten by mistake, system upgrade or reinstall, stolen. because you can backup your generated non-distributive RPMs elsewhere. If the answer to my question is yes, we at first need a "non-downloadable source" option for our purchased things, a "no noarch and architecture RPMs generation" option to make sure no binaries containing non-distributive codes are generated, then a "no branch" option to make sure no one except me can branch my project. (branching means redistribution which is prohibitted by upstream). At last, by adding NoSource: 0 tag to our specfiles, OBS will publish only a nosrc rpm which could be download by end desktop users. Is it already done in unreleased/secret version OBS ( SuSE China staff told me their OBS can import outside repositories like Pacman as dependencies where I learned there's a secret super-power version OBS) or is there any workarounds existing (please don't tell me I can install OBS locally...it's not funny)? It sounds, well, a little bit off-topic, but let's brainstorm. It may inspires OBS developers new features and others new way of using OBS. Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] How can a package build in the build service with no rpmlint check?
by Dave Plater 06 Mar '12

06 Mar '12

I've just declined a submission of fftw3 from home:cowsandmilk:branches:multimedia:libs because when I looked at the build log there wasn't an rpmlint check after rpmbuild. How is this possible in a branched package? I view fftw3 as a critical library that can mess with an entire system. I don't know if the user is aware of this or not but it's possibly dangerous. On the other hand I've been offline for a while and maybe there's something I've missed. sr#108067 Dave -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 3

[opensuse-packaging] DESIGN SCIENCE LICENSE
by Ilya Chernykh 04 Mar '12

04 Mar '12

Is this license permitted? -- 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] php5-pear-xinc problem
by Marguerite Su 03 Mar '12

03 Mar '12

Hi, Ralf, It's a weird problem. you can see it from here: https://build.opensuse.org/package/show?package=php5-pear-xinc&project=home… I deleted "xinc" from s:p:a and created a package "php5-pear-xinc". due to pear.php.net bug #9280 and #10661, I can't just install using: pear -c pearrc install --nodeps --packagingroot %{buildroot} %{SOURCE0} directly. it'll return a unknown channel and Xinc-2.1.tgz no valid error. so I found a workaround here: http://yuval.bar-or.org/blog/2009/11/offline-installation-of-pear-packages/ by replacing unofficial channel with pear.php.net using: sed -i "s/<channel>pear.elektrischeslicht.de<\/channel>/<channel>pear.php.net<\/channel>/" package.xml and later change it back to install xml. But I got a %post failure while the %post scriptlet is exactly the same as other packages in s:p:a. anyone knows how to get out from this? Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 16