Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: Earnie <earnie@us...> - 2011-02-16 12:13:03
|
Chris Sutcliffe wrote: > Hi All, > > I guess it's to be expected after the SourceForge attack, but it looks > like the mail hook on commit is broken: > > Generating notification message... > Traceback (most recent call last): > File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 433, in ? > main() Did you raise a support ticket to find out what's up? Earnie |
|
From: Chris Sutcliffe <ir0nh34d@gm...> - 2011-02-16 03:58:57
|
Hi All,
I guess it's to be expected after the SourceForge attack, but it looks
like the mail hook on commit is broken:
Generating notification message...
Traceback (most recent call last):
File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 433, in ?
main()
File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 426, in main
contextlines, fromhost, replyto)
File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 223, in
blast_mail
conn.connect(MAILHOST, MAILPORT)
File "/usr/lib64/python2.4/smtplib.py", line 306, in connect
raise socket.error, msg
socket.error: (111, 'Connection refused')
Mailing mingw-cvs@...
Generating notification message...
Traceback (most recent call last):
File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 433, in ?
main()
File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 426, in main
contextlines, fromhost, replyto)
File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 223, in
blast_mail
conn.connect(MAILHOST, MAILPORT)
File "/usr/lib64/python2.4/smtplib.py", line 306, in connect
raise socket.error, msg
socket.error: (111, 'Connection refused')
Chris
|
|
From: Earnie <earnie@us...> - 2011-02-16 12:13:03
|
Chris Sutcliffe wrote: > Hi All, > > I guess it's to be expected after the SourceForge attack, but it looks > like the mail hook on commit is broken: > > Generating notification message... > Traceback (most recent call last): > File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 433, in ? > main() Did you raise a support ticket to find out what's up? Earnie |
|
From: Keith Marshall <keithmarshall@us...> - 2011-02-16 13:14:35
|
On 16 February 2011 12:12, Earnie wrote: > Chris Sutcliffe wrote: >> I guess it's to be expected after the SourceForge attack, but it looks >> like the mail hook on commit is broken: As they already told us, in their site status blog. > Did you raise a support ticket to find out what's up? Is there any point? They already told us they know about it; indeed, they even suggest that they broke it deliberately! What isn't clear is whether they intend to fix it, and if so, when. All they have said is that projects might like to consider using curl, or some other alternative, to redirect the mail hook through an off-site service. Frankly, I'm far from impressed by SF's handling of the events of the past few weeks, and I'd be much more inclined to just wave goodbye to them altogether... The only thing keeping us there is inertia, and the lack of manpower resources to overcome it. -- Regards, Keith. |
|
From: Charles Wilson <cwilso11@us...> - 2011-02-16 15:50:50
|
On 2/16/2011 8:14 AM, Keith Marshall wrote: > On 16 February 2011 12:12, Earnie wrote: >> Chris Sutcliffe wrote: >>> I guess it's to be expected after the SourceForge attack, but it looks >>> like the mail hook on commit is broken: > > As they already told us, in their site status blog. > >> Did you raise a support ticket to find out what's up? > > Is there any point? They already told us they know about it; indeed, > they even suggest that they broke it deliberately! Right. > What isn't clear is whether they intend to fix it, and if so, when. Also correct (that is, unclear). Somebody even asked about that in the comments to the blog entry, and got no response. > All > they have said is that projects might like to consider using curl, or > some other alternative, to redirect the mail hook through an off-site > service. Or "Project Web" http://sourceforge.net/apps/trac/sourceforge/wiki/Project%20Web%20Email%20Configuration I'm not really clear on how you use "curl" to redirect the mail, but whatever -- especially and keep it secure; they talk about how your "webscript" that contains the *plaintext password for the email* should not be world readable...but what if all that stuff is stored in a code repo? Am I missing something? It certainly wouldn't work well for commit hooks in cvs, because those ARE stored in the CVS repo, and anybody can look at them. If they have to have the ProjectWeb password in them... > Frankly, I'm far from impressed by SF's handling of the events > of the past few weeks, and I'd be much more inclined to just wave > goodbye to them altogether... Well, to be fair, it seems that everything EXCEPT cvs was validated and restored within a few days; and they had PETAbytes of data to validate. But I hear you. > The only thing keeping us there is inertia, and the lack of manpower > resources to overcome it. Ack. One "easy" migration would be simply to take cgf up on his offer (is it still open?) to host the mingw/msys code repository on sourceware (and leave everything else as-is, including the FRS). We'd just shut down/disable the code repo at sourceforge, and change the web pages to point "over there" for code access. (sourceWARE would probably create and host a new mingw-cvs mailing list for the commit hook, although we could continue to have a sourceWARE commit hook send the notices to the current sourceFORGE mingw-cvs list). We'd then stay CVS (until/unless sourceware switches to svn or something). Alternatively, cvs2git works pretty well, and we could then upload the new git repo back to sourceforge, or to [github|repo.or.cz|gitorious|googlecode] instead -- and again, leave everything else as-is. I tend to agree with Keith, that unless forced to, there doesn't seem to be much gain to switch from cvs to svn or to any other non-Distributed VCS (*). But a switch to a DVCS has advantages, IF we can get the manpower to execute it. (**) (*) although any new projects that don't want to use a DVCS like git or hg would be well advised to start off with svn and not cvs, IMO. Unless they can't because the client isn't supported on their platform (e.g. MinGW/MSYS). (**) I still haven't had the time to update perl, in prep for supporting a "mingw-get integrated" git package. Part of this is, sadly, it's becoming painful to manage ANY updates in my mingw-get-generated installations in a CLEAN manner: given that "mingw-get upgrade" does NOT uninstall the old version before overlaying the new one, I'm never sure what breadcrumbs are left on the system. I used to have manual tools that maintained a database of packages and files, and used them to explicitly remove old versions before installing the new ones. (VERY manual. I had to worry about dependencies, manually update the database, manually remove, AND use the tools themselves to manually install.) mingw-get makes most of that easier and automatic (except for actually removing foo-$OLD before installing foo-$NEW) -- but my scripts can't grok mingw-get's database, so they are basically broken. So I can't say that the build-requires of package foo-$update are gcc-N, but only gcc-(N-2) updated to gcc-(N-1) updated to gcc-N -- otherwise I'm not guaranteed that somebody else can rebuild foo having ONLY ever installed gcc-N (ditto for all other build-reqs). There are obviously three choices here: 1) forgetaboutit. Just go with it. Assume gcc-N (or whatever-$latest) is sufficient regardless of any possible previous breadcrumbs. 2) Fix "mingw-get upgrade" to remove before installing. I know this is on Keith's TODO list, but...it's going rather slowly. And frankly it's not worthwhile for ME to try to understand how the innards of mingw-get work in order to add the feature myself, because I don't have a roadmap of where/how future development is supposed to go. No documentation. (Obviously, it's a choice: should Keith work on documentation OR code? Which is more likely, in the end, to make code development progress faster? Given the size of our potential developer pool, I can't say that focusing on code over docu is wrong -- because docu will enable only a VERY small developer count multiplier). 3) Use something similar to Cesar's(?) build environment scripts that were posted to this list. IIRC, these scripts take a list of build-reqs for package FOO and create a CUSTOM mingw/msys installation specifically for the task of building FOO. Part of the advantage here is you're guaranteed not to miss any build-reqs! But geez, what a pain... I'm willing to take suggestions. What do you guys think will be the most effective means going forward: 1, 2, or 3? (Keeping in mind that I've basically been in mode 2: wait for Keith to fix 'mingw-get upgrade' for the past several months) FYI: Here's the title of sourceforge's latest blog post, SURE to warm the cockles of Keith's heart: "Sitewide Emails in HTML" ('cause they just LOVE .css, and want to collect metrics from the email -- e.g. webbugs) -- Chuck |
|
From: Keith Marshall <keithmarshall@us...> - 2011-02-16 17:29:53
|
On 16 February 2011 15:50, Charles Wilson wrote: > > 2) Fix "mingw-get upgrade" to remove before installing. I know this > is on Keith's TODO list, but...it's going rather slowly. Right. I don't have a lot of time to work on it right now. FWIW, I do have code already in my sandbox, which performs the remove operation; it just lacks a rigorous check for dependants, to guarantee SAFE removal -- if I say remove foo, it will just do so, irrespective of the possibility that bar or quux requires foo, and that such removal would then break bar or quux respectively. Now, maybe we could just assume that, because an upgrade should replace foo, and so hopefully restore the status quo for bar or quux, it should be fairly safe to proceed with removal, in this specific case, without a rigorous check. If we can accept this, then I could probably get this much out quite quickly, with a bit of a hack to restrict to upgrade use only; what do you think? > And frankly it's not worthwhile for ME to try to understand how the > innards of mingw-get work in order to add the feature myself, because > I don't have a roadmap of where/how future development is supposed to > go. No documentation. (Obviously, it's a choice: should Keith work > on documentation OR code? Which is more likely, in the end, to make > code development progress faster? Given the size of our potential > developer pool, I can't say that focusing on code over docu is wrong > -- because docu will enable only a VERY small developer count > multiplier). Exactly so. However, it is something of a moot point; I have little enough time to work on either, at the moment. -- Regards, Keith. |
|
From: Charles Wilson <cwilso11@us...> - 2011-02-16 19:30:07
|
On 2/16/2011 12:29 PM, Keith Marshall wrote: > On 16 February 2011 15:50, Charles Wilson wrote: >> >> 2) Fix "mingw-get upgrade" to remove before installing. I know this >> is on Keith's TODO list, but...it's going rather slowly. > > Right. I don't have a lot of time to work on it right now. > > FWIW, I do have code already in my sandbox, which performs the remove > operation; it just lacks a rigorous check for dependants, to guarantee > SAFE removal -- if I say remove foo, it will just do so, irrespective of > the possibility that bar or quux requires foo, and that such removal > would then break bar or quux respectively. It also means that, IF you were to do this "unsafe" remove foo operation and it was NOT part of an upgrade (or the subsequent install part of the upgrade failed), the NEXT time you did 'mingw upgrade' of **bar or quux**, the old foo dependency would get pulled in and (re)installed. (Which is a good thing, I think). > Now, maybe we could just assume that, because an upgrade should replace > foo, and so hopefully restore the status quo for bar or quux, it should > be fairly safe to proceed with removal, in this specific case, without a > rigorous check. If we can accept this, then I could probably get this > much out quite quickly, with a bit of a hack to restrict to upgrade use > only; what do you think? Well, even if you DID have, right now, a working implementation of 'remove' with rigorous dependency checking, you'd have to add an override to suppress that checking when remove's internal implementation (call it "remove()") is invoked prior to install() as part of an 'upgrade' (or upgrade()). So, your proposal is sorta the backwards version of that...In fact, in 'rpm' terms, you'd be implementing rpm --force -e foo *without* having implemented rpm -e foo Then, you'd be implementing rpm -U foo as rpm --force -e foo && rpm -i foo ...and I think that's ok. Besides, I really expect that mingw-get upgrade is actually a more common use case than any mingw-get remove would be (although, ultimately, we want "real" remove support too). So, I say go for it. > Exactly so. However, it is something of a moot point; I have little > enough time to work on either, at the moment. I hear that! -- Chuck |
|
From: Earnie <earnie@us...> - 2011-02-16 21:29:24
|
Charles Wilson wrote: > > Ack. One "easy" migration would be simply to take cgf up on his offer > (is it still open?) to host the mingw/msys code repository on sourceware > (and leave everything else as-is, including the FRS). We'd just shut > down/disable the code repo at sourceforge, and change the web pages to > point "over there" for code access. (sourceWARE would probably create > and host a new mingw-cvs mailing list for the commit hook, although we > could continue to have a sourceWARE commit hook send the notices to the > current sourceFORGE mingw-cvs list). > I would rather take it to our web host and have NetworkRedux set it up for us on mingw.org. Or perhaps we could manage to do it ourselves but time is lacking. Maybe we could obtain an archive copy of the server side directory structure. Earnie |
|
From: Charles Wilson <cwilso11@us...> - 2011-02-16 22:13:47
|
On 2/16/2011 4:29 PM, Earnie wrote: > I would rather take it to our web host and have NetworkRedux set it up > for us on mingw.org. Reasonable. > Maybe we could obtain an archive copy of the server > side directory structure. That part's easy -- once 'adminrepo cvs' service is restored: http://sourceforge.net/blog/update-on-scm-services/ >> CVS is back online (rsync, pserver, SSH and ViewVC), with a few >> caveats: >> - adminrepo via the Interactive Shell is temporarily offline http://sourceforge.net/apps/trac/sourceforge/wiki/CVS%20adminrepo Shows two ways to get the server-side copy of the repo: 1) rsync -av PROJECTNAME.cvs.sourceforge.net::cvsroot/PROJECTNAME/* . (it isn't clear whether this has to be done from shell.sourceforge.net or if it can be done from a remote machine) 2) To "clone a copy of your repository to /cvsroot/PROJECT" adminrepo --checkout cvs from a session on shell.sourceforge.net Then I guess you can simply cd /cvsroot/PROJECT and tar it up. Dunno what the "structure" under that dir is, maybe it includes the CVSROOT/ dir and the other modules -- I would hope so. Anyway, then you do adminrepo --discard I was looking in to this the other day because at some point I'd like to directly edit the RCS files associated with the mingw-get-inst files, so that I can set their date/time info "correctly". > Or perhaps we could manage to do it ourselves but > time is lacking. If we just want to copy the repo, without trying to set up some mirroring script and 'transition phase' during which both repos are valid, that's pretty easy. All it takes is 1) wait for adminrepo service to be restored -- or maybe rsync works now? remotely? 2) create the tarball 3) hand it over to networkredux and ask them to set it up, where :pserver: access is read-only and :ext: users (ssh-validated) have write access. Dunno about the sourceforge flexibility where individual contributors can be granted write access to only selected modules...but that's basically all on networkredux, right? 4) all current admin users need to get a networkredux account, upload their ssh keys, etc. Problem is, there would be a period of time, unknown in duration -- however long it takes networkredux to do step #3 -- during which we would be CVS-less. Again. -- Chuck |