April 2006 - crux-devel - lists.crux.nu

[clc-devel] httpup daily report
by crux＠crux.nu 30 Apr '06

30 Apr '06

*** junk repo/crux.spb.ru/e-apps-e/CVS repo/crux.spb.ru/e-apps-e_utils/CVS repo/crux.spb.ru/e-apps-elicit/CVS repo/crux.spb.ru/e-apps-entice/CVS repo/crux.spb.ru/e-apps-entrance/CVS repo/crux.spb.ru/e-apps-iconbar/CVS repo/crux.spb.ru/e-libs-ecore/CVS repo/crux.spb.ru/e-libs-edb/CVS repo/crux.spb.ru/e-libs-edje/CVS repo/crux.spb.ru/e-libs-eet/CVS repo/crux.spb.ru/e-libs-embryo/CVS repo/crux.spb.ru/e-libs-engrave/CVS repo/crux.spb.ru/e-libs-epsilon/CVS repo/crux.spb.ru/e-libs-esmart/CVS repo/crux.spb.ru/e-libs-etox/CVS repo/crux.spb.ru/e-libs-evas/CVS repo/crux.spb.ru/e-libs-ewl/CVS repo/crux.spb.ru/e-libs-imlib2/CVS repo/crux.spb.ru/e-libs-imlib2_loaders/CVS repo/han/p5-xml-parser/perl-xml-writer repo/yhafri/p5-unicode-string/p5-uri repo/dahl/index.html repo/vico/index.html *** large (>1MB) repo/opt/tetex/.footprint repo/morlenxus/openttd/ttdx-files.tar.gz repo/ukraine/arm-scratchbox/.footprint *** repos crux ! spb ! ru: tzong () crux ! spb ! ru dahl: dahl () c64 ! org han: han () mijncomputer ! nl morlenxus: morlenxus () gmx ! net opt: crux () crux ! nu ukraine: artur () idt ! org ! ua vico: vico () bicisport ! de yhafri: ycrux () club-internet ! fr

1 0

[clc-devel] Perl versions in footprints
by Mark Rosenstand 29 Apr '06

29 Apr '06

