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
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 devel
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 o
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 downloadabl
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-c
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
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
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 tr
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 a
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
> >&g
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
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 require
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,
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
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 ne
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 t
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-ha
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/311df9b04
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 doe
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 s
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
>
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
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 o
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 sig
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 d
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" use
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
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)
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 tha
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”,
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
> com
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, a
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 mp
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
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
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 wh
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
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 expor
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
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 o
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
41 matches
Mail list logo
