Nabble - Gnu - Savannah - Dev

Re: [sebgerhardt@gmx.net: [Fwd: Problem with mailing list]]

2009-12-15T15:45:37Z

It was appeared problem with mailing list. Attempt to send message
into just created mailing list (ru-hurd-maillist@...) has
failed and server

> ru-hurd-maillist@...
> SMTP error from remote mailer after RCPT TO:<ru-hurd-maillist@...>:
> host mx10.gnu.org [199.232.76.166]: 550 Previous (cached) callout verification failure

I'm not sure if Sylvain already answered this, but if not: as I
understand it, there is always a delay after a mailing list is created
before it accepts mail. (I don't know why.) Try waiting a while --
hopefully a few hours should do it, but it might take a day -- and
trying again. (I guess it's been several days since your original msg,
so maybe it works now?)

I do see that ru-hurd-maillist exists on lists.gnu.org, and don't see
anything wrong with the setup.

Best,
Karl

[sebgerhardt@gmx.net: [Fwd: Problem with mailing list]]

2009-12-15T03:19:21Z

----- Forwarded message from Sebastian Gerhardt <sebgerhardt@...> -----

Date: Fri, 11 Dec 2009 17:25:17 +0100
From: Sebastian Gerhardt <sebgerhardt@...>
To: Sylvain Beucler <beuc@...>
Cc: Yury Chumak <sphynkx@...>
Subject: [Fwd: Problem with mailing list]
X-Mailer: Evolution 2.28.1

Hi Sylvain,

I got the attached mail from Yury about problems with the mailing list.
Can you please look into it?

Best,
Sebastian

Return-Path: <www-data@...>
X-Flags: 0000
Delivered-To: GMX delivery to sebgerhardt@...
Received: (qmail invoked by alias); 10 Dec 2009 23:41:16 -0000
Received: from savannah.gnu.org (EHLO sv.gnu.org) [199.232.41.3] by
mx0.gmx.net (mx018) with SMTP; 11 Dec 2009 00:41:16 +0100
Received: from [10.1.0.103] (helo=savannah.gnu.org) by sv.gnu.org with
esmtp (Exim 4.69) (envelope-from <www-data@...>) id
1NIsdF-0001fi-PO for sebgerhardt@...; Thu, 10 Dec 2009 23:41:14 +0000
Received: from www-data by savannah.gnu.org with local (Exim 4.69)
(envelope-from <www-data@...>) id 1NIsdE-0001fW-TY for
sebgerhardt@...; Thu, 10 Dec 2009 23:41:13 +0000
To: Sebastian Gerhardt <sebgerhardt@...>
Subject: Problem with mailing list
From: Yury Chumak <sphynkx@...>
X-Savane-Server: savannah.gnu.org:443 [10.1.0.103]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.8.1.4)
Gecko/20070515 Firefox/2.0.0.4
X-Apparently-From: 195.114.130.50 (Savane authenticated user sphynkx)
Message-Id: <20091211-014112.sv76443.13443@...>
Date: Thu, 10 Dec 2009 23:41:12 +0000
X-GMX-Antivirus: 0 (no virus found)
X-GMX-Antispam: 0 (Mail was not recognized as spam);
Detail=5D7Q89H36p5Oer5+B3tmVeu8aLPbnNYCDdZvr3QhYWW5LmtOzhjncsYj1SH0pSmcZJyIO
eETbKqV6G1+qrXdoKjBWuKsYTFA5jBBBn3kfu92yPNv6FqO2fuHJp1pHZLEiSf8HcFWTgQrqQPHY
B9YuQ==V1;
X-GMX-UID: VMFHIfI1aHI+wrLkXyclCiVqamdhZMQL
Content-Transfer-Encoding: 7bit

Hello Sebasian!!
Sorry if not in address... but I wasn't found support address on site and my
message wasn't appear in savannah-users mailing list. And any answer I didn't
received also.
Would you suggest me where I could answer such problem or how to solve one??
Problem described below.
--8<----------------------
It was appeared problem with mailing list. Attempt to send message into just
created mailing list (ru-hurd-maillist@...) has failed and server
return message:

>A message that you sent could not be delivered to one or more of its
>recipients. This is a permanent error. The following address(es) failed:
>
> ru-hurd-maillist@...
> SMTP error from remote mailer after RCPT
TO:<ru-hurd-maillist@...>:
> host mx10.gnu.org [199.232.76.166]: 550 Previous (cached) callout
verification failure
>

Mailing list was created successfully, submission message was confirmed, and
me subscribed on my mail list successfully also.
Is the problem with misconfiguration of mail-list, or it is problem with
savanna-server, or your mail-server don't work with my one (smtp.mail.ru
94.100.177.1)??
-->8----------------------

wbr

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

----- End forwarded message -----

