Re: packages.debian.org qmail (was Re: Using CVS for package development)
On Fri, 30 May 1997, Philip Hands wrote: What were you trying to achieve ? --- it might be simpler than you think. I just discovered that most of my alias handling under qmail was drivel, and could be dome much more simply. If someone wants to spend some time on a simple mailer hack, you can make this work. If you want mail to, for instance: [EMAIL PROTECTED] IIRC you can also alias an entire domain (packages.debian.org) to one user (how lists.debian.org is currently done). So [EMAIL PROTECTED] gets translated to, say bruce-packages-rsync. Then, ~bruce/.qmail-packages will execute a script to process it, or you can have .qmail-packages files for each pkg if you are worried about speed. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: packages.debian.org qmail (was Re: Using CVS for package development)
On May 29, Bruce Perens wrote I must admit to not understanding what that qmail alias file is for. I do _all_ of my aliases with .qmail-* files . What I was trying to achieve was to have qmail forward a message without messing around with the headers any more than necessary. Thus, I wanted to have a .qmail-packages-default file to handle the packages.debian.org domain, and that would look up the package name and map it to the maintainer address, and remail messages to the maintainer. This is not a terribly complicated hack, but I got busy. I don't understand why you need to use RFC822 style addresses here? You've got a message in-transit, so RFC821 seems more appropriate. Furthermore, qmail parses the destination addresses and stuffs it into various environmental variables, so parsing the dest address shouldn't be an issue. And, of course, identifying the proper smtp destination address for the package maintainer is something that should be done at the time the database is populated, not every time a message hits the system. Given these conditions, I can think of at least three different ways of implementing the forwarding: (1) user-map [if all package maintainers are local] (2) db lookup from -default (and of course there's lots of ways to implement db) (3) ~aliase/.q* [There's more ways .. you could generate an account for each package, ferinstance.] -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: packages.debian.org qmail (was Re: Using CVS for package development)
(1) user-map [if all package maintainers are local] If you just want to be delivering mail to package_name@packages.debian.org (rather than package_name-extension@packages.debian.org), you can deliver to remote addresses with: In users/assign, create one line per package: =package_name:alias:70:65534:/var/qmail/alias:+:fwd-maintainer_address: so in the case of my rsync package, that would be: =rsync:alias:70:65534:/var/qmail/alias:+:[EMAIL PROTECTED]: and in ~alias/.qmail+fwd-default: |forward $EXT2 If you want to deal with mail to e.g. [EMAIL PROTECTED] then it is more complicated. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
E.g. boot-floppies. I regularly receive patches from the people doing the ports to other architectures. If they could merge them into the CVS repository, they needn't wait until I released a new version. What provision do you suggest for code-review? It's important for things like boot-floppies where a patch for one architecture, done carelessly, might break another. You can use branches to deal with this. Each feature is worked on in its own branch and then merged back to a testing branch for the code- review you speak of. When it passes that, you can merge that back to the main tree for use/release. At least, this is one way... Brian ( [EMAIL PROTECTED] ) --- He who laughs last usually make a backup. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Communication should be done via a package-specific mailing list. The maintainer of the package decides who has commit privileges for this package and who gets on this package's developers' mailing-list. This mailing list could be used as target for the bug reports against this package. Regarding stability: We will need at least two branches: for stable and for unstable. When some people cooperate on porting to a specific architecture and this port does not work yet, they could create an extra branch. (Usually this won't be necessary.) This discussion is making me feel guilty. I hinted a while back that I would Debianize aegis, and have not got round to it. To quote an earlier mail from me: There is a CASE tool called Aegis that would seem to fit into this scheme quite well. ftp://ftp.agso.gov.au/pub/Aegis/aegis.2.3.README As I understand it, this would sit happily on top of CVS (or perhaps do what CVS does), and also take care of asking for the test team(s) approval of each change, and automatically building the system and running automated regression tests against the built system. The aim of Aegis is to maintain a baseline source tree that always passes it's own tests, and so can be expected to work. It does this by seeking approval of each change from a tester, and attempting to satisfy itself of the validity of the change by building the system with the change applied and ensuring that it passes any tests that exist. If we could actually put up with the (not very large) overhead involved, I think it would end up giving us a massive improvement in reliability. If some of the CVS gurus could have a look at the Aegis docs and see how they think it measures up --- I'll debianize it if it looks worthwhile. -- One reason I didn't rush to do anything about this was that I couldn't see a worthwhile way of doing it without setting up a CVS server, and I don't have the bandwidth. Now that it looks like you are trying for at least a partial CVS and ``make world'' system, Aegis might be more viable. If we could implement an Aegis based system, even if only for the base packages, then a fair amount of automated testing would become a possibility. An alternative use might be to unpack _all_ the source for packages that go into a release, and put it into CVS or aegis, and allow bug fixes to stable only via that source. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
On May 29, Bruce Perens wrote There actually is a packages.debian.org domain aliased on master, I had problems making it work because darned qmail won't parse a full RFC822 address on the command line (it wants you to remove the comments). If someone wants to spend some time on a simple mailer hack, you can make this work. Sure. Just tell me what you want qmail to do for you and point me at the sh/whatever scripts you started working on. Christian pgpABQJv8JU5X.pgp Description: PGP signature
Re: Using CVS for package development
Hi, I have had a very quick look at the aegis README. It has a baseline (main trunk in CVS; no mention of multiple independent branches and back merging that I could see). It implements a per change test rquirement (thought: what tests? that the package build? could be done with a commitinfo script in CVS). For the most part it fits in the same niche as CVS. I just wonder how easy is it to come up with regression tests for changes that are made, and whether they will be valid at the next change. Seems more, umm, restrictive than CVS, but I should really download the source to see. I can see why management will prefer this system over CVS (any manager would love to put the accumulated regression tests on a report). I'm leaving for the weekend, but I'll take a closer look when I get back next week. manoj -- What do you call it when someone rubs a Volkswagen van on your head? A Fahrvergnoogie. Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: packages.debian.org qmail (was Re: Using CVS for package development)
I must admit to not understanding what that qmail alias file is for. I do _all_ of my aliases with .qmail-* files . What I was trying to achieve was to have qmail forward a message without messing around with the headers any more than necessary. Thus, I wanted to have a .qmail-packages-default file to handle the packages.debian.org domain, and that would look up the package name and map it to the maintainer address, and remail messages to the maintainer. This is not a terribly complicated hack, but I got busy. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
From: Christian Hudon [EMAIL PROTECTED] Just tell me what you want qmail to do for you and point me at the sh/whatever scripts you started working on. I think we already have Joey (Martin Schulze) working on this today. Please check with him. Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Aegis looks interesting. I'd like to see how it works on top of a physically-distributed development using CVS. Do please package it when you have time, Phil. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: packages.debian.org qmail (was Re: Using CVS for package development)
What I was trying to achieve was to have qmail forward a message without messing around with the headers any more than necessary. Thus, I wanted to have a .qmail-packages-default file to handle the packages.debian.org domain, and that would look up the package name and map it to the maintainer address, and remail messages to the maintainer. This is not a terribly complicated hack, but I got busy. That seems simple enough. I think your best bet is this: 1) make sure control/locals does not contain packages.debian.org add this line to control/virtualdomains: packages.debian.org:alias-packages create ~alias/.qmail-packages-default, containing: |forward `/usr/local/bin/pkg2maint $EXT2` write /usr/local/bin/pkg2maint, which is a program that takes a package name, and puts the maintainers e-mail address on its STDOUT. The only extra thing to have pkg2maint do is output an address that will cause the mail to bounce if the maintainer cannot be found ([EMAIL PROTECTED] might work) Anyone already have the pkg2maint code already written ? Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: packages.debian.org qmail (was Re: Using CVS for package development)
Philip Hands [EMAIL PROTECTED] writes: [snip] That seems simple enough. I think your best bet is this: 1) make sure control/locals does not contain packages.debian.org But make sure it's in control/rcpthosts, of course. add this line to control/virtualdomains: packages.debian.org:alias-packages create ~alias/.qmail-packages-default, containing: |forward `/usr/local/bin/pkg2maint $EXT2` I would prefer |forward `/usr/local/bin/pkg2maint $EXT2` for security. write /usr/local/bin/pkg2maint, which is a program that takes a package name, and puts the maintainers e-mail address on its STDOUT. The only extra thing to have pkg2maint do is output an address that will cause the mail to bounce if the maintainer cannot be found ([EMAIL PROTECTED] might work) A better way to bounce when a maintainer is not found would be to do something like |/usr/local/bin/pkgforward $EXT2 where pkgforward execs qmail's forward if a maintainer is found, or prints unknown package or maintainer not found as appropriate and returns 100. If you've got 1000 or so spare inodes, you could just make a ~alias/.qmail-package-packagename for each package, containing [EMAIL PROTECTED] or whatever. If packages.debian.org is really master.debian.org, you could use users/assign to map packages-packagename to maintername. If you don't want to worry about unescaping the various formats of email addresses, add the appropriate Resent-... and Delivered-To: (from DTLINE) headers, set some env. vars and pipe the resulting message into qmail-inject, telling it to get its recipients from the message headers. I could probably be persuaded to write this... :-) -- Carey Evans * [EMAIL PROTECTED] Lies, damn lies, and computer documentation. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
I have had a very quick look at the aegis README. It has a baseline (main trunk in CVS; no mention of multiple independent branches and back merging that I could see). It relies on RCS or CVS for its version control, so you get access to most if not all the features of those (or at least I think you do --- been a long time since I used it) It does allow multiple people to work on the same thing, but only one baseline exists. You can only get stuff into the baseline if it doesn't break anything, its like the unstable vs. stable split, but with automated checks. It implements a per change test rquirement (thought: what tests? that the package build? could be done with a commitinfo script in CVS). This can be waived, but many tests would be fairly simple to write, and should really be done. The basic idea is that you write a script that fails with the old version, and succeeds with the new, so that the script tests for the bug-fix or feature that has just been introduced. Since the tests get run for every change, it should elliminate repeat occurences of the same bug. The other thing that it does, that people were talking about is administer the peer review thing, by mailing a tester, and requiring an approval before letting the change into the baseline. I can't see it working for ongoing unstable development because it would be too severe a bottleneck, but it might be useful for keeping stable stable, and the accumulated tests should be useful when we next do a freeze. For the most part it fits in the same niche as CVS. I just wonder how easy is it to come up with regression tests for changes that are made, and whether they will be valid at the next change. Seems more, umm, restrictive than CVS, but I should really download the source to see. I think so --- even if you don't use it, the ideas should be applicable. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
On Thu, 29 May 1997, Paul Bame wrote: = Should this CVS repository be mandatory, i.e. does every Debian = package have to be there? A brief word of warning... (I tried CVS on dpkg a while back) The natural CVS model is to name the directory for the package, for example .../dpkg/ and relegate the version numbers to tags. At least one package (dpkg) uses its directory name in such a way that when the directory is .../dpkg/ the build fails, while it works when the directory is a versioned one, .../dpkg-1.2.3/. This has been fixed now, since 1.4.0.9 (it was in my original automakizing patch, it now using the debian changelog to determine version). -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cvs.debian.org [Was: Using CVS for package development]
Brian White [EMAIL PROTECTED] writes: We are running cvs.debian.org over an ISDN line. Currently the only code under it is the Deity project. I can make other source trees and set up other users if others want to do distributed development this way. I need a shared CVS repository for boot-floppies. Especially people who do the porting to other architectures should be able to merge their changes wtihout needing to disturb the primary maintainer. Is there a way to restrict the people who can write to the repositroy part of one package? Unfortunately, I haven't been able to set up world read access yet because CVS always wants write access to the directory (for lock files) so currently it is either group read/write or world read/write. OpenBSD offers anonymous CVS ; you could try to ask them. I think that Debian's CVS repository should be located on a well-connected site; ISDN isn't enough. Sven -- Sven Rudolph [EMAIL PROTECTED] ; WWW : http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cvs.debian.org [Was: Using CVS for package development]
We are running cvs.debian.org over an ISDN line. Currently the only code under it is the Deity project. I can make other source trees and set up other users if others want to do distributed development this way. I need a shared CVS repository for boot-floppies. Especially people who do the porting to other architectures should be able to merge their changes wtihout needing to disturb the primary maintainer. No problem. Just mail me a list of the developers and the name of the project and I'll set it up for you. Things are pretty hectic right now and I haven't automated this process, so it may take a couple days for me to get it done. Is there a way to restrict the people who can write to the repositroy part of one package? For now, I'll set it up so only people in the group you mail me can write to it. Unfortunately, I haven't been able to set up world read access yet because CVS always wants write access to the directory (for lock files) so currently it is either group read/write or world read/write. OpenBSD offers anonymous CVS ; you could try to ask them. I've passed this on to the CVS maintainer and asked him if he could include those patches in the Debian package. I think that Debian's CVS repository should be located on a well-connected site; ISDN isn't enough. Somebody is free to take it if they want. I think you overestimate the amount of bandwith used, though. Unless we're archiving the entire source tree with all developers using it, I sincerely doubt there will be any problems. Brian ( [EMAIL PROTECTED] ) --- Generated by Signify v1.02. For this and more, visit http://www.verisim.com/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Andreas Jellinghaus [EMAIL PROTECTED] writes: great. since i meet other debian developers at the linux congress, i my a big friend of a cvs server with all debian packages. does anyone have a server with enough hard disks and a good conection to run it ? Some problems arise: Should this CVS repository be mandatory, i.e. does every Debian package have to be there? How much disk space will this take ? this could make some things much easier (i don't want to download the whole source and diffs, to look at two or three files). also it would help to coordinate updates (think of the menu package - this way we could have send diffs direct to the maintainer). My favourite example ;-) So I'll repeat this: IMHO Currently the overhead of fixing a bug and publishing the fixed version is too high. For unstable it would be enough to check-in the fix (e.g. an added menu file, a spelling-fix). Please note that the procedure for stable might be different. there are also situations where several developers have to work together. E.g. boot-floppies. I regularly receive patches from the people doing the ports to other architectures. If they could merge them into the CVS repository, they needn't wait until I released a new version. (Another example: We already used a CVS repository on master for the FAQ.) Sven -- Sven Rudolph [EMAIL PROTECTED] ; WWW : http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Sven Rudolph writes: Andreas Jellinghaus [EMAIL PROTECTED] writes: great. since i meet other debian developers at the linux congress, i my a big friend of a cvs server with all debian packages. does anyone have a server with enough hard disks and a good conection to run it ? Some problems arise: Should this CVS repository be mandatory, i.e. does every Debian package have to be there? How much disk space will this take ? Don't seriously bother about disk space. Debian has a fond of money from which additional disks could be paid. But a problem that I see is that it would be good if we could have _some_ mirrored cvs archives, i.e. there are a lot of european maintainer and it does make sense if we have a master cvs server cvs.debian.org and a europe/ german secondary. I don't know if and how we could arrange that uploads reach the master, too. also it would help to coordinate updates (think of the menu package - this way we could have send diffs direct to the maintainer). My favourite example ;-) And everyone would be able to get an older version than the actual, too. My favourite example: just after setting up an exchange system for my server a friend of mine encountered that the new uucp package was unusable, if I had installed it, the result would be horrorous (sp?). So I'll repeat this: IMHO Currently the overhead of fixing a bug and publishing the fixed version is too high. For unstable it would be enough to check-in the fix (e.g. an added menu file, a spelling-fix). Please note that the procedure for stable might be different. Hmm, where is the change? You still have to publish the fixed version, haven't you? Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / This copy of Netscape has expired. -- Netscape / /Ein weiterer Grund Mosaic zu benutzen. :-( / -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Andreas Jellinghaus [EMAIL PROTECTED] writes: great. since i meet other debian developers at the linux congress, i my a big friend of a cvs server with all debian packages. does anyone have a server with enough hard disks and a good conection to run it ? Some problems arise: Should this CVS repository be mandatory, i.e. does every Debian package have to be there? Definitely not - that would be a waste. Most packages are pretty simple, so having a shared CVS isn't all that useful for those packages. But it might be nice to be able to add an arbitrary package to the repository via a CGI script or something like that. Cheers, - Jim pgp2C2rx4h4bm.pgp Description: PGP signature
Re: Using CVS for package development
E.g. boot-floppies. I regularly receive patches from the people doing the ports to other architectures. If they could merge them into the CVS repository, they needn't wait until I released a new version. What provision do you suggest for code-review? It's important for things like boot-floppies where a patch for one architecture, done carelessly, might break another. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
= Should this CVS repository be mandatory, i.e. does every Debian = package have to be there? A brief word of warning... (I tried CVS on dpkg a while back) The natural CVS model is to name the directory for the package, for example .../dpkg/ and relegate the version numbers to tags. At least one package (dpkg) uses its directory name in such a way that when the directory is .../dpkg/ the build fails, while it works when the directory is a versioned one, .../dpkg-1.2.3/. -Paul Bame -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
[EMAIL PROTECTED] (Bruce Perens) writes: E.g. boot-floppies. I regularly receive patches from the people doing the ports to other architectures. If they could merge them into the CVS repository, they needn't wait until I released a new version. What provision do you suggest for code-review? It's important for things like boot-floppies where a patch for one architecture, done carelessly, might break another. Communication should be done via a package-specific mailing list. The maintainer of the package decides who has commit privileges for this package and who gets on this package's developers' mailing-list. This mailing list could be used as target for the bug reports against this package. Regarding stability: We will need at least two branches: for stable and for unstable. When some people cooperate on porting to a specific architecture and this port does not work yet, they could create an extra branch. (Usually this won't be necessary.) Sven -- Sven Rudolph [EMAIL PROTECTED] ; WWW : http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Communication should be done via a package-specific mailing list. The maintainer of the package decides who has commit privileges for this package and who gets on this package's developers' mailing-list. The way we are currently doing it here (at Pixar) is that nobody checks in an un-reviewed patch, even if they do have commit privilege. Anyone with commit privilege can review it for you and give you an OK to check it in, but it takes two people. It tends to make us think a bit harder about what we are doing. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
[EMAIL PROTECTED] (Bruce Perens) writes: Communication should be done via a package-specific mailing list. The maintainer of the package decides who has commit privileges for this package and who gets on this package's developers' mailing-list. (And the CVS commit messages are sent to this list.) The way we are currently doing it here (at Pixar) is that nobody checks in an un-reviewed patch, even if they do have commit privilege. Anyone with commit privilege can review it for you and give you an OK to check it in, but it takes two people. It tends to make us think a bit harder about what we are doing. We could implement this policy for the stable branch, but for the development branch it means much work due the more frequent changes; and the latency for getting a change distributed is high again. (Please note that even my first proposal doesn't make anything worse than it it is done currently. Current procedure is that one person makes a change, releases it (including the binary package). And then other people can review the change; I believe this almost never happens.) Sven -- Sven Rudolph [EMAIL PROTECTED] ; WWW : http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Sven Rudolph writes: Communication should be done via a package-specific mailing list. The maintainer of the package decides who has commit privileges for this package and who gets on this package's developers' mailing-list. This mailing list could be used as target for the bug reports against this package. Which brings me back to the point of [EMAIL PROTECTED] or [EMAIL PROTECTED] where the actual maintainer can modify the content of that alias by using his account on master and a feature of qmail. $package will point to [EMAIL PROTECTED] for instance. The aliasfile could be generated by a cronjob via examining the most recent Packages file. Comments? Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / This copy of Netscape has expired. -- Netscape / /Ein weiterer Grund Mosaic zu benutzen. :-( / -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
There actually is a packages.debian.org domain aliased on master, I had problems making it work because darned qmail won't parse a full RFC822 address on the command line (it wants you to remove the comments). If someone wants to spend some time on a simple mailer hack, you can make this work. Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
= Communication should be done via a package-specific mailing list. The = maintainer of the package decides who has commit privileges for this = package and who gets on this package's developers' mailing-list. = = The way we are currently doing it here (at Pixar) is that nobody checks = in an un-reviewed patch, even if they do have commit privilege. Anyone = with commit privilege can review it for you and give you an OK to check = it in, but it takes two people. It tends to make us think a bit harder = about what we are doing. There are advantages to commiting intermediate versions and un-reviewed patches. The redundancy is a good idea - you won't lose all your work if the disk crashes or somebody does 'rm -r /'. But perhaps a bigger advantage is anyone anywhere with CVS access can use 'cvs diff -rSTABLE' to review the changes -- they don't have to depend on you preparing a 'diff' e-mail or something. They can even check out the trial version to build or test or even compare your changes to their changes. The final commit is done by moving a tag or potentially moving something to a stable branch. This can be on the honor system since CVS doesn't have per-tag access control (that I know of) with audit possible (I think) through the CVS log files. Obviously all official/stable release/builds occur from the STABLE tag. -P -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Hi. Jason == Jason Gunthorpe [EMAIL PROTECTED] writes: Jason On 26 May 1997, Rob Browning wrote: Rob What do you do about packages whose upstream source is already Rob being managed by CVS and already has $Id$ markers, etc in it? Jason Nothing. When you check it into CVS it will rewrite all of the Jason $Id: $ markers and friends to reflect your CVS tree. It Jason shouldn't have any problems. You might not want that so you can Jason turn off substitution with -ko I think. Unfortunately, I think this just tend to bloat the diffs file with meaningless changes, hence I use -ko for the upstream sources. manoj -- Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
cvs.debian.org [Was: Using CVS for package development]
great. since i meet other debian developers at the linux congress, i my a big friend of a cvs server with all debian packages. does anyone have a server with enough hard disks and a good conection to run it ? We are running cvs.debian.org over an ISDN line. Currently the only code under it is the Deity project. I can make other source trees and set up other users if others want to do distributed development this way. Unfortunately, I haven't been able to set up world read access yet because CVS always wants write access to the directory (for lock files) so currently it is either group read/write or world read/write. If somebody knows CVS well enough to tell me how to overcome this, I'd appreciate some advice. Brian ( [EMAIL PROTECTED] ) --- Debian GNU/Linux! Search it at http://insite.verisim.com/search/debian/simple -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cvs.debian.org [Was: Using CVS for package development]
We are running cvs.debian.org over an ISDN line. Currently the only code under it is the Deity project. I can make other source trees and set up other users if others want to do distributed development this way. Unfortunately, I haven't been able to set up world read access yet because CVS always wants write access to the directory (for lock files) so currently it is either group read/write or world read/write. What about cvsup? All I know about it is that the FreeBSD use it to distribute their sources... It would be nice to be able to have an automated procedure to make any package in the Debian source tree available via CVS so that a group of people could work on it simultaneously. (no hurry though, just an idea) Another idea... is coda (an afs/nfs replacement from Carnegie-Mellon) a possibility for building a really large filesystem spread across multiple machines on the internet? Cheers, - Jim pgpMQEQVTH2mA.pgp Description: PGP signature
Re: cvs.debian.org [Was: Using CVS for package development]
because CVS always wants write access to the directory (for lock files) Yep. I've seen patches for this at MIT, but I don't think they're in the mainline... You've also got some potentially major access control problems; look at what freebsd does, and consider that you *don't* want general access -- you want a special case of people being able to read and diff and submit the diffs *through* some auditors... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cvs.debian.org [Was: Using CVS for package development]
because CVS always wants write access to the directory (for lock files) Yep. I've seen patches for this at MIT, but I don't think they're in the mainline... You've also got some potentially major access control problems; look at what freebsd does, and consider that you *don't* want general access -- you want a special case of people being able to read and diff and submit the diffs *through* some auditors... I'd like to specify a group that has full read/write access but still allow world read. Anybody in the world could also submit code via one of the people in the group. Brian ( [EMAIL PROTECTED] ) --- It's not the days in your life, but the life in your days that counts. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cvs.debian.org [Was: Using CVS for package development]
On Wed, 28 May 1997, Jim Pick wrote: We are running cvs.debian.org over an ISDN line. Currently the only code under it is the Deity project. I can make other source trees and set up other users if others want to do distributed development this way. Unfortunately, I haven't been able to set up world read access yet because CVS always wants write access to the directory (for lock files) so currently it is either group read/write or world read/write. What about cvsup? All I know about it is that the FreeBSD use it to distribute their sources... You will have to port SRC-Modula-3 first. It currently does not work with glibc 2.x. CVSup is the tool of choice for FreeLinux. It would be nice to be able to have an automated procedure to make any package in the Debian source tree available via CVS so that a group of people could work on it simultaneously. (no hurry though, just an idea) Another idea... is coda (an afs/nfs replacement from Carnegie-Mellon) a possibility for building a really large filesystem spread across multiple machines on the internet? We plan to support coda, however we are currently using AFS for the development machines of FreeLinux. Mike -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Rob Browning writes: I guess I was looking for -ko, since you wouldn't want to be rewriting the $Id$ values for the upstream source unless you actually changed things, and even then it's kind of iffy since your tree has nothing to do with theirs. In addition, without -ko, you'd get a bunch of spurious diffs against the upstream source. I don't how how to do that, but some people use their own keyword instead of $Id$. You'll find $XConsortium$ all around X11 code, I think; I already saw another such keyword, but can't remember where. I found nothing in the doc when I looked for it last year. On last resort, a specially-compiled CVS could be used ? Maybe we could use a $DebianId$ ? -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
On May 26, Manoj Srivastava wrote Hi, I would really like to get into using CVS for my package development tree, but I have been held back by the hassle of releasing packages. I have no problems testing packages with ./debian/rules binary and I always used dpkg-buildpackage for the last step, so I have written a script (cvs-buildpackage?) which exports things from CVS to a directory where I keep the upstream version files, and runs dpkg-buildpackage. great. since i meet other debian developers at the linux congress, i my a big friend of a cvs server with all debian packages. does anyone have a server with enough hard disks and a good conection to run it ? this could make some things much easier (i don't want to download the whole source and diffs, to look at two or three files). also it would help to coordinate updates (think of the menu package - this way we could have send diffs direct to the maintainer). there are also situations where several developers have to work together. a cvs tree is a big help in such cases. and if more than one people wants to work on a package, then you cannot work without an cvs server. regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Manoj Srivastava [EMAIL PROTECTED] writes: I would really like to get into using CVS for my package development tree, but I have been held back by the hassle of releasing packages. I wondered about this, and I had a question. I looked around in the CVS manual a little and didn't find anything, but feel free to tell me to RTFM if the answer's in the M. What do you do about packages whose upstream source is already being managed by CVS and already has $Id$ markers, etc in it? Thanks -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
On 26 May 1997, Rob Browning wrote: Manoj Srivastava [EMAIL PROTECTED] writes: I would really like to get into using CVS for my package development tree, but I have been held back by the hassle of releasing packages. I wondered about this, and I had a question. I looked around in the CVS manual a little and didn't find anything, but feel free to tell me to RTFM if the answer's in the M. What do you do about packages whose upstream source is already being managed by CVS and already has $Id$ markers, etc in it? Nothing. When you check it into CVS it will rewrite all of the $Id: $ markers and friends to reflect your CVS tree. It shouldn't have any problems. You might not want that so you can turn off substitution with -ko I think. Jason -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Hi, I just import the upstream version with ``cvs import -ko'', and ``cvs add'' my changes without any k options. This way the upstream sources do not get mangled, but the debian only files come with full RCS keywords. manoj From the info pages: File: cvs.info, Node: Substitution modes, Next: Log keyword, Prev: Avoiding \ substitution, Up: Keyword substitution Substitution modes == Each file has a stored default substitution mode, and each working directory copy of a file also has a substitution mode. The former is set by the `-k' option to `cvs add' and `cvs admin'; the latter is set by the -k or -A options to `cvs checkout' or `cvs update'. `cvs diff' also has a `-k' option. For some examples, *Note Binary files::. The modes available are: [...] `-ko' Generate the old keyword string, present in the working file just before it was checked in. For example, for the `Revision' keyword, generate the string `$Revision: 1.1 $' instead of `$Revision: 5.7 $' if that is how the string appeared when the file was checked in. `-kb' Like `-ko', but also inhibit conversion of line endings between the canonical form in which they are stored in the repository (linefeed only), and the form appropriate to the operating system in use on the client. For systems, like unix, which use linefeed only to terminate lines, this is the same as `-ko'. For more information on binary files, see *Note Binary files::. `-kv' Generate only keyword values for keyword strings. For example, for the `Revision' keyword, generate the string `5.7' instead of `$Revision: 5.7 $'. This can help generate files in programming languages where it is hard to strip keyword delimiters like `$Revision: $' from a string. However, further keyword substitution cannot be performed once the keyword names are removed, so this option should be used with care. One often would like to use `-kv' with `cvs export'--*note export::.. But be aware that doesn't handle an export containing binary files correctly. -- We have luck only with women -- not spacecraft! Kremnev, builder of failed Soviet FOBOS probes Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Jason Gunthorpe [EMAIL PROTECTED] writes: Nothing. When you check it into CVS it will rewrite all of the $Id: $ markers and friends to reflect your CVS tree. It shouldn't have any problems. You might not want that so you can turn off substitution with -ko I think. I guess I was looking for -ko, since you wouldn't want to be rewriting the $Id$ values for the upstream source unless you actually changed things, and even then it's kind of iffy since your tree has nothing to do with theirs. In addition, without -ko, you'd get a bunch of spurious diffs against the upstream source. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Using CVS for package development
Hi, I would really like to get into using CVS for my package development tree, but I have been held back by the hassle of releasing packages. I have no problems testing packages with ./debian/rules binary and I always used dpkg-buildpackage for the last step, so I have written a script (cvs-buildpackage?) which exports things from CVS to a directory where I keep the upstream version files, and runs dpkg-buildpackage. This was inspired by a script Lars Wirzenius wrote, I have just made it: a) require less input (it can parse the changelog file now), I just run it from my working directory. b) more robust, by using dpkg-parselog just like dpkg-buildpackage c) a complete wrapper around dpkg-buildpackage, by passing on *all* options of dpkg-buildpackage. The credit should really go to Lars Wirzenius and Ian Jackson, since this borrows from their work. If there is enough interest, I could package this up. (Oh, this is a sh script, and only needs dpkg-dev, no perl ;-) manoj __ cvs-buildpackage -h Debian GNU/Linux cvs-buildpackage 1.01. Copyright (C) 1997 Manoj Srivastava. This is free software; see the GNU General Public Licence version 2 or later for copying conditions. There is NO warranty. Usage: cvs-buildpackage [options] Options: -MCVS module The name of the CVS module, if different from the package name. -Wsrc dirRoot of the source dir. We expect to find the orig.tar.gz file under src dir/package name/ -n No action taken -d Turn on Debugging output The rest are passed to dpkg-buildpackage. -rgain-root-command -ppgp-command -us unsigned source -uc unsigned changes -aarch architecture field of the changes _file_name_ -bbinary-only, do not build source } also passed to -Bbinary-only, no arch-indep files } dpkg-genchanges -vversion changes since version version } -mmaint maintainer for release is maint} only passed -Cdescfile changes are described in descfile } to dpkg- -si (default) src includes orig for rev. 0 or 1} genchanges -sa uploaded src always includes orig} -sd uploaded src is diff and .dsc only } -tc clean source tree when finished -hprint this message This is a wrapper for dpkg-buildpackage, and derives the option parsing from it. __ cvs-buildpackage -n -rsudo -d sversion=3.31 uversion=3.31 tversion= workdir=/usr/local/src/Package/kernel-package pkgdir=/usr/local/src/Package/kernel-package/kernel-package-3.31 oversion=/usr/local/src/Package/kernel-package/kernel-package-3.31.orig.tar.gz cvstag=debian_version_3.31 sudo rm -rf .orig cvs export -d /usr/local/src/Package/kernel-package/kernel-package-3.31 -r debian_version_3.31 kernel-package cd /usr/local/src/Package/kernel-package/kernel-package-3.31 dpkg-buildpackage -rsudo __ cvs-buildpackage -n -rsudo sudo rm -rf .orig cvs export -d /usr/local/src/Package/kernel-package/kernel-package-3.31 -r debian_version_3.31 kernel-package cd /usr/local/src/Package/kernel-package/kernel-package-3.31 dpkg-buildpackage -rsudo -- Draft politicians, not human beings. antidraft slogan coined by Jeff Daiell, 1979 Manoj Srivastava url:mailto:[EMAIL PROTECTED] Mobile, Alabama USAurl:http://www.datasync.com/%7Esrivasta/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Manoj Srivastava [EMAIL PROTECTED] wrote: The credit should really go to Lars Wirzenius and Ian Jackson, since this borrows from their work. If there is enough interest, I could package this up. (Oh, this is a sh script, and only needs dpkg-dev, no perl ;-) Please do so. CVS is a really good thing, and I'd really apreciate to be able to use it for developing my packages (as soon as I can get a new hard drive :-(). Thanks, M. S. Martin A. Soto J. Profesor Departamento de Ingenieria de Sistemas y Computacion Universidad de los Andes [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
