(I'm not sure this can be done with cvs, but svn and git have this concept.) It would be very helpful to those of us using "live" builds to have the log of what version was checked out. This can help, for example, if bisecting a git problem, or just in general for reporting errors. We can go back to the log (which I get in email, but wherever it is) and see what version we have, and check earlier in the log (earlier email, whatever) to see what it used to be, and either choose to manually bisect (although being able to set an environment variable for the ebuild to use would be awesome), or just simply report our findings to the developers with proper context. Right now, I have to say "I compiled this on *date*, at *time* (*timezone*)" which is far from clear. Being able to simply cut&paste the svn level, or the git hash, from my log to the bug report would make this far, far easier. Reproducible: Always Steps to Reproduce: 1. emerge @live-rebuild 2. check log - no record of what level just got compiled
Ok in svn it might have reason, but are you sure that for user is anyhow meaningfull the git hash which is used for revision? No problem in me if users really want it it is really trivial to add it.
I'm assured by the upstream for, as an example, xf86-video-radeonhd, that it would be useful in my bug reports when I'm using their dev tree (the 9999* ebuilds). If it makes it into my ELOG email, then I can be sure of what level I'm running. I suppose that if you can (optionally?) log as much detail about it as possible, that's great, too (what branch, URL, etc.), as it can remove all doubt about what I'm running. e.g., Note: You are running PRERELEASE software. Don't file a gentoo bug if this doesn't work, but instead file a bug and refer to the following build level: git://anongit/freedesktop.org/git/xorg/driver/xf86-video-radeonhd branch: master git level: 0x1234556.... (whatever it is) Or something like that. I'm not a git expert, so I don't really understand what all might be important in there, but hopefully you get the giSt of it. :-) Thanks!
Ok i am convinced and i will work on it in x11 overlay. :] Dont expect it hit main tree soon, i think it have 3 more weeks of testing in x11 (4 weeks per major eclass change i have as rule :P) but it will be there waiting for ya nicely packed i guess on sunday evening :P
If you trigger a rebuild of a set (e.g. @kde-live) which includes many ebuilds, all of them are rebuilt even if only a small subset has been changed. If the sources of a specific ebuild in the set have not changed, this ebuild could be skipped Something like: - get latest revision number from repository - check revision number of current version in /usr/portage/distfiles/{git/svn}-src - if same, and module was successfully built with that revision, skip rebuild of module and continue with next module from the set
git eclass in x11 overlay now elog requested informations.
Will the same information be elog'd for SVN, too? The git information has already proved useful in upstream bug reports, and I've had more than one need for the svn commit level. Thanks,
In case of subversion.eclass, somebody should attach a patch for review.
Does this bug still apply? Now every major VCS eclass exports the checked out revision or some other identifier into environment.bz2. (In reply to comment #4) > - get latest revision number from repository > - check revision number of current version in > /usr/portage/distfiles/{git/svn}-src > - if same, and module was successfully built with that revision, skip rebuild > of module and continue with next module from the set Markus, you may want to take a look at app-portage/smart-live-rebuild.
(In reply to comment #8) > Does this bug still apply? Now every major VCS eclass exports the checked out > revision or some other identifier into environment.bz2. > > (In reply to comment #4) > > - get latest revision number from repository > > - check revision number of current version in > > /usr/portage/distfiles/{git/svn}-src > > - if same, and module was successfully built with that revision, skip rebuild > > of module and continue with next module from the set > > Markus, you may want to take a look at app-portage/smart-live-rebuild.
