February 2008 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Use of icedtea in 11?
by Michal Vyskocil 08 Mar '08

08 Mar '08

Hi, I'm currently working on update of some java packages from OBS project Java:jpackage-1.7 to stable. So I'm also trying to build some of these packages with icedtea. Some of them should be builded (like adaptx) with small patches, some of them currently not (like hsqldb). But the switch to icedtea is not an automated process anymore, so if the autobuild team switches the compiler, majority of java packages will not be builded and needs to do some patches or revert back to the non free compiler. I can update a package and try to build it by icedtea, so I'm be able to switch the BuildRequire to java-1_7_0-icedtea-devel, if it works. The problem is, that the icedtea is only for i386 and a x86_64 available. On ppc or s390 we are using an IBM's compiler only. But a majority of a java packages is noarch, because a Java bytecode is architecture indepentent. I'm not sure, if I should use something like %ifarch %ix86 x86_64 BuildRequires: java-1_7_0-icedtea-devel %else BuildRequires: java-devel %endif in a spec file for noarch packages. May I try to build the most of java packages using icedtea? And if yes, how to do that? Use of the %ifarch in spec? Regards Michal Vyskocil --------------------------------------------------------------------- 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] Yet Another Policy: No new packages in STABLE
by Stephan Kulow 06 Mar '08

06 Mar '08

Hi, Many people complain about Factory lacking dependencies on update. Most often this is due to new packages not yet being legally reviewed. So we discussed two policy chances (and will act on it after this email): - package splits / renames won't be reviewed in the future. For this clearly mark the split in the changelog. And do not branch packages that are not subpackages (this is _very_ important!). - new packages won't be checked into STABLE unless the base packagage (the name of the .src.rpm) is already reviewed (state production). Submit those packages to BETA and send a mail to suse-dist and only after your package was approved for distribution, submit it to STABLE. You can also submit it to STABLE too so you do not forget about it, but checkin will be delayed. I hope everyone understands the reasons. If not, check bug 365543. Greetings, Stephan -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 4

Re: [opensuse-packaging] [RFC Proposal] Distribution Branding
by radmanic＠novell.com 29 Feb '08

29 Feb '08

On Tuesday 26 February 2008 15:17:08 > Hallo. > > Here is a first draft of first part of proposal: creating of > branding-enabled packages. > > More should come later. > > > Proposal: Distribution Branding / Branding-Enabled Packages > > > Description of branding-enabled packages > > Branding-enabled packages provide its branding is a separate package. > > This technique is useful for: > > - Providing custom branding images. > - Providing custom default bookmarks. > > > Rules for packaging of branding enabled packages > > - Branding image should exist in a separate file. > - No custom branding images are added to the package. > > Package maintainer should split to two sub-packages - one with core > files (foo) and one with branding provided by upstream > (foo-branding-upstream). These packages are connected by branding > virtuals. Please keep in mind that a brand is somewhat like an identity or a signature and we should prevent misuse as good as possible. Branding can have legal implications, too. Therfore I propose the followiung amendments. - Branding packages must be mutually exclusive, but with the exception of the default "upstream" package. This should make sure that you cannot easily co-brand packages by adding your branding package to an existing one. This should prevent unauthorized co-branding - A brand package must contain a legal note on the authorized use of the package, its content and its distribution > Conventions > > > Package names > [...] > > Branding supplement > > Each branding package should supplement branding vendor. It allows to > choose correct branding package, if more branding packages are > available. Branding supplement symbol constist of "branding-" string and > symbolic name of the branding. Upstream branding symbolic name is > "upstream". > > > > Example: since we're talking about branding why not use #BRAND instead of #ART? > > Branding-enabled package: > > foo.spec: > Requires: foo-splash-300x400-art_foo_2_4 > Requires: foo-about-strip_middle-300x300 > > %package branding-upstream > Supplements: branding-upstream > #ART: foo-splash.png: png or jpg file, 300x400 pixels. Progress bar > #ART: will be displayed in lower 24 pixels. Image should include > #ART: package name "FOO" and version letters "2.4". > Provides: foo-splash-300x400-art_foo_2_4 > #ART: foo-info.png: Background of about dialog. Black names will > #ART: appear in the light stripe in the centre. > Provides: foo-about-strip_middle-300x300 regards -- Milisav Radmanic Engineering Manager Server Technologies SUSE LINUX Products GmbH Maxfeldstr. 5 90409 Nuernberg tel: +49 911 74053 0 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 3

