Dnia 2014-09-16, o godz. 12:30:59
Alan McKinnon alan.mckin...@gmail.com napisał(a):
On 16/09/2014 12:18, hasufell wrote:
Ulrich Mueller:
ChangeLogs are aimed at users
Did any1 ask them if they care?
I'm a user and I don't care.
I use diff. I only go to the Changelog when I can't
Dnia 2014-09-16, o godz. 10:52:13
W. Trevor King wk...@tremily.us 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
Dnia 2014-09-16, o godz. 10:18:35
hasufell hasuf...@gentoo.org napisał(a):
Ulrich Mueller:
ChangeLogs are aimed at users
Did any1 ask them if they care?
A bit off-topic but asking such a question usually makes some
developers point out that they are users too and they do care :).
On Wed, 17 Sep 2014, Michał Górny wrote:
Dnia 2014-09-16, o godz. 10:18:35
hasufell hasuf...@gentoo.org napisał(a):
Ulrich Mueller:
ChangeLogs are aimed at users
Did any1 ask them if they care?
A bit off-topic but asking such a question usually makes some
developers point out that
On 2014-09-16 14:40, hasufell wrote:
Michael Orlitzky:
To put things in perspective, all I had to do was ask for commit access
and somebody eventually gave it to me. We should worry about this when
breaking SHA1 becomes less expensive than the ebuild quizzes.
Yep, that's what I'd try to
On Wed, 17 Sep 2014 07:04:08 -0400
Aaron W. Swenson titanof...@gentoo.org wrote:
This is what's been driving me batty. None of you verified my identity
before letting me be an official Gentoo Developer.
Why does that matter?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
If someone wants to commit malicious code into Gentoo, they're far more
likely to take the ugly but pragmatic approach of, say, forcing someone to
commit malicious code at gunpoint and then shooting them, than to go to the
vast effort it would take to come up with malicious code that conveniently
On Wed, 17 Sep 2014 07:21:08 -0400
Tim Boudreau niftin...@gmail.com wrote:
If someone wants to commit malicious code into Gentoo, they're far
more likely to take the ugly but pragmatic approach of, say, forcing
someone to commit malicious code at gunpoint and then shooting them,
than to go to
On Tue, Sep 16, 2014 at 7:47 PM, Luca Barbato lu_z...@gentoo.org wrote:
The bc utility is part of the posix tools and it might be used to build
linux among the other stuff.
I'm fine with including useful utilities in the stage3s, as long as
they don't go into the system set. We really need to
On 2014-09-17 12:08, Ciaran McCreesh wrote:
On Wed, 17 Sep 2014 07:04:08 -0400
Aaron W. Swenson titanof...@gentoo.org wrote:
This is what's been driving me batty. None of you verified my identity
before letting me be an official Gentoo Developer.
Why does that matter?
My argument is Git
On Wed, 17 Sep 2014, Luca Barbato wrote:
The bc utility is part of the posix tools and it might be used to build
linux among the other stuff.
Luca,
bc is not in the system set and is a dependency of the kernel or any other
package that needs it, so why do we need to include a package that
On Wed, Sep 17, 2014 at 5:56 AM, Ulrich Mueller u...@gentoo.org wrote:
So the research that needs to be done first is to find out how often
our ChangeLog entries differ from the commit log. If it turns out that
they are identical in 99 % of all cases, then it obviously makes no
sense to
Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto:
On Wed, 17 Sep 2014, Luca Barbato wrote:
The bc utility is part of the posix tools and it might be used to build
linux among the other stuff.
Luca,
bc is not in the system set and is a dependency of the kernel or any
other
On 2014-09-17 14:20, viv...@gmail.com wrote:
Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto:
On Wed, 17 Sep 2014, Luca Barbato wrote:
The bc utility is part of the posix tools and it might be used to build
linux among the other stuff.
Luca,
bc is not in the system set
On 17/09/2014 14:49, Aaron W. Swenson wrote:
On 2014-09-17 14:20, viv...@gmail.com wrote:
Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto:
On Wed, 17 Sep 2014, Luca Barbato wrote:
The bc utility is part of the posix tools and it might be used to build
linux among the other stuff.
On Wed, Sep 17, 2014 at 9:29 AM, Alan McKinnon alan.mckin...@gmail.com wrote:
On 17/09/2014 14:49, Aaron W. Swenson wrote:
Agreed. I've been on -user for 10+ years and only a very few fetch their
kernels directly from upstream. The vast majority of users who have
described how they do it
There was a thread a while back about mix-in support and I think there
was genuine interest. For the most part we just need to do the work,
and the first step is identifying blockers. If some end up involving
PMS/etc then we may need to get the Council involved.
Rather than hijacking every
On 17/09/14 16:29, Alan McKinnon wrote:
On 17/09/2014 14:49, Aaron W. Swenson wrote:
On 2014-09-17 14:20, viv...@gmail.com wrote:
Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto:
On Wed, 17 Sep 2014, Luca Barbato wrote:
The bc utility is part of the posix tools and it might be
Daniel Campbell:
As a prospective Gentoo developer, having a guide around meant
specifically for Gentoo's practices would be incredibly helpful. I use
git in my own hobby development and learned from Pro Git, et al, but
it'd still be really nice to have, and give developers a place to
point
On Wed, Sep 17, 2014 at 11:28 AM, hasufell hasuf...@gentoo.org wrote:
NOTE: you may skip running repoman another time if you have manually
verified that the commits you are missing are totally unrelated to your
work (e.g. only affect a package that is not in the dependency chain of
yours). You
On 09/17/14 10:13, Samuli Suominen wrote:
On 17/09/14 16:29, Alan McKinnon wrote:
On 17/09/2014 14:49, Aaron W. Swenson wrote:
On 2014-09-17 14:20, viv...@gmail.com wrote:
Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto:
On Wed, 17 Sep 2014, Luca Barbato wrote:
The bc utility is
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
On 09/17/2014 09:58 AM, Rich Freeman wrote:
There was a thread a while back about mix-in support and I think there
was genuine interest. For the most part we just need to do the work,
and the first step is identifying blockers. If some end up involving
PMS/etc then we may need to get the
On Wed, Sep 17, 2014 at 07:21:08AM -0400, Tim Boudreau wrote:
If someone wants to commit malicious code into Gentoo, they're far more
likely to take the ugly but pragmatic approach of, say, forcing someone to
commit malicious code at gunpoint and then shooting them, than to go to the
vast
On Mon, 15 Sep 2014 14:51:56 -0400
Rich Freeman ri...@gentoo.org wrote:
In general you want each commit to represent a single change. That
might be a revbump in a single package, or it might be a package move
that involves touching 300 packages in a single commit.
Is it right that you are
On Wed, Sep 17, 2014 at 3:25 PM, Rick Zero_Chaos Farina
zeroch...@gentoo.org wrote:
The funtoo mixin system has absolutely nothing to do with adding
packages to stage3 that are not in @system.
Primarily adding packages to stage3 (or stage4 if we choose to call it
that) would only need us to
Dnia 2014-09-17, o godz. 12:36:16
Ciaran McCreesh ciaran.mccre...@googlemail.com napisał(a):
On Wed, 17 Sep 2014 07:21:08 -0400
Tim Boudreau niftin...@gmail.com wrote:
If someone wants to commit malicious code into Gentoo, they're far
more likely to take the ugly but pragmatic approach of,
Rich Freeman posted on Wed, 17 Sep 2014 09:58:46 -0400 as excerpted:
[Mix-in support] For the most part we just need to do the work, and the
first step is identifying blockers. If some end up involving PMS/etc
then we may need to get the Council involved.
Rather than hijacking every
Ciaran McCreesh posted on Wed, 17 Sep 2014 12:36:16 +0100 as excerpted:
On Wed, 17 Sep 2014 07:21:08 -0400 Tim Boudreau niftin...@gmail.com
wrote:
If someone wants to commit malicious code into Gentoo, they're far more
likely to take the ugly but pragmatic approach of, say, forcing someone
Hello,
The PowerPC development team has had our 2nd monthly meeting and I
wanted to provide an update on where we are.
1) Active Developers
The following are activly working on PPC/PPC64 as far as I know.
If I've listed you in error, please let me know.
Agostino Sarubbo (ago) - stablereq
On 18 September 2014 08:02, Diamond diam...@hi-net.ru wrote:
Git doesn't do this by default and it
will might be a nightmare to compare such revbumps by hand.
git diff -M1 -C1
^ is usually sufficient to show new files as differences between similar
files that were already there, including
On Wed, Sep 17, 2014 at 4:02 PM, Diamond diam...@hi-net.ru wrote:
On Mon, 15 Sep 2014 14:51:56 -0400
Rich Freeman ri...@gentoo.org wrote:
In general you want each commit to represent a single change. That
might be a revbump in a single package, or it might be a package move
that involves
I could use some help with bugs at,
http://bugs.gentoo.org/showdependencytree.cgi?id=479818hide_resolved=1
Specifically with x11-libs/fox bug
https://bugs.gentoo.org/show_bug.cgi?id=520674 because it's an library,
I'm almost ashamed my patch efforts to it have failed, I keep running
from one
On 18 September 2014 13:01, Rich Freeman ri...@gentoo.org wrote:
With git a revbump is:
cp foo-1.ebuild foo-2.ebuild
git add foo-2.ebuild
git commit
(I left out changelogs, repoman, etc, since there is no change with
any of these, and I left out syncing the git repo.)
There really is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 17/09/14 00:13, Zac Medico wrote:
I all looks very well done to me now. I'd encourage others on the
list to review it now, in case there's anything that I missed.
At a glance, it looks OK to me. You can commit it if you vouch for it,
Zac.
- --
On 09/17/2014 09:28 AM, Brian Dolbec wrote:
On Fri, 12 Sep 2014 11:12:27 -0700
Zac Medico zmed...@gentoo.org wrote:
Since self._dynamic_config._slot_operator_deps only contains deps for
packages added to the graph, it doesn't contain potentially relevant
deps of installed packages that have
On 09/17/2014 12:14 AM, Alexander Berntsen wrote:
On 17/09/14 00:13, Zac Medico wrote:
I all looks very well done to me now. I'd encourage others on the
list to review it now, in case there's anything that I missed.
At a glance, it looks OK to me. You can commit it if you vouch for it,
Zac.
Thanks Alexander and Zac for your review!
I'll add documentation for profile-env.
Do you prefer having it in the same patch or in a separate one ?
Bertrand
On Wed, Sep 17, 2014 at 11:02 AM, Zac Medico zmed...@gentoo.org wrote:
On 09/17/2014 12:14 AM, Alexander Berntsen wrote:
On 17/09/14
On 09/17/2014 11:12 AM, Bertrand Simonnet wrote:
Thanks Alexander and Zac for your review!
I'll add documentation for profile-env.
Do you prefer having it in the same patch or in a separate one ?
I'm not too particular, but all in one patch sounds good to me.
--
Thanks,
Zac
On 09/17/2014 02:28 PM, Michał Górny wrote:
diff --git a/pym/portage/repository/config.py
b/pym/portage/repository/config.py
index 5e0d055..ef8054e 100644
--- a/pym/portage/repository/config.py
+++ b/pym/portage/repository/config.py
@@ -40,7 +40,7 @@ if sys.hexversion = 0x300:
Michal, not opposed to splitting the patch into three parts.
I'd rather use the env/ mechanism instead of the package.env one as it is
more flexible.
It also feels better as ebuild.sh will walk the profiles to source the
bashrc script so a bashrc from a
low priority profile may override a
Please find the patch split into three smaller patch:
* refactoring: contains the Michal's suggestions. I also removed the
whitespace changes.
* profile attributes export: same as in the previous patch
* profile-env patch: uses has to check if profile-env is set. I also
included the documentation
42 matches
Mail list logo
