September 2004 - crux-devel

[clc-devel] unmaintained; next try
by Johannes Winkelmann 13 Sep '04

13 Sep '04

Hi there, As you might know many packages in unmaintained are outdated or even non-functional. Some of them have never versions in httpup repositories. We keep getting bug reports against those unmaintained ports, which means that some of us have to look after those ports (or defer the bug reports). I've been discussing with Juergen what the goal of CLC is; the choices were: 1. Have ports which we actively maintain 2. Have ports which seem important for a linux distribution The initial goal of CLC was to do the first of the two; as a consequence of this, we should not serve ports we don't maintain actively. Some time ago, having a collection like clc/unstable or unmaintained made sense since there was no alternative way to share ports. This is not the case anymore, and we could go back to follow goal #1 again. There is a certain need for ports which are "not quite ready" for contrib but are maintained by us. I'd therefore propose to drop unmaintained and start a new collection called 'testing'; ports which require further testing (both when the port or the ported software isn't stable) go there, but it should be our goal to move it to contrib or remove it altogether. 'testing' shouldn't be consider a permanent place for ports. Either they're fine for CLC, or they're not. Note that this would mean that we wouldn't have GNOME in our tree anymore, since rrm3 isn't around. IMO this would be the right consequence when a maintainer leaves, and we shouldn't try to keep the ports around but to find a new maintainer for them. Riders of Rohan, eerm, maintainers from CLC, Please discuss, comment or at least state whether you are in favor or against this step. Best regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net

7 9

[clc-devel] Gmail
by Logan Ingalls 07 Sep '04

07 Sep '04

(This is off-topic, but since this list includes all of the people I wanted to be sure to include, I'm sending it anyhow. Feel free to chew me out if this is inappropriate abuse of clc-devel.) I have six gmail invitations. All of the maintainers put forth such a huge amount of effort that I appreciate (literally) on a daily basis, so I'm offering them to you guys. First come, first served. Logan

1 0

[clc-devel] Ports to pick up...
by Johannes Winkelmann 07 Sep '04

07 Sep '04

Hi, I'm planning to get rid of subversion-perl and subversion-python and swig (which I only maintained since the other two depend on it). I anyone's interested, feel free to pick them up. I'll tag them unmaintained for now... Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net

1 1

[clc-devel] unmaintained/fbset: Cosmetic changes
by ncrfgs 03 Sep '04

03 Sep '04

One of the I like about Crux packages management system is that allows build script to be clean and simple. If they are not it's a pity. =) A possible patch is attached to this message. 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

[clc-devel] unmaintained/lm_sensors: Port update
by ncrfgs 02 Sep '04

02 Sep '04

With the Linux 2.6.x series, lm_sensor' kernel space code was include into the kernel and after CRUX switched to Linux kernel 2.6.x series, lm_sensors port' "README" and "post-install" files became useless and the the following line can be safely deleted from the "Pkgfile" script. rm -f $PKG/lib/modules/`uname -r`/modules* A possible patch is attached to this message. http://clc.morpheus.net:6999/clc/tktview?tn=11 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

2 1

[clc-devel] clcbuild results
by Simone Rota 02 Sep '04

02 Sep '04

Hi all, I had a couple of uber-outdated machines, so I re-run the infamous clcbuild script to get some binary package. Results at the same old place[1], as usual some failed port are my fault, known issues, etc. Regards, Simone [1] http://www.varlock.com/clcbuild -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip(a)varlock.com

2 2

[clc-devel] Rsync for Maintainers
by Victor 01 Sep '04

01 Sep '04

I am just curious, what was the reason again for not using rsync for port distribution? Just an idea, why can't we make people who submit ports have an rsync account: ---------------- rsyncd.cruxusers.conf ----------------- victord:pass1 cptn:pass2 ---------------- rsyncd.cruxusers.conf ----------------- ---------------- rsyncd.conf ----------------- # # /etc/rsyncd.conf # uid = nobody gid = nobody # use chroot = no max connections = 4 pid file = /var/run/rsyncd.pid log file = /var/log/rsyncd.log [victord] path = /data/PORTS/victord use chroot = true secrets file = /etc/rsyncd.cruxusers.secrets auth users = victord read only = false [cptn] path = /data/PORTS/cptn use chroot = true secrets file = /etc/rsyncd.cruxusers.secrets auth users = cptn read only = false # End of file ---------------- rsyncd.conf ----------------- (I checked, they don't seem to support %u to replace username) Then people who want their repos to be public, can ask for the account, and a simple script where user:pass is specified can generate these config files. Then it's up to them to update their trees. A gui (I have a php one that can handle this) can then list/search/etc the ports. Wouldn't this be an easy solutoion? It centralizes all the HTTPUP repos with minimal work. Am I missing something? We can even make httpup take -user -pass -rsync server, args so they can distribute them without learning rsync commands. And httpup can just sync their repo to central location with some default settings set for calling rsync. Victor

2 3

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

01 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 I might be wrong, but wouldn't changing $* to "$@" (notice the quotes) fix the problem? I had a similar problem with soapbox before. // Jukka

2 1

[clc-devel] Applying to be a package maintainer
by Anthony de Almeida Lopes 01 Sep '04

01 Sep '04

I'd like to know how to apply to be a package maintainer. The MaintainerGuidlines document on the wiki is pretty vague on that. I'd also like to know how I register an account for the bug reporting system, or whether all bugs are supposed to be anonymous. Thanks, * Anthony

2 4