Re: [gnu.org #499737] Savannah backup strategy

2009-12-15T02:12:58Z

On Mon, Dec 14, 2009 at 02:08:27PM -0500, Daniel Clark via RT wrote:

> The first savannah-backup backup finished:
>
> Number of files: 2099942
> Number of files transferred: 1843832
> Total file size: 123259679448 bytes
> Total transferred file size: 122393771613 bytes
> Literal data: 122469455639 bytes
> Matched data: 0 bytes
> File list size: 47007178
> File list generation time: 628.366 seconds
> File list transfer time: 0.000 seconds
> Total bytes sent: 36165433
> Total bytes received: 122610448822
>
> sent 36165433 bytes received 122610448822 bytes 358676.13 bytes/sec
> total size is 123259679448 speedup is 1.00
> rsync warning: some files vanished before they could be transferred (code 24) at main.c(1524)
> [generator=3.0.4]
> rsync of savannah-backup.gnu.org finished at Sat Dec 12 10:53:15 EST 2009
>
> I've now enabled savannah-backup in cron, and disabled savannah.

Thanks!

I have 2 comments:

- Currently the first (local) backup is ran at noon (12:00) _GMT_ ,
and takes less than 2h to complete.

For your backup to be clean, is it possible to start it at 3PM GMT
(so that both backups don't run at once) ?

- I wonder what files were excluded (25K files / 8GB), since files are
normally already excluded with the first backup. Would it be
possible to give me a temporary access to your backup so I can
inspect it?

--
Sylvain

signature.asc (205 bytes) Download Attachment

Re: [Savannah-users] Suppress message

2009-12-13T14:10:19Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

November 13th 2009 for Ludovic None <zall996@...> thread
"Suppress message".

>How can I contatct him ?

I do not know, Savannah is not affiliated with The Mail Archive, read
their FAQ http://www.mail-archive.com/faq.html

PD: Please do not PM me, write CC to savannah-users or I will ignore
your messages.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAkslZC4ACgkQZ4DA0TLic4hVkgCfUpHi8UFdFyn6q+V1nX+HjPkK
pwgAmQH+5zfMsmx/I3c+GCSuB3DTxTb7
=pUGA
-----END PGP SIGNATURE-----

Re: [Savannah-users] Suppress message

2009-12-13T13:18:37Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

November 13th 2009 for Ludovic None <zall996@...> thread
"Suppress message".

Please, read carefully before respond silly things I alredy say you
that we do not control The Mail Archive:

>"The Mail Archive" do not belog to GNU project, we do not control
>it. Contact their webmaster.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAkslWA4ACgkQZ4DA0TLic4hQJwCcClco8lS3oLvUxvfMIzXVBmQI
ve0AnAxVh1cVrj91S7J06d+pBWjKTi6T
=kB4h
-----END PGP SIGNATURE-----

2009/12/13 Ludovic None <zall996@...>:

> could you at least change the name : ludovic bavay to lba for example ?
>
> thanks
>
> 2009/12/13 Mario Castelán Castro <mariocastelancastro@...>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> November 13th 2009 for Ludovic None <zall996@...> thread
>> "Suppress message".
>>
>> >Is it possible to suppress this message ? or at least suppress my
>> >name ?
>>
>> "The Mail Archive" do not belog to GNU project, we do not control
>> it. Contact their webmaster.
>>
>> If you mean to delete it from the mailbox of the subscribers of that
>> mailing list then it is not possible. The mailbox of the subscribers
>> belongs to the subscriber in question and we can't delete messages
>> from it. Even if we would can, we wouldn't do it, that is againsting
>> the privacity.
>>
>> Anyway I do not see reason for the deletion of the message.
>>
>> Never post something than in the future you may want to delete.
>>
>> Regards.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>>
>> iEYEAREIAAYFAkslPNwACgkQZ4DA0TLic4iVEQCfUlXTeqcxzqj50XWIbx7qHUIj
>> /zQAnRRrmlLOd7njss2gAN9cejsAY8Nr
>> =Alkp
>> -----END PGP SIGNATURE-----
>
>

Re: [Savannah-users] Suppress message

2009-12-13T11:22:40Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

November 13th 2009 for Ludovic None <zall996@...> thread
"Suppress message".

>Is it possible to suppress this message ? or at least suppress my
>name ?

"The Mail Archive" do not belog to GNU project, we do not control
it. Contact their webmaster.

If you mean to delete it from the mailbox of the subscribers of that
mailing list then it is not possible. The mailbox of the subscribers
belongs to the subscriber in question and we can't delete messages
from it. Even if we would can, we wouldn't do it, that is againsting
the privacity.

Anyway I do not see reason for the deletion of the message.

Never post something than in the future you may want to delete.

Regards.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAkslPNwACgkQZ4DA0TLic4iVEQCfUlXTeqcxzqj50XWIbx7qHUIj
/zQAnRRrmlLOd7njss2gAN9cejsAY8Nr
=Alkp
-----END PGP SIGNATURE-----

mirroring mailing list

2009-12-12T16:11:42Z

In case anyone here is interested.

Date: Fri, 11 Dec 2009 16:50:38 -0500
Subject: Invitation to mailing list about mirror issues
Requestors: poeml@...

Hi GNU web- (& mirror-) master,

may I invite you to join the mailing list discuss@...?
Sinceever I found that there is no common forum for mirror admins and
mirror infrastructure maintainers to discuss mirror issues on a
general level, I wish to establish such a place.

There are only the project-wide mirror lists - but none where
everybody is present. As a result, issues tend to be discussed only in
the respective "mirror communities"; for instance,
* there is an interesting discussion about a mirror hierarchy on the
CentOS mirror mailing list.
* Other example, on the OpenOffice mirror mailing list people discuss
about securing a mirror system.
* I currently would like to discuss the merits of mirror selection by
geographic coordinates.

All these topics would better fit in one shared forum where all the
folks are present. There are enough topics in that everybody is
interested I think. What do you think?

I think that the following subjects could be interesting:

* discuss mirror selection schemes so it fits users, mirrors, content
providers alike
* share hard-to-aquire insights about how the Internet works in
different parts of the world, and about network "anomalies" (e.g.
satellite links, or remote regions)
* discuss, enhance and fine-tune geolocation
* discuss new variants of geolocation, using IPv6 and 32-bit ASNs
* share the experience collected in implementing mirror infrastructures
* foster collaboration
* avoid duplication of efforts
* develop best practices for running mirrors: tuning servers as
download servers (high througput, large files) and how to limit abuse
(DoS protection)
* discuss how to best sync content out to a mirror hiearchy
* develop better load balancing and mirror monitoring
* coordinate release days to avoid spikes by conflicts
but there could be more.

The mirror admins already connect to many mirror communities through
their respective mailing lists, but that's distributed over a number
of mailing lists, and the mirror infrastructure maintainers don't
connect among themselves yet.

Now, it takes a bit to get this new community started: at first,
there's nobody... but, the list has 13 subscribers at the moment, and
you could be number 14 :-) I think, once more involved people are
there, there is a good chance that it becomes really interesting.

To subscribe, send a mail containing "subscribe discuss" in the body
to: majordomo@...
(There'll be an initial delay due to greylisting.)

Archive: http://mirrorbrain.org/archive/discuss/

The following link might or might work with your mail client:
mailto:majordomo@...?body=subscribe%20discuss

And if there's anyone else, feel free to share this mail. Also, feel
free to post it on your mirror mailing list!

Thank you!
Peter

[gnu.org #499737] Savannah backup strategy

2009-12-11T10:50:11Z

FYI the first savannah-backup.gnu.org backup is still plodding along (at about 500kb/sec).

BTW we were promised a donation of rack space and bandwidth by MIT CSAIL last week, so this should start
sucking substantially less sometime next year.

Re: [Savannah-users] Re: Hosting of FLOSS project that links against CUDA library

2009-12-10T12:54:05Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

December 10th 2009 in savannah-hackers-public@... thread "Hosting
of FLOSS project that links against CUDA library"

>Stallman could have said ``Let's cancel this whole GNU project,
>because we are relying on Unix, which is a proprietary back end, and
>better than anything we have.'' Or ``Let's put the all other
>development on the shelf until we have a satisfactory kernel.''

- From http://www.gnu.org/philosophy/categories.html:

[...] We felt justified in installing Unix on our computer in the
1980s, because we were using it to write a free replacement for
Unix. Nowadays, since free operating systems are available, the excuse
is no longer applicable; we have eliminated all our non-free operating
systems, and any new computer we install must run a completely free
operating system.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAkshXcsACgkQZ4DA0TLic4glrwCggJ0NuUVLcWC0RIF0bZ0hkwTJ
x7oAmwZY3O30io3UvOGRJwCySbJrdMIN
=pxpq
-----END PGP SIGNATURE-----

Re: Port of Linux is free?

2009-12-09T13:55:08Z

Let's ask Jesper on what is the intention and help us understand how
the Savannah account plans on being used.

SYSTEM_PROFILER is defined in arch/cris/Kconfig.debug . It seems
available for Linux Libre. Unless the project plans on hosting Linux
kernel code on Savannah, I do not think we have to press this issue.

A custom kernel could mean anything. Perhaps what the applicant means is
that you could customize it by building your own kernel. As far I see
all the needed code is available in the mainline kernel.

It says in the description that the program is supposed to work under
any operating system. How could that be?

Other than the ambiguous project description and that the Copyright
notices come after the license notices, I believe the project meets the
requirements. It should be noted that the project is actually GPL
version 3 or later.

--
Nicodemo

Re: Port of Linux is free?

2009-12-09T00:39:17Z

Regarding to the project description, it is
(SYSTEM_PROFILER=y).

But I have been mistaken in that this option is in the mainline kernel.
Instead you need to get a special flavour (port) or patch the kernel
sources first. Google for "Axis Communications CRIS ports" and you will
find the needed patches in case it is not hosted on kernel.org.

On Wed, 2009-12-09 at 02:18 +0100, Simone Azzalin wrote:
> I don't know wich is this special option... Can someone tell me what
> it is please?

Re: Documentating hosting requirements

2009-12-08T16:11:47Z

On Thu, 03 Dec 2009 19:46:55 +0100
Sebastian Gerhardt <sebgerhardt@...> wrote:

> I always thought of Free Software as a label, kind of a trademark.
> Therefore I personally will continue to capitalize it but I won't argue
> with native speakers about how the official Savannah spelling should
> be ;)

RMS talks about that in a similar way in that "open source" is
too general to be a trademark. The same can be applied to the free
software term. If you look at any page on gnu.org or fsf.org, you
rarely see it is capitalized.
http://www.gnu.org/philosophy/free-software-for-freedom.html

> > ===== NEWLY REVISED VERSION BELOW =======
> >
> > Please read these usage terms carefully. If you do not follow
> > these terms, we will not accept your project. If we do not have enough
> > information to determine whether your project follows these terms, we
> > will have to ask you to register the project again with more details.
>
> Do we actually do this? Usually we ask on the tracker to fix issues we
> point out (as written further below), and only demand registering again
> if the submission is really FUBAR.

I am having a hard time arguing against what you are saying. Sometimes I
really ought to ask for more description on what the project is for. I
have a tendency to forget. So would the below be more acceptable?

"Please, read these usage terms carefully. If you do not follow these
terms, we will not accept your project. If you unsure how to follow
these terms, the Savannah Administrators may help you along. It would
help if you write a 100 word description with the programming languages
required, URL links to your dependencies, and the license that they
use."

Should the above also include the requirements threshold, since it
seems to flow somewhat.

> > B. No dependencies on non-free software.
> > 5. It must deliver the full functionality and convienence on a fully
> > free platform and free operating system environment. REVISED
> "convenience"
Fixed.
> > C. No non-free formats REVISED
> > 1. Your project must not create formats that can only be used
> > with non-free software. REVISED
>
> This is a very strict requirement. I think this goes a bit too far.
> If a free software can write such a file, doesn't that usually mean
> this file can be used with free software as well?

In software, there is a whole world of strange possibilities that can
be used against free software. Even so, I think it would be okay to
leave it out.

> > D. Speaking about free software
> > 1. Clearly describe your project as free software. REVISED
>
> This will be a momentous requirement as well. The way I understand it,
> we then will require the explicit label "free software" on any project
> description page, rather than just, say, in the license header.

One thing that strikes me, is that some people will leave out calling
their project open source in registration and then after approval call
it open source in their project description. Do you think it would it be
any better to say "You may describe your project as free software."?
Do you think the administrator should be advised to follow up and ask
them to revise their description?

> > E. Free software, documentation, and supporting file licenses REVISED
> > 1. All files must have a free license. Choose a standard, free license.
> > NEW (4)
>
> This paragraph is fine. But as this is one of the points that get
> missed, it should be moved up. To be A or B if you ask me ;)

I agree. How about this order?

Free software, documentation, and supporting file licenses
Applying the licenses
Speaking about free software
No dependencies on non-free software
No non-free formats
Use of project account
Advertisements
NonGNU and GNU Hosting
Requirements threshold
Why the legal checks
Helpful resources

> > I. Why the legal checks before approval? NEW (2)
>
> *nitpicking*
> This is no requirement but additional information, therefore it should
> not be enumerated the same way as the above.

Do you think this info would be better at the beginning as well? Does
this section really mean a tarball submitted through project
registration is not for public use? It seems to generalize tarballs are
not accessible to the public. I did not write it, so I am not quite
sure what to make out of it.

--
Nicodemo

Re: [simon@josefsson.org: [SCM] GNU Inetutils branch, master, updated. inetutils-1_6-127-gb68da88]

2009-12-08T15:11:40Z

On Tue, Dec 08, 2009 at 09:28:06AM -0500, Alfred M. Szmidt wrote:
> 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?

There.

--
Sylvain

[core]
repositoryformatversion = 0
filemode = true
bare = true
#logallrefupdates = true
sharedrepository = 1
[receive]
denyNonFastforwards = true
denyCurrentBranch = true
[hooks "denymerge"]
master = true
[hooks]
mailinglist = commit-inetutils@...
showrev = "t=%s; echo http://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=$t; echo; echo; git show -C $t; echo"
allowdeletebranch = true

#!/bin/sh
#
# Copyright (c) 2007 Andy Parkins
#
# An example hook script to mail out commit update information. This hook
# sends emails listing new revisions to the repository introduced by the
# change being reported. The rule is that (for branch updates) each commit
# will appear on one email and one email only.
#
# This hook is stored in the contrib/hooks directory. Your distribution
# will have put this somewhere standard. You should make this script
# executable then link to it in the repository you would like to use it in.
# For example, on debian the hook is stored in
# /usr/share/doc/git-core/contrib/hooks/post-receive-email:
#
# chmod a+x post-receive-email
# cd /path/to/your/repository.git
# ln -sf /usr/share/doc/git-core/contrib/hooks/post-receive-email hooks/post-receive
#
# This hook script assumes it is enabled on the central repository of a
# project, with all users pushing only to it and not between each other. It
# will still work if you don't operate in that style, but it would become
# possible for the email to be from someone other than the person doing the
# push.
#
# Config
# ------
# hooks.mailinglist
# This is the list that all pushes will go to; leave it blank to not send
# emails for every ref update.
# hooks.announcelist
# This is the list that all pushes of annotated tags will go to. Leave it
# blank to default to the mailinglist field. The announce emails lists
# the short log summary of the changes since the last annotated tag.
# hooks.envelopesender
# If set then the -f option is passed to sendmail to allow the envelope
# sender address to be set
# hooks.emailprefix
# All emails have their subjects prefixed with this prefix, or "[SCM]"
# if emailprefix is unset, to aid filtering
# hooks.showrev
# The shell command used to format each revision in the email, with
# "%s" replaced with the commit id. Defaults to "git rev-list -1
# --pretty %s", displaying the commit id, author, date and log
# message. To list full patches separated by a blank line, you
# could set this to "git show -C %s; echo".
# To list a gitweb/cgit URL *and* a full patch for each change set, use this:
# "t=%s; printf 'http://.../?id=%%s' \$t; echo;echo; git show -C \$t; echo"
# Be careful if "..." contains things that will be expanded by shell "eval"
# or printf.
#
# Notes
# -----
# All emails include the headers "X-Git-Refname", "X-Git-Oldrev",
# "X-Git-Newrev", and "X-Git-Reftype" to enable fine tuned filtering and
# give information for debugging.
#

# ---------------------------- Functions

#
# Top level email generation function. This decides what type of update
# this is and calls the appropriate body-generation routine after outputting
# the common header
#
# Note this function doesn't actually generate any email output, that is
# taken care of by the functions it calls:
# - generate_email_header
# - generate_create_XXXX_email
# - generate_update_XXXX_email
# - generate_delete_XXXX_email
# - generate_email_footer
#
generate_email()
{
# --- Arguments
oldrev=$(git rev-parse $1)
newrev=$(git rev-parse $2)
refname="$3"

# --- Interpret
# 0000->1234 (create)
# 1234->2345 (update)
# 2345->0000 (delete)
if expr "$oldrev" : '0*$' >/dev/null
then
change_type="create"
else
if expr "$newrev" : '0*$' >/dev/null
then
change_type="delete"
else
change_type="update"
fi
fi

# --- Get the revision types
newrev_type=$(git cat-file -t $newrev 2> /dev/null)
oldrev_type=$(git cat-file -t "$oldrev" 2> /dev/null)
case "$change_type" in
create|update)
rev="$newrev"
rev_type="$newrev_type"
;;
delete)
rev="$oldrev"
rev_type="$oldrev_type"
;;
esac

