Re: [opensuse-packaging] openSUSE 11.0 - call for package updates
Hello, On Jan 10 16:50 Stephan Kulow wrote (shortened): Am Donnerstag 10 Januar 2008 schrieb Andreas Jaeger: Marcus Meissner [EMAIL PROTECTED] writes: ... openSUSE 11.0 Beta1 is coming closer ... ... Beta1? Alpha1 is coming but not beta1 ;-) beta1 is coming closer too - just slower :) Wow! The first very official confession from the management that there is no such thing as a fixed schedule and that the time intervals between the releases increase over the time ;-) 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] openSUSE 11.0 - call for package updates
Hello, On Jan 11 12:01 Andreas Jaeger wrote (shortened): Johannes Meixner [EMAIL PROTECTED] writes: On Jan 10 16:50 Stephan Kulow wrote (shortened): Am Donnerstag 10 Januar 2008 schrieb Andreas Jaeger: Marcus Meissner [EMAIL PROTECTED] writes: ... openSUSE 11.0 Beta1 is coming closer ... ... Beta1? Alpha1 is coming but not beta1 ;-) beta1 is coming closer too - just slower :) Wow! The first very official confession from the management that there is no such thing as a fixed schedule and that the time intervals between the releases increase over the time ;-) You're reading more into this than there is. It seems you missed my ';-)'. And I guess you understood Stephan's slower as later but I sent a jokey comment about the consequences of slower (i.e. if the speed decreased how fast Beta1 would come compared to how fast Alpha1 is coming) - or in other words: What happens if the speed of the coaches in a train differs? To make it 100% totally clear for all readers: My comment was of course not meant seriously. 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] How to deal with Python .pyc and .pyo files?
Hello Jan, On Nov 15 20:09 Jan Matejek wrote (shortened): Johannes Meixner napsal(a): Are byte-compiled Python .pyc and .pyo files the same for any Python and/or is any Python sufficiently smart to know when .pyc and/or .pyo files are outdated (even if the matching .py files are unchanged)? They are (mostly) the same, AND there is some kind of version check in the file. Don't worry about this, python would notice any problem by itself ;e) Second worst case would be if you upgraded to a new major version of python, i.e. from 1.5 to 2.0. In that case python would report errors about bad bytecode, and i'm really not sure if it would recompile automatically. But i think it would. Worst case would be if you downgraded, i don't think python 1.5 could cope... But on the other hand, i don't think this problem is worth considering. That's why python has versioned site-packages. In your other post you noticed that python files are strewn all over the system. In most cases that is bad packaging. Generally speaking, all python files should be located in /usr/lib[64]/pythonx.y/site-packages (of course there are exceptions, but let's not go into that). Many thanks for the explanation! Now I understand the stuff and now I understand why and what I must fix in particular in my hplip package which installs its .py files (but no .pyc or .pyo file at all) under /usr/share/hplip/* Currently I just run HP's make install (HPLIP is made by HP) and I need to find a solution together with HP to get it fixed. By the way: Isn't there a general problem with python files strewn all over the system? How does Python deal with .py files from whatever personal Python projects in user's home directories? The user has write access so that he gets .pyc or .pyo files stored where his .py files are. What happens if the system admin upgrades to a new major version of Python? I think the same problem (perhaps even in a worse shape) exists for whatever third-party Python stuff which gets installed somewhere under /opt/ or /usr/local/. Think about proprietary third-party software which cannot be changed and which exists for more than one SLES version. I don't know if the Python license allows to have proprietary Python stuff but I think you understand the basic idea behind. http://www.python.org/doc/1.5.1p1/tut/node43.html seems to indicate that at least semi-proprietary Python stuff can exist because it reads: --- It is possible to have a file called spam.pyc (or spam.pyo when -O is used) without a module spam.py in the same module. This can be used to distribute a library of Python code in a form that is moderately hard to reverse engineer. --- There could be even binary-only third-party Python stuff where no .py files exist. What happens if a system upgrade (e.g. SLES N - SLES N+1) upgrades Python to a new major version? But even more important is that regular user doesn't have write access to wherever the .py files are stored. You would need to run each python program as root first, otherwise python would need to compile the sources every time the program is run. This has another consequence: It doesn't help not to provide .pyc or .pyo files in the RPM to avoid problems with outdated .pyc or .pyo files if the Python major version changes because when root runs whatever .py files, the matching .pyc or .pyo files are created in any case. I am no Python expert at all and I would be happy if a Python expert could provide some background information. is this background sufficient? ;e) Yes, it is perfect and I am happy. 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]
[opensuse-packaging] How to deal with Python .pyc and .pyo files?
Hello, what is the recommended way for packaging Python stuff? Either have byte-compiled Python .pyc and .pyo files packaged into the RPM or let this be done by the currently actually installed Python system during run-time on the end-user's computer and not by whatever (perhaps different) Python system during package build-time? 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] -mini packages purpose
Hello, On Nov 9 10:22 Michal Marek wrote: Cristian Rodriguez wrote: What is the specific reason for having foobar-mini packages ? I guess those provides less functionality but for what use cases are needed or what is the rationale behind them ? To minimize build dependencies and/or break cycles. They only live inside autobuild, because they have no use in a running system. In the Java/JPackage world we use *-bootstrap as package name for such kind of packages, e.g.: antlr-bootstrap.rpm, ecj-bootstrap.rpm, xerces-j2-bootstrap.rpm, xml-commons-apis-bootstrap.rpm, xml-commons-resolver-bootstrap.rpm, xml-commons-which-bootstrap.rpm 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] Split licenses.rpm (based on 'Building packages with linking a license from licenses.rpm')
Hello, On Jul 30 17:26 Juergen Weigert wrote (shortened): The point in having /usr/share/doc/licenses is that this establishes one single location where all licenses used in a product are visible. Might this cause confusion for some users when they find out that they have many special licenses installed but not the software which belongs to those special licenses? I.e. what about my installed licenses versus all licenses which are somewhere used by whatever software in the product? (Yes, I know, the obvious technical solution is to check to which installed license a symlink points ;-) 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] Building packages with linking a license from licenses.rpm
Hello, On Jul 24 10:46 Lukas Ocilka wrote (shortened): 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). ... Could someone, please point me (us) to some documentation, howto? And in particular some explanation how to make sure that the license in the 'licenses' package is still exactly the right one even after whatever kind of update of the referring package. What I like to point out is that I would not touch any license if there is no 100% safe automatism which checks that the licenses are 100% correct in any case. 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] Building packages with linking a license from licenses.rpm
Hello, On Jul 24 12:47 Lars Vogdt wrote (shortened): http://en.opensuse.org/Licenses The plain Requires: licenses can cause invalid licenses when another version of the package (with different licenses) is installed but the licenses package is not upgraded accordingly. I am speaking about the run-time system, not the build-time system. But even a strict Requires: licenses = 1.2.3 where 1.2.3 is the exact version of the licenses package which was used during build-time may cause problems: Assume there are two packages foo and bar which both use the license batz in licenses 1.2.3 but then license batz is upgraded and also package foo is upgraded (using the upgraded license batz in licenses 1.2.4). Then there would have to be licenses 1.2.3 (for package bar) and licenses 1.2.4 (for upgraded package foo) installed. 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] Building packages with linking a license from licenses.rpm
Hello, On Jul 24 15:10 Pavol Rusnak wrote (shortened): MD5 (or any other hash) guarantees that link is not pointing to wrong license file but it does not assure that such file license-hash.txt is installed on system. I think that's the issue Johannes wanted to point out. Exactly. By the way: Does anybody know about RFC 1925? (in particular its items (6a) and (8) ;-) 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] 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] Proposal: Any rm in .spec %install must be commented
Hello, On Mar 15 11:45 Stanislav Brabec wrote (shortened): So I propose: Each removal in %install phase must be correctly commented I suggest even more: Everything in the spec file where it is not totally obvious what it does and why it is done must be commented so that an external person understands what it does and why it is done. 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] Proposal: Any rm in .spec %install must be commented
Hello, On Mar 15 14:35 Klaus Singvogel wrote (shortened): Please explain to me: which maintainer is having so much time? I do not have the time to write no comments! Reason: When I work some time later again on the package I might perhaps not remember every detail why I did what and then my comments save my time. By the way 1: It is the same idea as with the poor hunter who cannot afford to have a cheap gun. By the way 2: How I like it when others change my spec files without a meaningful comment in the spec file what was done and why because it wastes my time when I must find out from a meaningless one line comment in the changes file what actually had happened (therefore I carefully watch the autobuld check-in mails). By the way 3: Perhaps I should buy a solid gun? ;-) Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex PS: To avoid misunderstandings: Klaus never changed my spec files. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Proposal: Any rm in .spec %install must be commented
Hello, On Mar 15 14:58 Juergen Weigert wrote (shortened): The concept of 'totally obvious' is an illusion. You got the idea because: I use this as a rule of thumb: Whenever I read my own code a second time, and have to think about a line for more than a split second, I put a comment next to it with the results of my analysis. I use a bit different rule of thumb: Whenever I write whatever kind of code and have to think about it for more than a few seconds, I put a meaningful comment next to it about what I had in mind (usually just a hint to point me into the right direction when I read the code later again). For example: NOT: # remove icon rm icon.png BUT: # there is a system default icon rm icon.png 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]
