[gentoo-dev] scm eclasses/ebuilds and revision logging

[gentoo-dev] scm eclasses/ebuilds and revision logging

[Bernd Steinhauser]

Hi,

this is sth. that has been brought up in the KDE4 forums thread and on
irc. The thing is, that if you're using a live ebuild you might very
likely run into bugs, that have been introduced in a newer revision.
Now when you get in touch with upstream about that bug it might be very
useful if you can tell them, that you know, that a specific version in
the past worked. The idea was now to add the ability to the scm eclasses
to do this automatically.
So after installation then sth. like this
${CAT}/${P} merged at revision (or commit) ${REVISION}
to a file like /var/log/portage/scm.log.
Now I'm sure there are a few dirty ways to achieve this, but I wonder if
there is an easy and clean way to do this?

The problem is (I think so), that you can't just write sth. to / because
of the sandbox, so there needs to be a way to get around that, and it
should also happen after installation (post_inst).

Now if anyone wonders if this might even be useful for the distributed
scm's, I do think so. Because of course if you merge sth. from another
tree, or your ebuild repo_uri fetches from a local dir, then you might
have _other_ commit hashes than upstream, but at least you can then look
into your own repo and tell them, when that was and what happened since
then.

I'm aware of the fact, that the revision of the currently installed
package is part of the environment and that is saved, but I'm not only
interested in the revision of the currently installed version, but also
in the revision of the previously installed version. Just wanted to
emphasize that again. ;)

Hope someone comes up with some good ideas. ;)

Greetings,
Bernd
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] scm eclasses/ebuilds and revision logging

[Avuton Olrich]

On 1/11/08, Bernd Steinhauser <gentoo@bernd-steinhauser.de> wrote:
> Hi,
>
> this is sth. that has been brought up in the KDE4 forums thread and on
> irc. The thing is, that if you're using a live ebuild you might very
> likely run into bugs, that have been introduced in a newer revision.
> Now when you get in touch with upstream about that bug it might be very
> useful if you can tell them, that you know, that a specific version in
> the past worked. The idea was now to add the ability to the scm eclasses
> to do this automatically.
> So after installation then sth. like this
> ${CAT}/${P} merged at revision (or commit) ${REVISION}
> to a file like /var/log/portage/scm.log.
> Now I'm sure there are a few dirty ways to achieve this, but I wonder if
> there is an easy and clean way to do this?
>
> The problem is (I think so), that you can't just write sth. to / because
> of the sandbox, so there needs to be a way to get around that, and it
> should also happen after installation (post_inst).
>
> Now if anyone wonders if this might even be useful for the distributed
> scm's, I do think so. Because of course if you merge sth. from another
> tree, or your ebuild repo_uri fetches from a local dir, then you might
> have _other_ commit hashes than upstream, but at least you can then look
> into your own repo and tell them, when that was and what happened since
> then.
>
> I'm aware of the fact, that the revision of the currently installed
> package is part of the environment and that is saved, but I'm not only
> interested in the revision of the currently installed version, but also
> in the revision of the previously installed version. Just wanted to
> emphasize that again. ;)

update-live-ebuilds[1] already stores scm x's 'cookie' (hash,
revision, whatever). CVS and TLA are the only two which don't have a
specific cookie that changes in the local directory, so sha1sum is
used on a file that is known to change with repository changes, thus
they are not a good target for this.