[opensuse-packaging] Fatal and stricter rpmlint checks for Factory
by Dirk Mueller 28 Feb '08

28 Feb '08

Hi, I think that I'm finished with updating the set of rpmlint checks for 11.0. You can see the current set of failures in beta-i386 (the other architectures are not rebuilding). Please submit fixes for the new fails: executable-docs - documentation should not be executable. most of the time this comes from using "install" (which installs with executable permissions by default). use install -m 644 or the %doc macro. makefile-junk - generated Makefile's should not be in /usr/share library-without-ldconfig-postun - add %postun -p /sbin/ldconfig to the library package percent-in-* - most likely an unexpanded macro. e.g. %version is not defined before the Version: line in the spec file summary-too-long - the summary should be short. put the long stuff into %description invalid-pkgconfig-file - most likely contains an unexpanded macro. make sure that your AC_SUBST are correct and your autoreconf did not break it. file-contains-buildroot - files should never contain the buildroot. make sure that the $RPM_BUILD_ROOT is not used outside %install, and that stuff is not build/rebuild during %install. some too clever build systems try hardcoding paths, which breaks for buildroot installation. invalid-filepath-dependency - the list of paths that can be used in filerequires is fixed. if you violate, it will break installation. please report false positives to me before suppressing them! Thanks, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

Re: [opensuse-packaging] HAL: cleanup of deprecated keys/properties
by Danny Kukawka 28 Feb '08

28 Feb '08

On Donnerstag, 28. Februar 2008, Tambet Ingo wrote: > On Tue, Feb 26, 2008 at 1:19 PM, Danny Kukawka <dkukawka(a)suse.de> wrote: > > > with the next HAL package for STABLE/Factory (planed for Monday > > > 03.03.2008) some keys/properties get removed from HAL because they are > > > deprecated and marked since 12 months in the SPEC to get removed at > > > the end of this month. > > Hey, > > What are your plans with HAL version for opensuse 11? There are 4 > different FATE entries for NetworkManager support for 3G cards and for > it to work we need HAL's help from this commit (from February 15th): > > http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=9cece37fd82df82d24744d2 >1fce693ba4eefa447 That's already part of the test package from [1]. I can't tell you which version will be finaly in 11.0, that depends on the upstream release cycle. If there is no new release in time I do the same as with each openSUSE release: update our HAL package as as long as possible with git-snapshots. Danny [1] http://download.opensuse.org/repositories/home:/dkukawka:/hal-beta/ -- Danny Kukawka dkukawka(a)suse.de Mobile Devices SUSE LINUX a Novell Business Maxfeldstr. 5, D-90409 Nuernberg, Germany SUSE LINUX Products GmbH, Nuernberg; 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

1 0

[opensuse-packaging] dropping obsolete shared library packages?
by Stanislav Brabec 27 Feb '08

27 Feb '08

Hallo. In 11.0 we will have a new rules for shared library package names. It implies a question: What happens with old shared library packages after increment of soname. We cannot obsolete them (third party can still use them) and we should not not-obsolete them (as it will cause increasing number of orphaned packages in the system). Is there any solution for it? I can imagine several possibilities: Packaging level: Weak-Obsoletes as counterpart of Recommends: Delete, if it will not causes breakage. Zypp level: Handle packages named lib*[number] Advanced zypp level: Discriminate between explicitly required and dependent packages External script level: Find and delete all obsolete libraries ... -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

7 12

[opensuse-packaging] mozilla embedding news
by Wolfgang Rosenauer 27 Feb '08

27 Feb '08

