git tag in localversion

git tag in localversion

[Andrea Arcangeli]

Hello,

The patch that adds the git tag in the localversion is screwing klive a
bit, see the 2.6.13-g* entries in
http://klive.cpushare.com/?branch=unknown

Those are supposed to go in the homepage but they're not recognized
anymore due the git tag and so they go in the unknown page.

So either we add a branch name in /proc/branch (for mainline that will
be "2.6.13 mainline", that tells the release number and the branch, or I
shall do a bit more of regexp on the localversion). The branch tag has
the advantage of being able to more reliably recognize non-mainline
kernels as well, klive was made for mainline, I didn't expect so many
users with vendor kernels, but that's ok as long as the regexp on uname
-r works ;). The regexp is already falling apart with distro like
debian, so the sort of /proc/branch was suggested by them infact.

Yet another way would be to remove the git tag from the localversion ;),
but I doubt that it would be ok with you since it'd pratically backout
the feature. I don't think it would be enough for you to have the git
tag in /proc, the way I understand it you want it in the uts_release to
avoid overwriting system.map.

Suggestions welcome thanks.

Re: git tag in localversion

[Dmitry Torokhov]

On 9/12/05, Andrea Arcangeli <andrea@suse.de> wrote:
> Hello,
> 
> The patch that adds the git tag in the localversion is screwing klive a
> bit, see the 2.6.13-g* entries in
> http://klive.cpushare.com/?branch=unknown
> 
> Those are supposed to go in the homepage but they're not recognized
> anymore due the git tag and so they go in the unknown page.
> 
> So either we add a branch name in /proc/branch (for mainline that will
> be "2.6.13 mainline", that tells the release number and the branch, or I
> shall do a bit more of regexp on the localversion). The branch tag has
> the advantage of being able to more reliably recognize non-mainline
> kernels as well, klive was made for mainline, I didn't expect so many
> users with vendor kernels, but that's ok as long as the regexp on uname
> -r works ;). The regexp is already falling apart with distro like
> debian, so the sort of /proc/branch was suggested by them infact.
> 
> Yet another way would be to remove the git tag from the localversion ;),
> but I doubt that it would be ok with you since it'd pratically backout
> the feature. I don't think it would be enough for you to have the git
> tag in /proc, the way I understand it you want it in the uts_release to
> avoid overwriting system.map.
> 
> Suggestions welcome thanks.

I think this question better be addressed to Ian or Sam (Andrea, did
you pick a wrong entry from your address book?), adding them to CC...

-- 
Dmitry

Re: git tag in localversion

[Andrea Arcangeli]

On Mon, Sep 12, 2005 at 04:31:24PM -0500, Dmitry Torokhov wrote:
> I think this question better be addressed to Ian or Sam (Andrea, did
> you pick a wrong entry from your address book?), adding them to CC...

hmm, if you're not the right person it means hg log -p has some
problem... this changeset was submitted by you according to mercurial.

http://kernel.org/hg/linux-2.6/?cmd=changeset;node=3c0ba37caa9aa696f87eaaee6ccd2a70aba78034

Re: git tag in localversion

[Dmitry Torokhov]

On 9/12/05, Andrea Arcangeli <andrea@cpushare.com> wrote:
> On Mon, Sep 12, 2005 at 04:31:24PM -0500, Dmitry Torokhov wrote:
> > I think this question better be addressed to Ian or Sam (Andrea, did
> > you pick a wrong entry from your address book?), adding them to CC...
> 
> hmm, if you're not the right person it means hg log -p has some
> problem... this changeset was submitted by you according to mercurial.
> 
> http://kernel.org/hg/linux-2.6/?cmd=changeset;node=3c0ba37caa9aa696f87eaaee6ccd2a70aba78034
> 

This is just a merge changeset. I was pulling from Linus and there
were conflicts so I had to do manual merge and apparently this is what
was produced.

-- 
Dmitry

Re: git tag in localversion

[Ryan Anderson]

On Tue, Sep 13, 2005 at 12:21:37AM +0200, Andrea Arcangeli wrote:
> On Mon, Sep 12, 2005 at 04:31:24PM -0500, Dmitry Torokhov wrote:
> > I think this question better be addressed to Ian or Sam (Andrea, did
> > you pick a wrong entry from your address book?), adding them to CC...
> 
> hmm, if you're not the right person it means hg log -p has some
> problem... this changeset was submitted by you according to mercurial.

