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
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
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
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
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: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
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
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
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 maintainer tag pointing to
the alias but we would still need to keep a
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
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
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 wk...@tremily.us 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
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
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):
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
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
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
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
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
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
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
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 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
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
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
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
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 Tue, Jan 21, 2014 at 07:41:21PM +0100, Tom Wijsman wrote:
On Tue, 21 Jan 2014 09:20:04 -0800 W. Trevor King wrote:
On Tue, Jan 21, 2014 at 05:59:54PM +0100, Tom Wijsman wrote:
On Tue, 21 Jan 2014 08:51:14 -0800 W. Trevor King wrote:
On Tue, Jan 21, 2014 at 04:40:19PM +0100, Tom
On Tue, Jan 21, 2014 at 08:22:31PM +0100, Tom Wijsman wrote:
On Tue, 21 Jan 2014 11:18:39 -0800 W. Trevor King wrote:
I'm all for recording suggested conventions in DEVELOPING, but I
don't think it's worth the trouble to over-specify the conditions
under which each tag should be used
On Sun, Jan 19, 2014 at 09:05:41PM +0100, Sebastian Luther wrote:
Am 19.01.2014 04:07, schrieb W. Trevor King:
The patches aren't particularly well tested yet. I ran the test
suite and got some errors, but they seemed to be related to my
non-root invocation, and not due to these changes
The current fetch() function is quite long, which makes it hard to
know what I can change without adverse side effects. By pulling this
logic out of the main function, we get clearer logic in fetch() and
more explicit input for the config extraction.
---
pym/portage/package/ebuild/fetch.py | 50
know where the
gentoo-portage-dev@ population falls on that issue.
W. Trevor King (3):
pym/portage/package/ebuild/fetch.py: Factor out
_get_checksum_failure_max_tries
pym/portage/package/ebuild/fetch.py: Factor out _get_fetch_resume_size
pym/portage/package/ebuild/fetch.py: Factor out
The current fetch() function is quite long, which makes it hard to
know what I can change without adverse side effects. By pulling this
logic out of the main function, we get clearer logic in fetch() and
more explicit input for the config extraction.
This block was especially complicated, so I
The current fetch() function is quite long, which makes it hard to
know what I can change without adverse side effects. By pulling this
logic out of the main function, we get clearer logic in fetch() and
more explicit input for the config extraction.
---
pym/portage/package/ebuild/fetch.py | 59
On Sun, Jan 19, 2014 at 02:45:24PM -0800, Alec Warner wrote:
On Sun, Jan 19, 2014 at 2:44 PM, Alec Warner anta...@gentoo.org wrote:
This function and the next function you wrote are identical. How
about making a single function?
…
def getIntValueFromSettings(settings, key, default):
On Sun, Jan 19, 2014 at 02:36:43PM -0800, Alec Warner wrote:
On Sat, Jan 18, 2014 at 7:07 PM, W. Trevor King wk...@tremily.us wrote:
+def _get_file_uri_tuples(uris):
+ Return a list of (filename, uri) tuples
+
As mike noted on another thread:
Return a list of (filename
On Sun, Jan 19, 2014 at 03:06:29PM -0800, W. Trevor King wrote:
On Sun, Jan 19, 2014 at 02:36:43PM -0800, Alec Warner wrote:
On Sat, Jan 18, 2014 at 7:07 PM, W. Trevor King wk...@tremily.us wrote:
+ # Order primaryuri_dict values to match that in SRC_URI.
+ for uris
On Mon, Jan 20, 2014 at 02:26:59AM +0100, Tom Wijsman wrote:
On Sat, 18 Jan 2014 19:07:45 -0800
W. Trevor King wk...@tremily.us wrote:
[...SNIP...]
+ v =
int(settings.get(PORTAGE_FETCH_CHECKSUM_TRY_MIRRORS,
+ default))
…
The code screams
On Mon, Jan 20, 2014 at 02:41:41AM +0100, Tom Wijsman wrote:
There is some duplicate code here, I think the conditions can be
rewritten in such way that the duplicate code doesn't take place.
Do you want a rewrite squashed into this commit, or as a follow-on
commit after this one (which gets a
On Mon, Jan 20, 2014 at 03:09:14AM +0100, Tom Wijsman wrote:
On Sat, 18 Jan 2014 20:15:57 -0800 W. Trevor King wrote:
On Sun, Jan 19, 2014 at 02:33:06AM +0100, Tom Wijsman wrote:
On Sat, 18 Jan 2014 15:24:59 -0800 W. Trevor King wrote:
If it doesn't need to get updated, then it probably
The current fetch() function is quite long, which makes it hard to
know what I can change without adverse side effects. By pulling this
logic out of the main function, we get clearer logic in fetch() and
more explicit input for the config extraction.
Following a suggestion by Tom Wijsman, I put
Make this easier to read by avoiding nested conditionals [1].
[1]: http://article.gmane.org/gmane.linux.gentoo.portage.devel/4058
Reported-by: Tom Wijsman tom...@gentoo.org
---
pym/portage/package/ebuild/fetch.py | 30 ++
1 file changed, 14 insertions(+), 16
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
The current fetch() function is quite long, which makes it hard to
know what I can change without adverse side effects. By pulling this
logic out of the main function, we get clearer logic in fetch() and
more explicit input for the config extraction.
---
pym/portage/package/ebuild/fetch.py | 50
digging deeper into the test suite.
Cheers,
Trevor
[1]: https://bugs.gentoo.org/show_bug.cgi?id=175612
W. Trevor King (3):
pym/portage/package/ebuild/fetch.py: Factor out
_get_checksum_failure_max_tries
pym/portage/package/ebuild/fetch.py: Factor out _get_fetch_resume_size
pym/portage
The current fetch() function is quite long, which makes it hard to
know what I can change without adverse side effects. By pulling this
logic out of the main function, we get clearer logic in fetch() and
more explicit input for the config extraction.
This block was especially complicated, so I
On Sun, Jan 19, 2014 at 02:33:06AM +0100, Tom Wijsman wrote:
On Sat, 18 Jan 2014 15:24:59 -0800
W. Trevor King wk...@tremily.us wrote:
If it doesn't need to get updated, then it probably already
started out explaining the consensus ;).
That is a guess, you can look this up in past patches
On Thu, Jan 16, 2014 at 06:05:50PM +0100, Alexander Berntsen wrote:
On 16/01/14 17:45, W. Trevor King wrote:
I love Signed-off-by, but in all projects where I've seen it used
it means the signer is agreeing to some form of a Developer's
Certificate of Origin [1]. Without such a DCO, I
On Thu, Jan 16, 2014 at 07:54:57PM +, Duncan wrote:
And one final note: A signed-off-by is a useful indicator of a patch that
an author considers ready to go, pending review, etc. Lack of that (from
a seasoned submitter who is familiar with the process) can be an
indication that the
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
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
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
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 when
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
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 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
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
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
59 matches
Mail list logo