Hi, (first sorry for the cross post but I wanted to make sure that everyone related has a chance to get that). openSUSE 11.0 is planned to have Firefox 3 and therefore we will also have Gecko 1.9 for embedding purposes. So far that has been done using mozilla-xulrunner181 which now got a first mozilla-xulrunner190 successor snapshot available for testing in the buildservice (mozilla:beta). Probably maw will start soon to bring that to factory. The test package does not replace older xulrunner versions yet but will reset the /usr/bin/xulrunner link to the new version. It shouldn't be a problem to install it in parallel on 10.2, 10.3 and factory. One note along the line: Gecko 1.9 won't run on distributions older than 10.2 because of gtk requirements. Relevant changes for projects embedding gecko are that the pkgconfig files changed their names. There are now: libxul-embedding-unstable.pc libxul-embedding.pc libxul-unstable.pc libxul.pc mozilla-gtkmozembed-embedding.pc mozilla-gtkmozembed.pc mozilla-js.pc mozilla-plugin.pc I'm encouraging anyone maintaining a depending package to play around with that and report issues to bugzilla's openSUSE 11.0 Firefox component. Wolfgang --------------------------------------------------------------------- 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] [RFC Proposal] Distribution Branding (packages)
by Stanislav Brabec 27 Feb '08

27 Feb '08

Hallo. Here is a first draft of first part of proposal: creating of branding-enabled packages. More should come later. Proposal: Distribution Branding / Branding-Enabled Packages Description of branding-enabled packages Branding-enabled packages provide its branding is a separate package. This technique is useful for: - Providing custom branding images. - Providing custom default bookmarks. Rules for packaging of branding enabled packages - Branding image should exist in a separate file. - No custom branding images are added to the package. Package maintainer should split to two sub-packages - one with core files (foo) and one with branding provided by upstream (foo-branding-upstream). These packages are connected by branding virtuals. Conventions Package names All branding packages names should consist from three parts - package core name, string "-branding-" and the branding name. A special branding name is created by default: "upstream". This is a branding provided by upstream. Spec file comments Each file there should contain comment providing sufficient information for the artist. You can expect, that upstream branding will be available to the artist. Each line of these comment should start by "#ART: " string followed by these information: - Spec source file name (mandatory). Spec source package file name should be unique for the whole distribution. For example, if the target file name is /usr/share/foo/splash/image.png, source package file name should be foo-splash-image.png and it should be copied to the correct target in %install phase. - use case (mandatory, if it is not part of the file name itself, e. g. "about" - decoration of about dialog, "splash" - image displayed for a short time, when application is launching, "toolbar" - image in toolbar, "initial screen" - displayed when application is started before user starts to use it). - required art, if any (mandatory, if the image should contains program name letters, branch number, required logm comment should say, what exactly has to be included). - overlays, if any (mandatory, if the image is overlayed with any text in image, comment should say its size, color and position). - dependencies, if any (mandatory, if you can customize your look using another file, you must mention it). Examples: "Width of foo-img1.png must be the same as width of foo-bg.png." "You can define overlay text color, size and and position in splash.xml." - allowed file sizes (optional, if not present, artist has to follow upstream size). - allowed file formats (optional, if not present, artist has to follow upstream file format). - For branding of launcher icon it is preferred to create custom icon theme instead of branding. Branding virtual symbols Packager should create one virtual for each top-level file in the branding package (If the branding consists of an image, virtual should be relative to the image. If the branding consist from config or svg and related bitmap images, virtual should be relative to config or svg). Package maintainer is responsible for choosing of decent symbols. Requires and Provides should be no more strict than needed but must not be vague to allow bad branding. Use version based virtuals, if and only if the art itself contain version numbers. Examples: foo-splash-300x400 (splash is 300x400 in size) foo-splash-art_foo_2_4 (splash contains "FOO 2.4" letters art). Note to versioned branding symbols: If project uses per-branch branding, you cannot use versioned symbols (Provides: foo-splash = 2.4 will only complicate things, if it is designed to fit 2.4.1, using of foo-splash-art_2_4 is more appropriate). Branding supplement Each branding package should supplement branding vendor. It allows to choose correct branding package, if more branding packages are available. Branding supplement symbol constist of "branding-" string and symbolic name of the branding. Upstream branding symbolic name is "upstream". Example: Branding-enabled package: foo.spec: Requires: foo-splash-300x400-art_foo_2_4 Requires: foo-about-strip_middle-300x300 %package branding-upstream Supplements: branding-upstream #ART: foo-splash.png: png or jpg file, 300x400 pixels. Progress bar #ART: will be displayed in lower 24 pixels. Image should include #ART: package name "FOO" and version letters "2.4". Provides: foo-splash-300x400-art_foo_2_4 #ART: foo-info.png: Background of about dialog. Black names will #ART: appear in the light stripe in the centre. Provides: foo-about-strip_middle-300x300 Branding package: foo-branding-myvendor.spec: Supplements: branding-myvendor #ART: foo-splash.png: png or jpg file, 300x400 pixels. Progress bar #ART: will be displayed in lower 24 pixels. Image should include #ART: package name "FOO" and version letters "2.4". Provides: foo-splash-300x400-art_foo_2_4 #ART: foo-info.png: Background of about dialog. Black names will #ART: appear in the light stripe in the centre. Provides: foo-about-strip_middle-300x300 Branding virtual package or pattern provides resolvable branding-myvendor. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

