get-cygwin-package - for anyone with upload privileges
As I mentioned in another post, I've hacked at the get-cygwin-package script so that it should properly handle -debuginfo packages. I also added a --release option which moves the packages into the release directory after downloading them. Without this option the script will only download to a staging area and stop. If the email contains a string like: Please remove 5.42-1 then that package will be removed and temporarily archived to a tar file in /tmp. So, for any existing packages, this should be as simple as just piping email via: |ssh sourceware.org get-cygwin-package If there are any problems please report them here. cgf
Re: get-cygwin-package - for anyone with upload privileges
On Wed, Oct 17, 2012 at 06:46:00PM -0400, Christopher Faylor wrote: As I mentioned in another post, I've hacked at the get-cygwin-package script so that it should properly handle -debuginfo packages. I also added a --release option which moves the packages into the release directory after downloading them. Without this option the script will only download to a staging area and stop. If the email contains a string like: Please remove 5.42-1 then that package will be removed and temporarily archived to a tar file in /tmp. So, for any existing packages, this should be as simple as just piping email via: |ssh sourceware.org get-cygwin-package If there are any problems please report them here. Sorry, that should be: |ssh sourceware.org --release get-cygwin-package cgf
Re: get-cygwin-package - for anyone with upload privileges
On 10/17/2012 4:46 PM, Christopher Faylor wrote: I've hacked at the get-cygwin-package script I take it this script is run by hand when a human has decided to do something about an RFU message? If so, is there a plan or even a wish for getting to a point where a script can run on sourceware.org (?) and just monitor the list for RFU messages and handle them all automatically? If the email contains a string like: Please remove 5.42-1 then that package will be removed and temporarily archived to a tar file in /tmp. Every natural language processor I've used -- including very well funded ones like Siri -- require that the human conform to the limitations of the computer's natural language parser. They give the illusion of flexibility while they generate frustration by refusing to accept text that looks similar to forms it does support. I think it's great that you've gone and done this, Chris. You can expect people to keep posting RFUs by the copy-paste-edit-send method, and the current forms are well understood. My point is that if you ever find yourself wanting to extend the natural language parser to cover another new case, instead of spending that time writing more natural language parsing code or a nastygram to the person who wrote the RFU, stop and consider. It might be better to spend that time inventing a more robust RFU message format that a script can parse with 100% confidence: if it parses, it's legal. For example, you can repurpose your setup.ini parser: [cygrfu] root: http://etr-usa.com/cygwin/ packages: ctags version: 5.8-2 That, coupled with info parsed from the package's existing setup.hint files or the setup.ini file would tell the script everything it needs to know to do the right thing. This formal RFU is saying that the script should expect a sourceware.org like release tree at the root path given, and that the package names found there differ only in the version number. The packages: line allows for single logical packages that are actually composed of several separate packages: packages: sqlite3, libsqlite3_0, libsqlite3-devel This is where parsing setup.ini comes in: it looks for [libsqlite3_0] to learn that it should expect to find it in sqlite3/libsqlite3_0 under the given root, not in sqlite3. The formal RFU request doesn't mention -src and -debuginfo because the tool already has the information to handle them implicitly. Then you can add tags for exceptional conditions: [cygrfu] prev: 5.7-1 That would mean remove 5.8-1 and leave the earlier 5.7-1 as prev. That as opposed to its default action, which would be to remove 5.7-1 and leave 5.8-1 as prev. The point of all this would be to get to a point where the script can monitor the mailing list and be expected to DTRT 100% of the time. The incentive to you, Chris, is that it potentially gets the human out of the RFU loop entirely. This should defeat the SHTDI argument, too. The Someone is one of those with upload privileges who wants a computer to put them out of a job. :) The incentive to the package maintainers is that if they use this format, they know the script will pick up their packages in computer time, instead of waiting for a human to process an informal RFU. A package maintainer might therefore have some hope of getting a fix out to the mirrors within 24 hours of sending the RFU. You might consider whether to add an email whitelist to this, which controls whether the script will pay attention to formal RFUs. Newbie maintainers or those the uploaders don't entirely trust for whatever reason won't be on the list. I think that's probably a sign they shouldn't have maintainership at all, though. The more independence you give the package maintainers, the fewer synchronization points you have, which is good for speed, as any experienced computer programmer knows. That said, a whitelist containing all package maintainers' known emails is probably still a good thing. You wouldn't want the script accepting formal RFU requests from random people.
Re: get-cygwin-package - for anyone with upload privileges
On Wed, Oct 17, 2012 at 08:12:16PM -0600, Warren Young wrote: On 10/17/2012 4:46 PM, Christopher Faylor wrote: I've hacked at the get-cygwin-package script I take it this script is run by hand when a human has decided to do something about an RFU message? If so, is there a plan or even a wish for getting to a point where a script can run on sourceware.org (?) and just monitor the list for RFU messages and handle them all automatically? I've been thinking about this problem for many years. I have lots of ideas on how to make this automatic. I have even partially implemented a more robust version of this which relied on package maintainers logging in via ssh into a chroot jail where packages are uploaded to a staging area which ran upset on packages before copying them to the final release area. I wasn't really satisified with it though, partly because I thought it would be a maintenance headache and partly because I was paranoid about security. Someday, possibly, I'll complete something like that and make the whole RFU thing obsolete. In the meantime, this is only intended as a useful utility for people who handle RFUs. cgf
Re: get-cygwin-package - for anyone with upload privileges
On Wed, Oct 17, 2012 at 06:53:57PM -0400, Christopher Faylor wrote: On Wed, Oct 17, 2012 at 06:46:00PM -0400, Christopher Faylor wrote: As I mentioned in another post, I've hacked at the get-cygwin-package script so that it should properly handle -debuginfo packages. I also added a --release option which moves the packages into the release directory after downloading them. Without this option the script will only download to a staging area and stop. If the email contains a string like: Please remove 5.42-1 then that package will be removed and temporarily archived to a tar file in /tmp. So, for any existing packages, this should be as simple as just piping email via: |ssh sourceware.org get-cygwin-package If there are any problems please report them here. Sorry, that should be: |ssh sourceware.org --release get-cygwin-package One more correction. I thought everyone who had login privileges on sourceware.org had /sourceware/infra/bin in their path but that's apparently not the case. So amend that to: |ssh sourceware.org --release /sourceware/infra/bin/get-cygwin-package That's what I'll be doing from mutt. I'm sure that this isn't anywhere near that easy from most GUI clients so you might have to save the file first. Again, these messages are only for the handful of people who have login capabilities on sourceware.org. Everyone else can safely ignore them. cgf
