At 23.30 PST on Sunday 27 Feb, it is very slow again. ~ 35 mins for a ~ 5
line commit. It was alright mid-afternoon PST.
Can you not just disable the cgit service (it seems to still be
available) until there is a solution for this problem? Being able to
commit is more important.
Jim Meyering wrote:
I've diagnosed and fixed the problem.
Great, thank you.
Hi,
The question why can't I maintain my gnu.org web-pages in something
other than CVS is one that crops up from time-to-time. It came up
again on the Emacs list recently:
http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00526.html
Personally, I have zero problem using CVS for this, but
Karl Berry wrote (on Wed, 24 Apr 2013 at 22:23 GMT):
And symlinks - .symlinks.
I forgot about that (or assumed people would still use .symlinks
rather than creating real ones).
Another small point is that savannah projects have only the one
hardwired slot for the web pages repository. So
Bob Proulx wrote:
/etc/cron.hourly/bzr_commit_mail_notification:
Traceback (most recent call last):
File /usr/src/bzr-hookless-email/bzr_hookless_email.py, line 328, in
module
main()
File /usr/src/bzr-hookless-email/bzr_hookless_email.py, line 79, in main
branch.update()
Bob Proulx wrote (on Wed, 1 May 2013 at 21:17 -0600):
In theory bzr wasn't upgraded. The package manager thinks it has
2.1.2-1 installed and there isn't an upgrade for it in Stable so there
shouldn't have been any changes. The log doesn't show any changes to
it. However bzr itself reports
Bob Proulx wrote (on Thu, 2 May 2013 at 00:30 -0600):
I applied that patch. It didn't apply cleanly due to file
differences. I manually and rather mechanically patched the
rejections into the vcs.savannah copy of the file. I ran the hourly
cron script just now and if no output is good
Bob Proulx wrote (on Thu, 2 May 2013 at 10:47 -0600):
I added that change to the script. I imagine we will need to wait
for the next commit before there is a notification. If you would
keep an eye open and report on the result that would be great.
Seems ok, thanks.
(I'm not subscribed, please cc me)
Bob Proulx wrote:
My personal preference is to use the local command. I would use
/usr/sbin/sendmail as a general local mailer because that takes no
configuration.
The external command is expected to behave like mail, ie accept the
-s and -a options.
I
OK, now I am hassling you.
Please could someone
apt-get install bzr-email
(the version from Debian testing would be preferred), then I suggest
applying the patch from
http://lists.gnu.org/archive/html/savannah-hackers-public/2013-05/msg00025.html
As it stands, bzr commit notifications
Karl Berry wrote (on Mon, 3 Jun 2013 at 22:43 GMT):
Would you willing to work on the other side of keyboard and do this
installation + patch yourself? Let me know and I'll add your ssh to
savannah's authorized_keys ...
I suppose I'll give it a go if no-one else wants to.
(I'll probably
Karl Berry wrote (on Wed, 5 Jun 2013 at 17:29 GMT):
Thanks for trying.
On the bzr mailing list today, they said it should work. I'll try once
again later on.
Maybe we should somehow try to revert back to the previous state?
If it doesn't work, that's going to be my suggestion (revert to bzr
I got it working.
There was a hard-coded --no-plugins being passed to bzr in
/usr/local/bin/sv_membersh .
Does anyone see any issue with removing that? I don't see one myself.
The original motivation is contained in the thread
Permission denied: '/var/lib/bzr/.bzr.log'
My bad, fixed. Now I know what that 8GB of log file is for...
Karl Berry wrote:
There was a hard-coded --no-plugins being passed to bzr in
/usr/local/bin/sv_membersh .
Amusingly, logging and plugins are disabled for authenticated users, but
not for anonymous users. Hence 8GB of (pointless, AFAICS) log file of
people typing bzr pull over the past
Eli Zaretskii wrote:
Doesn't bzr rotate log files automatically?
Evidently not (do I have to say 8GB log file again?).
Anyway, logrotate is trivial and I like it, so I used that.
Karl Berry wrote:
Could you, please, bump the timeout connection please? I get a
disconnect when checking out a branch of emacs.
5 hours isn't enough? Ok, I changed the timeout I know about to 10.
I don't think you needed to change that. At least, it won't help Ivan at
all, IIUC.
Ivan Kanis wrote:
Sorry I didn't. I was following Eli's suggestion.
I did suggest only doing that next time. There's not much point moving a
conversation that's already in progress. Anyway, let's carry on now.
I think that is the problem. My desktop is somewhat slow compared to
modern
PS Karl, should I write down somewhere what I think I understand about
how this is set up on Savannah? There's a wiki somewhere?
Karl Berry wrote:
We can in principle increase the 300s timeout by passing
--client-timeout=ARG to bzr serve in /usr/local/bin/sv_membersh,
I think we should (to, say, an hour), regardless of whether that helps
Ivan or not, because all experience is that networks fail in
Karl Berry wrote:
Agreed. Let's try removing it and see if there is some immediate
failure report?
Ah, the scientific method. :)
Done.
Ivan Kanis wrote:
Could you tell us what actually happens?
I get the timeout error.
I meant, what has been printed to the screen?
fetching revisions, preparing file merge, etc?
Have any of those stages finished? What does the completion counter say?
Etc.
Is it doing anything when it dies,
Eli Zaretskii wrote:
I meant, what has been printed to the screen?
fetching revisions, preparing file merge, etc?
Have any of those stages finished? What does the completion counter say?
Etc.
The answers to those questions can be looked up in the ~/.bzr.log
file, btw.
(I don't actually
Karl Berry wrote:
PS Karl, should I write down somewhere what I think I understand about
how this is set up on Savannah?
Yes please. For now, can you just post it here as an email message and
I will endeavor to save it for later updating?
Some blurb:
* Bzr Information for Users
rsync -avz -e ssh vcs.sv.gnu.org::sources/gcl/ ./gclr/
[...]
You tried to execute: rsync --server --daemon .
Sorry, you are not allowed to execute that command.
FWIW, works fine for me without -e ssh.
http://savannah.gnu.org/maintenance/CvSToSvN
rsync -av
Hi,
Anyone know of a reason why I should not `apt-get install locales' on
vcs.sv? I'd leave the default locale as None, as it is now.
I think this is the way to solve a bzr commit email issue with non-ascii
characters in people's Savannah user names.
It seems a bit odd that the package is not
Karl Berry wrote:
Anyone know of a reason why I should not `apt-get install locales' on
vcs.sv? I'd leave the default locale as None, as it is now.
As long as the default locale doesn't change, sounds safe enough to
me to try.
Done.
It actually looks like the Savannah gecos data
Karl Berry wrote:
For the record ... on vcs, in /etc/xinetd.d, I've just changed svn and
cvspserver and git-cvspserver to invoke their daemons with nice+timeout,
as we have done already with bzr and git.
Doesn't this merit an entry in /root/ChangeLog on mgt?
FWIW, anonymous bzr started
Assaf Gordon wrote:
My goal is to get a log of all the commits in a bzr repository - to be
used for more statistics about project activity on GNU Savannah.
These statistics are probably already available elsewhere, eg
https://www.openhub.net/p/emacs .
Assaf Gordon wrote:
Besides, it really sounds like something that should be easy to do...
With git/hg/cvs/svn it was trivial.
I'm sure there's a way to do with BZR, I simply haven't found it.
I'm going to be blunt and say: don't bother.
There are only ~ 11 projects on Savannah using bzr that
Assaf Gordon wrote:
How can I tell (programatically) which branches does a repository
have, or alternatively, clone them all at once?
This page says `bzr heads' will work:
http://stackoverflow.com/questions/19082720/getting-all-bazaar-bzr-branch-list-with-bzr-command
but I did not test it.
Eli Zaretskii wrote:
Assaf wants to collect information about VCS usage for the last 15
years, not only for 2014.
Well for Emacs those data are already also available in git form (on
Savannah).
There are only 64 other projects on Savannah with non-empty bzr repos.
(There seem to be about 10x
Eli Zaretskii wrote:
> There's something strange going on with the archives of GNU lists
I reported this to mailman@gnu yesterday.
(Savannah-hackers have no special control over the mailing lists AFAIK.)
sysadmin@gnu are working on it (#1052153).
It is now listed as a known issue at
Hi,
I got this message after pushing a commit to the emacs git repo:
remote: postdrop: warning: uid=66918: No space left on device
remote: sendmail: fatal: gm(66918): queue file write error
And indeed the vcs0 /var partition was 100% full.
The size of /var was 3.8GB, and almost all of
Assaf Gordon wrote:
> I assume it happens because over long period of time,
> various savannah admins changed various files
> (e.g. scripts on 'vcs'), but never checked them into the 'savane'
> repository.
I never knew anything about the repository. :)
> I'll have some time tomorrow, so I'll
Bob Proulx wrote:
> I just made a big edit, import, cleanup to the authorized keys file.
> Try it again now. I it should allow you in. You should be able to
> log in from fencepost to mgt0 now.
Thanks. If security is a concern you should probably all disable my
Savannah ssh access, since I
Bob Proulx wrote:
> Yes. Looks like bzr is logging to /var/lib/bzr/bzr-anon.log. Which I
> think should be /var/log/bzr/bzr-anon.log instead. I am going to make
> that change. Will copy the logrotate over for the new location.
It's as you prefer. But you will need to edit
I think I've copied all the changes across now, so it might be working.
I no longer have any writable bzr repos on Savannah to test with.
Here are the bzr notes from a few years ago, which may or not still be useful:
https://lists.gnu.org/archive/html/savannah-hackers-public/2013-06/msg00042.html
It should basically be the bzr-email plugin, yes.
Bob Proulx wrote:
> /var/cache/cgit directory.
[...]
> Some of the files are really quite large.
>
> -rw--- 1 www-data www-data 513M Mar 9 02:40 f011
Any idea what causes these enormous files to be produced?
I see cgit has an option:
max-blob-size
Specifies the maximum size of
Bob Proulx wrote:
> I know very little about cgit. I only rarely use it.
Me too. In a spirit of scientific enquiry, I added
max-blob-size=5
to /etc/cgitrc, so we'll see what happens. :)
There's a 178MB /var/cache/cgit/f301 right now.
It corresponds to the single pack file in the bash
>> IIUC, this can be disabled by adding
>>
>> enable-http-clone=0
This seems to have started working:
git clone http://git.savannah.gnu.org/cgit/test-project.git
Cloning into 'test-project'...
fatal: repository 'http://git.savannah.gnu.org/cgit/test-project.git' not found
s/cgit/git and it
Eli Zaretskii wrote:
> ELPA is git.savannah.gnu.org/srv/git/emacs/elpa.
True, this is the upstream repository, but elpa.gnu.org is a checkout of
that which builds and serves packages to Emacs users. The Savannah
admins have zero control over or responsibility for elpa.gnu.org, any
more than they
43 matches
Mail list logo