8 21

[opensuse-packaging] HAL: cleanup of deprecated keys/properties
by Danny Kukawka 26 Feb '08

26 Feb '08

Hi, with the next HAL package for STABLE/Factory (planed for Monday 03.03.2008) some keys/properties get removed from HAL because they are deprecated and marked since 12 months in the SPEC to get removed at the end of this month. The effected keys/properties are: * 2008-03-01: - info.bus --> replaced by info.subsystem - *.physical_device --> replaced by *.orginating_device * 2008-02-28: - smbios.system.manufacturer --> system.hardware.vendor - smbios.system.product --> system.hardware.product - smbios.system.version --> system.hardware.version - smbios.system.serial --> system.hardware.serial - smbios.system.uuid --> system.hardware.uuid - smbios.bios.vendor --> system.firmware.vendor - smbios.bios.version --> system.firmware.version - smbios.bios.release_date --> system.firmware.release_date - smbios.chassis.manufacturer --> system.chassis.manufacturer - smbios.chassis.type --> system.chassis.type - system.vendor --> system.hardware.vendor And please note, there are some keys planed to be removed at the end of March 2008. * 2008-03-21: - usb_device.speed_bcd (int) --> usb_device.speed (double) - usb_device.version_bcd (int) --> usb_device.version (double) Please check your packages for these keys (code and shipped fdi-files) and prepare them for the new HAL package. Danny -- Danny Kukawka dkukawka(a)suse.de Mobile Devices SUSE LINUX a Novell Business Maxfeldstr. 5, D-90409 Nuernberg, Germany SUSE LINUX Products GmbH, Nuernberg; 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

1 1

[opensuse-packaging] libraries renaming problems
by Petr Cerny 25 Feb '08

25 Feb '08

Hi, I'm not sure whether this hasn't been discussed here a while ago, yet I'm running into it more and more often lately: as libraries packages are renamed according to shlib policy, they do not provide older names, which makes some software uninstallable (especially with the latest libzypp based tools). Typical example of this is: libfoo -> libfoo1 which doesn't provide "libfoo" (only "libfoo1" as it's its name). When other package Requires: "libfoo", the package manager (and eventually the user) gets fooled and isn't able to install the desired package. Write .spec files like: Name: libfoo %define major 1 %define minor whatever Version: %{major}.%{minor} %package -n %{name}%{major} Provides: %{name} = %{version} should help. Best regards Petr --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

7 12

Re: [opensuse-packaging] SLE_10 missing mDNSResponder
by Andrew Jorgensen 24 Feb '08

24 Feb '08

Why do we provide these if they cannot be used? ----- Original message ----- > On Thursday 21 February 2008 22:02:10 wrote Andrew Jorgensen: > > Hello, The SLE_10 distro on OBS is missing mDNSResponder. I am trying > > to build giver for SLE_10 with a patch that uses mono-zeroconf instead > > of avahi-mono. This should let us build giver for SLE_10. > > mDNSResponder-lib and mDNSResponder-devel do exist there, nothing else has > been provided for SLE distributions. > > bye > adrian > > -- > > Adrian Schroeter > SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) > 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 > --------------------------------------------------------------------- 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] SLE_10 missing mDNSResponder
by Andrew Jorgensen 22 Feb '08

22 Feb '08

Hello, The SLE_10 distro on OBS is missing mDNSResponder. I am trying to build giver for SLE_10 with a patch that uses mono-zeroconf instead of avahi-mono. This should let us build giver for SLE_10. Can this be corrected? Thanks, -- Andrew Jorgensen <ajorgensen(a)novell.com> Novell, Inc. --------------------------------------------------------------------- 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] java-devel in factory
by Wolfgang Rosenauer 21 Feb '08