Cookie values and the emerging epoch are stored in a uniform manner,
in /var/db/ule/*, and since ULE is bash even a caveman could add
logging stuff to it cleanly.

I would suspect anyone who uses live ebuilds on a routine basis should
already know about ULE and be using it. Please excuse me if this
method considered 'dirty', or offtopic, it was not meant to be.
Patches and criticism welcome.

[1]http://forums.gentoo.org/viewtopic-t-518701.html
http://repo.or.cz/w/ule.git
-- 
avuton
--
 Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: scm eclasses/ebuilds and revision logging

[Ryan Hill]

Bernd Steinhauser wrote:
> I'm aware of the fact, that the revision of the currently installed
> package is part of the environment and that is saved, but I'm not only
> interested in the revision of the currently installed version, but also
> in the revision of the previously installed version. Just wanted to
> emphasize that again. ;)
> 
> Hope someone comes up with some good ideas. ;)

Would something like this work for you?

pkg_preinst() {
     local pkgdate=$(date "+%Y%m%d %H:%M:%S")
     subversion_wc_info
     if [[ -n ${PORT_SCMDIR} ]]; then
         [[ -e ${ROOT}/${PORT_SCMDIR}/${PN}.revision ]] \
             && cp "${ROOT}/${PORT_SCMDIR}"/${PN}.revision "${T}"
         echo "${pkgdate} - ${P} was merged at revision ${ESVN_WC_REVISION}" \
             >> "${T}"/${PN}.revision
         insinto "${PORT_SCMDIR}"
         doins "${T}"/${PN}.revision
     fi
}

that's for subversion of course.  set PORT_SCMDIR in make.conf.


-- 
fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwindows @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] scm eclasses/ebuilds and revision logging

[Bernd Steinhauser]

Avuton Olrich schrieb:
> On 1/11/08, Bernd Steinhauser <gentoo@bernd-steinhauser.de> wrote:
>> Hi,
>>
>> this is sth. that has been brought up in the KDE4 forums thread and on
>> irc. The thing is, that if you're using a live ebuild you might very
>> likely run into bugs, that have been introduced in a newer revision.
>> Now when you get in touch with upstream about that bug it might be very
>> useful if you can tell them, that you know, that a specific version in
>> the past worked. The idea was now to add the ability to the scm eclasses
>> to do this automatically.
>> So after installation then sth. like this
>> ${CAT}/${P} merged at revision (or commit) ${REVISION}
>> to a file like /var/log/portage/scm.log.
>> Now I'm sure there are a few dirty ways to achieve this, but I wonder if
>> there is an easy and clean way to do this?
>>
>> The problem is (I think so), that you can't just write sth. to / because
>> of the sandbox, so there needs to be a way to get around that, and it
>> should also happen after installation (post_inst).
>>
>> Now if anyone wonders if this might even be useful for the distributed
>> scm's, I do think so. Because of course if you merge sth. from another
>> tree, or your ebuild repo_uri fetches from a local dir, then you might
>> have _other_ commit hashes than upstream, but at least you can then look
>> into your own repo and tell them, when that was and what happened since
>> then.
>>
>> I'm aware of the fact, that the revision of the currently installed
>> package is part of the environment and that is saved, but I'm not only
>> interested in the revision of the currently installed version, but also
>> in the revision of the previously installed version. Just wanted to
>> emphasize that again. ;)
> 
> update-live-ebuilds[1] already stores scm x's 'cookie' (hash,
> revision, whatever). CVS and TLA are the only two which don't have a
> specific cookie that changes in the local directory, so sha1sum is
> used on a file that is known to change with repository changes, thus
> they are not a good target for this.
> 
> Cookie values and the emerging epoch are stored in a uniform manner,
> in /var/db/ule/*, and since ULE is bash even a caveman could add
> logging stuff to it cleanly.
> 
> I would suspect anyone who uses live ebuilds on a routine basis should
> already know about ULE and be using it. Please excuse me if this
> method considered 'dirty', or offtopic, it was not meant to be.
> Patches and criticism welcome.
> 
> [1]http://forums.gentoo.org/viewtopic-t-518701.html
> http://repo.or.cz/w/ule.git

Well, of course that would be possible, but I thought about making this
part of the ebuilds, because normally you need that kind of information
when you previously didn't think about it and imho it should be part of
the stand procedure for live ebuilds.

Bernd
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: scm eclasses/ebuilds and revision logging

[Bernd Steinhauser]

Ryan Hill schrieb:
> Bernd Steinhauser wrote:
>> I'm aware of the fact, that the revision of the currently installed
>> package is part of the environment and that is saved, but I'm not only
>> interested in the revision of the currently installed version, but also
>> in the revision of the previously installed version. Just wanted to
>> emphasize that again. ;)
>>
>> Hope someone comes up with some good ideas. ;)
> 
> Would something like this work for you?
> 
> pkg_preinst() {
>     local pkgdate=$(date "+%Y%m%d %H:%M:%S")
>     subversion_wc_info
>     if [[ -n ${PORT_SCMDIR} ]]; then
>         [[ -e ${ROOT}/${PORT_SCMDIR}/${PN}.revision ]] \
>             && cp "${ROOT}/${PORT_SCMDIR}"/${PN}.revision "${T}"
>         echo "${pkgdate} - ${P} was merged at revision
> ${ESVN_WC_REVISION}" \
>             >> "${T}"/${PN}.revision
>         insinto "${PORT_SCMDIR}"
>         doins "${T}"/${PN}.revision
>     fi
> }
> 
> that's for subversion of course.  set PORT_SCMDIR in make.conf.
> 
> 

This is sort of what I thought of (of course you brought it into
detail), but I didn't know if there is maybe a better way, or if there
is actually a way to do this after the installation and not in preinst.
But I guess if nobody comes up with something better this is the way to
do it.
Maybe sth. like elog, just you don't log a message to summary.log, but
you log the revision of the package.
(Meaning, that you can use elog in every phase of an ebuild.)

Bernd
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] scm eclasses/ebuilds and revision logging

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

On Friday 11 January 2008, Bernd Steinhauser wrote:
> this is sth.

reading your e-mail drove me nuts as i cant figure out what "sth" means.  
google says "Sonic The Hedgehog".  not sure how this applies to Gentoo (he's 
really fast?).

> that has been brought up in the KDE4 forums thread and on 
> irc. The thing is, that if you're using a live ebuild you might very
> likely run into bugs, that have been introduced in a newer revision.
> Now when you get in touch with upstream about that bug it might be very
> useful if you can tell them, that you know, that a specific version in
> the past worked. The idea was now to add the ability to the scm eclasses
> to do this automatically.

when i'm upstream, i leverage `svn info` and such so that the active rev makes 
it into the version information.  but this would of course require changes to 
upstream stuff.

> So after installation then sth. like this
> ${CAT}/${P} merged at revision (or commit) ${REVISION}
> to a file like /var/log/portage/scm.log.
> Now I'm sure there are a few dirty ways to achieve this, but I wonder if
> there is an easy and clean way to do this?
>
> The problem is (I think so), that you can't just write sth. to / because
> of the sandbox, so there needs to be a way to get around that, and it
> should also happen after installation (post_inst).

considering you care about the *src* and not *pkg*, you'd probably want to 
have it done in src_install.  if you exported a variable, it'd be retrievable 
later in the vdb, but that isnt easy for users.

installing into a common accepted directory (like /usr/share/scm/$P) is one 
possibility, but that too kind of sucks.  but it would be trivial for users 
to glean ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: [gentoo-dev] sth (Was: scm eclasses/ebuilds and revision logging)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

On Sat, 12 Jan 2008 19:11:06 -0500
Mike Frysinger <vapier@gentoo.org> wrote:
> reading your e-mail drove me nuts as i cant figure out what "sth"
> means. google says "Sonic The Hedgehog".  not sure how this applies
> to Gentoo (he's really fast?).

It's an abbreviation for "Similar To Harring". You'll also see "fex",
which is "Finds English eXtraneous".

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] scm eclasses/ebuilds and revision logging

[Bernd Steinhauser]

Mike Frysinger schrieb:
> On Friday 11 January 2008, Bernd Steinhauser wrote:
>> this is sth.
> 
> reading your e-mail drove me nuts as i cant figure out what "sth" means.  
> google says "Sonic The Hedgehog".  not sure how this applies to Gentoo (he's 
> really fast?).
http://en.wiktionary.org/wiki/something
Sorry, thought that was common. ;)

Bernd

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: scm eclasses/ebuilds and revision logging

[Markus Ullmann]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

Bernd Steinhauser schrieb:
> http://en.wiktionary.org/wiki/something
> Sorry, thought that was common. ;)

It seems so from german-schools' english teaching books. ;)

Greetz
-Jokey


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Re: scm eclasses/ebuilds and revision logging

[Bernd Steinhauser]

I did now try this for a while and it works quite good, it only has one
problem. If the package gets unmerged, for whatever reason, then the
file will be unmerged. I know, that it is possible to keep dirs, but is
it possible to keep files (without touching them manually outside portage)?

Bernd

Ryan Hill schrieb:
> Bernd Steinhauser wrote:
>> I'm aware of the fact, that the revision of the currently installed
>> package is part of the environment and that is saved, but I'm not only
>> interested in the revision of the currently installed version, but also
>> in the revision of the previously installed version. Just wanted to
>> emphasize that again. ;)
>>
>> Hope someone comes up with some good ideas. ;)
> 
> Would something like this work for you?
> 
> pkg_preinst() {
>     local pkgdate=$(date "+%Y%m%d %H:%M:%S")
>     subversion_wc_info
>     if [[ -n ${PORT_SCMDIR} ]]; then
>         [[ -e ${ROOT}/${PORT_SCMDIR}/${PN}.revision ]] \
>             && cp "${ROOT}/${PORT_SCMDIR}"/${PN}.revision "${T}"
>         echo "${pkgdate} - ${P} was merged at revision
> ${ESVN_WC_REVISION}" \
>             >> "${T}"/${PN}.revision
>         insinto "${PORT_SCMDIR}"
>         doins "${T}"/${PN}.revision
>     fi
> }
> 
> that's for subversion of course.  set PORT_SCMDIR in make.conf.
> 
> 

-- 
gentoo-dev@lists.gentoo.org mailing list