Re: [Leaf-devel] Package description file proposal
On 4/14/02 at 11:20 AM, Mike Noyes [EMAIL PROTECTED] wrote: David outlines a package description file in his Developing for LRP guide. The format follows. /var/lib/lrpkg/pkg.desc Name: upx Version: 1.20 Release: 1 Packager: David Douthitt [EMAIL PROTECTED] Packaged: Wed Jul 18 09:40:25 CDT 2001 Keywords: compressor compress Description: Use UPX to compress executables and kernels! URL: http://upx.sourceforge.net/ License: GPL2 Group: Utilities/Compression I propose the following changes: Comments follow... use program name instead of package name, Thought those were supposed to be (close) to the same? Probably the actual name of the binary or program should be used. use ISO 8601 date format, I figured the date format could be whatever - ISO 8601 works for me use version format from pkg.version, Yes and no... add glibc version, Good idea... remove Keywords, Release, and Group. Bad idea. Keywords allow basic searches: cd /var/lib/lrpkg grep -li ^Keywords: .*keyword* | sed 's/.desc$//' Release allows you to separate releases from versions. Group is one of the best reasons for *.desc: what category IS this package - allows nice creation of FTP repositories. Name: Ultimate Packer for eXecutables Ouch! That's neither a program name nor a package name. The program is upx Version: 1.20-1 upx is not version 1.20-1 but version 1.20 (at least in this example). Packager: David Douthitt [EMAIL PROTECTED] Packaged: 2001-07-18 glibc: 2.1.3 Description: UPX is a free, portable, extendable, high-performance executable packer for several different executable formats. It achieves an excellent compression ratio and offers very fast decompression. Your executables suffer no memory overhead or other drawbacks. URL: http://upx.sourceforge.net/ License: GPL2 -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Package description file proposal
On Tue, 2002-04-16 at 03:46, David Douthitt wrote: On 4/14/02 at 11:20 AM, Mike Noyes [EMAIL PROTECTED] wrote: David outlines a package description file in his Developing for LRP guide. The format follows. snip I propose the following changes: Comments follow... use program name instead of package name, Thought those were supposed to be (close) to the same? Probably the actual name of the binary or program should be used. David, I think we should use the program's name, or place it in what RedHat calls Summary. Personally I prefer the deb format, but it doesn't include summary/program name information. :-( Program: Ultimate Packer for eXecutables = RPM Summary = DEB N/A Executable: upx = RPM Name = DEB Package Package: upx.lrp = RPM N/A = DEB Filename Debian packages provide the following information (apt-cache show): Package, Version, Priority, Section, Maintainer, Depends, Suggests, Conflicts, Provides, Replaces, Architecture, Filename, Size, MD5sum, Description, installed-size. RedHat rpms have this summary information (rpm -q -i): Name, Version, Release, Install date, Group, Size, URL, Summary, Description, Relocations, Vendor, Build Date, Build Host, Source RPM, License Does anyone know what information is provided by Debian udeb or Midori packages? snip remove Keywords, Release, and Group. Bad idea. Keywords allow basic searches: cd /var/lib/lrpkg grep -li ^Keywords: .*keyword* | sed 's/.desc$//' Release allows you to separate releases from versions. Group is one of the best reasons for *.desc: what category IS this package - allows nice creation of FTP repositories. Who determines what keywords and categories apply to each package? I believe these tags will cause confusion if there is no set categorization template. Name: Ultimate Packer for eXecutables Ouch! That's neither a program name nor a package name. The program is upx In my opinion that is the program name, while upx is the executable name (see example above). Version: 1.20-1 upx is not version 1.20-1 but version 1.20 (at least in this example). In your example, why did you indicate a release level of 1? Is the release level different than the hyphen would indicate? -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ldd libc minor version
On Mon, 2002-04-15 at 22:52, Jeff Newmiller wrote: On 15 Apr 2002, Mike Noyes wrote: Everyone, I'm still unable to decipher the libc minor version from output generated by ldd. All of our packages that I have looked at so far use libc major version 6. The output below is from KP's squid-2 package. He states that it was compiled with glibc 2.1.3. How can I verify this from the output below? You can't, unfortunately. Your goal is a hard one to reach, at least for me. Jeff, For me too. :-( Your original question to which I responded with the ldd solution did not specify specifically the glibc versioning problem. Sorry I didn't read between the lines. It's probably my fault for incorrectly articulating the problem. Output generated on shell.sf.net: snip Output generated on my local machine: very informative information removed One possible avenue would be to learn what the offset of the last function in glibc2.0 was, and if any of the fixup offsets in an executable was greater than that value then that executable would be expected to break with glibc2.0 (when the program calls it, it would execute undefined opcodes). This might be extended to handle various glibc versions, but I suspect it would be uncomfortably closely tied to specific compilations of glibc. This is probably possible, but it's beyond my ability to do. BTW: apparently, the number in parentheses displayed by ldd is the process space address at which the first byte of the library would be loaded. I think this is what the fixup offsets in the executable would be added to to get the locations of the library functions. It would probably be specific to each compilation of that program, and would have no direct value in determining the library version. OK. Thanks for the information. Everyone, Apparently it's a non-trivial task to determine the minor version of libc used for package creation. Tomorrow I'm going to start committing our packages to cvs with the following tree structure: bin/packages + /glibc2.0 | + /glibc2.1 Should I use libc6 and libc6.1 instead of glibc? Commits will include the following information if known: Program name: Program version: Packager: Creation Date: I'll place all of the packages that require libc.so.6 in the glibc2.0 directory. The few packages that don't depend on any libc will be placed in the bin/packages directory. Anyone that created packages that use glibc 2.1 please let me know about them. Look at the file below to see my commit order. http://leaf.sourceforge.net/pub/packages/test.txt Comments and suggestions are welcome. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ldd libc minor version
Everyone, Apparently it's a non-trivial task to determine the minor version of libc used for package creation. Tomorrow I'm going to start committing our packages to cvs with the following tree structure: bin/packages + /glibc2.0 | + /glibc2.1 Should I use libc6 and libc6.1 instead of glibc? Commits will include the following information if known: Program name: Program version: Packager: Creation Date: I'll place all of the packages that require libc.so.6 in the glibc2.0 directory. The few packages that don't depend on any libc will be placed in the bin/packages directory. How about using bin/packages/nolibc (or similar) instead? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Package description file proposal
Who determines what keywords and categories apply to each package? I believe these tags will cause confusion if there is no set categorization template. Maybe there should be one file templated out with certain information, like source version, package revision, packagename, glibc-required, maintainer, etc put a space/comma seperated line similar to the LRP= line in syslinux.cfg for the repository. This would be easily parsed by awk for administration of the list... but this would require strict adherance to the template format to work. Version: 1.20-1 upx is not version 1.20-1 but version 1.20 (at least in this example). In your example, why did you indicate a release level of 1? Is the release level different than the hyphen would indicate? It would indicate to me that it uses the same compliled source-code, but the package scripting (for .lrp) has been revised/patched. This will likely happen on occasion since the package maintainer does add scripting for use with LEAF. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Package description file proposal
On Tue, 2002-04-16 at 09:46, guitarlynn wrote: Who determines what keywords and categories apply to each package? I believe these tags will cause confusion if there is no set categorization template. Maybe there should be one file templated out with certain information, like source version, package revision, packagename, glibc-required, maintainer, etc put a space/comma seperated line similar to the LRP= line in syslinux.cfg for the repository. This would be easily parsed by awk for administration of the list... but this would require strict adherance to the template format to work. Lynn, Good idea, but I think XML meta-data would be the preferred format. This would allow parsing by many different programs. Maybe the filename should be /var/lib/lrpkg/pkg.xml instead of pkg.desc. We still have to agree on what fields should be included, and their names. Also, I'm still concerned about the keywords and categories. How will we define them for each package? Will we use RedHat's/Debian's keywords/categories or something else? Version: 1.20-1 upx is not version 1.20-1 but version 1.20 (at least in this example). In your example, why did you indicate a release level of 1? Is the release level different than the hyphen would indicate? It would indicate to me that it uses the same compliled source-code, but the package scripting (for .lrp) has been revised/patched. This will likely happen on occasion since the package maintainer does add scripting for use with LEAF. Ok, I'm confused. What is the difference between a patch level and a revision? Aren't they different names for the same thing? David's example (developer.rtf) had a revision of 1, so I included the -1. If there was no revision, shouldn't his example have used 0? This would have resulted in a version of 1.20-0 (aka 1.20). -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: New LRP site?
Reply cc'd to the leaf-devel list I am building a open-source website for LRP. I am interested in featuring LEAF on my site. I am not sure if I need to ask permission to do so. Do I? Do you have any good suggestions for the site? Your help would be much appreciated. Thanks for your time. I'm not a lawyer, but the short answer is AFAIK, you don't need permission from me or other members of the LEAF project to mention LEAF on your website, link to the LEAF project from your website, etc, although we always like to hear about folks who are mentioning or linking to our project. As far as suggestions for your site, I'd say you should start by subscribing to the leaf-developer list, and asking questions there. The LEAF project's initial goal was to combine the many independent sites run by individuals interested in LRP, which we have mainly achieved. The work now is primarily focused on integrating the content from our many contributors into a more cohesive whole, as well as continued development of newer versions. So my question for you is: Exactly what sort of LRP based site are you planning, and is there a particular reason you want to mention LEAF, rather than add your content to the LEAF site? Charles Steinkuehler [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ldd libc minor version
On Tue, 2002-04-16 at 08:37, Charles Steinkuehler wrote: I'll place all of the packages that require libc.so.6 in the glibc2.0 directory. The few packages that don't depend on any libc will be placed in the bin/packages directory. How about using bin/packages/nolibc (or similar) instead? Charles, Would this be acceptable? bin/packages + /glibc-2.0 | + /glibc-2.1 | + /glibc-any -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ldd libc minor version
On 16 Apr 2002, Mike Noyes wrote: [...] Everyone, Apparently it's a non-trivial task to determine the minor version of libc used for package creation. Tomorrow I'm going to start committing our packages to cvs with the following tree structure: bin/packages + /glibc2.0 | + /glibc2.1 Should I use libc6 and libc6.1 instead of glibc? No. Both glibc2.0 and glibc2.1 get stored in libc.so.6... glibc ignores the shared library versioning conventions. [...] --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ldd libc minor version
Charles, Would this be acceptable? bin/packages + /glibc-2.0 | + /glibc-2.1 | + /glibc-any I guess so, but I sort of got the idea (perhaps incorrect) that there were packages that *did not* require a C library. If that's the case, the above is misleading (to me it implies the package requires a c library, but doesn't care which one). Something like + /glibc-none or maybe + /static would indicate packages with no libc requirements. My list of a few of the proposed CVS directory names, and what I would *assume* was contained within, based on the directory name: + /glibc-any would indicate packages work with any libc version...there's probably nothing that could correctly go into this directory (especially when you consider things like uC-libc, diet-libc, and the like)...if a package is dynamically linked against a c library, it probably needs to be catagorized by the library flavor. + /glibc-none -or- + /nolibc dynamic executables that are not linked to libc, or are linked to libc statically (but still dynamically linked to other packages) + /glibc-static -or- + /static packages that are statically linked, requiring no other libraries to function The entire point of my first post was to encourage using other subdirectorys for packages that do not fit into the glibc-2.0 or glibc-2.1 catagories rather than cluttering up the root packages directory...remember, it's hard to move files once they're in CVS, so starting with a good directory structure is a good thing... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Has anybody got a bzfrelay .lrp for bzflag forwarding?
Hi folks I destroyed my LRP compilation platform some time ago. Now I would like to forward bzflag packets, which almost certainly means running the relay: http://www.bzflag.org/man-bzfrelay.html Has anybody compiled this for Dachstein (or a compatible)? - Brian ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] ldd libc minor version
Charles, Would this be acceptable? bin/packages + /glibc-2.0 | + /glibc-2.1 | + /glibc-any I guess so, but I sort of got the idea (perhaps incorrect) that there were packages that *did not* require a C library. If that's the case, the above is misleading (to me it implies the package requires a c library, but doesn't care which one). Something like + /glibc-none or maybe + /static would indicate packages with no libc requirements. My list of a few of the proposed CVS directory names, and what I would *assume* was contained within, based on the directory name: + /glibc-any would indicate packages work with any libc version...there's probably nothing that could correctly go into this directory (especially when you consider things like uC-libc, diet-libc, and the like)...if a package is dynamically linked against a c library, it probably needs to be catagorized by the library flavor. Any interest in a uClibc branch (or uClibc content in a non-glibc branch)? + /glibc-none -or- + /nolibc dynamic executables that are not linked to libc, or are linked to libc statically (but still dynamically linked to other packages) + /glibc-static -or- + /static packages that are statically linked, requiring no other libraries to function A primary classification based on dynamic linkage to a particular C-library is clean and useful, but I'm not sure what would be gained by bringing in dependence on other libraries or packages (at least at this level) For example, I can imagine a package consisting of shell scripts that extend weblet.lrp (hence in + /nolibc). Why should this package be in a separate branch from seawall.lrp, which requires no other packages or libraries to function (hence in + /static). The entire point of my first post was to encourage using other subdirectorys for packages that do not fit into the glibc-2.0 or glibc-2.1 catagories rather than cluttering up the root packages directory...remember, it's hard to move files once they're in CVS, so starting with a good directory structure is a good thing... Charles Steinkuehler -Richard ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ldd libc minor version
On 4/16/02 at 3:46 PM, Charles Steinkuehler [EMAIL PROTECTED] wrote: I guess so, but I sort of got the idea (perhaps incorrect) that there were packages that *did not* require a C library. I'm sure there are... If that's the case, the above is misleading (to me it implies the package requires a c library, but doesn't care which one). Something like + /glibc-none or maybe + /static would indicate packages with no libc requirements. However, some programs have OTHER library requirements. So I think I'd be tempted just to have noglibc and a lib directory for the libraries: --+--- glibc2.0 | +--- glibc2.1 | +--- glibc2.2 | +--- noglibc | +--- libs Thus, elvis.lrp would be in glibc2.0 - even though it requires libm.lrp (in libs) and ncurses5.lrp (in libs). e3.lrp would be in noglibc, however. I would suggest that these directories be used for archives, and for source code. My personal Oxygen tree is shaping up like the FreeBSD /usr/ports directories - and I would suggest this. It has the benefits of: 1. No binary code to watch over... 2. Smaller repository: just makefiles and patches. 3. Much more automated, and can generate packages on the fly - so a glibc 2.0 program could be compiled for glibc 2.2 if one wanted. Now that I think of it, the above graphic tree would be bad for development CVS archives: 1. A program that used to compile under glibc 2.0 but didn't any longer would have to have its entire CVS tree moved. 2. One could never be sure where a package was. A perfect (recent) example: a program called remark (or regex-markup): the first version compiled under Red Hat 6.2; the latest version has gcc requirements that mean it won't compile on less than Red Hat 7 something (7.2 in my case). I think ntop had some requirements that way too - the networking code was nasty that way; a lot of networking details seem to change between glibc 2.0 systems and glibc 2.1 systems. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Package description file proposal
On 4/16/02 at 7:26 AM, Mike Noyes [EMAIL PROTECTED]
wrote:
On Tue, 2002-04-16 at 03:46, David Douthitt wrote:
David,
I think we should use the program's name, or place it in what RedHat
calls Summary. Personally I prefer the deb format, but it doesn't
include summary/program name information. :-(
Personally, I like the RPM (Red Hat) format :P
Program: Ultimate Packer for eXecutables = RPM Summary = DEB N/A
Executable: upx = RPM Name = DEB Package
Package: upx.lrp = RPM N/A = DEB Filename
Debian packages provide the following information (apt-cache show):
Package, Version, Priority, Section, Maintainer, Depends, Suggests,
Conflicts, Provides, Replaces, Architecture, Filename, Size, MD5sum,
Description, installed-size.
RedHat rpms have this summary information (rpm -q -i):
Name, Version, Release, Install date, Group, Size, URL,
Summary, Description, Relocations, Vendor, Build Date,
Build Host, Source RPM, License
There's a LOT more than that - rpm -qi rpm only lists those things
that are used by the current package.
Who determines what keywords and categories apply to each package?
The creator of the package.
I believe these tags will cause confusion
if there is no set categorization template.
I agree. Personally, I believe that:
1. A consistent standard is a good idea, and should be done.
2. A consistent standard will not be followed by all, and there will
be some confusion.
Go to http://www.rpmfind.org and do a look up by Group and you'll see
what I mean. Look up by Distribution and it's similar.
One thing I was thinking of - these *.desc files could (should?) be
treated the way HTML is: an unknown keyword (matches the pattern
/^[^:]*:/ ) causes a line to be ignored. So if someone suddenly
started using a new tag (Architecture: PPC for example) then these
lines would be ignored by current code.
Also, to be able to ignore multiline tags, one should ignore all lines
that start with a whitespace character after an unknown tag.
Name: Ultimate Packer for eXecutables
Ouch! That's neither a program name nor a package name.
The program is upx
In my opinion that is the program name, while upx is the
executable name (see example above).
Program: upx
Summary: Ultimate Packer for eXecutables (UPX)
...and package name is: ${program}.lrp
...and pkg.version is: ${version}-${release}
...and so forth...
Version: 1.20-1
upx is not version 1.20-1 but version 1.20 (at least in
this example).
In your example, why did you indicate a release level of 1? Is the
release level different than the hyphen would indicate?
A release level indicates the release of the package, and the version
is the version level of the software.
It could have just as easily been:
Version: 2.54BETA20
Release: 2
...like nmap - which leads to nmap.version being 2.54BETA20-2
--
David Douthitt
UNIX Systems Administrator
HP-UX, Unixware, Linux
[EMAIL PROTECTED]
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
