[opensuse-packaging] [Fwd: [yast-devel] sw_single Acccessibility Category]
Hi, It seems that this mail rather belongs here. RPM Groups should be assigned in RPM spec file. YaST software management doesn't assign packages to groups (here called "category"). Thx && Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) - SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic --- Begin Message --- We're working on figuring out what all the accessibility tools software already exists. For now, we're looking at gnome.org's accessibility documentation and then running searches in sw_single to determine whether we have it already. But some tools listed in their documentation is named differently on our end. For example: gnome-online-keyboard in the documentation is gok in our repository. We think it would be well worth it if an accessibility category could be added so users could easily narrow down what tools are available for download/already-installed. Would it be feasible to add such a category? I would be more than happy to compile a list over the next few months of such tools so we can populate the category. Thanks! -- ---Bryen--- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- End Message --- signature.asc Description: OpenPGP digital signature
[opensuse-packaging] licenses.rpm again
Hi, I've found this output in the finished 'build': --- cut --- Your package contains a file that contains the FSF GPLv2 license. If you really have to ship it, consider symlinking it from the licenses package. --- cut --- I remember deciding that we'll not use the licenses.rpm... or am I wrong? What's the current status, please :)? Thanks Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) - SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic signature.asc Description: OpenPGP digital signature
Re: [opensuse-packaging] New rpmlint check in BETA
Dirk Mueller napsal(a): > Hi, > > as a followup of the discussion of yesterday: > > There is a new check in BETA which will check for missing prerequires for > your %pre/%post/%preun%postun scripts. > > An example would be : > > kdemultimedia3-extra.i586: E: no-prereq-on coreutils for mv > > which says, that kdemultimedia3-extra contains a %post script that contains a > call to "/bin/mv", however coreutils or /bin/mv is not in the prereq for that > package. The check is fatal for repeated abuse. > > for (other) details, please refer to http://en.opensuse.org/Packaging/RpmLint > > Please file bugreports if you run accross a false positive/false negative/do > not understand the report/etc. Thanks a lot! That's even more than I expected to happen :) It seems that cooperation works at this mailing-list. Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) - SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic signature.asc Description: OpenPGP digital signature
Re: [opensuse-packaging] RPM dependencies vs. post-install scripts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Volker Kuhlmann wrote:
> On Fri 02 Nov 2007 23:11:41 NZDT +1300, Martin Vidner wrote:
>
>> here's a patch, untested.
>
>> --- PostCheck.py.orig2006-11-08 20:34:35.0 +0100
>> +++ PostCheck.py 2007-11-02 11:10:04.0 +0100
>
>> +['cp', ('coreutils', '/bin/cp')],
>> +['ln', ('coreutils', '/bin/ln')],
>> +['mv', ('coreutils', '/bin/mv')],
>> +['rm', ('coreutils', '/bin/rm')],
>> +['sed', ('sed', '/bin/sed')],
>
> I know nothing about nothing, but looking at that list makes me want to
> check whether awk/gawk/nawk are missing.
Oh, good point! Thanks.
Maybe also these, just quessing...
/bin/rmdir, /bin/mknod, /bin/ls, /bin/touch, /bin/chmod, /bin/chown,
/bin/cat, /usr/bin/cut, /usr/bin/md5sum
(all in coreutils.rpm)
Any other (e.g., better) ideas ;)?
Thanks && Bye
Lukas
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHK6bZVSqMdRCqTiwRAhuiAJ4z03T5GywupxIClhCYFEQAj8aCjQCbBiL+
t2ie24hTPVxeG11rde7KXO0=
=KP3N
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] RPM dependencies vs. post-install scripts
Stephan Kulow napsal(a): > Am Donnerstag 01 November 2007 schrieb Lukas Ocilka: >> Hi, >> >> I've found that some packages containing post-install scripts might not >> have defined RPM dependencies correctly. All those commands used in >> post-scripts should be explicitly requested. Please, correct me if I'm >> wrong :) >> >> --- examples --- >> 2007-10-31 19:20:46 lukemftp-1.5-660.x86_64.rpm installed ok >> Additional rpm output: >> /var/tmp/rpm-tmp.16471: line 1: rm: command not found >> >> 2007-10-31 19:21:50 preload-0.2-110.x86_64.rpm installed ok >> Additional rpm output: >> /var/tmp/rpm-tmp.11270: line 16: sed: command not found >> --- examples --- >> >> Please, check and fix your packages. >> Thanks >> >> Maybe someone could extend our 'build' scripts to check the post-install >> scripts whether they contain only commands (binaries) mentioned in RPM >> dependencies? >> > Do you speak python? Extend rpmlint's PostCheck.py It's a shame but I don't ;) I hope, there's someone who does and is willing to help. Any volunteer? Bye Lukas signature.asc Description: OpenPGP digital signature
[opensuse-packaging] RPM dependencies vs. post-install scripts
Hi, I've found that some packages containing post-install scripts might not have defined RPM dependencies correctly. All those commands used in post-scripts should be explicitly requested. Please, correct me if I'm wrong :) --- examples --- 2007-10-31 19:20:46 lukemftp-1.5-660.x86_64.rpm installed ok Additional rpm output: /var/tmp/rpm-tmp.16471: line 1: rm: command not found 2007-10-31 19:21:50 preload-0.2-110.x86_64.rpm installed ok Additional rpm output: /var/tmp/rpm-tmp.11270: line 16: sed: command not found --- examples --- Please, check and fix your packages. Thanks Maybe someone could extend our 'build' scripts to check the post-install scripts whether they contain only commands (binaries) mentioned in RPM dependencies? Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) - SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic signature.asc Description: OpenPGP digital signature
Re: [opensuse-packaging] rpm5.org
Marcus Rueckert napsal(a): > On 2007-10-25 13:06:59 +0200, Peter Czanik wrote: >> Well, in this case I would not need to enter a blocker bug for openSUSE >> 10.3 ppc32 just a few minutes ago ( >> https://bugzilla.novell.com/show_bug.cgi?id=336678 ). The problem is, >> that 64bit packages are installed on a 32bit system, and render it >> practically useless, especially when it comes to on-line updates... > > that is a yast bug and not an RPM bug. > > subtile difference. Is that a YaST or libzypp bug? That's also different... Lukas signature.asc Description: OpenPGP digital signature
Re: [opensuse-packaging] -lang subpackages
Wolfgang Rosenauer napsal(a):
> Hi,
>
> maybe I missed some announcement or document but I noticed that some
> packages (seems mainly Gnome ones) splitted the locale files out into an
> extra %{name}-lang package.
>
> What's the purpose of doing that? Is there any package conventions
> document about it?
> Is it to prepare an en-US only media and keeping the package sizes as
> small as possible?
Hi,
As openSUSE is localized into more and more languages, the total size of
all translations for grows as well. In my opinion this was done (also)
to make one-CD-installation and LiveCD possible. Non-English
translations can be downloaded from Online Repositories even during the
installation process.
On the other hand, splitting into '%{name}' and '%{name}-lang' makes
sense only for packages with not many strings for translations. If there
are many strings translated, it's worth creating separate RPMs even for
particular translations '%{name}-lang-%{translation}'.
Some other packages have been split into '%{name}' and
'%{name}-devel-doc' just for the same reason (for instance some YaST
packages).
BTW: Splitting into more packages needs to be always evaluated how
worthy it is, e.g., because of the RPM-metadata overload.
Lukas
--
Lukas Ocilka, YaST Developer (xn--luk-gla45d)
-
SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic
signature.asc
Description: OpenPGP digital signature
Re: [opensuse-packaging] Re: Handling license symlinks
Richard Guenther wrote: > On Mon, 3 Sep 2007, Juergen Weigert wrote: >> ... >> Unfortunatly, this licenses package is error prone. Not very probable, but >> with possbile severe effects: if a package has a symlink for GPL, but >> this link is dangling, we violate the GPL. >> >> Does anybody know if the licenses package had a space >> saving effect on the media? >> >> Any tears if we roll back to the state we had before? > > Well, I proposed to handle this problem with rpm provides / requires. > That is, licenses should provide license-$MD5 for all licenses it includes > and a package with the symlink should require this. That way no > dangling symlink can happen unless you install with --nodeps. Libzypp supports --nodeps as a fallback solution for installing RPMs. First, it, of course, tries to install an RPM in a normal way, then libzypp tries that with --nodeps automatically. So even our package manager is able to install such package without installing licenses.rpm. Lukas signature.asc Description: OpenPGP digital signature
Re: [opensuse-packaging] Handling license symlinks
Christian Boltz wrote: > Hello, > > creating the symlink to licenses in the licenses package is curently > done by including a small script in each spec file, like: > > for FILE in COPYING copyright.txt ; do > MD5SUM=$(md5sum $FILE | sed 's/ .*//') > if test -f /usr/share/doc/licenses/md5/$MD5SUM ; then > ln -sf /usr/share/doc/licenses/md5/$MD5SUM $FILE > fi > done > > This is error-prone (see bug 306681) and adds lots of duplicated code to > the spec files. > > Please add a small script to the licenses package or create a rpm macro > that creates the symlink. If the rpm macro could also drop in a > "Requires: licenses", it would be even better. We already tried to solve this issue. The problem is (also) that there is no known list of license filenames (COPYING, copyright.txt, Copyright.txt, COPYING.english ...) Anyway, I'd be still for having the macro, probably two of them: 1.) automatic macro that tries known filenames 2.) manual macro that expects filenames as a parameter Adding or checking whether RPM requires 'licenses' would be very nice! ;) Bye Lukas signature.asc Description: OpenPGP digital signature
Re: [opensuse-packaging] Split licenses.rpm (based on 'Building packages with linking a license from licenses.rpm')
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Boltz wrote: > Hello, > ... > You mentioned an interesting point: Licenses used just for one package. > IMHO it's pointless to move them to the licenses package because you > can't save any space - you only can waste it if the package with that > license isn't installed. > > I'd propose to put only licenses that are used at least by 10 packages > in the licenses package. This solves several problems: > - the non-existing space saving effect I mentioned above > - the risk of having to keep old licenses (as mentioned by Robert) just > to stay backward-compatible is reduced (because at least some of the > packages will still be using it ;-) > - the licenses package would be smaller - no need to split it Actually *all* licenses are in one package, so moving a license file from one to another isn't *space wasting* :) rpm -ql licenses | grep /usr/share/doc/licenses/md5/ | wc -l 263 Your proposal including a license in licenses.rpm seems to be interesting, however it doesn't solve *space wasting* because there is no such issue. We should, of course, include only licenses, that are in use. Backward compatibility should be considered only for already released RPMs for one product. (I think this might be a bit tricky if not handled correctly). Have a nice... whatever :) Lukas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGrPmcVSqMdRCqTiwRAmCEAJ0cuzTS3uqiknL+9Y5+AiLVCWEAoACbBEH4 xSjdK0qREwQ/qXjbogV9mPo= =nyNm -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Split licenses.rpm (based on 'Building packages with linking a license from licenses.rpm')
Robert Schiele wrote: > On Wed, Jul 25, 2007 at 02:27:13PM +0200, Lukas Ocilka wrote: >> We are asking for your opinion whether it even makes sense to invest >> (waste) some time in this area ;) > > You should consider one big warning here: If you have only one license package > you can just add licenses there and basically never delete one. This ensures > that with a license package that is at least as recent as your other most > recent package you can always fulfill any dependencies. If you do > licenses-base you might want to remove licenses there as well and move them > into the other licenses package but as soon as you start removing licenses > from there you might break older packages installed on a system. > > Sure you can find solutions for all these problems but in my opinion it will > just produce a bug mess and source of inconsistencies. That's a good point, thanks. On the other hand it always depends on the current solution: Possibly buggy solution --- * licenses-base.rpm provides 'licenses-base' * my package requires 'licenses-base' Possibly working solution :) - (already mentioned on this mailing-list) * licenses-base.rpm provides 'licenses/md5/005e9765ce1a51f0aab9b2e14a785474' ... 'licenses/md5/0636e73ff0215e8d672dc4c32c317bb3' 'licenses/md5/18ba770020b624031bc7c8a7b055d776' ... 'licenses/md5/fd6c32a44ff3cf3efd167ddb697b9eb1' * my package requires 'licenses/md5/0636e73ff0215e8d672dc4c32c317bb3' Even if the license is moved anywhere else, the dependency is solved automagically ;) (if "Provides" is changed as well). Lukas signature.asc Description: OpenPGP digital signature
Re: [opensuse-packaging] Building packages with linking a license from licenses.rpm
Juergen Weigert wrote: > On Jul 25, 07 15:40:26 +0200, Petr Cerny wrote: >> Juergen Weigert wrote: >>> Due to the symlink, the package has now one more dependency. >>> It is simply an incomplete package, unless licenses.rpm is also installed. >>> If the FSF insists on having a copy in each RPM, we can simply stop doing >>> symlinks for GPL, and still have saved a tree with all the other licenses >>> symlinked. >> As GPL is (by guess) in most of our packages, it wouldn't make sense to >> create license-package without GPL in it. > > Besides saving space on distribuition media, > the license package serves another goal: > It establishes /usr/share/doc/licenses as a central point for license > files. This goal could also be achieved by other means. Open to > suggestions. And even if FSF doesn't accept our solution. We could just use /usr/share/doc/licenses (+/md5/ab58...586cc) for storing the license of our package. The same file would be just owned by several packages. Plus linking it from our package. OK, not a nice solution, but it might work if the licenses.rpm one fails. Lukas signature.asc Description: OpenPGP digital signature
Re: [opensuse-packaging] Split licenses.rpm (based on 'Building packages with linking a license from licenses.rpm')
Marcus Rueckert wrote: > On 2007-07-25 14:07:07 +0200, Lukas Ocilka wrote: >> After our discussion with JSrain we decided to write to packages with >> just another issue about licenses.rpm. >> >> The current RPM content size (unpacked) is quite big >> du -sh /usr/share/doc/licenses/ -> 3.9 MB > > how much space do we save with no longer duplicating files? > >> This package-size is a bit disputable when talking about saving-space ;) > > it would still save us space on the media. and text files can be > compressed very well. Yes, the current solution fits the task 'make installation media smaller' well but there is another major task: 'make the minimal installation small as possible'. >> Actually it is because the package contains some very-rare licenses or >> some obscure licenses used just for one package in our distribution. >> >> The proposal is simple: >> - Find out, which packages in a minimal installation use which licenses >> and create licenses-base.rpm (for example) that would contain only >> those important/used licenses. >> - The rest could stay in licenses.rpm. >> >> We'd save space for the minimal-installation and we'd still have all >> licenses for 'the other cases'. BTW: I have to admit, that splitting-it >> up was a jsrain's idea :) ;) >> >> What do you think of that? > > do you have any numbers for the license-base.rpm? how many licenses > would be needed? whats the installed size? Honestly, we didn't do any research in that way. That would need to check every single package in the minimal installation whether it contains some file with license and which license it is. We are asking for your opinion whether it even makes sense to invest (waste) some time in this area ;) Lukas signature.asc Description: OpenPGP digital signature
[opensuse-packaging] Split licenses.rpm (based on 'Building packages with linking a license from licenses.rpm')
Moin, After our discussion with JSrain we decided to write to packages with just another issue about licenses.rpm. The current RPM content size (unpacked) is quite big du -sh /usr/share/doc/licenses/ -> 3.9 MB This package-size is a bit disputable when talking about saving-space ;) Actually it is because the package contains some very-rare licenses or some obscure licenses used just for one package in our distribution. The proposal is simple: - Find out, which packages in a minimal installation use which licenses and create licenses-base.rpm (for example) that would contain only those important/used licenses. - The rest could stay in licenses.rpm. We'd save space for the minimal-installation and we'd still have all licenses for 'the other cases'. BTW: I have to admit, that splitting-it up was a jsrain's idea :) ;) What do you think of that? Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) - SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic signature.asc Description: OpenPGP digital signature
Re: [opensuse-packaging] Building packages with linking a license from licenses.rpm
Reinhard Max wrote: > On Wed, 25 Jul 2007 at 12:00, Ludwig Nussel wrote: > >> You wouldn't be able to install the package without breaking >> dependencies. That's annoying at least. > > Right, but that wouldn't matter from a legal point of view. If a > license requires us to include the license text with the binary > package, we might break the license no matter how hard we make it to > install the package without the license file being installed as well. > > GPLv2 says (section 1.) "[...] and give any other recipients of the > Program a copy of this License along with the Program." So, is setting > a symlink to a file and adding a dependency to the package enough to > fulfill the "along with the Program" requirement? When I saw this discussion, I decided to ask JW and Coolo if the solution is legal and Coolo wrote me this: --- cut --- Well, as Jürgen is both maintainer of that package and part of our license review team, I don't feel any need to play lawyer. So stop worrying :) --- cut --- Let's accept that, please :) Bye Lukas signature.asc Description: OpenPGP digital signature
[opensuse-packaging] Building packages with linking a license from licenses.rpm
Hi, I've found that we have a 'licenses' package that contains all known/used licenses. The intention seems to be to save some space by not including own copy of license in each package but linking it (and to clean the system up a bit). It seems to be quite good idea but I haven't found any documentation, howto, wiki page that would describe how to modify my packages to use it. Could someone, please point me (us) to some documentation, howto? Thanks & Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) - SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic signature.asc Description: OpenPGP digital signature
[opensuse-packaging] Changing YaST Packages in Autobuild
Hi, It happens time to time that someone needs to urgently change some YaST package in autobuild. This is actually possible but you should know that autobuild is not the primary source of YaST packages. Our primary source is our SVN: http://svn.opensuse.org/svn/yast/ First, you had better contact the MAINTAINER of the package and consult the change with him/her. You can change the package in autobuild but you need to send a diff file to the maintainer or change SVN as well. Please, NEVER submit a changed package to autobuild without announcing the change to the maintainer of the package and without providing the patch or changing the source directly in SVN. Thanks & Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) - SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic signature.asc Description: OpenPGP digital signature
[opensuse-packaging] New Functionality: Ports for SuSEfirewall added via packages
Hi,
A new functionality "Ports for SuSEfirewall added via packages" (FATE
#300687) has been added to YaST in openSUSE 10.3. Of course, this
functionality needed to be implemented in SuSEfirewall2 first (since
openSUSE 10.2 thanks to Ludwig).
So what is it all about and why am I writing about it to this mailing-list?
In older versions of YaST Firewall, there was a hard-coded list of so
called "Known Services" (e.g., Samba Server or DNS Server) with defined
ports to be open in firewall but this list didn't reflect the current
state of installed packages and it was a pain to add a new service there.
What the current solution offers?
* Only installed services are offered in YaST Firewall to be open.
* Abstraction layer for SuSEfirewall2 that increases the security.
* Solved conflicting services - lighthttpd vs. apache2, nfs vs. nis.
* No need for hard-coded and not-maintained static list.
More detailed information:
http://en.opensuse.org/SuSEfirewall2/Service_Definitions_Added_via_Packages
Some of you have been already assigned to a bugzilla enhancement, that
requests adding such configuration file into your packages and more will
probably come.
PS: Just a small change for using these services in YaST. Using the
hard-coded list is an obsolete functionality but still remains the same,
for using the new definition of services, you need to identify the
service by "service:${service-id}".
Thanks & Bye
Lukas
--
Lukas Ocilka, YaST Developer (xn--luk-gla45d)
-
SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic
signature.asc
Description: OpenPGP digital signature
