Re: [Savannah-hackers-public] Problem with Mailman
Bandali reported that lists.gnu.org ran out of disk space, and escalated that to sysadmin@. There was a spike in spam on Monday as well .. so might be afterquakes...
Re: [Savannah-hackers-public] SubversionException: 13 - Can't open file '/srv/svn/gnueval/db/fs-type': Permission denied
Thank you for this report. I don't know why but the permissions on that one file were incorrect. drwxrws--- 6 root gnueval 253 Nov 9 11:34 /srv/svn/gnueval/db Yeah, I cannot explain it .. the gnueval repository is not heavily used. I have one job that runs a `svn update' to send out a periodical email. But that is it. Thanks for the fix.
[Savannah-hackers-public] SubversionException: 13 - Can't open file '/srv/svn/gnueval/db/fs-type': Permission denied
E.g., https://svn.savannah.gnu.org/viewvc/?root=gnueval -> An Exception Has Occurred Python Traceback Traceback (most recent call last): File "/usr/lib/viewvc/lib/viewvc.py", line 4322, in main request.run_viewvc() File "/usr/lib/viewvc/lib/viewvc.py", line 268, in run_viewvc self.repos.open() File "/usr/lib/viewvc/lib/vclib/svn/svn_repos.py", line 403, in open self.repos = repos.svn_repos_open(self.rootpath) File "/usr/lib/python2.7/dist-packages/libsvn/repos.py", line 216, in svn_repos_open return _repos.svn_repos_open(*args) SubversionException: 13 - Can't open file '/srv/svn/gnueval/db/fs-type': Permission denied or make: Entering directory '/srv/data/home/a/ams/gnueval' svn update Updating '.': svn: E170013: Unable to connect to a repository at URL 'svn://svn.savannah.gnu.org/gnueval' svn: E13: Can't open file '/srv/svn/gnueval/db/fs-type': Permission denied Makefile:24: recipe for target 'pending-report-mail' failed make: *** [pending-report-mail] Error 1 make: Leaving directory '/srv/data/home/a/ams/gnueval'
[Savannah-hackers-public] please get rid of this nuisance message from sv_membersh
Can we please turn this nuisance off? It is nothing related to the AGPL in any shape or form. You even get this utter garbage when doing an rsync?! ... sv_membersh is part of Savane. In order to download the corresponding source code of Savane, run rsync -avz --cvs-exclude a...@cvs.savannah.nongnu.org:/opt/src/savane . ... This is a total misreading of the AGPL and just a waste of peoples energy.
Re: [Savannah-hackers-public] verbose cvs -q update
> I believe users who authenticate do interact with sv_membersh > in a way analogous to the frontend PHP code invoked through Apache. > > I don't agree that the AGPL requires this message to be shown on every > cvs update. It's one possible interpretation, but not the only one. No, but it does require a prominent offer to be shown every user connecting through a network. Have you any better ideas for how to implement it? That is not what the GNU AGPL requires or say. Karl already raised this: You are not interacting with the sv_membersh. I as a user am not talking to the script in any shape or form, just like I am not interacting to your editor of choise when you wrote your email. > When I run cvs on my machine *I* am not interacting with sv_membersh. > I'm just running CVS, which obviously knows nothing about sv_membersh. > It's the savannah implementation doing the interaction. Sorry. When I run a web browser on my machine *I* am not interacting with Savane PHP code. I'm just running my web browser, which obviously knows nothing about Savane PHP code. It's the savannah implementation doing the interaction. The GNU AGPL is not concerned where you are running the program, in the case of Savane PHP you are _DEFINITLY_ interacting with it. It is no more different than a Dungeon crawler written in PH. Karl is right, this is just annoying and not required.
Re: [Savannah-hackers-public] stale directory in CVS-managed WWW pages for groff project
Thank you for your help! Happy hacking!
Re: [Savannah-hackers-public] stale directory in CVS-managed WWW pages for groff project
It looks like I need some coaching with CVS. It's been a long, long time since I used it daily. No worries, same here .. trying to recall. > $ cvsu > X manual/html_node $ cvsu cvsu: command not found I assume you had a typo, but for what, I'm not sure. Not a typo, it is part of the cvsutils package. $ cvs update -PAd Right, cvs update will try to add the files back. Did you do remove? You also need to do commit after. So basically, cvs remove foo.html; cvs commit -m "foo.html: Delete." foo.html If my memory serves me right. I would suggest, just to be on the safe side, to do it in a fresh checkout. _IF_ you want, you can add me to the groff project, and I can wipe those files.
Re: [Savannah-hackers-public] stale directory in CVS-managed WWW pages for groff project
>https://web.cvs.savannah.gnu.org/viewvc/groff/groff/manual/ If you open that URL you will find a directory: https://web.cvs.savannah.gnu.org/viewvc/groff/groff/manual/html_node/ Yes, that directory exists. alongside this one: https://web.cvs.savannah.gnu.org/viewvc/groff/groff/manual/groff.html.node/ So does this one. I asked my CVS checkout what the status of the former is. $ cvs status | grep html_node || echo NO RESULT cvs status: Examining . NO RESULT Which, given a fresh checkout, does not return NO RESULT; since the directory html_node exists in CVS. So the question remains, how did you checkout, and what did you do in your directory. I would _guess_ that you've removed it locally, but never done the cvs step of removing it. E.g., in a fresh checkout, I do $ rm -rf manual/html_node $ cvs status|grep html_node||echo NO RESULT cvs2 status: Examining . cvs2 status: Examining manual cvs2 status: Examining manual/groff.html.node NO RESULT $ cvsu X manual/html_node And I will bet that if you do "cvs update -PAd" .. you will once again have that directory. To remove it, you need to do "cvs remove manual/html_node" -- or similar.
Re: [Savannah-hackers-public] stale directory in CVS-managed WWW pages for groff project
There is a stale directory in the GNU groff project's website. https://www.gnu.org/software/groff/manual/html_node/ This corresponds to the groff 1.22.4 release, which is nearly 5 years old. The directory also shows up in ViewVC. https://web.cvs.savannah.gnu.org/viewvc/groff/groff/manual/ However it is _not_ present in my CVS checkout. How did you checkout your directory? What did you do in your checkout? I did a fresh checkout, and manual/ is there, as it should be from the looks of it. So it is not stale, might be out-dated, but that is becuase nobody removed it. My memories of CVS are that it didn't handle symlinks well. Does this require administrative intervention? I'm not sure what intervention is needed, manual/ is part of the source tree, nobody (you?) never removed it.
Re: [Savannah-hackers-public] gnu coding standards
>> Savannah Hackers, would you please add Alfred? > >Alfred was added to gnustandards on 2023-06-18. > > Not as admin. Brandon is no longer active. Done; I've also added you to the 'www' group where the generated output is posted, in prep/. Please be more specific if anything else is needed. Sorry, though it was. Thanks for the help!
Re: [Savannah-hackers-public] gnu coding standards
> Savannah Hackers, would you please add Alfred? Alfred was added to gnustandards on 2023-06-18. Not as admin. Brandon is no longer active.
Re: [Savannah-hackers-public] gnu coding standards
> > And some rule on what can "automatically" go into the GCS without your > > explicit review and approval. > >Normally all changes in the GNU standards have to be approved by me, >though it would be ok to fix a trivial typo. > > Fair enough. I'm still waitig for Savannah admins to add me to the > gnustandards project. Got a pointer to the issue tracker entry for this? No, only this email.
Re: [Savannah-hackers-public] gnu coding standards
[[[ To any NSA and FBI agents reading my email: please consider]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > And some rule on what can "automatically" go into the GCS without your > explicit review and approval. Normally all changes in the GNU standards have to be approved by me, though it would be ok to fix a trivial typo. Fair enough. I'm still waitig for Savannah admins to add me to the gnustandards project.
Re: [Savannah-hackers-public] gnu coding standards
> *waves hand as volunteer* I could do it, it isn't that much work. Thank you for volunteering -- please take up the responsibility. Do you need anyone else's help to do that? Only admin access to https://savannah.gnu.org/projects/gnustandards -- CCing savannah hackers. And some rule on what can "automatically" go into the GCS without your explicit review and approval.
Re: [Savannah-hackers-public] Please disallow www-commits in robots.txt
That sounds reasonable to me. I would assume that if webmasters don't have access to change robots.txt, it would just be the fsf tech team. They do. It is in www. I'm still sorta opposing this .. we have always been transparant. That search engines "have no business" is as saying that other GNU hackers have no business looking at www-commits, www-discuss, or whatever. It is anti-social. We aren't publishing sensetive information...
Re: [Savannah-hackers-public] Please disallow www-commits in robots.txt
Might be worth noting that www.gnu.org is mostly usable locally from the CVS checkout as well, if one needs to look things over. So a patch to www-discuss@ or whatever for a unpublished article would be sufficient in postponing any publishing. It would just be a matter of applying the patch, and looking at the web pages locally to see what is or isn't.
Re: [Savannah-hackers-public] Please disallow www-commits in robots.txt
Le 10/05/2023 à 20:50, Alfred M. Szmidt a écrit : > > You've not explained the actual problem. What are you trying to > > solve? > > "it" is the www-commits list, which registers all changes to the www > directory, including to pages that are not published yet. I suspect most > of the other *-commits lists deal with source code repositories, which > are public anyway. > > If you wish to disallow access to pages, do not publish them -- > www-commits is a public list, the www repository is a public > repository -- any commit is by definition published. It is no > different than getting bug reports for commits in a software > repository that still hasn't had a release. > > If you let crawlers access changes to disallowed directories, you are > defeating the purpose of robots.txt. What was supposed to be unpublished > is actually published. > > The purpose of robots.txt is to avoid overloading a web site, it is > not to disallow access to pages. > > This still does not explain what the problem is -- "don't let crawlers > crawl" doesn't explain it. What are you trying to solve? That > unpublished articles are not published before they are finished? Yes, basically. The purpose of the staging area is to work on articles that are not ready yet. What about putting such articles / pages on fp? Or sharing them on some internal list?
Re: [Savannah-hackers-public] Please disallow www-commits in robots.txt
> You've not explained the actual problem. What are you trying to > solve? "it" is the www-commits list, which registers all changes to the www directory, including to pages that are not published yet. I suspect most of the other *-commits lists deal with source code repositories, which are public anyway. If you wish to disallow access to pages, do not publish them -- www-commits is a public list, the www repository is a public repository -- any commit is by definition published. It is no different than getting bug reports for commits in a software repository that still hasn't had a release. If you let crawlers access changes to disallowed directories, you are defeating the purpose of robots.txt. What was supposed to be unpublished is actually published. The purpose of robots.txt is to avoid overloading a web site, it is not to disallow access to pages. This still does not explain what the problem is -- "don't let crawlers crawl" doesn't explain it. What are you trying to solve? That unpublished articles are not published before they are finished?
Re: [Savannah-hackers-public] Please disallow www-commits in robots.txt
Because it registers every single commit to www, What is "it"? How is this different from _any_ -commits list we have? including to working directories that webmasters have disallowed, for instance */po/, /server/staging/, */workshop/, /prep/gnumaint/, etc. Ok, and? Please see https://www.gnu.org/robots.txt. And? You've not explained the actual problem. What are you trying to solve?
Re: [Savannah-hackers-public] Please disallow www-commits in robots.txt
I was searching for an article with DuckDuckGo, and guess what appeared on top of the results... https://lists.gnu.org/archive/html/www-commits/2023-05/msg00082.html and https://lists.gnu.org/archive/html/www-commits/2023-05/msg00062.html !! What is the problem? I understand it wouldn't be practical to make this list private, but it could at least be off-limits for crawlers. How is www-commits different from anything else?
Re: [Savannah-hackers-public] Delays in mail delivery by gnu.org mailing lists
Lately, mail delivery by gnu.org mailing lists intermittently suffers from very long delays. For example, currently emacs-devel and help-gnu-emacs mail is delivered with delays between 45 minutes and 1.5 hours (based on admittedly small and potentially non-representative sample). This happens a lot during the last days. What causes this? Can this be improved? TIA. I've not seen any specific delays, but that doesn't mean that there aren't any. So this is more of an ACK that someone read this specific email... Usually, though Savannah hackers are fast, mail related issues is handled by the FSF so ... sysad...@gnu.org, CC forward there. P.S. https://hostux.social/@fsfstatus is as usual not helpful.
Re: [Savannah-hackers-public] Sending email via fencepost fails
Sometimes, some of us subscribed here, can also ping the FSF admins in other ways -- sysadmin@ is not a list that is easily subscribed to AFAIK.
Re: [Savannah-hackers-public] Sending email via fencepost fails
But the gripe about the FSF Status page is real: lately I find it less and less useful in such cases. Which is too bad. Just to give a small shout, I agree.
Re: [Savannah-hackers-public] Email address no more hidden
This is I think better directed to the FSF sysadmins. CCing. > Date: Tue, 28 Jul 2020 09:54:28 +0200 (CEST) > From: Angelo Graziosi > > I noticed that reading the post online (https://lists.gnu.org/archive/html/emacs-devel/2020-07/index.html, for example), the email address in citation is not substituted with "addres@hidden" any more, so would be desirable to avoid email address in citation when replaying to an email. > > The "address@hidden" starts to disappear between May 26-27 The above message was posted today to the emacs-devel mailing list. I verified that Angelo is factually correct, and that the corresponding setting of the emacs-devel list still says to make the addresses not recognizable. So why is this happening? TIA
Re: [Savannah-hackers-public] Emacs git repository clone limits
Why not simply use a reference repository? git clone --mirror git://git.gnu.org/emacs.git ~/emacs-reference And when cloning: git clone --reference ~/emacs-reference git://git.gnu.org/emacs.git the ~/emacs-reference place can be accessible where ever you are using it. This will work incrementally, and not use up scares resources..
Re: [Savannah-hackers-public] Shutting down the old frontend?
> Is there any reason we can't shutdown the old frontend now? I can't > think of anything that is still using it. I think the time has come > that we can now shutdown halt the old frontend. I moved the content of frontend:/root into frontend0:/root/old-frontend-root - it had some files and scripts from various admins, some might be useful (didn't go through it, yet). Tip, always name things with a date. In 1, 10, 20 years you will wonder when that directory was created. ;-)
Re: [Savannah-hackers-public] [gnu.org #1162706] Website DOWN
I have forwarded this to the Chapters/Planet admin(s).
Re: [Savannah-hackers-public] New Wiki page explaining when/how to contact FSF sysadmins
Comments, suggestions and improvements welcomed. I like it. Maybe put it into the GNU maintainers guide as well?
Re: [Savannah-hackers-public] Web CVS server unavailable
Maybe incorperate it with the Free Software Directory somehow, there could be an icon showing that a package is available in Guix; and which version.
Re: [Savannah-hackers-public] Web CVS server unavailable
Itâs clear that CVS is a hindrance for such purposes so if thereâs another possibility, Ludo, why must we go through this yet again? Surely you know perfectly well by now that there is no other possibility at present. Not to mention that it isn't a problem with CVS; git would have similar issues down the line; and the file as such is heavy for the network pipe on both ends -- it is a 7MiB download.
Re: [Savannah-hackers-public] Savannah and the present
Perhaps Savannah is not suited for the purpose of replacing Github, but at the very least the FSF should sponsor sites like: https://notabug.org/ which are based on free software and host exclusively free software (unlike Github, which accepts proprietary programs). It seems that http://notabug.org also accepts non-free programs, for example: https://notabug.org/nelis/hg-shopp-theme This has no license information what so ever. If this is in error or not, I don't know. > This also keeps Javascript requirements to minimum - which is > another added bonus for some. Github does not require JavaScript and can be completely operated by a free command line program that uses their API called "hub". >From what I recall this is not entierly correct, to be able to use github you need an account -- that requires non-free javascript. If it's perceived as something old and clunky, we can't expect people to support it, and consequently, many people will not make their programs part of the GNU project, which often means releasing them under permissive licenses to satisfy the "open source" supporters who think the GPL is "viral" and "restrictive" and they "wouldn't touch any GPL code". People who call the GPL "viral", and "restrictive" are already people who would be unwilling to use Savannah, since they are already hostile to the idea of computer user freedom -- it doesn't matter to them what Savannah looks like. The goal of Savannah, and the GNU project isn't to make more GNU projects -- it is to provide a free software hosting platform and a free operating system.
Re: [Savannah-hackers-public] Savannah and the present
> It seems that http://notabug.org also accepts non-free programs, for > example: > > https://notabug.org/nelis/hg-shopp-theme > > This has no license information what so ever. If this is in error or > not, I don't know. This should have not happened, according to what I know. I'm putting the NAB admin in CC, hoping he will give you a satisfying answer. Thank you. > People who call the GPL "viral", and "restrictive" are already people > who would be unwilling to use Savannah, since they are already hostile > to the idea of computer user freedom -- it doesn't matter to them what > Savannah looks like. But it gives them some arguments in favor of their labelling of the GNU Project as elitist and dated ("just look at Savannah"). People who are hostile toward our goals will always find an excuse to call us names and attack us, there is little we can do about it. If we have a "pretty" web page, they will attack us for that. > The goal of Savannah, and the GNU project isn't to make more GNU > projects -- it is to provide a free software hosting platform and > a free operating system. But outside of GNU, the GPL isn't very common. It is the most common free software license being used, it can't be much more common than that. I think the goal of the GNU Project should be to take as many project under its umbrella as possible, [...] There are many good reasons to reject a free software project to be part of the GNU project -- there is another project that does the same job being the most common reason. But for before a project can become a GNU project, the hackers who work on it have to have at least aligned their views with the views of the Free Software movement and the GNU project -- Savannah looking pretty or not has little to do with ethics and morals.
Re: [Savannah-hackers-public] Licensing advice for package submitters
There is no license that limits commercial use and still compatible with GPLv2 (and GNU savannah). Or any free software license for that matter. All free software licenses explicitly allow commercial use.
[Savannah-hackers-public] unpacker error when pushing
I'm getting the following error when trying to push, anyone know what is wrong? $ git push --verbose Pushing to git://git.sv.gnu.org/womb/hacks.git Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 426 bytes | 0 bytes/s, done. Total 3 (delta 2), reused 1 (delta 0) error: unpack failed: unpack-objects abnormal exit To git://git.sv.gnu.org/womb/hacks.git ! [remote rejected] master - master (n/a (unpacker error)) error: failed to push some refs to 'git://git.sv.gnu.org/womb/hacks.git'
Re: [Savannah-hackers-public] Non-fast-forward pushes on git
Instead of getting emotional, have you tried doing `git commit --amend'? That command is exactly created for situations like this!
Re: [Savannah-hackers-public] Non-fast-forward pushes on git
My new project has been recently approved (gnu-social-mode), but due to a new member's mistake there is a commit on the repository which is malformed. The proper way is to use `git commit -amend'; not rewrite history. But what do you mean malformed? These are the few last commits to gnu-social-mode, none of them seem malformed: commit 7c7d3f6f9eb29edfece1841911e80f4f594e3d17 Author: Albino Biasutti Neto b...@riseup.net Date: Mon Jul 21 19:53:22 2014 -0300 fix link identica-mode L25 commit 12ba11968045b5fb3da8fcbf93b5c242e9aa3c61 Author: Sergio Durigan Junior sergi...@sergiodj.net Date: Sat Jul 19 20:08:51 2014 -0300 Rename files, comments, functions, etc. This commit is a major renaming for the project. It basically does s/identica/gnu-social/ in every file. It also renames the files themselves, and makes a few adjustments needed for the OAuth support on gnu-social-mode.el. commit 5b7d171392db4f2a2a0713f3ecba9bdf602f64ba Author: Sergio Durigan Junior sergi...@sergiodj.net Date: Fri Jul 18 21:17:34 2014 -0300 Relicense code to GPLv3+ for gnu-social-mode This is the first commit of the new gnu-social-mode project. It simply relicenses all the code to GPLv3+ on all files. Very tiny cleanups were also made on the top comments of those files as well. Welcome, gnu-social-mode! commit cf9183ee11ac922e85c7c908f04e2d00b03111b3 Author: Gabriel Saldana gabr...@gabrielsaldana.org Date: Mon Feb 4 16:53:42 2013 -0600 bump version to 1.3.1 after patches
Re: [Savannah-hackers-public] Non-fast-forward pushes on git
Or you, if you're the only one working on that repository, you could try to fix it using `git revert` (see the manual for that). Yeah, I know about git-revert. But the wrong commit is so small/simple that it doesn't take much to revert it. Just use `git commit --amend' for that. There are already four people, and eleven emails already involved (if that is simple/small then one might wonder what complex/big is) -- and for a change that is immensly minor change. There have been _three_ commits (of which two you are the author of) in over one year of which none are malformed: fix link identica-mode L25H Rename files, comments, functions, etc. Relicense code to GPLv3+ for gnu-social-mode
Re: [Savannah-hackers-public] Savannah dead in the water...
I assume this is known, but the savannah web site isn't answering and neither is the git repo (git.sv.gnu.org). Savannah (including all other GNU and FSF machines) are being moved to a new colo. | The GNU/FSF servers are moving between February 22nd and March 1st, | 2012. There will be service interruptions during that period. | There will be a multi-hour outage for most services on February | 28th, 2012, starting at 10am EST (UTC/GMT -5). The GNU/FSF servers | are moving to a new colocation facility. This will involve | renumbering all our IP addresses. | The work starts February 22nd and will be completed by March 1st. | There will be occasional service interruptions during this period. | There will be a multi-hour outage for most services on February | 28th, starting at 10am EST (UTC/GMT -5). | We will be posting updates via https://identi.ca/group/fsfstatus | Feel free to contact sysad...@gnu.org if you see something that | seems wrong, but please keep in mind that some downtime is | inevitable. | If the FSF hosts a virtual machine for your organization, please | contact sysad...@gnu.org to plan the migration of your virtual | machine.
Re: [Savannah-hackers-public] Projects for Android in GNU Savannah
The question is not whether Android requires aditional software to be useful but whether it can be used with only free software, for otherwise Android-specific projects can't run on a fully free enviroment which is a requirement in GNU Savannah. A simple approach might be to do what is done for other non-free operating systems, like OS X. Do we host code for projects that only run on those? If no, then we should do the same for Android projects. By the way I, there is the GNU HURD. And Linux, specially in its form of Linux-Libre.
Re: [Savannah-hackers-public] #savannah on irc.gnu.org
I won't object the migration of #savannah to some other IRC network if someone trustable first check than it doesn't have issues like this one (Or precisely this one). But I'm definitively not that someone. I see no reason why you can't do it, could you do it so we can resolve this issue? Do you know someone who can try and setup TOR with Freenode, and work with the Freenode people to resolve any issues if you don't have the time?
Re: [Savannah-hackers-public] #savannah on irc.gnu.org
I haven't recived any updates on this, have you tried using Freenode with TOR? Could you update me on the status?
Re: [Savannah-hackers-public] #savannah on irc.gnu.org
We shouldn't confuse the discussion, it is about having #savannah on irc.gnu.org, not about Freenode, OTFC or where to host it. If TOR users have issues with Freenode it is better to solve the problems with them, than changing networks every week. Could you bring the issues you experienced with supp...@freenode.net first? Saying that Freenode is hostile towards TOR users is harsh, and untrue. Freenode does support TOR, it may be a bit of a fiddle since it has been abused; but this is no different than it being fiddly to access the GNU machines since people abused them and now we have to use SSH. Personally, I'd like to see GNU hosting as IRC server.
[Savannah-hackers-public] #savannah on irc.gnu.org
Hi, I find it immensly annoying that irc.gnu.org isn't hosting #savannah, while I understand Sylvain's concerns regarding TOR, it does more harm than good to have some IRC channels (specially ones as important as #savannah, which has been invaluable when shit hits the fan) on random servers. If freenode for whatever reason cannot support our needs, then maybe we should switch. But I think that #savannah should exist, and be active when you connect to irc.gnu.org. Cheers, Alfred
[Savannah-hackers-public] [mats.anders...@gisladisker.se: Re: Me failing at SSH keys]
Could someone look into this? We don't know what is wrong. --- Start of forwarded message --- Date: Thu, 18 Nov 2010 17:39:50 +0100 To: Sergey Poznyakoff g...@gnu.org.ua Cc: Alfred M. Szmidt a...@gnu.org, Jeff Bailey jbai...@raspberryginger.com, Alain Magloire ala...@gnu.org From: Mats Erik Andersson mats.anders...@gisladisker.se Subject: Re: Me failing at SSH keys Dear Sergey, torsdag den 18 november 2010 klockan 17:44 skrev Sergey Poznyakoff detta: Hi Mats, I would just like to keep you informed on my failure to get the uploading of SSH keys at Savannah to work properly. Could you give more detail please? What it is you attempted to do and how exactly did it fail? I have uploaded two RSA keys to Savannah using the web interface. They seem to be accepted every time, also after proof reading the key material and replacing all ambiguous letters: 0, O, 1, l, and I. I have also checked, using ssh-keygen -y -f key-path, that I do in fact remember both pass phrases! In order to access Savannah I have attempted at ssh -i key-path git.gnu.org (Alfred suggested this.) git clone ssh://git.sv.gnu.org/srv/git/inetutils.git Yes, my SSH client ties the correct key to git.sv.gnu.org. Both attempts end in a disappointing Permission denied (publickey) The latter attempt asks for my pass phrase three time, whereas the first command communicates a denial right off! Whithout the ability to clone the repository, there is no way I could push my ACK-ed changes back, so I must somehow resolve this calamitym, if I should become productive in the service of GNU Inetutils at all. Best regards, Mats --- End of forwarded message ---
Re: [Savannah-hackers-public] inetutils: accidental push of branch
It's a mostly-default one. You can enable branch deletion by doing this on the server: git --git-dir /vservers/vcs-noshell/srv/git/inetutils.git \ config hooks.allowdeletebranch true I have enabled it. Sorry for not being able to react earlier. Alfred, please retry deleting. Thanks! Not sure if we want to allow branch deletion, I have no real opinion on the topic.
Re: [Savannah-hackers-public] [si...@josefsson.org: [SCM] GNU Inetutils branch, master, updated. inetutils-1_6-127-gb68da88]
We're using contrib/hooks/post-receive-email from the Git release. I would suggest sending patches to the Git project. Can you send me a copy of this file?
[Savannah-hackers-public] [si...@josefsson.org: [SCM] GNU Inetutils branch, master, updated. inetutils-1_6-127-gb68da88]
It seems that `git diff' still gets immensly confused when producing diff output, man/Makefile.am was not copied from Makefile.am. The summary at the end if also confusing, the diff states that Makefile.am was copied to man/Makefile.am, while the summary says rexec/Makefile.am was copied to man/Makefile.am. --- Start of forwarded message --- To: commit-inetut...@gnu.org From: Simon Josefsson si...@josefsson.org Date: Mon, 07 Dec 2009 10:45:59 + Subject: [SCM] GNU Inetutils branch, master, updated. inetutils-1_6-127-gb68da88 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Inetutils . The branch, master has been updated via b68da88c4318500bb32a64da58221895be0feb94 (commit) from 01469ec1de61765657f4a94660a60b0bdab5b922 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - - Log - http://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=b68da88c4318500bb32a64da58221895be0feb94 commit b68da88c4318500bb32a64da58221895be0feb94 Author: Simon Josefsson si...@josefsson.org Date: Mon Dec 7 11:45:55 2009 +0100 Add (some) man pages. diff --git a/ChangeLog b/ChangeLog index 94c9ec4..a6154e5 100644 - --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2009-12-07 Simon Josefsson si...@josefsson.org + + * configure.ac: Check for help2man. + * configure.ac (AC_CONFIG_FILES): Add man/Makefile. + * Makefile.am (SUBDIRS): Add man directory. + * man/Makefile.am: Add file. + * man/telnet.x, man/telnetd.x, man/rshd.x: New files. + 2009-12-06 Giuseppe Scrivano gscriv...@gnu.org * NEWS: Mention the new program rexec. diff --git a/Makefile.am b/Makefile.am index 5c9f40c..72437dd 100644 - --- a/Makefile.am +++ b/Makefile.am @@ -26,7 +26,7 @@ EXTRA_DIST = README-alpha paths ChangeLog.0 SUBDIRS = lib headers libinetutils libtelnet \ hostname inetd telnetd libls ftpd rshd rlogind uucpd rexecd syslogd \ tftpd talkd telnet ftp rsh rcp rlogin tftp logger whois talk \ - - libicmp ping doc ifconfig traceroute rexec tests + libicmp ping doc ifconfig traceroute rexec tests man DISTCLEANFILES = pathdefs.make paths.defs diff --git a/configure.ac b/configure.ac index bfe17bc..d2df5a3 100644 - --- a/configure.ac +++ b/configure.ac @@ -132,6 +132,7 @@ AC_PROG_INSTALL AC_PROG_MAKE_SET AC_PROG_RANLIB AC_PROG_YACC +AM_MISSING_PROG(HELP2MAN, help2man, $missing_dir) gl_INIT @@ -844,5 +845,6 @@ confpaths.h:confpaths.h.in headers/Makefile doc/Makefile tests/Makefile +man/Makefile ]) AC_OUTPUT diff --git a/Makefile.am b/man/Makefile.am similarity index 50% copy from Makefile.am copy to man/Makefile.am index 5c9f40c..61235ed 100644 - --- a/Makefile.am +++ b/man/Makefile.am @@ -1,6 +1,5 @@ # - -# Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, - -# 2006, 2007, 2008, 2009 Free Software Foundation, Inc. +# Copyright (C) 2009 Free Software Foundation, Inc. # # This file is part of GNU Inetutils. # @@ -17,18 +16,24 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see `http://www.gnu.org/licenses/'. - -AUTOMAKE_OPTIONS = 1.9 +dist_man1_MANS = telnet.1 telnetd.1 rshd.1 - -ACLOCAL_AMFLAGS = -I m4 -I am +man_aux = $(dist_man1_MANS:.1=.x) +EXTRA_DIST = $(man_aux) - -EXTRA_DIST = README-alpha paths ChangeLog.0 +MAINTAINERCLEANFILES = $(dist_man1_MANS) - -SUBDIRS = lib headers libinetutils libtelnet \ - - hostname inetd telnetd libls ftpd rshd rlogind uucpd rexecd syslogd \ - - tftpd talkd telnet ftp rsh rcp rlogin tftp logger whois talk \ - - libicmp ping doc ifconfig traceroute rexec tests +telnet.1: telnet.x $(top_srcdir)/telnet/main.c $(top_srcdir)/configure.ac + $(HELP2MAN) \ + --include=telnet.x \ + --output=$@ $(top_builddir)/telnet/telnet$(EXEEXT) - -DISTCLEANFILES = pathdefs.make paths.defs +telnetd.1: telnetd.x $(top_srcdir)/telnetd/telnetd.c $(top_srcdir)/configure.ac + $(HELP2MAN) \ + --include=telnetd.x \ + --output=$@ $(top_builddir)/telnetd/telnetd$(EXEEXT) - -snapshot: - - $(MAKE) dist distdir=$(PACKAGE)-`date +%Y%m%d` +rshd.1: rshd.x $(top_srcdir)/rshd/rshd.c $(top_srcdir)/configure.ac + $(HELP2MAN) \ + --include=rshd.x \ + --output=$@ $(top_builddir)/rshd/rshd$(EXEEXT) diff --git a/man/rshd.x b/man/rshd.x new file mode 100644 index 000..c3dfb66 - --- /dev/null +++ b/man/rshd.x @@ -0,0 +1,4 @@ +[NAME] +rshd \- Remote shell server +[SEE ALSO] +rsh(1) diff --git a/man/telnet.x b/man/telnet.x new file mode 100644 index 000..1abcd29 - --- /dev/null +++ b/man/telnet.x @@ -0,0 +1,4 @@ +[NAME] +telnet \- User interface