# The revision type tells us what type the commit is, combined with
# the location of the ref we can decide between
# - working branch
# - tracking branch
# - unannoted tag
# - annotated tag
case "$refname","$rev_type" in
refs/tags/*,commit)
# un-annotated tag
refname_type="tag"
short_refname=${refname##refs/tags/}
;;
refs/tags/*,tag)
# annotated tag
refname_type="annotated tag"
short_refname=${refname##refs/tags/}
# change recipients
if [ -n "$announcerecipients" ]; then
recipients="$announcerecipients"
fi
;;
refs/heads/*,commit)
# branch
refname_type="branch"
short_refname=${refname##refs/heads/}
;;
refs/remotes/*,commit)
# tracking branch
refname_type="tracking branch"
short_refname=${refname##refs/remotes/}
echo >&2 "*** Push-update of tracking branch, $refname"
echo >&2 "*** - no email generated."
exit 0
;;
*)
# Anything else (is there anything else?)
echo >&2 "*** Unknown type of update to $refname ($rev_type)"
echo >&2 "*** - no email generated"
exit 1
;;
esac

# Check if we've got anyone to send to
if [ -z "$recipients" ]; then
case "$refname_type" in
"annotated tag")
config_name="hooks.announcelist"
;;
*)
config_name="hooks.mailinglist"
;;
esac
echo >&2 "*** $config_name is not set so no email will be sent"
echo >&2 "*** for $refname update $oldrev->$newrev"
exit 0
fi

# Email parameters
# The email subject will contain the best description of the ref
# that we can build from the parameters
describe=$(git describe $rev 2>/dev/null)
if [ -z "$describe" ]; then
describe=$rev
fi

generate_email_header

# Call the correct body generation function
fn_name=general
case "$refname_type" in
"tracking branch"|branch)
fn_name=branch
;;
"annotated tag")
fn_name=atag
;;
esac
generate_${change_type}_${fn_name}_email

generate_email_footer
}

generate_email_header()
{
# --- Email (all stdout will be the email)
# Generate header
cat <<-EOF
To: $recipients
Subject: ${emailprefix}$projectdesc $refname_type, $short_refname, ${change_type}d. $describe
X-Git-Refname: $refname
X-Git-Reftype: $refname_type
X-Git-Oldrev: $oldrev
X-Git-Newrev: $newrev

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 "$projectdesc".

The $refname_type, $short_refname has been ${change_type}d
EOF
}

generate_email_footer()
{
SPACE=" "
cat <<-EOF

hooks/post-receive
--${SPACE}
$projectdesc
EOF
}

# --------------- Branches

#
# Called for the creation of a branch
#
generate_create_branch_email()
{
# This is a new branch and so oldrev is not valid
echo " at $newrev ($newrev_type)"
echo ""

echo $LOGBEGIN
show_new_revisions
echo $LOGEND
}

#
# Called for the change of a pre-existing branch
#
generate_update_branch_email()
{
# Consider this:
# 1 --- 2 --- O --- X --- 3 --- 4 --- N
#
# O is $oldrev for $refname
# N is $newrev for $refname
# X is a revision pointed to by some other ref, for which we may
# assume that an email has already been generated.
# In this case we want to issue an email containing only revisions
# 3, 4, and N. Given (almost) by
#
# git rev-list N ^O --not --all
#
# The reason for the "almost", is that the "--not --all" will take
# precedence over the "N", and effectively will translate to
#
# git rev-list N ^O ^X ^N
#
# So, we need to build up the list more carefully. git rev-parse
# will generate a list of revs that may be fed into git rev-list.
# We can get it to make the "--not --all" part and then filter out
# the "^N" with:
#
# git rev-parse --not --all | grep -v N
#
# Then, using the --stdin switch to git rev-list we have effectively
# manufactured
#
# git rev-list N ^O ^X
#
# This leaves a problem when someone else updates the repository
# while this script is running. Their new value of the ref we're
# working on would be included in the "--not --all" output; and as
# our $newrev would be an ancestor of that commit, it would exclude
# all of our commits. What we really want is to exclude the current
# value of $refname from the --not list, rather than N itself. So:
#
# git rev-parse --not --all | grep -v $(git rev-parse $refname)
#
# Get's us to something pretty safe (apart from the small time
# between refname being read, and git rev-parse running - for that,
# I give up)
#
#
# Next problem, consider this:
# * --- B --- * --- O ($oldrev)
# \
# * --- X --- * --- N ($newrev)
#
# That is to say, there is no guarantee that oldrev is a strict
# subset of newrev (it would have required a --force, but that's
# allowed). So, we can't simply say rev-list $oldrev..$newrev.
# Instead we find the common base of the two revs and list from
# there.
#
# As above, we need to take into account the presence of X; if
# another branch is already in the repository and points at some of
# the revisions that we are about to output - we don't want them.
# The solution is as before: git rev-parse output filtered.
#
# Finally, tags: 1 --- 2 --- O --- T --- 3 --- 4 --- N
#
# Tags pushed into the repository generate nice shortlog emails that
# summarise the commits between them and the previous tag. However,
# those emails don't include the full commit messages that we output
# for a branch update. Therefore we still want to output revisions
# that have been output on a tag email.
#
# Luckily, git rev-parse includes just the tool. Instead of using
# "--all" we use "--branches"; this has the added benefit that
# "remotes/" will be ignored as well.

# List all of the revisions that were removed by this update, in a
# fast forward update, this list will be empty, because rev-list O
# ^N is empty. For a non fast forward, O ^N is the list of removed
# revisions
fast_forward=""
rev=""
for rev in $(git rev-list $newrev..$oldrev)
do
revtype=$(git cat-file -t "$rev")
echo " discards $rev ($revtype)"
done
if [ -z "$rev" ]; then
fast_forward=1
fi

# List all the revisions from baserev to newrev in a kind of
# "table-of-contents"; note this list can include revisions that
# have already had notification emails and is present to show the
# full detail of the change from rolling back the old revision to
# the base revision and then forward to the new revision
for rev in $(git rev-list $oldrev..$newrev)
do
revtype=$(git cat-file -t "$rev")
echo " via $rev ($revtype)"
done

if [ "$fast_forward" ]; then
echo " from $oldrev ($oldrev_type)"
else
# 1. Existing revisions were removed. In this case newrev
# is a subset of oldrev - this is the reverse of a
# fast-forward, a rewind
# 2. New revisions were added on top of an old revision,
# this is a rewind and addition.

# (1) certainly happened, (2) possibly. When (2) hasn't
# happened, we set a flag to indicate that no log printout
# is required.

echo ""

# Find the common ancestor of the old and new revisions and
# compare it with newrev
baserev=$(git merge-base $oldrev $newrev)
rewind_only=""
if [ "$baserev" = "$newrev" ]; then
echo "This update discarded existing revisions and left the branch pointing at"
echo "a previous point in the repository history."
echo ""
echo " * -- * -- N ($newrev)"
echo " \\"
echo " O -- O -- O ($oldrev)"
echo ""
echo "The removed revisions are not necessarilly gone - if another reference"
echo "still refers to them they will stay in the repository."
rewind_only=1
else
echo "This update added new revisions after undoing existing revisions. That is"
echo "to say, the old revision is not a strict subset of the new revision. This"
echo "situation occurs when you --force push a change and generate a repository"
echo "containing something like this:"
echo ""
echo " * -- * -- B -- O -- O -- O ($oldrev)"
echo " \\"
echo " N -- N -- N ($newrev)"
echo ""
echo "When this happens we assume that you've already had alert emails for all"
echo "of the O revisions, and so we here report only the revisions in the N"
echo "branch from the common base, B."
fi
fi

echo ""
if [ -z "$rewind_only" ]; then
echo "Those revisions listed above that are new to this repository have"
echo "not appeared on any other notification email; so we list those"
echo "revisions in full, below."

echo ""
echo $LOGBEGIN
show_new_revisions

# XXX: Need a way of detecting whether git rev-list actually
# outputted anything, so that we can issue a "no new
# revisions added by this update" message

echo $LOGEND
else
echo "No new revisions were added by this update."
fi

# The diffstat is shown from the old revision to the new revision.
# This is to show the truth of what happened in this change.
# There's no point showing the stat from the base to the new
# revision because the base is effectively a random revision at this
# point - the user will be interested in what this revision changed
# - including the undoing of previous revisions in the case of
# non-fast forward updates.
echo ""
echo "Summary of changes:"
git diff-tree --stat --summary --find-copies-harder $oldrev..$newrev
}

#
# Called for the deletion of a branch
#
generate_delete_branch_email()
{
echo " was $oldrev"
echo ""
echo $LOGEND
git show -s --pretty=oneline $oldrev
echo $LOGEND
}

# --------------- Annotated tags

#
# Called for the creation of an annotated tag
#
generate_create_atag_email()
{
echo " at $newrev ($newrev_type)"

generate_atag_email
}

#
# Called for the update of an annotated tag (this is probably a rare event
# and may not even be allowed)
#
generate_update_atag_email()
{
echo " to $newrev ($newrev_type)"
echo " from $oldrev (which is now obsolete)"

generate_atag_email
}

#
# Called when an annotated tag is created or changed
#
generate_atag_email()
{
# Use git for-each-ref to pull out the individual fields from the
# tag
eval $(git for-each-ref --shell --format='
tagobject=%(*objectname)
tagtype=%(*objecttype)
tagger=%(taggername)
tagged=%(taggerdate)' $refname
)

echo " tagging $tagobject ($tagtype)"
case "$tagtype" in
commit)

# If the tagged object is a commit, then we assume this is a
# release, and so we calculate which tag this tag is
# replacing
prevtag=$(git describe --abbrev=0 $newrev^ 2>/dev/null)

if [ -n "$prevtag" ]; then
echo " replaces $prevtag"
fi
;;
*)
echo " length $(git cat-file -s $tagobject) bytes"
;;
esac
echo " tagged by $tagger"
echo " on $tagged"

echo ""
echo $LOGBEGIN

# Show the content of the tag message; this might contain a change
# log or release notes so is worth displaying.
git cat-file tag $newrev | sed -e '1,/^$/d'

echo ""
case "$tagtype" in
commit)
# Only commit tags make sense to have rev-list operations
# performed on them
if [ -n "$prevtag" ]; then
# Show changes since the previous release
git rev-list --pretty=short "$prevtag..$newrev" | git shortlog
else
# No previous tag, show all the changes since time
# began
git rev-list --pretty=short $newrev | git shortlog
fi
;;
*)
# XXX: Is there anything useful we can do for non-commit
# objects?
;;
esac

echo $LOGEND
}

#
# Called for the deletion of an annotated tag
#
generate_delete_atag_email()
{
echo " was $oldrev"
echo ""
echo $LOGEND
git show -s --pretty=oneline $oldrev
echo $LOGEND
}

# --------------- General references

#
# Called when any other type of reference is created (most likely a
# non-annotated tag)
#
generate_create_general_email()
{
echo " at $newrev ($newrev_type)"

generate_general_email
}

#
# Called when any other type of reference is updated (most likely a
# non-annotated tag)
#
generate_update_general_email()
{
echo " to $newrev ($newrev_type)"
echo " from $oldrev"

generate_general_email
}

#
# Called for creation or update of any other type of reference
#
generate_general_email()
{
# Unannotated tags are more about marking a point than releasing a
# version; therefore we don't do the shortlog summary that we do for
# annotated tags above - we simply show that the point has been
# marked, and print the log message for the marked point for
# reference purposes
#
# Note this section also catches any other reference type (although
# there aren't any) and deals with them in the same way.

echo ""
if [ "$newrev_type" = "commit" ]; then
echo $LOGBEGIN
git show --no-color --root -s --pretty=medium $newrev
echo $LOGEND
else
# What can we do here? The tag marks an object that is not
# a commit, so there is no log for us to display. It's
# probably not wise to output git cat-file as it could be a
# binary blob. We'll just say how big it is
echo "$newrev is a $newrev_type, and is $(git cat-file -s $newrev) bytes long."
fi
}

#
# Called for the deletion of any other type of reference
#
generate_delete_general_email()
{
echo " was $oldrev"
echo ""
echo $LOGEND
git show -s --pretty=oneline $oldrev
echo $LOGEND
}

# --------------- Miscellaneous utilities

#
# Show new revisions as the user would like to see them in the email.
#
show_new_revisions()
{
# This shows all log entries that are not already covered by
# another ref - i.e. commits that are now accessible from this
# ref that were previously not accessible
# (see generate_update_branch_email for the explanation of this
# command)

# Revision range passed to rev-list differs for new vs. updated
# branches.
if [ "$change_type" = create ]
then
# Show all revisions exclusive to this (new) branch.
revspec=$newrev
else
# Branch update; show revisions not part of $oldrev.
revspec=$oldrev..$newrev
fi

other_branches=$(git for-each-ref --format='%(refname)' refs/heads/ |
grep -F -v $refname)
git rev-parse --not $other_branches |
if [ -z "$custom_showrev" ]
then
git rev-list --pretty --stdin $revspec
else
git rev-list --stdin $revspec |
while read onerev
do
eval $(printf "$custom_showrev" $onerev)
done
fi
}

send_mail()
{
if [ -n "$envelopesender" ]; then
/usr/sbin/sendmail -t -f "$envelopesender"
else
/usr/sbin/sendmail -t
fi
}

# ---------------------------- main()

# --- Constants
LOGBEGIN="- Log -----------------------------------------------------------------"
LOGEND="-----------------------------------------------------------------------"

# --- Config
# Set GIT_DIR either from the working directory, or from the environment
# variable.
GIT_DIR=$(git rev-parse --git-dir 2>/dev/null)
if [ -z "$GIT_DIR" ]; then
echo >&2 "fatal: post-receive: GIT_DIR not set"
exit 1
fi

projectdesc=$(sed -ne '1p' "$GIT_DIR/description")
# Check if the description is unchanged from it's default, and shorten it to
# a more manageable length if it is
if expr "$projectdesc" : "Unnamed repository.*$" >/dev/null
then
projectdesc="UNNAMED PROJECT"
fi

recipients=$(git config hooks.mailinglist)
announcerecipients=$(git config hooks.announcelist)
envelopesender=$(git config hooks.envelopesender)
emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
custom_showrev=$(git config hooks.showrev)

# --- Main loop
# Allow dual mode: run from the command line just like the update hook, or
# if no arguments are given then run as a hook script
if [ -n "$1" -a -n "$2" -a -n "$3" ]; then
# Output to the terminal in command line mode - if someone wanted to
# resend an email; they could redirect the output to sendmail
# themselves
PAGER= generate_email $2 $3 $1
else
while read oldrev newrev refname
do
generate_email $oldrev $newrev $refname | send_mail
done
fi

Talk at FOSDEM

2009-12-08T14:45:26Z

Hi,

I just applied to give a "lightning" (15mn) talk at FOSDEM 2010
(Brussels).

We should know if it's accepted within a week :)

--
Sylvain

Re: Port of Linux is free?

2009-12-08T13:04:39Z

Hi,

as far as I understand this, he means that the kernel has to be compiled
with a special option activated. He is only aware of one distributor who
ships a kernel which is configured with this option per default.

But every decent GNU/Linux distribution, including GnuSense, gives you
the means to compile your own kernel with this option. So in my opinion,
there is no problem here.

If he plans to distribute kernel patches from Savannah, we need to pay
attention whether they have the "any later clause", as this is often
forgotten when people write stuff for the GPLv2 only Linux.

On Mon, 2009-12-07 at 17:35 -0600, Mario Castelán Castro wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> December 7th 2009 for savannah-hackers-public thread "Port of Linux is
> free?"
>
> This proyect https://savannah.gnu.org/task/index.php?9952 says to use
> "a specially modified Linux kernel" wich is "exist only for the Axis
> Communications CRIS ports of Linux in the mainline version of the
> Linux kernel."
>
> AFIK Linux contains propietary blobs but I are unsure if this specific
> port have blobs. If someone knows please tellme so I can begin to
> evaluate the project.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEAREIAAYFAksdkSgACgkQZ4DA0TLic4iONQCcCNDZtkDwU8mQ+mUpo22hM103
> lfoAniqEVD9zhLD7RlKDkwRMJN/qT1tl
> =epJl
> -----END PGP SIGNATURE-----
>

Re: [simon@josefsson.org: [SCM] GNU Inetutils branch, master, updated. inetutils-1_6-127-gb68da88]

2009-12-08T06:28:06Z

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?

Re: inetutils: accidental push of branch

2009-12-08T02:45:00Z

> 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: OpenVPN link to chapters.gnu.org

2009-12-08T01:23:13Z

Sylvain Beucler wrote:

> Hi Nacho,
>
> Can you check the OpenVPN link between Savannah and Chapters?
>
> colonialone:~# ping chapters.in.savannah.gnu.org
> PING chapters.in.savannah.gnu.org (10.1.0.201) 56(84) bytes of data.
> >From 10.1.0.1 icmp_seq=1 Destination Host Unreachable
> >From 10.1.0.1 icmp_seq=2 Destination Host Unreachable
> >From 10.1.0.1 icmp_seq=3 Destination Host Unreachable
> >From 10.1.0.1 icmp_seq=4 Destination Host Unreachable
> >From 10.1.0.1 icmp_seq=5 Destination Host Unreachable
>
> You still can send me your public key to get access to Savannah btw.
>

Hi,

Sorry friday the GNUchapters server crashed and I've found some troubles
on the restart, I will take a look today at about this VPN and I will
try to reopen it again.

Best regards,
Nacho.

Port of Linux is free?

2009-12-07T15:35:54Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

December 7th 2009 for savannah-hackers-public thread "Port of Linux is
free?"

This proyect https://savannah.gnu.org/task/index.php?9952 says to use
"a specially modified Linux kernel" wich is "exist only for the Axis
Communications CRIS ports of Linux in the mainline version of the
Linux kernel."

AFIK Linux contains propietary blobs but I are unsure if this specific
port have blobs. If someone knows please tellme so I can begin to
evaluate the project.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAksdkSgACgkQZ4DA0TLic4iONQCcCNDZtkDwU8mQ+mUpo22hM103
lfoAniqEVD9zhLD7RlKDkwRMJN/qT1tl
=epJl
-----END PGP SIGNATURE-----

Re: inetutils: accidental push of branch

2009-12-07T05:49:29Z

Jim Meyering <jim@...> ha escrit:

> 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.

Regards,
Sergey

Re: inetutils: accidental push of branch

2009-12-07T05:22:02Z

Sylvain Beucler wrote:

> On Mon, Dec 07, 2009 at 01:57:06PM +0100, Jim Meyering wrote:
>> Sylvain Beucler wrote:
>> > On Mon, Dec 07, 2009 at 05:55:05AM -0500, Alfred M. Szmidt wrote:
>> >> On Sat, Dec 05, 2009 at 05:43:36AM -0500, Alfred M. Szmidt wrote:
>> >> > Could someone remove the ams branch in inetutils? I pushed it by
>> >> > accident, and it seems that I cannot remove.
>> >>
>> >> This section is dedicated to you:
>> >> http://savannah.gnu.org/maintenance/UsingGit#removing-a-branch
>> >>
>> >> $ git push origin :ams
>> >> *** Deleting a branch is not allowed in this repository
>> >> error: hooks/update exited with error code 1
>> >> error: hook declined to update refs/heads/ams
>> >>
>> >> So that section is of no help to me.
>> >
>> > Jim, do you know what is inetutils' "update" hook?
>>
>> Hi Sylvain,
>>
>> 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
>>
>> There are comments in hooks/update that describe this
>> and the other config-controlled options.
>
> Yes but we don't use it by default - I suppose that you installed it
> as part of the migration to Git.

Yes, it was on request.

> What was its purpose - so we know what we should or should not modify
> (or disable it entirely)?

Part of its goal is to prohibit pushing merge commits:

# hooks.denymerge.BRANCH_NAME
# When this boolean is true, you may not push a merge commit to BRANCH_NAME.
# By default, you may.

That is currently enabled via this config setting:

hooks.denymerge.master=true

Re: inetutils: accidental push of branch

2009-12-07T05:07:43Z

On Mon, Dec 07, 2009 at 01:57:06PM +0100, Jim Meyering wrote:

> Sylvain Beucler wrote:
> > On Mon, Dec 07, 2009 at 05:55:05AM -0500, Alfred M. Szmidt wrote:
> >> On Sat, Dec 05, 2009 at 05:43:36AM -0500, Alfred M. Szmidt wrote:
> >> > Could someone remove the ams branch in inetutils? I pushed it by
> >> > accident, and it seems that I cannot remove.
> >>
> >> This section is dedicated to you:
> >> http://savannah.gnu.org/maintenance/UsingGit#removing-a-branch
> >>
> >> $ git push origin :ams
> >> *** Deleting a branch is not allowed in this repository
> >> error: hooks/update exited with error code 1
> >> error: hook declined to update refs/heads/ams
> >>
> >> So that section is of no help to me.
> >
> > Jim, do you know what is inetutils' "update" hook?
>
> Hi Sylvain,
>
> 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
>
> There are comments in hooks/update that describe this
> and the other config-controlled options.

Yes but we don't use it by default - I suppose that you installed it
as part of the migration to Git.

What was its purpose - so we know what we should or should not modify
(or disable it entirely)?

--
Sylvain

Re: [simon@josefsson.org: [SCM] GNU Inetutils branch, master, updated. inetutils-1_6-127-gb68da88]

2009-12-07T05:06:29Z

Hi,

We're using contrib/hooks/post-receive-email from the Git release.
I would suggest sending patches to the Git project.

--
Sylvain

On Mon, Dec 07, 2009 at 06:00:07AM -0500, Alfred M. Szmidt wrote:

> 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-inetutils@...
> From: Simon Josefsson <simon@...>
> Date: Mon, 07 Dec 2009 10:45:59 +0000
> 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 <simon@...>
> 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 <simon@...>
> +
> + * 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 <gscrivano@...>
>
> * 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 0000000..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 0000000..1abcd29
> - --- /dev/null
> +++ b/man/telnet.x
> @@ -0,0 +1,4 @@
> +[NAME]
> +telnet \- User interface to TELNET
> +[SEE ALSO]
> +telnetd(1)
> diff --git a/man/telnetd.x b/man/telnetd.x
> new file mode 100644
> index 0000000..d9ead50
> - --- /dev/null
> +++ b/man/telnetd.x
> @@ -0,0 +1,4 @@
> +[NAME]
> +telnetd \- Telnet server
> +[SEE ALSO]
> +telnet(1)
>
> - -----------------------------------------------------------------------
>
> Summary of changes:
> ChangeLog | 8 ++++++++
> Makefile.am | 2 +-
> configure.ac | 2 ++
> {rexec => man}/Makefile.am | 27 ++++++++++++++++-----------
> man/rshd.x | 4 ++++
> man/telnet.x | 4 ++++
> man/telnetd.x | 4 ++++
> 7 files changed, 39 insertions(+), 12 deletions(-)
> copy {rexec => man}/Makefile.am (53%)
> create mode 100644 man/rshd.x
> create mode 100644 man/telnet.x
> create mode 100644 man/telnetd.x
>
>
> hooks/post-receive
> - --
> GNU Inetutils
>
>
> _______________________________________________
> Commit-inetutils mailing list
> Commit-inetutils@...
> http://lists.gnu.org/mailman/listinfo/commit-inetutils
> ------- End of forwarded message -------
>

Re: inetutils: accidental push of branch

2009-12-07T04:57:06Z

Sylvain Beucler wrote:

> On Mon, Dec 07, 2009 at 05:55:05AM -0500, Alfred M. Szmidt wrote:
>> On Sat, Dec 05, 2009 at 05:43:36AM -0500, Alfred M. Szmidt wrote:
>> > Could someone remove the ams branch in inetutils? I pushed it by
>> > accident, and it seems that I cannot remove.
>>
>> This section is dedicated to you:
>> http://savannah.gnu.org/maintenance/UsingGit#removing-a-branch
>>
>> $ git push origin :ams
>> *** Deleting a branch is not allowed in this repository
>> error: hooks/update exited with error code 1
>> error: hook declined to update refs/heads/ams
>>
>> So that section is of no help to me.
>
> Jim, do you know what is inetutils' "update" hook?

Hi Sylvain,

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

There are comments in hooks/update that describe this
and the other config-controlled options.

Re: inetutils: accidental push of branch

2009-12-07T04:52:56Z

On Mon, Dec 07, 2009 at 05:55:05AM -0500, Alfred M. Szmidt wrote:

> On Sat, Dec 05, 2009 at 05:43:36AM -0500, Alfred M. Szmidt wrote:
> > Could someone remove the ams branch in inetutils? I pushed it by
> > accident, and it seems that I cannot remove.
>
> This section is dedicated to you:
> http://savannah.gnu.org/maintenance/UsingGit#removing-a-branch
>
> $ git push origin :ams
> *** Deleting a branch is not allowed in this repository
> error: hooks/update exited with error code 1
> error: hook declined to update refs/heads/ams
>
> So that section is of no help to me.

Jim, do you know what is inetutils' "update" hook?

--
Sylvain

[simon@josefsson.org: [SCM] GNU Inetutils branch, master, updated. inetutils-1_6-127-gb68da88]

2009-12-07T03:00:07Z

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-inetutils@...
From: Simon Josefsson <simon@...>
Date: Mon, 07 Dec 2009 10:45:59 +0000
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 <simon@...>
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 <simon@...>
+
+ * 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 <gscrivano@...>

* 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 0000000..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 0000000..1abcd29
- --- /dev/null
+++ b/man/telnet.x
@@ -0,0 +1,4 @@
+[NAME]
+telnet \- User interface to TELNET
+[SEE ALSO]
+telnetd(1)
diff --git a/man/telnetd.x b/man/telnetd.x
new file mode 100644
index 0000000..d9ead50
- --- /dev/null
+++ b/man/telnetd.x
@@ -0,0 +1,4 @@
+[NAME]
+telnetd \- Telnet server
+[SEE ALSO]
+telnet(1)

- -----------------------------------------------------------------------

Summary of changes:
ChangeLog | 8 ++++++++
Makefile.am | 2 +-
configure.ac | 2 ++
{rexec => man}/Makefile.am | 27 ++++++++++++++++-----------
man/rshd.x | 4 ++++
man/telnet.x | 4 ++++
man/telnetd.x | 4 ++++
7 files changed, 39 insertions(+), 12 deletions(-)
copy {rexec => man}/Makefile.am (53%)
create mode 100644 man/rshd.x
create mode 100644 man/telnet.x
create mode 100644 man/telnetd.x

hooks/post-receive
- --
GNU Inetutils

_______________________________________________
Commit-inetutils mailing list
Commit-inetutils@...
http://lists.gnu.org/mailman/listinfo/commit-inetutils
------- End of forwarded message -------

Re: inetutils: accidental push of branch

2009-12-07T02:55:05Z

On Sat, Dec 05, 2009 at 05:43:36AM -0500, Alfred M. Szmidt wrote:
> Could someone remove the ams branch in inetutils? I pushed it by
> accident, and it seems that I cannot remove.

This section is dedicated to you:
http://savannah.gnu.org/maintenance/UsingGit#removing-a-branch

$ git push origin :ams
*** Deleting a branch is not allowed in this repository
error: hooks/update exited with error code 1
error: hook declined to update refs/heads/ams

So that section is of no help to me.

OpenVPN link to chapters.gnu.org

2009-12-06T13:39:13Z

Hi Nacho,

Can you check the OpenVPN link between Savannah and Chapters?

colonialone:~# ping chapters.in.savannah.gnu.org
PING chapters.in.savannah.gnu.org (10.1.0.201) 56(84) bytes of data.
From 10.1.0.1 icmp_seq=1 Destination Host Unreachable
From 10.1.0.1 icmp_seq=2 Destination Host Unreachable
From 10.1.0.1 icmp_seq=3 Destination Host Unreachable
From 10.1.0.1 icmp_seq=4 Destination Host Unreachable
From 10.1.0.1 icmp_seq=5 Destination Host Unreachable

You still can send me your public key to get access to Savannah btw.

--
Sylvain

Re: inetutils: accidental push of branch

2009-12-06T11:18:15Z

Re: CVS errors on commit for sourceinstall

2009-12-06T08:59:19Z

Hi,

On Sun, Dec 06, 2009 at 04:46:14PM +0100, Claudio Fontana wrote:

> Hello Sylvain,
>
> I am checking in some changes to the sourceinstall CVS after many years.
> Maybe something changed that I am not aware of?
>
> For each and every file I commit, I receive this warning:
>
> cvs commit: warning: cannot open history file
> `/sources/sourceinstall/CVSROOT/history' for write: Permission
> denied
>
> Should I worry? Is there something to fix/do?
>
> Ciao & thanks,
>
> Claudio

There was a bad group ownership on some files (CVSROOT/history,
CVSROOT/val-tags, source-install/) - maybe we forgot to do something
when importing the project.

I fixed the group ownership to 'sourceinstall'.

--
Sylvain

inetutils: accidental push of branch

2009-12-05T02:43:36Z

Could someone remove the ams branch in inetutils? I pushed it by
accident, and it seems that I cannot remove.

Re: Auto generated files

2009-12-04T14:28:19Z

I think it's licenSing@...

We did receive Mario's question on licensing@... aka
licensing@..., so I guess there is an alias somewhere.

And I am about to send him the same reply I already posted here :).

Re: Auto generated files

2009-12-04T12:03:39Z

On Fri, Dec 04, 2009 at 01:57:42PM -0600, Mario Castelán Castro wrote:
> True, but it is @fsf.org, I send the message to licensing@... and
> write "licencing" in the body, was a typography mistrake, thanks for
> correction.

For the record, licensing@... is an alias to @fsf.org :)

--
Sylvain

Re: Auto generated files

2009-12-04T11:57:42Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

November 4th 2009 for Sylvain Beucler <beuc@...>

True, but it is @fsf.org, I send the message to licensing@... and
write "licencing" in the body, was a typography mistrake, thanks for
correction.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAksZaaIACgkQZ4DA0TLic4gxcACeMlpvxMiSHGqQFQtAv6ySxTn0
h9MAoI2pImRS69eNoZkOqgP8lzqwg8oz
=FGnw
-----END PGP SIGNATURE-----

Re: Auto generated files

2009-12-04T11:48:29Z

Hi,

On Fri, Dec 04, 2009 at 01:17:24PM -0600, Mario Castelán Castro wrote:
> November 4th 2009 for savannah-hackers-public@...,
> licencing@...

I think it's licenSing@...

--
Sylvain