Re: [opensuse-packaging] policy for naming devel packages
On Wednesday, 23. May 2007, Stefan Dirsch wrote: > It's not a policy, but xorg-x11-server-sdk is the package name, that > other distributors use for these files as well. distributor_s_ ? I've checked. on debian/*ubuntu, the package is called xserver-xorg-dev. -dev is the -devel suffix for debian style distros. on mandriva, the package is named xorg-x11-server-devel. The only distro this is consistent with (while they're apparently inconsistent here with their own rules) is fedora. If you say that you don't want to rename it just for the purpose of renaming then thats fine, because we don't have a consistent naming policy anyway. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] policy for naming devel packages
Hi, On Wed, 23 May 2007, Stefan Dirsch wrote: > It's not a policy, but xorg-x11-server-sdk is the package name, that > other distributors use for these files as well. I'm not aware of anyone > using xorg-x11-server-devel. I don't see much benefit for renaming it > besides from confusing our customers by constantling renaming our X11 > packages. I agree. If the -sdk name is already established practice, that fact wins. Ciao, Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] policy for naming devel packages
On Wed, May 23, 2007 at 04:37:56PM +0200, Michael Matz wrote: > Hi, > > On Wed, 23 May 2007, Dirk Mueller wrote: > > > it was recently (in bugreport 277317) brought to my attention that we > > have three packages containing development files, but not being named > > with a "-devel" suffix: > > > > > wnn-sdk > > This is not a subpackage of something, but really a package in it's own. > IOW upstream calls it like so, we shouldn't differ without good reasons, > so this name would be IMO okay. > > > OpenOffice_org-sdk > > xorg-x11-server-sdk > > About these I'm less sure. The xorg-x11-server-sdk indeed only contains > stuff you usually would expect from your random -devel package. In one > way it's different: this package is for developing other X11 server code, > not for normal developers doing X11 stuff, i.e. more or less an artifact > of the big split of X11 into modules (I realize that this characterization > is a bit stretching). It could reasonably be named xorg-x11-server-devel, > but I don't see a big reason to enforce that name. It's not that anyone > who doesn't know the current name would want to have it. > > OpenOffice_org-sdk could also be named -devel I think. It mostly contains > IDL defs and UNO interfaces. OTOH it doesn't contain libraries to > directly link against, something which I would expect in a random -devel > package. > > > I was wondering if there is a special policy regarding the -sdk suffix > > that I'm not aware of? Shouldn't those packages be named -devel? It's not a policy, but xorg-x11-server-sdk is the package name, that other distributors use for these files as well. I'm not aware of anyone using xorg-x11-server-devel. I don't see much benefit for renaming it besides from confusing our customers by constantling renaming our X11 packages. Best regards, Stefan Public Key available -- Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.deGermany - SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] policy for naming devel packages
Hi, On Wed, 23 May 2007, Dirk Mueller wrote: > it was recently (in bugreport 277317) brought to my attention that we > have three packages containing development files, but not being named > with a "-devel" suffix: > > wnn-sdk This is not a subpackage of something, but really a package in it's own. IOW upstream calls it like so, we shouldn't differ without good reasons, so this name would be IMO okay. > OpenOffice_org-sdk > xorg-x11-server-sdk About these I'm less sure. The xorg-x11-server-sdk indeed only contains stuff you usually would expect from your random -devel package. In one way it's different: this package is for developing other X11 server code, not for normal developers doing X11 stuff, i.e. more or less an artifact of the big split of X11 into modules (I realize that this characterization is a bit stretching). It could reasonably be named xorg-x11-server-devel, but I don't see a big reason to enforce that name. It's not that anyone who doesn't know the current name would want to have it. OpenOffice_org-sdk could also be named -devel I think. It mostly contains IDL defs and UNO interfaces. OTOH it doesn't contain libraries to directly link against, something which I would expect in a random -devel package. > I was wondering if there is a special policy regarding the -sdk suffix > that I'm not aware of? Shouldn't those packages be named -devel? IMHO: xorg-x11-server-sdk should be named -devel, the others not. My criteria would be: What's the most interesting thing in there? If it's header files and libraries -> -devel. If other stuff prevails -> whatever. And no, that's no policy :) Ciao, Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Packaging vanilla kernel
2007/5/23, Bernhard Walle <[EMAIL PROTECTED]>: I mean the mainline (= vanilla) kernel. I'm quite sure that vanilla kernel from http://software.opensuse.org/download/Kernel:/Vanilla/SUSE_Factory/ doesn't include bcm43xx... I typed: uname -a; echo ""; modinfo bcm43xx; echo ""; modprobe bcm43xx and there is output: Linux acer 2.6.22-rc1-48-default #1 SMP Sat May 19 03:41:30 UTC 2007 i686 athlon i386 GNU/Linux modinfo: could not find module bcm43xx FATAL: Module bcm43xx not found. -- Rafał Miłecki
[opensuse-packaging] policy for naming devel packages
Hi, it was recently (in bugreport 277317) brought to my attention that we have three packages containing development files, but not being named with a "-devel" suffix: OpenOffice_org-sdk wnn-sdk xorg-x11-server-sdk I was wondering if there is a special policy regarding the -sdk suffix that I'm not aware of? Shouldn't those packages be named -devel? Thanks, Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Packaging vanilla kernel
* Rafal Milecki <[EMAIL PROTECTED]> [2007-05-23 14:08]: > 2007/5/23, Bernhard Walle <[EMAIL PROTECTED]>: > >* Rafal Milecki <[EMAIL PROTECTED]> [2007-05-23 12:37]: > >> > >> Could someone responsible for packaing vanilla kernel add module > >> "bcm43xx" to this compiled version? I installed v2.6.22-rc1 but it > >> doesn't include bcm43xx driver for my WiFi. > > > >It is in the mainline kernel. > > Do you mean "HEAD" that is here: I mean the mainline (= vanilla) kernel. Gruß, Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmlint checks in Factory
Hello, On May 23 11:21 Dirk Mueller wrote (shortened): > So far, the following checks are enabled: > > arch-dependent-file-in-usr-share 590 > infopage-not-gzipped 540 > wrong-script-interpreter 533 > arch-independent-package-contains-binary-or-object 499 > library-without-ldconfig-postun 400 > shlib-with-non-pic-code 223 > files-duplicated-waste 100 > summary-not-capitalized 63 > spurious-executable-perm 50 > devel-file-in-non-devel-package 50 > wrong-file-end-of-line-encoding 1 > ... > The number behind the check name above is the badness score > that was assigned to it. if any build has a score above 1000, > it is currently failed. I do not understand why the badness of different errors are added at all. I think one single error is either severe enough to let the build fail or not. E.g. why is it built with one arch-dependent-file-in-usr-share and one library-without-ldconfig-postun error but not with one wrong-script-interpreter error and one arch-independent-package-contains-binary-or-object error? I suggest to compare the badness value for each single error with a threshold but not sum up anything. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Packaging vanilla kernel
2007/5/23, Bernhard Walle <[EMAIL PROTECTED]>:
* Rafal Milecki <[EMAIL PROTECTED]> [2007-05-23 12:37]:
>
> Could someone responsible for packaing vanilla kernel add module
> "bcm43xx" to this compiled version? I installed v2.6.22-rc1 but it
> doesn't include bcm43xx driver for my WiFi.
It is in the mainline kernel.
Do you mean "HEAD" that is here:
http://software.opensuse.org/download/Kernel:/HEAD/ ?
If you do, there is a problem because in HEAD there aren't RCs of
2.6.22 version. When I asked ppl compiling kernel for HEAD, they told
me that they will not prepare RCs of 2.6.22 for some time.
Moreover, thay said me to use vanilla version. When I replied that
vanilla version has not "bcm43xx", they told me I should write about
this to someone responsible for vanilla version.
--
Rafał Miłecki
N�r��y隊Z)z{.��ZrF��x>�{.n�+���Ǩ�h��]�ب��\�i��� ��$j���^��)z{.�
Re: [opensuse-packaging] Packaging vanilla kernel
* Rafal Milecki <[EMAIL PROTECTED]> [2007-05-23 12:37]: > > Could someone responsible for packaing vanilla kernel add module > "bcm43xx" to this compiled version? I installed v2.6.22-rc1 but it > doesn't include bcm43xx driver for my WiFi. It is in the mainline kernel. Thanks, Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] Packaging vanilla kernel
Hello, Could someone responsible for packaing vanilla kernel add module "bcm43xx" to this compiled version? I installed v2.6.22-rc1 but it doesn't include bcm43xx driver for my WiFi. -- Rafał Miłecki
Re: [opensuse-packaging] rpmlint checks in Factory
On Wednesday, 23. May 2007, Pavol Rusnak wrote: > Are we going to bzip2 all patches? I think it is necessary only for > large ones ... No, this warning is going to be suppressed completely. actually it seems to be a bug that it is not. Please ignore this one. > > W: plib no-cleaning-of-buildroot %install > > You should clean $RPM_BUILD_ROOT in the %clean section and just > > after the beginning of %install section. Use "rm -Rf $RPM_BUILD_ROOT". Same reason, it is supposed to be suppressed (and it is if you use the rpmlint package of STABLE on your package). it only happens with rpmlint-mini. I'll suppress it ASAP. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmlint checks in Factory
Dirk Mueller wrote: > On Wednesday, 23. May 2007, Michal Marek wrote: > >> This is one too strict: There are -examples or -doc subpackages with >> example source files, which is perfectly valid IMHO (we don't want to >> put them into -devel directly in order not to bloat buildroots. > > You're right, I've also noticed it. Please file a bugreport so that I do not > forget to fix the check. done: https://bugzilla.novell.com/show_bug.cgi?id=277317 >> Second, why sum the score for multiple instances of the same check? >> Right now a package with 20+ *.c files will fail :( > > which package are you looking at? swig of course ;-) But eg. kdevelop3 has the same problem. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmlint checks in Factory
On Wednesday, 23. May 2007, Michal Marek wrote: > Also, what about excluding /usr/share/doc/** from the checks or > degrading errors to warnings here? Some of the checks make sense even in %_docdatadir. For example, we don't want arch dependant binaries under %_docdatadir. (except if they're stored in an arch specific subdirectory, like the tex packages do right now). Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmlint checks in Factory
On Wednesday, 23. May 2007, Michal Marek wrote: > This is one too strict: There are -examples or -doc subpackages with > example source files, which is perfectly valid IMHO (we don't want to > put them into -devel directly in order not to bloat buildroots. You're right, I've also noticed it. Please file a bugreport so that I do not forget to fix the check. > Second, why sum the score for multiple instances of the same check? > Right now a package with 20+ *.c files will fail :( which package are you looking at? Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmlint checks in Factory
Dirk Mueller wrote: > Other checks are also perform and printed in the log file (autobuild only, > opensuse buildservice will follow later), but they _do_ _not_ _matter_ right > now. Warnings that caught my eye are: > W: plib source-or-patch-not-bzipped plib-1.8.4-joystick.diff > A source archive or file in your package is not bzipped (doesn't > have the .bz2 extension). To bzip it, use bzip2. Are we going to bzip2 all patches? I think it is necessary only for large ones ... > W: plib no-cleaning-of-buildroot %install > You should clean $RPM_BUILD_ROOT in the %clean section and just > after the beginning of %install section. Use "rm -Rf $RPM_BUILD_ROOT". I read on some mailing list that cleaning of build root in install section is a security issue. Unfortunately, I cannot remember which list it was :( -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package MaintainerLihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.czhttp://www.suse.cz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmlint checks in Factory
Michal Marek wrote: > Dirk Mueller wrote: >> Hi, >> >> There are new, considered to be experimental, checks for rpmlint diagnostics >> in Factory. So far, the following checks are enabled: >> > ... >> devel-file-in-non-devel-package 50 > ... > > This is one too strict: There are -examples or -doc subpackages with > example source files, which is perfectly valid IMHO (we don't want to > put them into -devel directly in order not to bloat buildroots. > > Second, why sum the score for multiple instances of the same check? > Right now a package with 20+ *.c files will fail :( Also, what about excluding /usr/share/doc/** from the checks or degrading errors to warnings here? The /usr/lib/rpm/find-requires script also skips this path. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmlint checks in Factory
Dirk Mueller wrote: > Hi, > > There are new, considered to be experimental, checks for rpmlint diagnostics > in Factory. So far, the following checks are enabled: > ... > devel-file-in-non-devel-package 50 ... This is one too strict: There are -examples or -doc subpackages with example source files, which is perfectly valid IMHO (we don't want to put them into -devel directly in order not to bloat buildroots. Second, why sum the score for multiple instances of the same check? Right now a package with 20+ *.c files will fail :( Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] rpmlint checks in Factory
Hi, There are new, considered to be experimental, checks for rpmlint diagnostics in Factory. So far, the following checks are enabled: arch-dependent-file-in-usr-share 590 infopage-not-gzipped 540 wrong-script-interpreter 533 arch-independent-package-contains-binary-or-object 499 library-without-ldconfig-postun 400 shlib-with-non-pic-code 223 files-duplicated-waste 100 summary-not-capitalized 63 spurious-executable-perm 50 devel-file-in-non-devel-package 50 wrong-file-end-of-line-encoding 1 Other checks are also perform and printed in the log file (autobuild only, opensuse buildservice will follow later), but they _do_ _not_ _matter_ right now. The number behind the check name above is the badness score that was assigned to it. if any build has a score above 1000, it is currently failed. There are some packages which might suffer from false positives of above checks. Please, in order to help clean that up, file a bugreport against me ([EMAIL PROTECTED]) mentioning package name and check that you consider false, and I'll fix it ASAP. About the warning only checks: If you encounter any of such checks that you feel are wrong, are not complying our best practices or are exceptions that should be suppressed, PLEASE tell me about it! Do not hack around them! So, if you have a failed build today, please look ONLY for '^E:' in the logfile to figure out why it was failed. Each line has a badness score besides it. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