21 Feb '08

Hi, in the past it was possible to use "java-devel" (and before java2-devel-packages IIRC) as a BuildRequires to get a "default" Java environment installed. Currently (at least in the OBS's Factory tree) I get expansion errors because I have three different alternatives: java-1_7_0-icedtea-devel java-1_6_0-sun-devel java-1_5_0-sun-devel Will there be a "default" java-devel again or do I need to specify explicitely (which means again quite some %if s in the specfile? Wolfgang --------------------------------------------------------------------- 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] BETA: watch out for new rpmlint fun
by Dirk Mueller 15 Feb '08

15 Feb '08

Hi, externals: stop reading here. Hopefully soon the new rpmlint checks will be enabled in BETA, which might be more strict and can cause new packages to fail. There was no particular new check added, just that some of the slow brp scripts were rewritten and integrated into rpmlint for performance and ease of maintenance. There might be fallout: false positives and false negatives. Please let me know if you find anything particularly interesting so that I can improve the checks. Thanks, Dirk :-) -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 8

[opensuse-packaging] New rpmlint check
by Dirk Mueller 14 Feb '08

14 Feb '08

Hi, I've implemented the suggestion in bnc#357040, which checks if a package, that installs a file in /etc/cron.*/ or /etc/logrotate.d/, also rpm-requires "cron". As cron is not part of a minimal installation, this explicit rpm requires is useful to make sure that your package works as designed. Please watch for "missing-dependency-to-cron" rpmlint checks. These are not fatal at the moment but they might gain badness soon. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 11

[opensuse-packaging] BuildRoot Tag
by Christian Morales Vega 11 Feb '08

11 Feb '08

I know that they are just recommendations and isn't so important at all... but couldn't we agree at least with this? I don't see any recommendation from Mandriva, openSUSE "prefers" "%{_tmppath}/%{name}-%{version}-build", and Fedora says: "The BuildRoot value MUST be below %{_tmppath}/ and MUST contain at least %{name}, %{version} and %{release}. It may invoke mktemp since this is guaranteed to exist on every system. From there, packagers are expected to use a sane BuildRoot. The recommended values for the BuildRoot tag are (in descending order of preference) : %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) %{_tmppath}/%{name}-%{version}-%{release}-root At one point, the second was a mandatory value, but it is now left to the packager to decide. If unsure, simply pick the first." http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot http://en.opensuse.org/SUSE_Package_Conventions/RPM_Style#1.16._BuildRoot_T… Someone has any problem in changing the SUSE Package Conventions/RPM Style wiki and copying the text from Fedora? Their option makes more sense anyway. With the openSUSE "preference" two users at the same machine could try to create at the same time a package of the same sotware/version with different spec files and end using the same build directory. --------------------------------------------------------------------- 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] fedora needs some deltarpm love :)
by Valent Turkovic 10 Feb '08

10 Feb '08

Hi, let me first introduce myself. I'm a Fedora contributor and Fedora Ambassador for Croatia, but I'm not directly part od Fedora board or Fedora Project. Still I would like to ask you for assistance in one matter that you have more experience dealing that Fedora - and that is deltarpm. Fedora 9 features list has Presto[1] on it - it is a yum plugin that handles deltarpms during updates. Currently the deltarpm integration is stuck because the infrastructure team is stuck[2] in its implementation. Is there some way in which you can help with your longer experience with handling deltarpm files so that this greatly needed feature comes on by default in Fedora 9? Is there some other list that is more specialized on this sort of topics that I would be better of trying elsewere? Cheers, Valent from Croatia. [1] http://fedoraproject.org/wiki/Releases/FeaturePresto [2] http://fedoraproject.org/wiki/Infrastructure/PrestoBuildsysIntegration -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 7

[opensuse-packaging] SUSE insanities
by Krzysztof Kotlenga 09 Feb '08

09 Feb '08

