Re: [gentoo-dev] RFI: A better workflow for github pull requests
On Sat, Sep 12, 2015 at 02:31:11PM -0700, W. Trevor King wrote: > On Sat, Sep 12, 2015 at 11:15:14PM +0200, hasufell wrote: > > Because that is not a valid bug report. Patches must be attached > > to bugzilla. > > Right, thanks. In that case, I think you'll need a hook to push a > new patch whenever the GitHub branch is updated, rebased, etc. That > could make for a lot of Bugzilla spam… Coincidentally, I was catching up on Git Rev News [1], and the 2015-06-03 post talks about Git itself picking up a GitHub PR → upstream submission tool [2]. The Git Rev News post reproduces the workflow notes from the anouncement on the Git list [3], but the main point is that users trigger submitGit [4,5] manually, to have it push the pull-request upstream (in their case as a series of patch emails, but for us it would be to a Bugzilla patch). There's no mechanism for syncing comments (inline or otherwise) between GitHub an the mailing list, folks just keep discussion on the mailing list [3]. I haven't looked through the Git list to see how this approach is going for them, but it does mean that at least some folks who prefer GitHub PRs for submitting patches will punch an extra button or two to submit the series upstream and use the upstream channel to continue discussion. A similar approach may be an option for us, with a button to push a PR to Bugzilla. The initial button-push would send over a patch and start syncing comments, and subsequent button-pushes would send over revised patches. Cheers, Trevor [1]: http://git.github.io/rev_news/rev_news.html [2]: http://git.github.io/rev_news/2015/06/03/edition-4/ [3]: http://thread.gmane.org/gmane.comp.version-control.git/269699 [3]: https://submitgit.herokuapp.com/ [4]: https://github.com/rtyley/submitgit -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFI: A better workflow for github pull requests
On Sun, Sep 13, 2015 at 01:30:44PM +1200, Kent Fredric wrote: > If the patch is automatedly filed against bugzilla, people will > assume viewing that patch tells them all they need to know. > > But the reality is somebody may rebase/amend/repush to the > publicised branch location before any developer reviews the patch in > bugzilla, and so by the time somebody reviews the patch, it is > already wrong. This is what I was trying to get at [1]. And I still think some sort of rate-limited posting of updated patches is the best way to handle it. Git remotes are more complete (signatures and committer info) and as current as you like while you're actively reviewing [2], and I expect the point of the attached patch is to provide an archival reference that folks can refer to after GitHub (or whoever's hosting the remote) closes down. In that case, having the attached patch occasionally lag by a week (or whatever) is not going to be a big deal. Cheers, Trevor [1]: http://thread.gmane.org/gmane.linux.gentoo.devel/97329/focus=97333 Message-ID: <20150912213111.gb14...@odin.tremily.us> [2]: http://thread.gmane.org/gmane.linux.gentoo.devel/97329/focus=97333 Message-ID: <20150912210734.ga14...@odin.tremily.us> -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFI: A better workflow for github pull requests
On Sat, Sep 12, 2015 at 11:15:14PM +0200, hasufell wrote: > Because that is not a valid bug report. Patches must be attached to > bugzilla. Right, thanks. In that case, I think you'll need a hook to push a new patch whenever the GitHub branch is updated, rebased, etc. That could make for a lot of Bugzilla spam, because folks tend to cycle less formally in GitHub branches than they do with list-based (and similar) workflows. For example, if I submit a patch series to a mailing list, I'll wait a week before pushing v2 with a bunch of typo fixes, etc. But if I submit a patch series via a GitHub PR, I'll push fixes for those sort of things immediately. I'm skeptical that you'll be able to retrain frequent GitHub users to pace their pushes, so hopefully this has a technical solution. Maybe iterate over open PRs every week and push changed patches to Bugzilla? That avoids too much spam, but it means that comments via GitHub and Bugzilla may be talking about different versions of the branch (which seems like it would cause trouble ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFI: A better workflow for github pull requests
On Sat, Sep 12, 2015 at 10:11:27PM +0200, hasufell wrote: > We should probably auto-attach the patch from the pull request. This > can easily be done with link-rewriting, e.g.: > https://github.com/gentoo/gentoo/pull/83 to > https://github.com/gentoo/gentoo/pull/83.patch > yields a nice downloadable patch. Why not [1]: $ GITHUB_REMOTE=origin # adjust this to match whatever you call GitHub's gentoo/gentoo $ git config --add remote.$GITHUB_REMOTE.fetch +refs/pull/*/head:refs/remotes/$GITHUB_REMOTE/pr/* That will let you fetch the remote branch (e.g. origin/pr/83 assuming ‘origin’ is your GitHub remote). That seems easier than copy/pasting around commits and messing with ‘git am’ and other things that will change the committer, which will in turn invalidate any commit signatures (the patch seems to drop those anyway). Cheers, Trevor [1]: https://gist.github.com/piscisaureus/3342247 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] signatures in git work flow
On Sun, Jul 05, 2015 at 09:05:12PM -0400, Rich Freeman wrote: > All the gpg stuff really exposes the weakness of git being based on > sha1 though. I wouldn't think that it would be that hard to change > git's hash function, with the caveat that the resulting repositories > might not be backwards-compatible… If you want a Merkle DAG with flexible hashes, you may be interested in IPFS [1]. It doesn't have Git's source-control tooling yet, but it does a good job at passing around generic Merkle objects with self-identifying hashes [2]. That way you can make your hash as strong as you like, although you'll still have public-rebase style incompatibilities if you want to go back and republish an older part of the DAG with a stronger hash. Cheers, Trevor [1]: http://ipfs.io/ [2]: https://github.com/jbenet/multihash/ -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Thu, Oct 16, 2014 at 12:13:45AM +, Jorge Manuel B. S. Vicetto wrote: > For stage1 and stage2 the *order* we build packages is relevant. Is this really true? The stage1 is being built with ROOT, so it's only using the seed stage3 packages. It's hard to have cyclic dependencies when you're using packages from one root (the seed stage3) but installing into another (/tmp/stage1root). Looking through a stage1 log I see: emerge --quiet --oneshot --nodeps --update sys-apps/portage … emerge --quiet --update --deep --newuse --complete-graph --rebuild-if-new-ver gcc … emerge --quiet --usepkg --buildpkg --newuse --oneshot --nodeps sys-apps/baselayout … emerge --quiet --usepkg --buildpkg --newuse --oneshot sys-devel/gnuconfig sys-devel/bison … The first two are just covering us against serious missmatches between the package tree and the seed stage3 (and are installed with ROOT=/). I expect we could handle shoving baselayout into the final emerge along with the other packages.build stuff. The logs for stage2 aren't as clear, but looking through the script I only see: * A Portage-updating emerge * The main GCC, binutils, … emerge * A possible 'emerge --prune sys-devel/gcc' I'm not sure this is needed at all. I'll try and find time to build a stage3 directly from a stage1, and we'll see if it blows up ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Fri, Oct 10, 2014 at 09:45:37PM -0400, Rich Freeman wrote: > Obviously this entails work on somebody's part, but would it still > make sense to make the stage build process more generic along the > lines Robin suggested? That is, instead of having 3 specific places > we use to generate a stage1/2/3, we instead just define a stage as a > virtual of some kind that optionally depends on another stage (not > necessarily using the standard DEPEND mechanism) and then pulls in a > list of packages. The root stage would not depend on another stage, > and therefore would be built from the host system. Why bother with multiple layers and per-profile package lists if a straight emerge is all you need? My ideal long-term situation would be to explicitly list all a package's dependencies (no implicit @system dependencies). Then have the stage1 just emerge a self-hosting virtual/toolchain (which can have per-arch dependencies if it needs them) from an arbitrary seed, and stage2 rebuild -e using itself. Everything after that could be user-generated @world stuff, and you might want virtual/release with nano and whatever else you want to put up under releases/$ARCH/autobuilds/gentoo-$ARCH-$DATE.tar.bz. That's less magical, and Catalyst could be a bit simpler, but I don't have the energy to move things there ;). It's also pretty much what we have now, except @system is floating around between virtual/toolchain (our current stage1 packages) and virtual/release (our current stage3 packages). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Fri, Oct 10, 2014 at 09:22:18PM +, Robin H. Johnson wrote: > In a similar vein, would releng be open to moving stage1/2/3 package > sets to virtual packages or package sets? Presently they are inside > catalyst, and I think this would clean things up a lot. They're already in the Portage tree (the profile's packages.build for stage1, scripts/bootstrap.sh for stage2, and the profile's packages for stage3) [1]. Cheers, Trevor [1]: http://git.tremily.us/?p=catalyst.git;a=blob;f=doc/HOWTO.txt;h=cec22c35484d480fa127beb7be6bbdd9e942dc39;hb=HEAD#l139 Linking to my public repo, because the gitweb service on git.overlays.gentoo.org is still broken. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Thu, Sep 25, 2014 at 11:49:53AM -0400, Rich Freeman wrote: > On Thu, Sep 25, 2014 at 11:29 AM, W. Trevor King wrote: > > What about a entry in metadata.xml that points people to > > the suggested mailing list for discussing a package? Bugzilla > > could automatically add the list to its CC list, and both devs and > > non-devs could join the list without adding a lot of email > > addresses to the tree. > > Yeah, I was thinking about something like an automatic per-package > email list or something like that, but I'm not sure how much use it > would get, and it would of course fragment discussions all over the > place. The benefit to a entry is that it doesn't need to be per-package. Everything currently in the python herd could be pushed to gentoo-python@. If the folks running that list thing dev-python/somepackage is too noisy, they can kick them off, and make them spin up their own list. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Thu, Sep 25, 2014 at 11:00:32AM -0400, Rich Freeman wrote: > On Wed, Sep 24, 2014 at 12:31 PM, W. Trevor King wrote: > > On Wed, Sep 10, 2014 at 04:18:40PM +0200, Michał Górny wrote: > >> > >> 4. A mail alias that is not project :). For example, we have > >> clang@ for easily aggregating all clang-related build failures > >> and other bugs but it isn't a formal team. > > > > As an incremental solution, what about a tag in > > metadata.xml with the same format as except that > > being a watcher doesn't imply a willingness to *do* anything about > > a project, it just means you want to be notified of changes and > > added to the CC list. > > I'd given some thought to this as well, but didn't think it was a > good idea. > > First, you can already create queries in bugzilla. Not all package activity has an associated bugzilla entry, but maybe enough of it does? > Or, would it make more sense to find a way for anybody to follow > issues in packages, assuming bugzilla queries aren't enough? What about a entry in metadata.xml that points people to the suggested mailing list for discussing a package? Bugzilla could automatically add the list to its CC list, and both devs and non-devs could join the list without adding a lot of email addresses to the tree. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
On Wed, Sep 10, 2014 at 04:18:40PM +0200, Michał Górny wrote: > Dnia 2014-09-10, o godz. 07:53:31 Rich Freeman napisał(a): > > On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos wrote: > > > Personally I would vote for simply have a tag pointing to > > > the alias but we would still need to keep a list of real maintainers for > > > that alias as usually not all people listed in the alias are willing to > > > maintain the packages. > > > > I think the solution to this is that maintainers can be either: > > 1. Devs - identified by their email address. (simple enough) > > or > > 2. Projects - identified by their email alias. > > or > > 3. A proxy maintainer identified by email address (in which case > > either a dev or project must also be listed, potentially including the > > proxy maintainer project). > > 4. A mail alias that is not project :). For example, we have clang@ for > easily aggregating all clang-related build failures and other bugs but > it isn't a formal team. As an incremental solution, what about a tag in metadata.xml with the same format as except that being a watcher doesn't imply a willingness to *do* anything about a project, it just means you want to be notified of changes and added to the CC list. Then devs can sign up to maintain or watch packages without using herds. Folks who find herds convenient can continue to use them with as implied maintainers [1] (or implied watchers, I don't really care). Folks who don't find herds convenient can leave them and just add their maintainer/watcher tags directly. Then reap herds if/when they go empty. I don't see the need for a dramatic change here, or even one that requires much consensus building. Or is a tag controversial? I'm not sure how the bugzilla CC lists are generated, maybe it would be terribly complicated to iterate over maintainers + watchers? Cheers, Trevor [1]: http://article.gmane.org/gmane.linux.gentoo.devel/92877 id:1410348781.5850.7.ca...@gentoo.org -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
On Mon, Sep 22, 2014 at 04:56:58PM -0400, Rich Freeman wrote: > In any case, I don't think it is necessary to actually modify the DCO. Ah, good. Then the verbatim copy license is sufficient, and we don't need to decide if the GPLv2 with Linus' exception applies. > I don't believe that it requires redistributing commit messages. I don't either, it just means that you *can* sign the DCO for a commit that you got from someone who's also signed the DCO for that commit. We just went down this licensing track because of: On Mon, Sep 22, 2014 at 02:13:53PM -0400, Rich Freeman wrote: > Perhaps the c clause should be clarified that the source files > themselves were not modified - not the commit message. I thought that sounded like you were suggesting a modification to the DCO, so I pointed out that I don't think that's legal. If you were just suggesting some “we interpret clause (c) to mean …” comment on the wiki or somewhere else, that clearly is legal, but I don't see the point. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
On Mon, Sep 22, 2014 at 03:35:29PM -0400, Rich Freeman wrote: > On Mon, Sep 22, 2014 at 3:27 PM, W. Trevor King wrote: > > On Mon, Sep 22, 2014 at 03:13:35PM -0400, Rich Freeman wrote: > >> On Mon, Sep 22, 2014 at 2:28 PM, W. Trevor King wrote: > >> > On Mon, Sep 22, 2014 at 02:13:53PM -0400, Rich Freeman wrote: > >> >> Perhaps the c clause should be clarified that the source files > >> >> themselves were not modified - not the commit message. > >> > > >> > The DCO text is verbatim copies only [1], so I don't think > >> > adjusting clauses is legal. > >> > >> I copied it from /usr/src/linux/Documentation/SubmittingPatches > >> which is GPLv2, as far as I can tell. > > > > Luis R. Rodriguez and I spent some time trying to track this down with > > the authors while I was factoring the signed-off-by documentation out > > into a stand-alone repository [1,2]. There was some debate about > > whether the text was copyrightable, but the explicit copyright claim > > and license on the Linux Foundation's DCO page [3] settles it for me. > > Great to hear that it settles it for you, but as far as I can tell, > the Linux Foundation has released it under the GPL and continues to do > so to this day. I suppose they can sue me if they don't agree, not > that I can see why they would want to. :) There's no Signed-off-by on the commits adding the DCO to the Linux tree ;). The only information I can find claiming copyright and licensing by one of the DCO authors is at http://developercertificate.org/. I suppose you could alter the DCO and claim it's under a different license, but the Linux Foundation lawers wrote the thing, so I think it's more respectful to take them at their word or just write your own certificate from scratch. > >> > Personally, I don't think the maintainer appending their s-o-b to > >> > the user's commit is all that important (certainly not worth > >> > blowing away the user's signature) when they can just sign and > >> > s-o-b an explicit merge commit. > >> > >> Agree. No need to modify the original commit. > > > > So the policy in the wiki should be: > > > > “Don't clobber the user's signature on a commit, even to add your > > Signed-off-by. Instead, explicitly merge signed user commits, or > > have the user reroll the commit with your tweaks and re-sign it.” > > I disagree with this. > > I have no objections to keeping the original commit. However, I do > object to requiring that the original commit being preserved. So, “You don't need to clobber…. Instead, you can explicitly….” Then it's clear that clobbering user sigs is allowed, even if it's not very nice ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
On Mon, Sep 22, 2014 at 03:13:35PM -0400, Rich Freeman wrote: > On Mon, Sep 22, 2014 at 2:28 PM, W. Trevor King wrote: > > On Mon, Sep 22, 2014 at 02:13:53PM -0400, Rich Freeman wrote: > >> Perhaps the c clause should be clarified that the source files > >> themselves were not modified - not the commit message. > > > > The DCO text is verbatim copies only [1], so I don't think > > adjusting clauses is legal. > > I copied it from /usr/src/linux/Documentation/SubmittingPatches > which is GPLv2, as far as I can tell. Luis R. Rodriguez and I spent some time trying to track this down with the authors while I was factoring the signed-off-by documentation out into a stand-alone repository [1,2]. There was some debate about whether the text was copyrightable, but the explicit copyright claim and license on the Linux Foundation's DCO page [3] settles it for me. > > Personally, I don't think the maintainer appending their s-o-b to > > the user's commit is all that important (certainly not worth > > blowing away the user's signature) when they can just sign and > > s-o-b an explicit merge commit. > > Agree. No need to modify the original commit. So the policy in the wiki should be: “Don't clobber the user's signature on a commit, even to add your Signed-off-by. Instead, explicitly merge signed user commits, or have the user reroll the commit with your tweaks and re-sign it.” Cheers, Trevor [1]: https://github.com/wking/signed-off-by [2]: http://www.do-not-panic.com/2014/02/developer-certificate-of-origin.html [3]: http://developercertificate.org/ -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
On Mon, Sep 22, 2014 at 02:13:53PM -0400, Rich Freeman wrote: > Perhaps the c clause should be clarified that the source files > themselves were not modified - not the commit message. The DCO text is verbatim copies only [1], so I don't think adjusting clauses is legal. And if you're modifying neither the source files nor the commit message, I'm not sure where you're suggesting the Signed-off-by go. Or are you saying that when a maintainer adds their s-o-b and blows away the user's signature, they should just say “don't worry, this is still pretty much what the user signed”? Personally, I don't think the maintainer appending their s-o-b to the user's commit is all that important (certainly not worth blowing away the user's signature) when they can just sign and s-o-b an explicit merge commit. > I don't have a problem with preserving contributor commits via merge > commits, but I don't think that is the general proposed workflow. The wiki has [2]: don't do complicated rebases to avoid a merge commit at all cost (it may even cause losing information, e.g. user signatures) which makes sense to me. Cheers, Trevor [1]: http://developercertificate.org/ [2]: https://wiki.gentoo.org/index.php?title=Gentoo_git_workflow&redirect=no#atomicity -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
On Mon, Sep 22, 2014 at 11:29:52AM -0400, Rich Freeman wrote: > On Mon, Sep 22, 2014 at 10:50 AM, Ulrich Mueller wrote: > > Another issue, should we require "Signed-off-by:" lines? At least > > for things that are contributed by users? > > > > … > > Thanks for bringing this up. I had circulated the start of a > proposal on this a year ago: > http://dev.gentoo.org/~rich0/copyrightpolicy.xml The (c) clause (“I got this patch from someone else who'd signed the DCO for it”) leads to chains like: Signed-off-by: A. U. Thor Signed-off-by: Some Maintainer … as the patch percolates up to the main repository. In Gentoo, that's probably going to be just a Gentoo dev, or an external contributor plus a Gentoo dev. The multiple-signoffs version is not going to play well with signed commits, because if A. U. Thor signed his commit (with just his Signed-off-by), Some Maintainer will not be able to add her Signed-off-by without dropping Thor's commit signature. My suggested solution here is to take the same approach we're suggesting for commit signatures, and just have the maintainer add their Signed-off-by to an explicit merge commit pulling in the contributor's work. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Git copy detection (was: My masterplan for git migration...)
On Fri, Sep 19, 2014 at 01:01:13AM +0400, Diamond wrote: > On Thu, 18 Sep 2014 13:08:11 -0700 W. Trevor King wrote: > > Git can check for copies if you like: > > > > $ git clone git://github.com/cerebrum/dr.git > > $ cd dr/ > > $ git show --find-copies-harder 311df9b04 > > … > > copy from games-strategy/openra/openra-20140608.ebuild > > copy to games-strategy/openra/openra-20140722.ebuild > > --find-copies-harder is better but it isn't shown on github in a > convenient way for package management. So Git works great, and GitHub's web UI doesn't support all of Git's bells and whistles, so… switch to a different VCS? Personally, my conclusion is “just use Git from the command line”. It's not like you're abandoning long years of experience using CVSHub with some miracle UI ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
[gentoo-dev] Git copy detection (was: My masterplan for git migration...)
On Thu, Sep 18, 2014 at 11:33:40PM +0400, Diamond wrote: > Lets assume, that I don't want to scrap old ebuild yet. There's no git > cp command. git mv is just git rm + git add. That's what does it look > like (usual revbump with git add in reality): > https://github.com/cerebrum/dr/commit/311df9b04d876f5847416fe5ba699edfab50adb6 Git can check for copies if you like: $ git clone git://github.com/cerebrum/dr.git $ cd dr/ $ git show --find-copies-harder 311df9b04 commit 311df9b04d876f5847416fe5ba699edfab50adb6 … diff --git a/games-strategy/openra/openra-20140608.ebuild b/games-strategy/openra/openra-20140722.ebuild similarity index 100% copy from games-strategy/openra/openra-20140608.ebuild copy to games-strategy/openra/openra-20140722.ebuild Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)
On Wed, Sep 17, 2014 at 10:36:45AM +0200, Michał Górny wrote:
> Dnia 2014-09-16, o godz. 10:52:13
> W. Trevor King napisał(a):
> > $ git pull --depth=1
> >
> > for subsequent syncs. pym/_emerge/actions.py currently hardcodes
> > ‘git pull’ for the latter, and doesn't seem to have any code for
> > the former. On the other hand, it wouldn't be too terrible to
> > force users to shallow their history manually whenever they felt
> > like it.
>
> This isn't a good idea at all :). For git, --depth=1 fetching is the
> same thing as --depth=1 clone. This way, you refetch everything
> rather than just getting the update.
You don't refetch everything, but the pull fails because it doesn't
know how the original and new shallow commits are related (so it can't
(ff-)merge them). It works if you fetch and reset (skipping the
merge). Here's my test script:
#!/bin/sh
rm -rf upstream local-1 local-2 &&
mkdir upstream &&
(
cd upstream &&
git init &&
echo 'Some project' >README &&
git add README &&
git commit -m 'Start the project' &&
for X in 1 2 3 4 5 6 7 8 9
do
echo "${X}" >"${X}" &&
git add "${X}"
done &&
git commit -m 'Add a bunch of dummy files'
) &&
git clone --depth 1 "file://${PWD}/upstream" local-1 &&
(
cd upstream &&
echo 'Build with ...' >>README &&
git commit -am 'Add building instructions' &&
echo 'Test with ...' >>README &&
git commit -am 'Add testing instructions'
) &&
(
cd local-1 &&
git fetch --depth 1 &&
git reset --hard origin/master &&
git --no-pager log --oneline --decorate &&
du -s . &&
git reflog expire --expire=now --all &&
git gc --aggressive --prune=now &&
du -s .
) &&
git clone --depth 1 "file://${PWD}/upstream" local-2 &&
(
cd local-2 &&
du -s .
)
and here are some excerpts of it's output:
* The shallow fetch only pulls in three objects (the new README, tree,
and commit):
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From file:///tmp/upstream
+ 73f6253...5abbe64 master -> origin/master (forced update)
HEAD is now at 5abbe64 Add testing instructions
* After the shallow fetch and reset, local-1 has a shallow history:
5abbe64 (grafted, HEAD, origin/master, origin/HEAD, master) Add testing
instructions
* But it still has references to the old master in the reflog, and
that takes up some space:
168 .
* Expiring the reflog and garbage collectiong gets us that space back
(although in practice, I'd just let Git expire these automatically
in the course of time):
Counting objects: 12, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (12/12), done.
Total 12 (delta 0), reused 9 (delta 0)
140 .
* A fresh shallow clone gets all 12 objects (not just the three new
ones):
Cloning into 'local-2'...
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 12 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (12/12), done.
Checking connectivity... done.
* And takes up as much space as our garbage-collected local-1:
140 .
Again, I'm happy to leave it to users to manually
$ git fetch --depth 1
$ git reset --hard origin/master
to shorten their history, but I expect many will not bother, and then
get annoyed as that unpurged history takes up more and more space ;).
In any case, we don't have to resolve this before the transition.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)
On Tue, Sep 16, 2014 at 10:52:13AM -0700, W. Trevor King wrote: > Oh, lovely :). Looks like that landed in 2.2.0 with 47e8d22d (Add > support for multiple repositories in `emerge --sync`, 2013-07-23). Actually, ‘git pull’ support in one form or another dates back to ba797c11 (Add --sync support for `git pull`, 2008-12-11), which landed in v2.2_rc18. > There are older Portages in the tree though (back to 2.1.6.7_p1), so > you'd still want to wait until those were gone before dropping rsync. The ‘git pull’ support was also backported to the 2.1.6.7_p1 series with d3c42937 (Add --sync support for `git pull`, 2008-12-11), which landed in v2.1.6.1, so I doubt any Portage users lack pull support. I'm not sure about folks using other package managers though. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)
On Tue, Sep 16, 2014 at 05:35:08PM +, Duncan wrote: > W. Trevor King posted on Mon, 15 Sep 2014 13:33:46 -0700 as excerpted: > > On Mon, Sep 15, 2014 at 01:29:44PM -0700, W. Trevor King wrote: > >> I don't see any benefit to using rsync vs. a shallow clone as the > >> transmission protocol. > > > > Other than the fact that before you dropped it you'd need to push a > > ‘emerge sync’ that could handle either rsync or Git, stabilize that > > Portage, and then wait for folks to adopt it. > > Portage already handles it. =:^) Oh, lovely :). Looks like that landed in 2.2.0 with 47e8d22d (Add support for multiple repositories in `emerge --sync`, 2013-07-23). There are older Portages in the tree though (back to 2.1.6.7_p1), so you'd still want to wait until those were gone before dropping rsync. Also, I don't see a way to say “use Git to sync, but keep a shallow repository”. Ideally, we'd want: $ git clone --depth=1 git://git.gentoo.org/gentoo-portage.git for the initial clone (modulo whatever URI), and: $ git pull --depth=1 for subsequent syncs. pym/_emerge/actions.py currently hardcodes ‘git pull’ for the latter, and doesn't seem to have any code for the former. On the other hand, it wouldn't be too terrible to force users to shallow their history manually whenever they felt like it. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)
On Mon, Sep 15, 2014 at 01:29:44PM -0700, W. Trevor King wrote: > I don't see any benefit to using rsync vs. a shallow clone as the > transmission protocol. Other than the fact that before you dropped it you'd need to push a ‘emerge sync’ that could handle either rsync or Git, stabilize that Portage, and then wait for folks to adopt it. That's going to slow down your migration a bit ;). I think an rsync-able version is a better choice for the migration, but since it's not destined to live long (in my view), I don't think it really matters what goes into it. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: My masterplan for git migration (+ looking for infra to test it)
On Mon, Sep 15, 2014 at 10:18:39PM +0200, Michał Górny wrote: > Dnia 2014-09-15, o godz. 15:55:35 Anthony G. Basile napisał(a): > > If the argument is that there are no Changelogs in rsync, then > > let's write git hooks to generate them when the repository is > > mirrored to the rsync host. The only problem I see is with this > > is then adding ChangeLog to the manifest and gpg signing it which > > has to be done at the developer's side. But, I think the tree > > that users get from rsync should have the logs. Having *both* a > > ChangeLog file and git log is redundant. > > Can't we just kill rsync then? The whole ChangeLog seems to take > more effort than the actual benefit it gives. I'm +1 for killing rsync and having everyone use Git. With --shallow clones for folks who don't care about the history, and deep clones for those who do (and you can change your mind both ways), I think everyone gets what they want without messing around with a Git → rsync conversion layer. Of course, it would be nice if the CSV → Git migration added any ChangeLog notes to the associated commit message to avoid losing information, but I imagine it would be hard to automate that and still get readable commit messages ;). I don't see any benefit to using rsync vs. a shallow clone as the transmission protocol. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
On Sun, Sep 14, 2014 at 11:25:33PM +, hasufell wrote: > So can we get this clear now. > > Robin said > > > The Git commit-signing design explicitly signs the entire commit, > > including blob contents, to avoid this security problem. > > Is this correct or not? That is false. The commit signature explicitly signs the commit, which includes the root tree hash. That is the only connection between the signature and the tree contents. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
On Sun, Sep 14, 2014 at 07:13:21PM -0400, Rich Freeman wrote: > The only thing that gets signed is the commit message, and the only > thing that ties the commit message to the code is the sha1 of the > top-level tree. If you can attack sha1 either at any tree level or at > the blob level you can defeat the signature. > > That is way better than nothing though - I think it is worth pursuing > until somebody comes up with a way to upgrade git to more secure > hashes. Most projects don't gpg sign their trees at all, including > linux. I'm not worried about the attack (as I explained earlier in this thread). I'm just arguing for signing first-parent commits to master, and not worrying about signatures on any side-branch commits. So long as the merge gets signed, you've got all the security you're going to get. Leaving the side-branch commits unchanged allows you to preserve any non-dev commit hashes, which makes it easier for contributors to verify that their changes have landed (the same way that GitHub is checking to know when to automatically close pull requests). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
On Sun, Sep 14, 2014 at 10:56:33PM +, hasufell wrote: > W. Trevor King: > > On Sun, Sep 14, 2014 at 10:38:41PM +, hasufell wrote: > >> So we'd basically end up using either "git cherry-pick" or "git > >> am" for "pulling" user stuff, so that we also sign the blobs. > > > > Rebasing the original commits doesn't protect you from the > > birthday attach either, because the vulnerable hash is likely > > going to still be in the rebased commit's tree. All rebasing does > > is swap the committer and drop the initial signature. > > According to Robin, it's not about rebasing, it's about signing all > commits so that messing with the blob (even if it has the same > sha-1) will cause signature verification failure. All cherry-pick and am do is apply one commit's diff to a different parent. Changing the parent hash (which is stored in the commit body [1]), so old signatures won't apply to the new commit. If there have been other tree changes between the initial parent and the new parent, the tree hash will also change, which would also break old signatures. None of that has anything to do with a malicious blob being pushed into the tree disguised as a same-hashed good blob. Such a blob will *not* break any signatures, since GnuPG is *never hashing the blob contents* when signing commits [1,2]. You're only signing the commit object, not the tree and blob objects referenced by that commit. Cheers, Trevor [1]: http://article.gmane.org/gmane.linux.gentoo.devel/77537 [2]: http://git.kernel.org/cgit/git/git.git/tree/commit.c?id=v2.1.0#n1076 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
On Sun, Sep 14, 2014 at 10:38:41PM +, hasufell wrote: > Yes, there is a possible attack vector mentioned in this comment > https://bugs.gentoo.org/show_bug.cgi?id=502060#c16 From that comment, the point 1.2 is highly unlikely [1]: 1. Attacker constructs a init.d script, regular part at the start, malicious part at the end 1.1. This would be fairly simple, just construct two start() functions, one of which is mundane, the other is malicious. 1.2. Both variants of the script have the same SHA1... > So we'd basically end up using either "git cherry-pick" or "git am" > for "pulling" user stuff, so that we also sign the blobs. Rebasing the original commits doesn't protect you from the birthday attach either, because the vulnerable hash is likely going to still be in the rebased commit's tree. All rebasing does is swap the committer and drop the initial signature. Cheers, Trevor [1]: http://article.gmane.org/gmane.comp.version-control.git/210622 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
On Sun, Sep 14, 2014 at 05:40:30PM +0200, Michał Górny wrote: > Dnia 2014-09-15, o godz. 03:15:14 Kent Fredric napisał(a): > > Only downside there is the way github pull reqs work is if the > > final SHA1's that hit tree don't match, the pull req doesn't > > close. > > > > Solutions: > > > > - A) Have somebody tasked with reaping old pull reqs with > > permissions granted. ( Uck ) > > - B) Always use a merge of some kind to mark the pull req as dead > > ( for instance, an "ours" merge to mark the branch as deprecated ) > > > > Both of those options are kinda ugly. > > If you merge a pull request, I suggest doing a proper 'git merge -S' > anyway to get a developer signature on top of all the changes. Some previous package-tree-in-Git efforts suggested that only Gentoo-dev signatures were acceptable, and that those signatures would be required on every commit (not just the first-parent line) [1,2]. I don't see the point of that, so long as Gentoo devs are signing the first-parent line, but if folks still want Gentoo-dev signatures on every commit the ‘git merge -S’ approach will not work for closing PRs. Cheers, Trevor [1]: http://article.gmane.org/gmane.linux.gentoo.devel/77572 id:cagfcs_manfikevtj3cmcq1of-uqavebe2r1okykygwc5vom...@mail.gmail.com [2]: https://bugs.gentoo.org/show_bug.cgi?id=502060#c0 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Catalyst news item - v2
On Thu, Jan 30, 2014 at 04:21:39PM +, Jorge Manuel B. S. Vicetto wrote: > +If you need to track the stable branch, please use the catalyst > +2.0. ebuild that tracks the 2.X branch. How about “If you want to track the stable 2.X branch, please use the catalyst 2.0. ebuild.”? Other than that minor tweak, it looks good to me. I'm agnostic on - audience restriction ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Catalyst news item
On Thu, Jan 30, 2014 at 02:14:53AM -0100, Jorge Manuel B. S. Vicetto wrote: > +After many years of stalled development, the catalyst repository is > +going to have major changes introduced to master in the next few days. “the next few days” sounds a little optimistic to me ;). “next few months”, which you use later, seems more accurate here too. > +report issues to the catalyst team, This reads “catalyst@” to me, which is fine if that's what you indend. However, you may want to suggest gentoo-catalyst@ instead, if you want a wider net of possible responders. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: rfc: formally allow qa to suspend commit rights
On Sat, Jan 18, 2014 at 11:02:24PM -0600, William Hubbs wrote: > +* In case a particular developer persistently causes breakage, the QA lead > may request commit rights of that developer to be suspended by the Infra > team. Comrel should then proceed to evaluate the situation, by finding a > compromise or pernamently revoking those rights. s/pernamently/permanently/ Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: devmanual moved to github
On Mon, May 13, 2013 at 12:24:09AM +0200, Alexander Berntsen wrote: > On 13/05/13 00:21, Peter Stuge wrote: > > There is no problem if github is only used for hosting, but if it > > is the primary point of contact, or if pull requests are accepted, > > then github is also writing to repositories, and merge commits are > > enforced for all external contributions. That does not scale at > > all. > > Users can still send patches via email even if the project is hosted on > GitHub. And for the record I have not had problems with messy merges > when commiting pull requests. You can also merge pull requests locally and format them however you like (including fast forward merges). GitHub automatically closes the PR when it's tip commit lands in the target branch. My major gripe with PRs is folks sometimes add lots of good details to the PR summary, and then have little one-line commit messages :p. If you can convince them to incorperate motivation, etc., in the commit messages, than the fact that code came in via a PR is irrelevant. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
[gentoo-dev] Binary package dependencies for sub-slot-less EAPIs
Over on #gentoo-releng and in gentoo-catalyst@ we've been running into binary package dependency problems [1]. Before EAPI-5 and sub-slots, the version of dependency packages is not recorded in the binary package metadata (the Packages file). For example, a binary package for GCC built against mpc-0.8.2 will link to libmpc.so.2. If you install that package on a system that only has mpc-1.0.1 (and thus, libmpc.so.3), your cc1 will crash because libmpc.so.2 is missing. What we need is a way to track ABI sub-slot dependencies for all packages, even those that currently use EAPI-0. My initial idea was to store a fake EAPI-5-style sub-slot information in the binary package metadata, but further discussion on #gentoo-portage pointed me at the toolchain folks: 10:33 < zmedico> dol-sen: wouldn't it be easier to just migrate those pkgs to EAPI 5 + slot-operator? 10:34 * zmedico doesn't feel like doing extra work when EAPI 5 already does everything we need … 11:16 < Tommy[D]_> Zero_Chaos: my suggestion: ask the toolchain guys about their preferred way (like updating existing eclass, using a new eclass, moving code into ebuilds) and when you got that, do the needed work, including an EAPI-5 version of toolchain ebuilds I looked in bugzilla for requests to update the toolchain EAPIs, but didn't find anything [2]. I don't want to bother people if the issue had already been hashed out, and searching on Gmane turned up the “[RFC] Drop EAPI=0 requirement for system packages.” thread from last October [3]. This early comment from Rich seemed to summarize the anti-EAPI-bump camp: On Wed, Oct 17, 2012 at 03:00:12PM -0400, Rich Freeman wrote: > A policy that says all new ebuilds shall use EAPI foo might result in > fewer new ebuilds. Sure, they'll have new and shiny fooness, but > arguably I'd rather have more packages supported on older EAPIs then > fewer packages supported on newer ones. > > Again, as I stated before, things that actually benefit the end users > like slot dependencies are fine to mandate when it makes sense to do > so. In other words, “Why force folks to do this if there is no benefit?”. This is understandable, but I think the broken binary packages [1] are enough of a visible benefit. The thread suggested filing bugs for bumping effected packages, but for this issue “effected packages” is “anything you might want to distribute as a binary package that uses something without EAPI-5 sub-slots” [4]. I'm happy to start filing bugs, but that doesn't strike me as the most productive way forward. If anyone can think of other solutions besides tweaking Portage or bumping a bunch of package EAPIs, I'd be happy to hear them ;). Otherwise I'd be happy to hear suggestions about moving forward on at least one of those fronts. Since I seem to be the most bothered by this issue, it's only fair that I help with the itch scratching. I just need a roadmap from the folks with commit access so I can start chipping away at whichever solution y'all think looks most appealing ;). Cheers, Trevor [1]: http://thread.gmane.org/gmane.linux.gentoo.catalyst/2137/focus=2237 [2]: https://bugs.gentoo.org/buglist.cgi?short_desc=EAPI&resolution=---&query_format=advanced&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=RESOLVED&bug_status=VERIFIED&short_desc_type=allwordssubstr&component=Core%20system&component=Development&component=Core%20system&component=Development&product=Gentoo%20Linux [3]: http://thread.gmane.org/gmane.linux.gentoo.devel/80705 [4]: Although on the catalyst side, only @system is really important. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New install isos needed
On Sun, Mar 24, 2013 at 09:55:05PM +0100, Alexander Berntsen wrote: > On 24/03/13 21:17, Ben Kohler wrote: > > I strongly believe it's important that we have an official install > > medium [that] the official installation handbook is based [on]. > > I agree. Let's make it SystemRescueCd. This is not my bailiwick, but I feel like releng has better documentation for their build process than SystemRescueCd. It's not clear to me how you would go from a seed system to a fresh SystemRescueCd without Francois Dupoux (the sole SystemRescueCd developer) at the wheel. I'm also don't think SystemRescueCd supports the less common architectures like MIPS, it's just x86/amd64, sparc, and ppc [1]. Cheers, Trevor [1]: http://sourceforge.net/projects/systemrescuecd/files/ -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Ohloh Organizations - Gentoo Linux
On Mon, Nov 26, 2012 at 09:58:32PM +0100, Dirkjan Ochtman wrote: > https://www.ohloh.net/orgs/gentoo I'm not a dev, and I haven't really been following this thread, but all the other organization summaries start out with something like Organization X is … not In order to sustain the current quality … Perhaps it would be worth rewriting to start with The Gentoo Foundation is … or Gentoo is …. In order to sustain … To give readers a cozier vibe ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)
On Tue, Jul 24, 2012 at 03:33:03PM -0400, Rich Freeman wrote: > The difference is that news only communicates what is "news." Unless > the manual contains a revision history it contains everything you > already know, perhaps with a gem buried in there somewhere. > > This is the same reason why when something is wrong with Chromium you > are supposed to post a 5-line patch to the bug and not a 300MB tarball > with the patch applied, though at least in that case modern tools > actually make finding the change fairly easy. Hmm, are the manuals versioned with a public interface (git clone …/handbook.git)? That would make finding new gems in the manual much easier. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: udev-rules.eclass
On Wed, Jul 11, 2012 at 02:11:42PM -0500, William Hubbs wrote:
> For packages that install udev rules in ${FILESDIR}, we need an eclass
> that tests the version of udev installed on the user's system and
> installs the udev rules in the proper place. I'm not sure how many
> packages do this, so if it is a very small number of packages, it may
> not be worth the eclass.
I do this in sci-misc/comedi-headers (wtk overlay). Actually, I had
just been installing the rules into /etc/udev/rules.d, because I
hadn't read the docs thoroughly enough. +1 for an eclass to handle
this for me ;).
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing
On Fri, Jun 08, 2012 at 03:40:57PM +0200, Michael Weber wrote: > I'd suggest to generate an tarball (containing an keyring) to sign by > an master key (member of trustee/council/..) to be deployed on all > systems (like it's done on archlinux and debian). > > But the current vulnerability is exporting/importhing these keys to > pgp.mit.edu et al. If you just want to check for valid signatures, you can blindly download the keys from a keyserver. If you want to verify that those signing keys belong to Gentoo devs, you'll need a web of trust, just like any other PGP situation. The problem is distributing the trust, not the distributing the keys [1]. If you want a central policy for trusting Gentoo devs, you've already got an authentication scheme set up to log into the Gentoo servers. If you trust that scheme, and trust those servers against privilege escalation and the like, then if a dev can log into the server and configure their preferred key fingerprint, that seems like a sufficiently rigorous proof for the Gentoo infra folks to conclude that the dev in question owns the key in question. The fact that the Gentoo infra folks might trust the dev's key enough to publish snapshots signed by that key has no bearing on whether I, as a non Gentoo dev who knows none of the infra folks, can trust the key. I've got to establish my own web of trust to make that happen, and it's not something that I expect Gentoo to help me with. [1]: http://www.gnupg.org/gph/en/manual.html#AEN533 http://www.gnupg.org/gph/en/manual.html#AEN554 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing
On Mon, Jun 04, 2012 at 04:57:42PM -0400, Rich Freeman wrote: > 2. Hacker commits something to the tree. Top of tree is not signed. > No need for preimage attacks or whatever on sha1 - they just log into > the server and do a git commit or whatever right into the tree. > 3. Gentoo dev commits a bunch of stuff to the tree. Top of tree is signed. When the breach is discovered, you can then isolate the dev (or devs) who implicitly signed the hack (2) by pulling the ToT without checking for a valid signature (3). Then you yell at them for sloppy security, and tell them to install your signature-checking post-receive hook. Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
On Sat, Jun 02, 2012 at 03:56:43AM +1200, Kent Fredric wrote: > You can however merge dissimilar histories with no common parents if > you know what you're doing. It does warn you, but it still lets you do > it. > > … > > Yeah, selectively pulling in files with histories however is hard, > I've occasionally been fussed enough to create temporary copies of > branches, and then iterate over their history so the history is > reduced to changes only for a small selection of files, but its > largely lots of work, and I can't remember how to do it every time I > go to do it -_- I have to look it up every time I need it too, but the procedure involves `git filter-branch` [1,2], and actually is pretty easy to wrap your head around, even though the paricular commands are not so easy to remember. Trevor [1]: http://stackoverflow.com/questions/7375528/ [2]: http://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/ -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
[gentoo-dev] econf's localstatedir default doesn't match GNU suggestions
I'm curious abotu why econf uses
"${EPREFIX}"/var/lib
for the default value of localstatedir, when the GNU coding standards
[1] and autoconf site default examples [2] both suggest
$(prefix)/var
Not that it's a big deal to add
src_configure()
{
econf --localstatedir="${EPREFIX}"/var
}
to an ebuild, but the missmatch is odd. I did some digging through
the history of both Portage and PMS, but didn't find anything clear.
PMS has had that value as the default since
commit a686e410fd4d20f1d67b1c991936de78379d00c1
Author: Stephen Bennett
Date: Tue Mar 6 18:44:21 2007 +
Add build commands section based on pioto's patch. Add a TODO
command using the fixme package, and change todiscuss to use this
too. Possibly other misc changes.
which is not very informative on it's own. Portage has had the value
since
commit d9fc4acc572c6647a4f27b838d35d27d805d190e
Author: Jason Stubbs
Date: Sun Aug 28 08:37:44 2005 +
Migration (without history) of the current stable line to subversion.
Also not very helpful.
Anyhow, there is obviously a good deal of history here. Looking
through the ebuilds of packages on my system that do have something in
`/var/lib`, it looks like they either don't use autoconf
(e.g. sys-apps/portage), hardcode the path (i.e. avoid using
localstatedir, e.g. app-admin/eselect and app-crypt/mit-krb5) or
override the value in their own ebuilds (e.g. x11-base/xorg-server)
$ equery belongs -n /var/lib | while read LINE; do \
ATOM="${LINE%% *}"; \
grep -c localstatedir "/usr/portage/$ATOM/"*.ebuild; done
Is this one of those things that's too baked in to be worth changing,
or is this just too peripheral to have bothered anyone else?
Thanks,
Trevor
[1]: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
[2]:
http://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Site-Defaults.html
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
