Re: [gentoo-dev] $Header:$ and ebuilds
On Fri, 20 Apr 2007 14:30:54 +0200 Fabian Groffen <[EMAIL PROTECTED]> wrote: > On 20-04-2007 08:22:42 -0400, Mike Frysinger wrote: > > does anyone actually find this useful ? i think ive used the value > > in there like once (when in reality a `md5sum` would have worked > > just as well) ... otherwise, from my perspective: > > - it causes annoying bogus hunks in diffs > > - not uncommon for people to contact me as the maintainer because > > i'm in that > > - wastes space (well, probably not a strong argument due to bytes > > vs blocks) > > - for mostly green users, it's confusing and they get it wrong > > I use it to make deltas of changes made in the tree, and apply those > deltas on the overlay I'm using. Without $Header: $ there I have no > way to actually see which version I'm dealing with, so which > revisions to retrieve for differences. > For that reason, I prefer as much files as possible in the tree to > have a $Header: $ somewhere, so I can easily sync, keeping my local > changes. I do the same. The '$Header: $' tells me which version of a file in the CVS tree I last synced to in my overlay, then I can just do a cvs diff on the tree to get a patch of differences since then. Very useful. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
> > So I'd be in favour of getting rid of them, if we make sure that > everybody always commits to the ChangeLog (Make it a repoman failure). > Side benefit of removing the need to double-commit from the hashes > changing. > i have never understood why repoman doesn't automatically put the commit message into the ChangeLog (share your use case!) taking this one more step ahead, the ChangeLog could perhaps be made a virtual file, which on demand is extracted from VCS metadata... now _that_ would save some bandwidth and space (no numbers, sorry). i am all for the removal of $Header:$, btw. the current double commits simply suck! regards Thilo pgpFGtCBHRfL3.pgp Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
> > I do the same. The '$Header: $' tells me which version of a file in > the CVS tree I last synced to in my overlay, then I can just do a cvs > diff on the tree to get a patch of differences since then. Very > useful. right - but this functionality would not go away - it would just have to be implemented differently. a potential move to git would make this much more easy, if i am not mistaken. kind regards Thilo pgpva6EUHQ2Yb.pgp Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
So to sum up this thread: It seems that: a) we are moving to GIT which doesn't cope with $Header: $ stuff b) we want to avoid the "double commit" caused by $Header: $ For a) I would prefer then to remove the $Header: $ stuff until GIT is really about to be used. In a GIT world things will change completely anyway (if it works at all). Then for b) I like to suggest to ask the portage team to simply skip the $Header: $ part(s) when calculating the digests, and shove that change in at the same time manifest1 is obsoleted and migrated into the tree (removal of digest-* files). On 20-04-2007 08:22:42 -0400, Mike Frysinger wrote: > does anyone actually find this useful ? i think ive used the value in there > like once (when in reality a `md5sum` would have worked just as well) ... > otherwise, from my perspective: > - it causes annoying bogus hunks in diffs > - not uncommon for people to contact me as the maintainer because i'm in that > - wastes space (well, probably not a strong argument due to bytes vs blocks) > - for mostly green users, it's confusing and they get it wrong -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New Developer: Aggelos Orfanakos (agorf)
On Fri, 20 Apr 2007 14:52:22 +0300 Mart Raudsepp wrote: > > Once Aggy isn't around computers, he finds time to enjoy swimming (/me > > winks > > at dad eryof), table tennis, photography, astronomy and listening to music. > > I challenge you to a match of table tennis. Now come over here and beat > me! No, not far at all, just the other side of Europe, so no excuses :p Well, judging from the Developers Map, the closest I've ever been to you is Helsinki (almost a decade ago though), so you better be practicing already cause you never know... > > So please welcome Aggelos (or Aggy, for those who are as lazy as I am) > > as a new fellow developer among us ! > > We need to make sure he makes his IRC client beep/highlight on "Aggy" > too ;) That can be arranged. :-) Thanks for your wishes everybody! -- Aggelos Orfanakos 0x89D2D3D0 (GPG) http://agorf.gr/ pgpKGO5qEAjPt.pgp Description: PGP signature
Re: [gentoo-dev] Re: pciparm init script for sys-apps/pciutils
federico ha scritto: > Steve Long ha scritto: > >> What benefits does it show; why would I want it on my machine? >> >> http://www.gentoo.org/doc/en/articles/hardware-stability-p2.xml > > cause you don't want to write setpci stuff in /etc/conf.d/local.start ;D > > seriously: because you can disable it by a kernel command line > 'nopciparm' (like the hdparm script does); because it provides a place > to store those settings; > > although I don't like wrapping each register into a variable... too much > work on the script side. would be better to simplify it to: > > ALL="latency_timer=0b ..." > ="latency_timer=ff rom_address=4801" > ="poo=foo ..." > and finally, I've made those changes. (bug is REOPENED) I guess this is the last contribution, if anything works fine bye -- Federico -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Sat, 21 Apr 2007 12:40:42 +0200 Fabian Groffen <[EMAIL PROTECTED]> wrote: > Then for b) I like to suggest to ask the portage team to simply skip the > $Header: $ part(s) when calculating the digests, and shove that change > in at the same time manifest1 is obsoleted and migrated into the tree > (removal of digest-* files). You realize what a mess that would cause? 1) it makes checksums much harder to verify manually 2) different portage versions/other package managers would generate different checksums, which results in bogus verification errors So from my POV that's definitely not an option. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Sat, 21 Apr 2007 12:00:55 +0200 Thilo Bangert <[EMAIL PROTECTED]> wrote: > > I do the same. The '$Header: $' tells me which version of a file in > > the CVS tree I last synced to in my overlay, then I can just do a > > cvs diff on the tree to get a patch of differences since then. Very > > useful. > > right - but this functionality would not go away - it would just have > to be implemented differently. a potential move to git would make > this much more easy, if i am not mistaken. By "implemented differently" you mean "by adding extra steps and data to the synchronisation process". Currently, I compare the Header field in my overlay (which SVN doesn't touch) with that in the Gentoo CVS, and use the difference to drive the 'cvs diff' command to get a patch. Removing the header would mean I'd have to record the origin version somewhere, and keep that up-to-date whenever the file is re-synchronised. Having said that, it only works for me because my overlay is in SVN and and is not configured to process CVS header keywords. However I can honestly say that in my experience, the file revision identification is _always_ recorded in the file - I've never yet seen an SCM used in practice that didn't have that information. The reason people put that information in, is so that when the file is taken out of the context of the SCM repository, it's still clear where it came from. This is precisely how I'm using it. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fabian Groffen wrote: > So to sum up this thread: > > It seems that: > a) we are moving to GIT which doesn't cope with $Header: $ stuff we are _not_ moving to any different scm anytime soon. - -- === Mike Doty kingtaco -at- gentoo.org Gentoo Council Gentoo Infrastructure Gentoo/AMD64 Strategic Lead GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.2 (GNU/Linux) iQCVAwUBRipAq4BrouQZ9K4FAQLsTQP/ejvTR/mrscrbOgDsdG1mNZUcpR+0aaru DLasHWjixW3Cs2BJccuP4XhSXeZJ9zd6cbAUJXlmNBUoimnxKT3/Nz/NboiOMJzJ 6B0Kuqb+EfaId5LkZpAUNwFeBCd/nTjFbnZu5pKRGrqbNL0jetaAkG4ZkFWy12P+ dRQUDeUB0v4= =gJCb -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
Kevin F. Quinn wrote: > On Sat, 21 Apr 2007 12:00:55 +0200 > Thilo Bangert <[EMAIL PROTECTED]> wrote: > >>> I do the same. The '$Header: $' tells me which version of a file in >>> the CVS tree I last synced to in my overlay, then I can just do a >>> cvs diff on the tree to get a patch of differences since then. Very >>> useful. >> right - but this functionality would not go away - it would just have >> to be implemented differently. a potential move to git would make >> this much more easy, if i am not mistaken. > > By "implemented differently" you mean "by adding extra steps and data > to the synchronisation process". Currently, I compare the Header field > in my overlay (which SVN doesn't touch) with that in the Gentoo CVS, > and use the difference to drive the 'cvs diff' command to get a patch. > > Removing the header would mean I'd have to record the origin version > somewhere, and keep that up-to-date whenever the file is > re-synchronised. > > Having said that, it only works for me because my overlay is in SVN and > and is not configured to process CVS header keywords. > > However I can honestly say that in my experience, the file revision > identification is _always_ recorded in the file - I've never yet seen > an SCM used in practice that didn't have that information. The reason > people put that information in, is so that when the file is taken out > of the context of the SCM repository, it's still clear where it came > from. This is precisely how I'm using it. GIT records the content of files in 'blobs', so the only keyword var that makes sense in a file is $blobId$, which would expand to a SHA1 checksum of the file. The design here is to re-use blob's when the SHA1 matches to save on computation. Since $blobID$ only really changes when the content changes (ie they are tied together) there is no 'loss' in having a $blobId$. If you put something like author in there, the author may change, or the author may be the same for every commit to a particular file. Binding the author means you change the checksum of the file every time the author changes, so if I commit rev1 and I commit rev2 and then you revert the file back to rev1, if we have $header$, the SCM wouldn't be able to re-use the blob from rev1 because my name is in the blob, instead of yours. I'll spare you the details[1]. PS: We aren't switching version control systems as far as I'm aware. Robin is just doing research into moving to git. The whole point of his inquiry is 'is anyone using $header in a manner than cannot be ported to using $blobid$'. [1] http://thread.gmane.org/gmane.comp.version-control.git/44750 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
Thilo Bangert wrote: So I'd be in favour of getting rid of them, if we make sure that everybody always commits to the ChangeLog (Make it a repoman failure). Side benefit of removing the need to double-commit from the hashes changing. i have never understood why repoman doesn't automatically put the commit message into the ChangeLog (share your use case!) Yeah I would like at least a switch that would call echangelog first and then do its stuff, sunrise-commit which I use for overlays has -c for this. Hm well I can make myself a wrapper but if it was already there, it would be better :) taking this one more step ahead, the ChangeLog could perhaps be made a virtual file, which on demand is extracted from VCS metadata... now _that_ would save some bandwidth and space (no numbers, sorry). Interesting idea, if that's possible with CVS... but I don't see how it saves space and bandwith for rsync users. i am all for the removal of $Header:$, btw. the current double commits simply suck! I would leave it as long as we use CVS, for the reasons others already said (syncing changes to overlays which I myself used to do). But if we move to some other VCS, it would destroy the beauty of atomic commits... -- Vlastimil Babka (Caster) Gentoo/Java -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Sat, Apr 21, 2007 at 10:54:15AM -0700, Alec Warner wrote: > PS: We aren't switching version control systems as far as I'm aware. > Robin is just doing research into moving to git. The whole point of his > inquiry is 'is anyone using $header in a manner than cannot be ported to > using $blobid$'. > > [1] http://thread.gmane.org/gmane.comp.version-control.git/44750 That thread was a followup to this previous thread: http://thread.gmane.org/gmane.comp.version-control.git/44298 Wherein I discussed what Gentoo would need out of Git that wasn't yet fully polished in Git (as followup research to see if Gentoo _were_ switching to Git, what would happen). The second thread came about because somebody else posted a partial prototype, that Linus Torvalds then dissected for why it wouldn't work with Git. Torvalds notes that if you are taking the file out of the repository, it should be done with 'git export' adding revisions during that process, but this means that the developers and users get different content :-(. As a useful side, our Manifest files already contain the SHA1 of the ebuilds, and those are in fact the Git BlobIds, so we do have them recorded there, but the Manifest gets regenerated, so it's easy to lose them. Linus's response on the style of problem you have in copying files over to your overlay, is that your overlay should be a Git branch of the original tree. -- Robin Hugh Johnson Gentoo Linux Developer & Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpm0YOdEL6mS.pgp Description: PGP signature
Re: [gentoo-dev] $Header:$ and ebuilds
On Sat, Apr 21, 2007 at 12:40:42PM +0200, Fabian Groffen wrote: > a) we are moving to GIT which doesn't cope with $Header: $ stuff Please drop this notion. My work on the Git mailing lists has strictly been: - IFF Gentoo WANTED to switched to Git, how would Git have to change. This was my posting to the Git mailing list: http://thread.gmane.org/gmane.comp.version-control.git/44298/focus=44473 Summarizing from that list: #1 History slicing - In Git already, some minor bugs I identified #2 Subtree slicing - External patchset to Git, WIP #3 ACL support - Patch was posted to the Git ML yesterday, needs some Gentoo-specific polishing. #4 Keywords - see the massive threads on the Git ML that were spawned These also intersect with my own needs for Git for work projects, so I can justify some of my work time for doing some Git development. That said, from a VCS management point of view, and understanding the results of Antarus's GSoC2006 work [1], SVN wasn't really suitable on the server or client side (massive disk hog compared to CVS amongst other things). The best option on the management side of things, is still to stick with CVS at the moment. [1] http://www.gentoo.org/proj/en/infrastructure/cvs-migration.xml but beware that the results themselves are from August 2006, and have changed radically for Git - SVN may have changed radically as well, I don't follow SVN enough to know. -- Robin Hugh Johnson Gentoo Linux Developer & Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpoS3BWiruA0.pgp Description: PGP signature
[gentoo-dev] Re: Deskzilla license for Gentoo Bugzilla for everyone
Bjarke Istrup Pedersen wrote: >>> Please find attached a site license for Gentoo Linux project. Feel >>> free to share the license key with anyone interested or post it on the >>> web. The license allows any number of users, and it is locked to >>> Gentoo Linux Bugzilla URL. If in the future the URL changes, please >>> let me know and I'll create another license key. >>> >>> Please note that this license key requires Deskzilla 1.3 or later. You >>> can download the latest version from >>> http://almworks.com/deskzilla/download.html . I've been playing with this for about an hour now and it kicks ass. Considering i'm offline 5 days a week it's perfect for me. Thanks :D -- where to now? if i had to guess dirtyepic gentoo orgi'm afraid to say antarctica's next 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last Rite: dev-java/systray4j
diff -r1.7158 package.mask 23a24,29 > # Alistair Bush <[EMAIL PROTECTED]> (22 Apr 2007) > # Masked for removal to junkyard in 30 days > # Generation 1 package with stale (2004) upstream. > # Save this package by contacting the gentoo-java ml. > dev-java/systray4j > -- Alistair John Bush Developer Gentoo Java OpenPGP key 0x4900CFB7 www.gentoo.org www.gentoo.org/proj/en/java -- [EMAIL PROTECTED] mailing list