Hi, First: package groups. That list: http://en.opensuse.org/Packaging/SUSE_Package_Conventions/RPM_Groups It's incomplete, nobody respects it. Stupid groups: Productivity/Networking/Napster - but there is no common group for P2P applications Productivity/Networking/AOLInstantMessenger - but there is no common group for IM applications! Pidgin is in "Productivity/Networking/Instant Messenger", gajim in "Productivity/Networking/InstantMessaging" etc. Categorization funnies: gstreamer010-plugins-base in System/GUI/GNOME (same for other gstreamer packages). I'd never thought. Second: lists of authors in package descriptions. That what AUTHORS files are for! God damn it! I bet that most of it are incomplete, because it's a waste of time to update them in specs. I run rpm -qi and... whoa!, must rerun with some pager to see a real description. Again, piding.spec is a good example. OK, enough for today. With love, yours truly, openSUSE user. -- Krzysztof Kotlenga <piernik$gmail,com> --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

9 15

[opensuse-packaging] Packaging Day II: April 4th/April 5th
by Dirk Mueller 08 Feb '08

08 Feb '08

Dear openSUSE Packagers, We'll be repeating the Packaging Day we held in November again, in time for openSUSE 11.0, so this is your chance to make sure your pet project is building against or even becoming part of 11.0 :-) All the details and a more detailed announcement can be found below and will be announced later: http://en.opensuse.org/Packaging/Packaging_Day Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint --------------------------------------------------------------------- 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] ati-fglrxG01-kmp-default -- openSUSE comunity package
by Marek Stopka (M4r3k) 06 Feb '08

06 Feb '08

Hi! I am user of ati-fglrxG01-kmp-default package from ATI Legacy Repository (http://opensuse-community.org/ati/10.3/) and i can't find who is responsible for this repository. But that package is not compatible with kernel from Updates repository... That package should be rebuilded. So anybody from openSUSE comunity portal please rebuild this package against kernel-source from Updates repository. Thanks (And i am so sorry for this SPAM) I hope, the responsible person is registred to this list... -- S pozdravem / Best regards Marek Stopka Kontakty / Contacts Mobil/Cell phone: 774 59 79 40 E-mail: marekstopka(a)gmail.com WEB: www.m4r3k.org --------------------------------------------------------------------- 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] watch out for security bugs!
by Ludwig Nussel 06 Feb '08

06 Feb '08

Hi, Just a reminder in case it's not obvious anyways :-) If you notice that upstream fixed a (potential) security problem in a package that is contained in openSUSE please tell the SUSE Security team about it. We may need to release online updates for older products then. You can reach us at security(a)suse.de. Thanks, Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ 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

1 0

[opensuse-packaging] driver fo webcams "gspcav1-kmp-default" package built against wrong kernel version
by Rastislav Krupanský 05 Feb '08

05 Feb '08

Hello After upgrade to the newest kernel 2.6.22.16, it is impossible to install driver for webcams "gspcav1-kmp-default" package available ...repositories/drivers:/webcam... , because it requires older kernel. Can anyone upgrade it? Thanks a lot for it. Regards, Rasto --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

8 13

[opensuse-packaging] Licence when software doesn't specifies one.
by Christian Morales Vega 04 Feb '08

04 Feb '08

In Internet sometimes you find software available from the author webpage, with the source code available... but without specifying a licence. Even if you try to contact with the author he often doesn't knows nothing about GPL, licence compatibility, etc. What can/should we do in these cases if we want to package his software? I understand than even if he hasn't specified a licence he is the copyright holder and so I can't redistribute his software without permision. An easy solution is to recommend him the GPL. But a lot of them want a licence that: a) Is "free". Allowing the redistribution at no cost. b) Does *not* allows "commerical" use. c) Requires any redistribution to make reference to the original author. Such a software can be hosted in the OBS? Is "Creative Commons Attribution-Noncommercial-Share Alike" a good option? I suppose it is GPL incompatible. If he accepts to licence under <licence>. How can I prove that he allowed me to redistribute the software under that licence? I need to ask him to modify the files hosted in his website adding the licence? --------------------------------------------------------------------- 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] joomla for EDU-cd
by James Tremblay 01 Feb '08

01 Feb '08

Hey guys, i know you are all working hard already. But, might I ask if someone could help put a joomla package together for the edu-cd? some called "illusio" i believe has one that with a little dumbing down might just be easy enough for teachers to install. no offense to any teachers here, most of my colleges are science or math teachers first , IT geeks second. ;) already to busy to learn anything more than where is that 2k3 disk. -- James Tremblay Director of Technology Newmarket School District Newmarket NH 03857 "let's make a difference" http://en.opensuse.org/education --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 4