- crux-devel - lists.crux.nu

[clc-devel] Cvstrac customizations
by Simone Rota 28 Oct '04

28 Oct '04

Hi all, Inspired by sqlite.org cvstrac customizations, I started to tinker a little with cvstrac header/footer/css; here's a couple of static pages: http://www.varlock.com/tmp/clc/wiki.html http://www.varlock.com/tmp/clc/timeline.html (please forget about the temporary lame logo ripoff, and be glad I didn't chose this one: http://www.lexingtonma.org/clc/CLCLogo.gif :) ) Nothing really exciting, I know, just a reminder of a possible subproject we can discuss at CRUXCon 2004, so if anybody has some idea or proposal he can collect them now and put them on the table when needed. Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip(a)varlock.com

2 2

[clc-devel] Re: Your CLC maintainership
by Logan Ingalls 12 Oct '04

12 Oct '04

Hi all, I haven't really been keeping up with the ports that I'm maintaining. I've been extremely busy lately with work, and they cut off my access to the outside world (i.e. CVS). I only have a few ports in contrib, but I don't get the chance to update them that frequently. It would probably be best if I retired from official maintainership and someone else take electricsheep, graphviz, or snort (all of which are probably not up-to-date). I still use Crux and I still love it, but since I can't really contribute to ports very much with my work schedule and their draconian firewall rules, this would probably help CLC and contrib. I do have a couple of ports that I do keep up-to-date for work (vmware, for one). I'll probably make an httpup repo for those, since that's what httpup repos are for. (Thanks to Tilman for nudging me to make a decision on this.) -- Logan Ingalls http://plutor.org/

2 1

[clc-devel] Policy for closing tickets
by Simone Rota 09 Oct '04

09 Oct '04

Hi all, This could sound stupid, but are we using some implicit rule for marking closed cvstrac tickets? I've always used the "closed" tag, but I see a lot of "fixed" lately. I feel fixed is more appropriate, shall we use closed for tickets that did not require intervention? (ie: http://clc.morpheus.net:6999/clc/tktview?tn=28,4 ) Just a cosmetic issue, I know. Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip(a)varlock.com

2 2

[clc-devel] A few thoughts on Java and Games
by Jay Dolan 08 Oct '04

08 Oct '04

Hi guys, I was wondering if anyone is objected to removing the (outdated) quakeforge port from unmaintained. It's sortof an oddball, anyway. But the main reason I ask is because I maintain a full set of Quake related ports in my httpup repository. They're all current and adhere to a uniform structure. Quakers could get most of what they need from there, leaving clc's collections for more ..serious things ;) Regarding Java.. listing Java as a dependency is a pain in the butt, as I'm sure we can all agree. Currently two redundant ports, j2re and j2sdk, live in contrib. J2re is most often used as the core dependency for Java applications, and rightly so. But this solution nudges people who already have j2sdk installed towards downloading a big tarball to build an almost identical pacakge for j2re. Can the two be merged to create a "java" metaport that installs the j2sdk and some symlinks in /usr/bin? Off the top of my head, I don't see why this would fail - and it would clean things up a bit for Java developers. Thanks, ===== Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com

2 1

[clc-devel] Application for CLC Maintainer
by Jay Dolan 30 Sep '04

30 Sep '04

Hi guys :) Most of you know me from the general mailing list and from IRC. My name's Jay Dolan, and I'd like to become a maintainer. My ports have been online for several months, and are now located at http://jdolan.dyndns.org/jaydolan/ports. Of the ones found there, I think most of the non-gaming ports are decent candidates for contrib. The odd-balls and gaming ports should probably remain in my own repository. As far as a well-defined list of ports currently in unmaintained that I'd be willing to adopt - I'm not terribly sure. I'd like to take care of orphaned audio / multimedia apps as well as some Java-centric ones. But if there's a certain group that requires attention, I'll consider taking said ports on. GNOME does interest me, but Jaeger is already providing a nice collection in his repository. The other area I'd like to help in is with the web portal. I'm a decent technical writer, so populating / cleaning up the Wiki would be a lot of fun for me. In all, I'm pretty committed to CRUX, and I think my ideas generally coincide with the CLC. Thanks for your consideration, ===== Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com

5 6

[clc-devel] Re: important changes in contrib/ccache and contrib/distcc
by ncrfgs 21 Sep '04

21 Sep '04

