On Mon, 2006-03-20 at 15:45 -0800, Bret Towe wrote:
perhaps having some proxys of a sort that accept patchs and such
from trusted users that would commit fixes to portage would help.
similiar to the kernel format that way users can 'commit'/help out quickly
without having to go thru the long
Jonathan Coome posted
[EMAIL PROTECTED], excerpted below,
on Wed, 22 Mar 2006 10:49:29 +:
Taking this idea a bit further, what about proxy maintainers? There seem
to be quite a few packages that are being effectively maintained by
users on bugzilla, but are not in portage because they
On 3/22/06, Duncan [EMAIL PROTECTED] wrote:
A possible alternative that could be rolled out sooner would be some form
of contrib eclass. Make it a simple matter to inherit contrib and get
the standard contrib warnings and handling. One thing the eclass could
handle would be a USE=contrib
A developer could then take these ebuilds, make sure they
don't do anything malicious, or break QA, or whatever, and act as the
bridge between the portage tree and the users actually working on the
ebuild and keeping things up to date and working.
The easiest way to handle contrib as far
The process for getting unstable ebuilds from bugzilla to portage could
even be automated to the extent that when an ebuild is put into
bugzilla it gets auto committed to the tree but masked unstable.
I don't think that auto committing user submitted ebuilds is safe,
even if they are masked.
Asking developers to proxy takes almost as much time as it does to
ask them to maintain a package by themselves. The developer is
directly responsible for anything he commits, so he will have to still
test the ebuild, still test any revisions, and still follow the
package to make sure there are
Hi Daniel,
On 3/20/06, Daniel Drake [EMAIL PROTECTED] wrote:
One of the bigger problems is that we have a huge user community who are
keen on contributing, but we have such a high barrier for entry to the
developer community. Quite rightly so - we're dealing with a live tree,
so we can't give
On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote:
Asking developers to proxy takes almost as much time as it does to
ask them to maintain a package by themselves. The developer is
directly responsible for anything he commits, so he will have to still
test the ebuild, still test any
This is the summary of the IRC meeting the Gentoo Linux Security Team had on
Monday, March 20, 20:00 UTC in #gentoo-security (freenode).
A raw IRC log of the meeting can be found here:
http://dev.gentoo.org/~dercorny/security/sec-meeting-20060320.log
Agenda was:
---
1/ Project status
Stuart Herbert wrote:
I've been very happy with using svn+trac overlays to bridge this gap.
They provide a sandbox for contributions to be shared and evaluated.
They provide a place where I've been able to give commit access to
non-devs, so that they can learn the ropes w/out threatening the
On Wednesday 22 March 2006 12:03, Donnie Berkholz wrote:
Stuart Herbert wrote:
I've been very happy with using svn+trac overlays to bridge this gap.
They provide a sandbox for contributions to be shared and evaluated.
They provide a place where I've been able to give commit access to
On Wed, 22 Mar 2006 09:03:38 -0800 Donnie Berkholz
[EMAIL PROTECTED] wrote:
| This definitely sounds like a fun idea. It would be even cooler if we
| were using a distributed SCM on both ends that allowed for easy
| merging.
Word of warning to anyone planning to implement one of these that
On Wed, 2006-03-22 at 09:03 -0800, Donnie Berkholz wrote:
Stuart Herbert wrote:
I've been very happy with using svn+trac overlays to bridge this gap.
They provide a sandbox for contributions to be shared and evaluated.
They provide a place where I've been able to give commit access to
This definitely sounds like a fun idea. It would be even cooler if we
were using a distributed SCM on both ends that allowed for easy merging.
Donnie
It's probably the right time for me to flesh out what I've been
planning for overlays.g.o.
The vision I have for overlays.g.o is one official
Hi all,
There aren't really any remaining blockers to keep modular X out of
~arch, as far as I can see.
If anyone's got one, please bring it up now. I'm planning to unmask
later tonight.
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
On Wed, 2006-22-03 at 15:16 -0800, Donnie Berkholz wrote:
Hi all,
There aren't really any remaining blockers to keep modular X out of
~arch, as far as I can see.
If anyone's got one, please bring it up now. I'm planning to unmask
later tonight.
If modular X is used and
On Mar 22, 2006, at 4:13 PM, Olivier Crete wrote:
If modular X is used and gnome-base/control-center is not
patched..
gnome-settings-daemon on some evdev combinations...
Not sure if that's a blocker... but we should rush in a new version of
control-center with the patch
Nah, not a
On Wednesday 22 March 2006 19:59, Donnie Berkholz wrote:
On Mar 22, 2006, at 4:13 PM, Olivier Crete wrote:
If modular X is used and gnome-base/control-center is not
patched..
gnome-settings-daemon on some evdev combinations...
Not sure if that's a blocker... but we should rush in a
On Wed, Mar 22, 2006 at 08:20:01PM -0500, Mike Frysinger wrote:
On Wednesday 22 March 2006 19:59, Donnie Berkholz wrote:
On Mar 22, 2006, at 4:13 PM, Olivier Crete wrote:
If modular X is used and gnome-base/control-center is not
patched..
gnome-settings-daemon on some evdev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I've written a patch [1] that adds support for tracing python. It uses pythons
debugger hooks [2] to trace execution events (mostly function calls and
returns).
The patch causes python tracing to be enabled in --debug mode if
Paul Marks wrote:
Paul Marks wrote:
I couldn't get my lirc-0.8.0 to compile with the new kernel 2.6.16,
so I pulled a couple files out of CVS and generated this patch. It
works for me on 2.6.16 now.
Sorry, I think I may have sent this to the wrong list. I better go
read more carefully and
I was thinking about it, too, and found something i do like maybe more.
It would be not binary, but code dependancy. This is limited to
specific languages, then, but after all, there may also be different
binary dependencies, too [for example, you may depend on fonts
images from another package].
I hope you did read my previous mail of code dependancy -- if not, it's
at the end of message. This here is not so much overthought thing, but
a good starting point, maybe, if code deps are used.
Anyway, i give here the same idea in more complete form and good syntax
(good, because it could be
On Wed, 2006-03-22 at 19:40 +0200, tvali wrote:
I was thinking about it, too, and found something i do like maybe
more. It would be not binary, but code dependancy. This is limited to
specific languages, then, but after all, there may also be different
binary dependencies, too [for example,
2006/3/22, Patrick Lauer [EMAIL PROTECTED]:
There are a few reasons why this won't work :-)First: What if I have assembler? python? perl?Your example is limited to the C preprocessor.
Yes that i did tell there that it's limited to c already :) but bin
dep, after all, is limited to lib dependencies
As an addition to code deps discussion.
I didnt understand exactly, why bin deps were supposed to be better
than what we have now, as i am not yet exactly sure what we have :)
Anyway, i see one basic plus of code deps. It's that you may have huge
number of codelines, all containing #defines and
On Tue, 2006-21-03 at 10:50 -0600, MIkey wrote:
tvali wrote:
So, if portage would be looked as lists and operations with lists
(calculating dependencies of package would be operation with list of
that package and list of all - portage tree -, then); building tools
[shell commands] for
27 matches
Mail list logo