(This was filed in FS #37, but because of the comments, I'm lead to believe that it got rejected for the wrong reasons - so I'm opening it here for discussion, where we're not stuck in a stupid web interface.) Python is nice enough to keep its modules in a <major>.<minor> versioned directory, so footprint mismatches are rare, and when they do occur, it's a pretty good hint that the modules *needs* to be re-tested. However, because Perl puts its modules in a <major>.<minor>.<micro> directory, every upgrade triggers footprint mismatches for all Perl modules, most (all?) of which are bogus. Since we're a source distro, our general upgrade logic is that when a library (or "module") is upgraded, it's a good idea to rebuild dependent packages. Perl (and Python, which doesn't even promise bytecode compatability between micro version upgrades) modules is no exception to this. So, I suggest ignoring the perl version in the footprint like it already happens for kernel modules. Please note that it's the path in the footprint which is ignored, *not* the actual path in the file system. Also note that the purpose is to avoid bogus footprint mismatches in packages with Perl modules, not the perl package itself. This means that when Perl is upgraded, it won't find the modules compiled for the old version (just like it happens now, so our upgrade logic is kept intact.) And as can be witnessed by the attached suggested patch, implemention is trivial. With that said, nobody died from bogus footprint mismatches fo far, so if the proposal is rejected, that's fine - I just want to be sure it happens for the right reasons :)

5 12

[clc-devel] Future development of CRUX / pkgutils discussions
by Johannes Winkelmann 29 Apr '06

29 Apr '06

Hi there, The dust after the 2.2 release has settled a bit, and I'd say it worked out pretty well. Thanks for your efforts in making that a (relatively) painless update. I've started two wiki pages to discuss the future development of CRUX itself and pkgutils, meant to serve as a outline for IRC meetings. Those pages are: http://crux.nu/Main/DevVision http://crux.nu/Main/PkgutilsIdeas I'd appreciate if anyone with write access would add his notes to those pages. Regarding DevVision: This page should serve to define a common vision and future goals of CRUX. Obviously, this is subject to frequent change, but I'd like to nail down some basic tasks and goals to make sure we're on the same page, and we're not wasting time implementing things the majority of devs doesn't want. In addition, this should allow people interested in certain subtasks to start working on it early on, seeing that we i.e. want something for the 2.3 release. Regarding PkgutilsIdeas: It's a rather longish document; if you're not that much interested, please jump directly to the "Summary" section. There's a section for personal comments and goals, and I'd be happy if those of you who have expressed an interest in pkgutils hacking (that would be at least sip, jdolan, tilman and vektori) to add their ideas there as well. Also related to this, I wrote a prototype (read: code not meant to be used in a final product but to demonstrate a concept) for attribute based pkgutils, including meta data in binary packages. There's an extra page for this at http://crux.nu/Main/PkgutilsAttributes, including a section on how to get the code and play with it. I'd suggest to have two separate IRC meetings (pkgutils first, the "vision" second) before the end of May; dates are subject to discussion. Comments both on the wiki pages and the rest of this mail are highly welcome. Kind regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch

6 13

[clc-devel] httpup daily report
by crux＠crux.nu 29 Apr '06

29 Apr '06

*** junk repo/crux.spb.ru/e-apps-e/CVS repo/crux.spb.ru/e-apps-e_utils/CVS repo/crux.spb.ru/e-apps-elicit/CVS repo/crux.spb.ru/e-apps-entice/CVS repo/crux.spb.ru/e-apps-entrance/CVS repo/crux.spb.ru/e-apps-iconbar/CVS repo/crux.spb.ru/e-libs-ecore/CVS repo/crux.spb.ru/e-libs-edb/CVS repo/crux.spb.ru/e-libs-edje/CVS repo/crux.spb.ru/e-libs-eet/CVS repo/crux.spb.ru/e-libs-embryo/CVS repo/crux.spb.ru/e-libs-engrave/CVS repo/crux.spb.ru/e-libs-epsilon/CVS repo/crux.spb.ru/e-libs-esmart/CVS repo/crux.spb.ru/e-libs-etox/CVS repo/crux.spb.ru/e-libs-evas/CVS repo/crux.spb.ru/e-libs-ewl/CVS repo/crux.spb.ru/e-libs-imlib2/CVS repo/crux.spb.ru/e-libs-imlib2_loaders/CVS repo/han/p5-xml-parser/perl-xml-writer repo/yhafri/p5-unicode-string/p5-uri repo/dahl/index.html repo/vico/index.html *** large (>1MB) repo/opt/tetex/.footprint repo/morlenxus/openttd/ttdx-files.tar.gz repo/ukraine/arm-scratchbox/.footprint *** repos crux ! spb ! ru: tzong () crux ! spb ! ru dahl: dahl () c64 ! org han: han () mijncomputer ! nl morlenxus: morlenxus () gmx ! net opt: crux () crux ! nu ukraine: artur () idt ! org ! ua vico: vico () bicisport ! de yhafri: ycrux () club-internet ! fr

1 0

[clc-devel] [PROPOSAL] drop opt/pine
by Daniel Mueller 28 Apr '06

28 Apr '06

Hello, I don't know anyone who's using pine(1) these days. Why not just drop it and add opt/mutt + opt/nano(as replacement for pico(1))? CRUX's userbase seems to grow continuously - I think we should at least support UTF8/Unicode in all 'major' programs (the latest CRUX CD comes with pine). bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A ---------- Forwarded Message ---------- Subject: [Clc-crux64] replace pico on nano? Date: Tuesday 25 April 2006 18:32 From: Виталий Бердинских <***.vitaly(a)***.kh.***.gov.ua> To: ***(a)lists.***.de Hello cruxers, hello Daniel! Propose add in distro nano and remove pico (for best Unicode support). -- Best regards, Vitaly mailto:***@users.***.net _______________________________________________ Clc-crux64 mailing list ********(a)lists.******.de http://lists.berlios.de/mailman/listinfo/clc-crux64 -------------------------------------------------------

4 3

[clc-devel] CC: [suggestions for http://distrowatch.com/crux]
by Nick Steeves 28 Apr '06

28 Apr '06

Hi, Can we generate a listing of core and opt ports on crux.nu, so that DistroWatch can update our list of packages? Does everyone feel that such a thing is a good idea? Also, what would the most appropriate name for this column be? "Ports"? "Current Ports"? If we put this file in a branch-independent location, and changed that cat command to "cat crux-$version/{core/*/Pkgfile,opt/*/Pkgfile}", then it shouldn't be much of a maintenance hassle. If anyone knows of a better way to generate this package list file, please feel free to implement it. Cheers, Nick ----- Forwarded message from Ladislav Bodnar <distro(a)distrowatch.com> ----- Date: Wed, 12 Apr 2006 17:12:49 +0800 From: Ladislav Bodnar <distro(a)distrowatch.com> To: Nick Steeves <nick.steeves(a)shaw.ca> Subject: Re: suggestions for http://distrowatch.com/crux On Wednesday 12 April 2006 16:57, Nick Steeves wrote: > Attached is the requested file. It was created by "cat opt/*/Pkgfile > core/*/Pkgfile | grep -B2 version= > /tmp/CRUX-core_opt-ports-20060412". > How would you like to receive future updates? Is there a mechanism in Do you generate it directly on the crux.nu server? If so, just place it somewhere where I can retrieve it once a day to update the CRUX page. That's how I do it with all other distributions. Ladislav ----- End forwarded message -----

3 6

[clc-devel] dependencies listings for ports in core
by Johannes Winkelmann 28 Apr '06

28 Apr '06

Hi there, We just discussed the dependency listings of core ports again on IRC which showed that people have different opinions, so let's try to come to some definite guideline for this. I opened a bug report about a month ago regarding this: https://crux.nu/bugs/?do=details&id=17 Unfortunately, only Jürgen commented from the CRUX devs (privately), so here's a short summary of what I thought was the new definition: 1. We list all runtime dependencies except for gcc (libstdc++) and glibc. 2. 'core' contains essential packages for a CRUX system, and our scripts and ports expect them programs provided by 'core' to be installed; this means that build dependencies provided by core are _not_ listed in the dependency header The rationale behind this was that core contains libraries like openssl, or curl, which can cause major breakage when updated; therefore, the dependency information should be available to rebuild the dependency tree recursively. Now, several have raised concerns that every program calling less, grep, sed etc. will have to list those as a dependency, since it's not strictly a build dependency; this is of course perfectly valid. Extending the above would then lead to: 1. We list all runtime dependencies except for gcc (libstdc++) and glibc. 2. 'core' contains essential packages for a CRUX system, and our scripts and ports expect them programs provided by 'core' to be installed; this means that a) build dependencies provided by core are _not_ listed in the dependency header b) run-time dependencies from core which aren't dynamically linked in are not to be listed, either This would imply that: - we have proper dependency trees for all libraries, no matter where they are in the ports tree - no additional cruft by adding tools like grep etc. - many packages need to include zlib in their dependency list This would allow to rebuild all packages when there's another security hole in zlib (thanks to Tilman for this argument :-)) I think this would be a pretty good deal. The only alternative I can think of is to move more libraries to opt, like curl and openssl (which implies that we either move wget to opt too, or remove its ssl support again), which has more or less the same effect though. [your alternative here] Ideas and comments welcome. Best regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch

5 4

[clc-devel] httpup daily report
by crux＠crux.nu 28 Apr '06

28 Apr '06

*** junk repo/crux.spb.ru/e-apps-e/CVS repo/crux.spb.ru/e-apps-e_utils/CVS repo/crux.spb.ru/e-apps-elicit/CVS repo/crux.spb.ru/e-apps-entice/CVS repo/crux.spb.ru/e-apps-entrance/CVS repo/crux.spb.ru/e-apps-iconbar/CVS repo/crux.spb.ru/e-libs-ecore/CVS repo/crux.spb.ru/e-libs-edb/CVS repo/crux.spb.ru/e-libs-edje/CVS repo/crux.spb.ru/e-libs-eet/CVS repo/crux.spb.ru/e-libs-embryo/CVS repo/crux.spb.ru/e-libs-engrave/CVS repo/crux.spb.ru/e-libs-epsilon/CVS repo/crux.spb.ru/e-libs-esmart/CVS repo/crux.spb.ru/e-libs-etox/CVS repo/crux.spb.ru/e-libs-evas/CVS repo/crux.spb.ru/e-libs-ewl/CVS repo/crux.spb.ru/e-libs-imlib2/CVS repo/crux.spb.ru/e-libs-imlib2_loaders/CVS repo/han/p5-xml-parser/perl-xml-writer repo/yhafri/p5-unicode-string/p5-uri repo/dahl/index.html repo/vico/index.html *** large (>1MB) repo/opt/tetex/.footprint repo/morlenxus/openttd/ttdx-files.tar.gz repo/ukraine/arm-scratchbox/.footprint *** repos crux ! spb ! ru: tzong () crux ! spb ! ru dahl: dahl () c64 ! org han: han () mijncomputer ! nl morlenxus: morlenxus () gmx ! net opt: crux () crux ! nu ukraine: artur () idt ! org ! ua vico: vico () bicisport ! de yhafri: ycrux () club-internet ! fr

1 0

[clc-devel] httpup daily report
by crux＠crux.nu 27 Apr '06

27 Apr '06

*** junk repo/crux.spb.ru/e-apps-e/CVS repo/crux.spb.ru/e-apps-e_utils/CVS repo/crux.spb.ru/e-apps-elicit/CVS repo/crux.spb.ru/e-apps-entice/CVS repo/crux.spb.ru/e-apps-entrance/CVS repo/crux.spb.ru/e-apps-iconbar/CVS repo/crux.spb.ru/e-libs-ecore/CVS repo/crux.spb.ru/e-libs-edb/CVS repo/crux.spb.ru/e-libs-edje/CVS repo/crux.spb.ru/e-libs-eet/CVS repo/crux.spb.ru/e-libs-embryo/CVS repo/crux.spb.ru/e-libs-engrave/CVS repo/crux.spb.ru/e-libs-epsilon/CVS repo/crux.spb.ru/e-libs-esmart/CVS repo/crux.spb.ru/e-libs-etox/CVS repo/crux.spb.ru/e-libs-evas/CVS repo/crux.spb.ru/e-libs-ewl/CVS repo/crux.spb.ru/e-libs-imlib2/CVS repo/crux.spb.ru/e-libs-imlib2_loaders/CVS repo/han/p5-xml-parser/perl-xml-writer repo/yhafri/p5-unicode-string/p5-uri repo/dahl/index.html repo/vico/index.html *** large (>1MB) repo/opt/tetex/.footprint repo/morlenxus/openttd/ttdx-files.tar.gz repo/ukraine/arm-scratchbox/.footprint *** repos crux ! spb ! ru: tzong () crux ! spb ! ru dahl: dahl () c64 ! org han: han () mijncomputer ! nl morlenxus: morlenxus () gmx ! net opt: crux () crux ! nu ukraine: artur () idt ! org ! ua vico: vico () bicisport ! de yhafri: ycrux () club-internet ! fr

1 0

[clc-devel] Repository layout
by Mark Rosenstand 26 Apr '06

26 Apr '06

How do people feel about a more classic subversion layout in the form of a trunk, branches and tags, over the current crux-2.1 and crux-2.2? Perhaps move core and opt directly into the directories (skipping the 'ports' directory), i.e.: crux/ branches/ 2.1/ Makefile core/ opt/ ... 2.2/ core/ opt/ ... tags/ 2.1/ core/ ... 2.2/ core/ ... trunk/ Makefile core/ opt/ ... tools/ prt-get/ trunk/ ... ...

1 1