On Wed, Sep 22, 2004 at 12:04:47AM +0200, Johannes Winkelmann wrote: > > > This means that you no longer have to export CC and CXX, but prepend the > > > respective path to your $PATH variable: for ccache, prepend > > > /usr/lib/ccache to your path; for distcc, /usr/lib/distcc. > > > > > > Please let me know if there are any problems. > > > > What if one uses both at the same time? > > There's a section on the in the man page of distcc; basically, what you > do is just prepending both paths to the PATH variable, like: > PATH=/usr/lib/ccache:/usr/lib/distcc:$PATH Yes sorry. I didn't explain myself well. I meant what if one uses both at the same time, how can you make it to work with the "export PATH" way? I didn't think PATH=/usr/lib/ccache:/usr/lib/distcc:$PATH would have worked, but then I read the distcc man page masquerade section and now I understand. It can work because distcc intercepts the calls to the compiler and then removes itself from the PATH to find the real compiler. I think ccache behaves the same. Thanks for the pointer. Best regards. -- Value your freedom, or you will lose it, teaches history. ``Don't bother us with politics,'' respond those who don't want to learn. -- Richard M. Stallman http://www.gnu.org/philosophy/linux-gnu-freedom.html

1 1

[clc-devel] RFC: Cross-compiling toolchain default location
by ncrfgs 19 Sep '04

19 Sep '04

Hi, After having successfully built a cross-compiling toolchain thanks to cross-lfs (http://www.linuxfromscratch.org/~ryan/scripts/cross-lfs/) I'm trying to adapt the wonderful scripts written by Ryan Oliver for the Linux From Scratch system, to the form of some Pkgbuild package building scripts. Unfortunately while trying to accomplish this task I'm facing some problems, first of all the choice of the cross-compiling toolchain default location. What do you think is the best location in the filesystem for the cross-compiling toolchain or, in other words, what do you think is the best configure time prefix to use? At the moment I put it into /opt/ppc/usr but I wonder whether is there a way to make it to coexist with the "regular" toolchain in /usr or whether is there a better location to put it into. Another problem I'm facing from the package management point of view are the files that gcc and glibc share among the different build steps. Maybe it's a bit Off Topic but I hope some of you have some experiences to share. Let's take for example the case of gcc. The gcc-static package shares all of its files with the gcc-shared package while the following files are included in the gcc-shared package only. $PREFIX/lib/gcc-lib/powerpc-unknown-linux-gnu/3.3.3-hammer/libgcc_eh.a $PREFIX/powerpc-unknown-linux-gnu/ $PREFIX/powerpc-unknown-linux-gnu/lib/ $PREFIX/powerpc-unknown-linux-gnu/lib/libgcc_s.so -> libgcc_s.so.1 $PREFIX/powerpc-unknown-linux-gnu/lib/libgcc_s.so.1 Should gcc-shared be seen as a gcc-static "upgrade"? Or may I safely delete from the gcc-shared package all the files already installed by gcc-static and leave only the new ones (namely libgcc_eh.a and libgcc_s.so*)? What when, just like in the case of the different glibc builds, the two packages shares only some files? Thanks in advance. Best regards. -- Value your freedom, or you will lose it, teaches history. ``Don't bother us with politics,'' respond those who don't want to learn. -- Richard M. Stallman http://www.gnu.org/philosophy/linux-gnu-freedom.html

1 0

Re: [clc-devel] RFC: wrapper for ccache and distcc
by Jukka Heino 19 Sep '04

19 Sep '04

> I'd like to ask for a few more comments on this question, since the > symlink variant has still a higher success rate compared to the wrapper > solution. > > /usr/share/gcc-wrappers/{distcc,ccache}/{gcc,g++} > /usr/lib/gcc-wrappers/{distcc,ccache} > ? I've been using a symlink in ~/bin, but I agree, a system-wide solution would be better. I propose /usr/lib/{distcc,ccache}/bin since this would have the same structure as already existing ports (j2re, ant, db3...) Additionally it seems a bit more FHS-like than gcc-wrappers. // Jukka

2 1

[clc-devel] Docs in Wiki
by Johannes Winkelmann 17 Sep '04

17 Sep '04

Hi, I was wondering whether we should call for contributors to write some documentation in our Wiki; howtos, configuration tips, screenshots etc. Anyone in favour of that? Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net

3 2

Re: [clc-devel] opera, anyone? (port to adopt)
by Jukka Heino 17 Sep '04

17 Sep '04

> Hey, > > I'm currently maintaining contrib/opera but stopped using it a good > while ago. I think it's a good browser and worth having in contrib, but > I think it would be better if we had a maintainer who is actually using > it, so if someone's interested in maintaining opera, please let me know. > Otherwise, I'll continue to maintain it, of course. I'm using Opera on some low-end computers, so if you don't want to maintain anymore, I could very well take care of it. // Jukka

2 1