September 2004 - crux-devel

[clc-devel] Software licenses
by Jukka Heino 22 Nov '04

22 Nov '04

Hi, Now that Simone Rota has committed his datastudio port into contrib, I began to wonder if CLC has some sort of policy on what software licenses should be allowed in contrib. At least one user was concerned that he might accidentally install software which would require a commercial license for the purpose he's using it for. I, for one, would find something like a "License" field in Pkgfiles useful so that with a quick glance one could see under which terms the software is released (GPL, BSD...). What do others think? Regards, // Jukka

6 5

[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] 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

[clc-devel] RFC: wrapper for ccache and distcc
by Johannes Winkelmann 16 Sep '04

16 Sep '04

Hi, A work collegue of mine brought to my attention that building tcl fails when using ccache, and I realized that the error is quite simple (not to say stupid ;-)); ccache comes with wrappers for gcc and g++ which just call 'ccache gcc $*' or 'ccache g++ $*'. Unfortunately this creates a problem when the Makefile calls the wrapper like this: ccache-gcc [...] -DTCL_WIDE_INT_TYPE=long\ long Since the wrapper is a shell script and will call ccache gcc $* This will break the last argument into two ("-DTCL_WIDE_INT_TYPE=long" and "long"). Maybe there's a way to work around that, but I wouldn't know about it. This e.g. breaks tcl, and I remember it also broke gimp < 2 (not sure about >= 2). Anyway, if ccache (the application) is called as gcc (by renaming it or creating a symlink called 'gcc'), it works fine. The additional advantage of this is that even if a Makefile doesn't use the CC and CXX variables, this will work. The problem (and reason why I didn't do it like this earlier) is that those symlinks must be put somewhere, and I'm not sure what the right place is; IMO it should be something which isn't in the path usually, which means that /bin shouldn't even be considered. gentoo uses /usr/lib/bin/{gcc,cc,g++,c++}, not sure what others use. Are there any suggestions what might be a good path for CRUX? Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net

1 1

[clc-devel] opera, anyone? (port to adopt)
by Johannes Winkelmann 15 Sep '04

15 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. Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net

1 0