- crux-devel - lists.crux.nu

[clc-devel] [CLC Ticket Notification] Updated version for centericq
by crux＠morpheus.net 22 Feb '05

22 Feb '05

Assigned to [clc-devel(a)lists.berlios.de] The following CLC ticket (64) has been created or modified: Description: I have a new port for centericq. A u to date version can be found at http://www.strcat.de/crux/ports/ Remarks: Contact: strcat at gmx dot net CLC User: anonymous Status: new URL: http://clc.morpheus.net:6999/clc/tktview?tn=64

1 0

[clc-devel] [CLC Ticket Notification] Updated version for slrn
by crux＠morpheus.net 22 Feb '05

22 Feb '05

Assigned to [clc-devel(a)lists.berlios.de] The following CLC ticket (63) has been created or modified: Description: Remarks: Contact: strcat at gmx dot net CLC User: anonymous Status: new URL: http://clc.morpheus.net:6999/clc/tktview?tn=63

1 0

[clc-devel] [CLC Ticket Notification] gstreamer update
by crux＠morpheus.net 19 Feb '05

19 Feb '05

Assigned to [clc-devel(a)lists.berlios.de] The following CLC ticket (59) has been created or modified: Description: Remarks: Contact: codah_pazo at shiba dk CLC User: sten Status: review URL: http://clc.morpheus.net:6999/clc/tktview?tn=59

1 0

[clc-devel] suggestion for a 'proposal submission' procedure
by Johannes Winkelmann 18 Feb '05

18 Feb '05

Hey, I've talked to Jukka regarding proposals sent to clc which are forgotten after some time, and was wondering whether there are opinions regarding a policy to submit proposals which are automatically accepted after a while, if there's a certain amount of acceptance. The procedure I imagine would look like the following: 1. Submit a proposal, e.g. to cvstrac 2a discussion takes place 2b silent agreement (;-)) 4. Adjust proposal, call for vote 5a Interested maintainers vote (-1, 0, +1) there 6. After a certain time (for example 2 weeks), the proposal is either accepted or rejected I know this sounds very bureaucratic, but IMHO it's worse to make good proposals and be commited to solve existing problems and just being ignored. Please note that this is not at all meant as a criticism, just attempt to cope with reality :-) Ideas for such proposals are: - define a naming scheme for perl related ports (p5- vs- perl-); from Jukka - The guidelines about changing other maintainer's Job from Sten - "port of the week"; put up a webpage where extraordinary nice ports are published (no lengthy desciption). I e.g. discovered dnsmasq which I find _very_ handy, easy to use and working fine. Please comment :-) Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net

4 5

[clc-devel] ports in contrib depending on ports in unmaintained
by Jukka Heino 16 Feb '05

16 Feb '05

Hi, When building every single port in contrib I noticed that some of them depend on packages that either don't exist or are unmaintained. In my opinion contrib shouldn't depend on having unmaintained available. I usually even disable unmaintained completely on my systems so some ports in contrib fail because of this. - bmp depends on libglade (unmaintained) - electricsheep depends on xscreensaver (unmaintained) - gal depends on libgnomeprintui and libgnomeui (unmaintained) - madwifi depends on linux (doesn't exist) - nicotine depends on pygtk (unmaintained) - obconf depends on libglade and startup-notification (unmaintained) - ogle depends on libglade (unmaintained) - rox-clib depends on libgtop (unmaintained) - rox-lib depends on pygtk (unmaintained) - rss-glx depends on xscreensaver (unmaintained) - spamassassin depends on p5-html-parser (doesn't exist) - xautolock depends on xfree86 (should be x11) - xblast depends on xfree86 (should be x11) - xsoldier depends on xfree86 (should be x11) So in my opinion maintained ports shouldn't depend on unmaintained or non-existant ports. The current situation is of course understandable, since most of the GNOME stuff isn't maintained anymore. But in general I propose we move towards a uniformly maintained contrib with no dependencies on other collections than base, opt and contrib itself. Regards, // Jukka

4 4

[clc-devel] [CLC Ticket Notification] gstreamer update
by crux＠morpheus.net 08 Feb '05

08 Feb '05

Assigned to [clc-devel(a)lists.berlios.de] The following CLC ticket (59) has been created or modified: Description: Remarks: Please submit an httpup url to an updated port rather than unformatted wiki text, please. Contact: codah_pazo at shiba dk CLC User: jaeger Status: defer URL: http://clc.morpheus.net:6999/clc/tktview?tn=59

1 0

[clc-devel] [CLC Ticket Notification] gstreamer update
by crux＠morpheus.net 08 Feb '05

08 Feb '05

Assigned to [clc-devel(a)lists.berlios.de] The following CLC ticket (59) has been created or modified: Description: Remarks: Contact: codah_pazo at shiba dk CLC User: anonymous Status: new URL: http://clc.morpheus.net:6999/clc/tktview?tn=59

1 0

[clc-devel] 2.1 approaching
by Johannes Winkelmann 07 Feb '05

07 Feb '05

Hi there,

4 13

[clc-devel] CLC CVS Guidelines
by Simone Rota 06 Feb '05

06 Feb '05

Hi, since I'm committed to annoy all the people on this list, I remind there's a useful CLC Wiki page proposal by sten here: http://clc.morpheus.net:6999/clc/tktview?tn=38 In which a internal policy for clc ports is proposed (in particular to rule out what one should do if there are problems / updates to a port he does not maintain). Extract: ### - If any download is broken; feel free to fix it. One should then courteously notify the maintainer of the port. - For all other fixes, email a patch to the maintainer. - If the fix is security-related, and the maintainer does not respond after 48 hours, commit and tag. ### Just my 2c: - If there's a security update _AND_ a maintainer know what he's doing, I'd prefer an immediate update when available instead of waiting 2 days with an unpatched system. That could go just for remote vulns or in general. - I feel very small changes could be handled by a clc member that is not the maintainer, ie when the minor version for a port changes and there are no consequences on related ports (or no related port at all). See my today sox commit[1] as an example of what I'm blabbering of. So, If anybody would like to share his point of view, feel free to reply to this thread and / or add stuff to the ticket. Regards, Simone [1] http://clc.morpheus.net:6999/clc/chngview?cn=1289 -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip(a)varlock.com

6 7

[clc-devel] installing into /home (or not)
by Johannes Winkelmann 04 Feb '05

04 Feb '05

Hi, On my CRUX box at work, I'm mounting /home via NFS (and automount), which leads to conflicts with certain ports which try to install to /home. I've compiled a list of those ports, and they're mainly http or ftp servers: apache and apache-suexec cvstrac phpmyadmin thttpd-php vsftpd webfs apache-doc boa gopher While I don't mind changing the ports I want to install manually, I was wondering whether moving that to someplace else (e.g. /var) might be a good idea. Comments, opinions? Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net

6 8