I submitted the "Auto Localversion" change (and a fix for the fact that
it doesn't auto-disappear on a tagged version like it is supposed to,
submitted 5 minutes ago).

Yes, the goal of this was to avoid overwriting similar, but different
versions, for those of us who are, too lazy to download patches,
but are willing to type "git pull origin && make oldconfig && make" on a
regular basis.

My suggestion would be to classify these wherever they would fall if the
-gXXXXXXXX wasn't present, as they fall into the same category.

They won't get as much testing, but if you see 5 or 10 of these in the
same category and -rc range, that's a good indication that a few people
are testing those kernels.

-- 

Ryan Anderson
  sometimes Pug Majere

Re: git tag in localversion

[Andrea Arcangeli]

On Tue, Sep 13, 2005 at 04:31:27AM -0400, Ryan Anderson wrote:
> My suggestion would be to classify these wherever they would fall if the
> -gXXXXXXXX wasn't present, as they fall into the same category.

I was considering doing this last night.

OTOH if I do that, I should merge the -git(\d+) in the same category
too.

> They won't get as much testing, but if you see 5 or 10 of these in the
> same category and -rc range, that's a good indication that a few people
> are testing those kernels.

Right now I simply moved them from unknown to the mainline branch, but I
still leave them separated like the -git(\d+) tags.

I probably should change that and merge after removing hte -g and -git
tags (of course without discarding the tag but showing it after clicking
on the kernel release).

Thanks.

Re: git tag in localversion

[Andrea Arcangeli]

On Tue, Sep 13, 2005 at 04:16:18PM +0200, Andrea Arcangeli wrote:
> On Tue, Sep 13, 2005 at 04:31:27AM -0400, Ryan Anderson wrote:
> > My suggestion would be to classify these wherever they would fall if the
> > -gXXXXXXXX wasn't present, as they fall into the same category.
> 
> I was considering doing this last night.
> 
> OTOH if I do that, I should merge the -git(\d+) in the same category
> too.

Just an update, I did it right now. I hope this is more useful. Of
course the -rc and the .\d+ are left separated. Only the -git\d+
snapshots and the final -gXXXXXXXX tags are merged into the same group.

If this isn't nicer I can restore the previous behaviour with just a
single command. We can give it a try this way.

BTW, after some discussion with Sven, Debian nicely added a vendor +
kernel_group tag to their /proc/version, this is ideal for people to
specify where their kernels should be grouped and classified in klive
(that way I can even automate the branch classification like I'm already
doing with the architectures).

Their format is like this:

10:49 < waldi> Linux version 2.6.13-1-powerpc64 (Debian 2.6.13-1)
(waldi@debian.org) (gcc version 4.0.2 20050821 (prerelease) (Debian 4.0.1-6))
#1 SMP Wed Sep 14 09:28:56 UTC 2005

So the "(Debian 2.6.13-1)" string is what will tell me in which branch
it will go (Debian), and in which kernel_group it will go (2.6.13-1).

I preferred to have it in a separate file, but this should be good
enough too. Unfortunately I didn't send to the server the /proc/version
string in the client, so this will require a protocol update to
activate. If you've suggestion on other bits to add to the protocol,
please tell on the klive mailing list.

The next protocol will also contemplate how to optionally send oopses to
the server with an udp packet and the session number, and optionally
pciids and stuff like that. I guess the oops and other sensitive payload
could be optionally encrypted using a random symmetric key to set in the
kernel, that way people could use klive to securely store oopses to
retrieve later and to decrypt locally later (no ssl involved at all, all
client side). I know myself that I will encrypt it. This should allow to
never risk to lose an oops (as long as we're connected to the ethernet).
If no encryption is used, the oops can go public automatically.

This isn't going to happen soon, probably 2/3 months before the protocol
is implemented (some other project has higher prio).

There is also a twisted-less client invoked purerly by cron implemented
by Christian Aichinger and almost finished if people don't have other
twisted or python services in the background and they want to save a few
megs (once finished I'll add to the package).

The protocol update will not require client updates, old protocol will
keep going. Anyway I feel this is getting a bit offtopic for l-k sorry!