August 2004 - crux-devel

[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

[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

Re: [clc-devel] httpup repositories and unmaintained (next try) [long]
by Jukka Heino 24 Aug '04

24 Aug '04

Hi, Since discussion seems to be dying out and the solution Johannes suggested could apparently only improve the current situation of rotting unmaintained ports and decentralized repositories, I propose we start implementing the 'people' collection if no one has anything major against it. My Perl and PHP skills are at your disposal if I can be of any help. Regards, // Jukka Heino

3 2

Re: [clc-devel] httpup repositories and unmaintained (next try) [long]
by Jukka Heino 22 Aug '04

22 Aug '04

Hi, On Fri, 20 Aug 2004 19:59:44 +0200, Johannes Winkelmann <jw(a)tks6.net> wrote: > What I'd like to suggest differs a bit from my httpup mirror service > proposal I wrote to crux@ a while ago and is rather what Jay Dolan > suggested: Create a new httpup collection, called 'people' (for example; > I have no strong opinion about the name of this thing); packager can > apply to have their repository included in this collection. There are a > few basic rules to follow: > - No dups over base, opt or contrib; use a separate repository for this > - Rather have few but well maintained ports, than many outdated ones > - React on conflicts > - subscribe to and read the clc-people-admin (naming comment from above > applies again) mailing list > > If a conflict (duplicate) is detected, a notification is sent to a > clc-people-admin; the packagers are required to resolve it. > -> there must be an instance to decide if the packagers can't agree on a > compromise I agree that this could be a working solution to the problem of distributed repositories. What I'm not really sure about is whether there should be a strict set of rules on this new 'people' collection. Having to subscribe to and read a whole new mailing list etc. might scare off some of the potential repository maintainers. Maybe we should more actively recruit new CLC members instead of creating a sort of pseudo-CLC? I'm not bashing the idea, I'm just wondering how much duplication of tasks this would cause. The way I see it is that the 'people' collection could be just a central mirror with a subdirectory for each repository. That way people could immediately see who is maintaining what and over time trust some maintainer enough to e.g. add their repository directory to /etc/prt-get.conf. Regards, // Jukka

4 4

[clc-devel] httpup repositories and unmaintained (next try) [long]
by Johannes Winkelmann 21 Aug '04

21 Aug '04

Hi there, I have yet another proposal about a change I'd like to make, addressing the problems I see with the current httpup repositories and unmaintained. I think this one is good; at least better than the situation as it is now. First of all, the following are the problems I'd like to address: - distributed port repositories suffer from the following flaws: 1. it's confusing at least to subscribe to ports; especially for new users 2. People put just everything into they're repositories, e.g. duplicates over contrib ports, but also duplicates when using multiple private collections. This has two bad consequences: there is no improved version by merging the ports, and it is important to choose the right order in prt-get.conf - ports in unmaintained are outdated; often, there are newer variant in private httpup repositories When looking closely at unmaintained, there are two kinds of ports there: first those of us CLC maintainers which we don't think are quite ready yet; second such from external guys, often submitted with the submission service we had a long time ago, and maybe updated by an update report. What I'd like to suggest differs a bit from my httpup mirror service proposal I wrote to crux@ a while ago and is rather what Jay Dolan suggested: Create a new httpup collection, called 'people' (for example; I have no strong opinion about the name of this thing); packager can apply to have their repository included in this collection. There are a few basic rules to follow: - No dups over base, opt or contrib; use a separate repository for this - Rather have few but well maintained ports, than many outdated ones - React on conflicts - subscribe to and read the clc-people-admin (naming comment from above applies again) mailing list If a conflict (duplicate) is detected, a notification is sent to a clc-people-admin; the packagers are required to resolve it. -> there must be an instance to decide if the packagers can't agree on a compromise If a repository goes offline, the port remains in the collection, but is marked as unmaintained. This way, a new packager can pick it up by simply adding the port to his/her collection. This is exactly the same sitation we have now, except for the fact that once a new package appears, the new version will be used. We can still use an external tool to check which ports have been unmaintained for a long time and remove them. The other purpose of the current 'unmaintained' collection, the ports from CLC maintainers which are not ready for contrib, should be moved into private port repositories. Many of us have them anyway. This solution has the following properties (with respect to the current sitution): - people can easily pick up ports from unmaintained and provide new versions through the 'people' collection - httpup repositories are available at a central location - all ports are in the ports tree -> use find/grep/prt-get to search them; disadvantage: large number of ports (probably) - httpup repo maintainer have a meeting point with others in the same position, which might help to improve ports Most important, this would change the meaning of unmaintained: 'unmaintained' would mean that there's no CLC maintainer and no httpup maintainer looking after the port. I have a script ready to do most of the required work to collect the repositories, find dups, merge the ports, mark them 'unmaintained' if a repository fades away etc. It can definitely be optimized, but it is ready for a test run. For those still reading, what do you think? is this a viable solution? I'll happy write a more detailed description and drafts of requirements, but I'd like to avoid it if there are objections. Feedback is (guess what ;-)) highly appreciated. Thanks for bearing with me && kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net

2 1

Re: [clc-devel] httpup repositories and unmaintained (next try) [long]
by Jukka Heino 21 Aug '04

21 Aug '04

> Well, I think it should. If this is potentionally too much for a > maintainer, he/she shouldn't take part. But it might very well be > possible that I'm way off and that little to none httpup repo > maintainers would want to take part if there are regulations like this. It all depends on what we're aiming for. If it's only important to have a central access point for the repositories, we're better off with no rules. But if we're trying provide the highest quality ports while bridging the gap between CLC and external repositories, there's an apparent need for regulation. > To me, there's a major difference between the CLC and the people > project: all it takes to be part of the later is the will to be active > (read the mailing list, react on problems); no matter how you behave > etc. This doesn't apply to CLC, where it is more important (at least to > me) to have a working team than the largest collection of ports ever. > > It is true that we are still looking for maintainers, as the website > says... but I think this is a different story, IMHO, and the 'people' > collection could even be a good place to recruit them. Now I see what you mean. Come to think of it, this reminds me a bit of Arch Linux's Trusted User Repositories (http://tur.archlinux.org/) An intermediate stage like this _could_ prove to be useful. > > The way I see it is that the 'people' collection could be just a central > > mirror with a subdirectory for each repository. That way people could > > immediately see who is maintaining what and over time trust some > > maintainer enough to e.g. add their repository directory to > > /etc/prt-get.conf. > This sounds very much like the latest suggestion we discussed: > http://marc.theaimsgroup.com/?l=crux&m=109108750918706&w=2 > > The disadvantage is that you either introduce a new tool, or that people > still have to go the a webpage to search a port, find its repository, > download the *.httpup file, execute ports -u and add the new directory > to prt-get.conf. Works fine, it's just not obvious, especially to new > users. What I meant was that all the ports would be downloaded by default, e.g. my repository would go into /usr/ports/people/jheino. No need to go to a webpage for anything, since everything is already downloaded on the user's computer. If he needs a port, he can search in the 'people' collection. But I guess this comes down to what level of trust we're trying to achieve. I trust some external repository maintainers more than others, so I'd like to be able to say "I trust xyz, let prt-get use his ports automatically." I can install the ports in contrib with no worries, but when dealing with unknown external repositories I usually at least take a look at the Pkgfile. Regards, // Jukka

1 0

[clc-devel] CLC ports available again...
by Matt Housh 17 Aug '04

17 Aug '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With a lot of help and patience from Daniel (danm) and Johannes (cptn), I've gotten the ports up again and available for use. If you're a maintainer, you'll need to send me an email requesting your access be reinstated. I've still got all your keys but I'd like to know who's active and who's not. In order get the ports using cvsup and ports -u, simply edit /etc/ports/clc.cvsup and change the host line from: *default host=crux.fh-regensburg.de to *default host=clc.morpheus.net If you're lazy, grab it here: http://jaeger.morpheus.net/linux/crux/files/clc.cvsup Go forth and port! Matt (jaeger@freenode/#crux) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBIoVUGFVQ7mavvGgRAqkcAJ9ShpRHNhf4roAH8IxXirtS2IuQogCeLdVL W9VtWWRCQLGGDoyjeE2oTP0= =wAxH -----END PGP SIGNATURE-----

1 0

[clc-devel] [port update] opt/xfsprogs Ports version update from 2.6.10 to 2.6.13
by clc-devel＠berlios.de 14 Aug '04

14 Aug '04

Description: 2.6.13 is the xfsprogs current version. 2.6.10 is the xfsprogs Ports current version. Could you please update it? Thanks in advance. Best regards. Contact: ncrfgs at tin dot it User: anonymous http://crux.fh-regensburg.de/cgi-bin/cvstrac/tktview?tn=163

1 0

[clc-devel] Re: Amaya new version...
by Rune Stokka 12 Aug '04

12 Aug '04

On Thursday 12 August 2004 15:41, you wrote: > Hi, > > The new version of Amaya is out, can you update the Pkgfile to use 8.6 > instead of 8.0? > > ~Mayuresh Hi, last time I updated Amaya was version 8.5, the updated port is however not reflected in the unmaintained ports collection even though I submitted it (I'll think the maintainers is busy men). The 8.6 release is just a snapshot (like a showcase), version 8.5 is still the most recent. The version 8.5 posted in april: https://lists.berlios.de/pipermail/clc-devel/2004-April/000429.html Cheers, Rune Stokka

2 1

[clc-devel] [port update] mplayerplug-in
by clc-devel＠berlios.de 12 Aug '04

12 Aug '04

Your port submission has been marked 'defer' General advise: Please don't answer to this message unless you are subscribed to the clc-devel mailinglist; reopen your original submission (set state to 'new') and add a remark instead Description: update from .80 to 2.66 User: winkj http://crux.fh-regensburg.de/cgi-bin/cvstrac/tktview?tn=159 Remark: Please read the port submission guidelines and submit an httpup repo url as requested

1 0