On 12/20/2014 01:11 PM, Zac Medico wrote:
For tests, override portage.const.EPREFIX in order to avoid unwanted
access to /etc/portage. This override may seem evil, but it is a
convenient way to simulate a prefix install, and it is reasonable to do
this because tests should be self-contained
On Sat, Jan 17, 2015 at 01:44:21PM +0100, Dirkjan Ochtman wrote:
On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer patr...@gentoo.org wrote:
* Stage3 archives are too fat
See https://bugs.gentoo.org/show_bug.cgi?id=531632
We're now shipping three python versions and glib for extra
On Sat, Jan 17, 2015 at 12:00 PM, William Hubbs willi...@gentoo.org wrote:
On Sat, Jan 17, 2015 at 01:44:21PM +0100, Dirkjan Ochtman wrote:
On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer patr...@gentoo.org wrote:
* Stage3 archives are too fat
See
The previous default emerge --backtrack=10 setting could lead to lots
of wasted cpu time in cases where it will ultimately fail to find a
valid solution anyway. Therefore, reduce the default to --backtrack=3.
In order for the BacktrackingTestCase.testBacktrackNoWrongRebuilds to
succeed, the test
On 01/17/2015 04:07 AM, Sergei Trofimovich wrote:
For consistency and defense against future copy/paste errors
converted all uses of ${EAPI} for ${EAPI-0} in 'bin/eapi.sh'.
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
bin/eapi.sh | 90
On Sat, 17 Jan 2015 19:35:09 +0800
Patrick Lauer patr...@gentoo.org wrote:
* AutoRepoman catches issues, but no one but me seems to care
Fix: Remind people of
http://packages.gentooexperimental.org/repoman-current-issues.txt
I've tweaked two random things in this list :)
Thank you!
--
On 01/17/2015 03:35 AM, Patrick Lauer wrote:
* Portage is too slow
On 'small' hardware emerge -upNDv @world can take enough time
to make updates prohibitive - on an 800Mhz machine it took me
about 3 days to figure out a solution to some silly blockers due to the
very slow
On 01/17/2015 05:16 AM, Michał Górny wrote:
Fix module_names enumeration to consider all modules. Before, the first
module on the list was omitted ('cvs' in this case).
Another thing is, the CVS module is completely, utterly and inevitably
broken. And the whole syncing thing is a great pile
On 01/17/2015 05:55 AM, Michał Górny wrote:
Print single Syncing repository '%s' into '%s'... before syncing,
and single === Sync completed for %s after successful sync.
Remove duplicate in-module clone/pull messages. Instead, verbosely print
git commands executed.
Remove useless
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
# Manuel Rüger mr...@gentoo.org (17 Jan 2015)
# Unmaintained. Old eclasses, EAPIs and various bugs.
# See bug #533642
# Removal in 30 days.
rox-base/mime-editor
rox-base/oroborox
rox-base/pager
rox-base/rox
rox-base/rox-autostart
On Saturday 17 January 2015 15:03:05 Ciaran McCreesh wrote:
On Sat, 17 Jan 2015 22:58:33 +0800
Patrick Lauer patr...@gentoo.org wrote:
On Saturday 17 January 2015 14:32:03 Ciaran McCreesh wrote:
On Sat, 17 Jan 2015 21:03:30 +0800
Patrick Lauer patr...@gentoo.org wrote:
Last
On 01/17/2015 03:10 AM, Michał Górny wrote:
---
pym/portage/util/compression_probe.py | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
LGTM.
BTW, I've verified that all the the new entries in _decompressors
support -c and -q, as required by BinpkgExtractorAsync.
--
On 01/17/2015 03:58 AM, Michał Górny wrote:
Support sync-clone-depth with the default set to 1. This allows the user
to reduce the number of historical commits fetched along with the
repository (git --depth).
---
man/portage.5 | 4
On 01/17/2015 04:28 AM, Michał Górny wrote:
Discard the git-rev-parse error output to avoid 'fatal: Not a git
repository [...]' errors when checking whether the repository exists.
---
pym/portage/sync/modules/git/git.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Saturday 17 January 2015 14:00:34 William Hubbs wrote:
On Sat, Jan 17, 2015 at 01:44:21PM +0100, Dirkjan Ochtman wrote:
On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer patr...@gentoo.org
wrote:
* Stage3 archives are too fat
See https://bugs.gentoo.org/show_bug.cgi?id=531632
On 01/17/2015 04:46 PM, Patrick Lauer wrote:
On Saturday 17 January 2015 13:12:56 Zac Medico wrote:
On 01/17/2015 03:35 AM, Patrick Lauer wrote:
* Portage is too slow
On 'small' hardware emerge -upNDv @world can take enough time
to make updates prohibitive - on an 800Mhz machine it
On 01/17/2015 02:45 AM, Michał Górny wrote:
Default MAKEOPTS job number to (number of CPUs + 1) when it is not
provided in the ebuild environment.
Suggested-By: Daniel Robbins drobb...@funtoo.org
---
pym/portage/package/ebuild/doebuild.py | 8 +++-
pym/portage/util/cpuinfo.py
Patrick Lauer:
On Saturday 17 January 2015 17:25:15 hasufell wrote:
Patrick Lauer:
On Friday 16 January 2015 18:29:08 hasufell wrote:
Patrick Lauer:
On 01/16/15 23:26, hasufell wrote:
Patrick Lauer (patrick):
patrick 15/01/16 04:16:55
Modified: ChangeLog
Added:
On 01/17/2015 08:22 PM, Zac Medico wrote:
On 01/17/2015 02:45 AM, Michał Górny wrote:
Default MAKEOPTS job number to (number of CPUs + 1) when it is not
provided in the ebuild environment.
Suggested-By: Daniel Robbins drobb...@funtoo.org
---
pym/portage/package/ebuild/doebuild.py | 8
On 01/17/2015 12:20 PM, Zac Medico wrote:
On 01/17/2015 04:07 AM, Sergei Trofimovich wrote:
For consistency and defense against future copy/paste errors
converted all uses of ${EAPI} for ${EAPI-0} in 'bin/eapi.sh'.
Signed-off-by: Sergei Trofimovich sly...@gentoo.org
---
bin/eapi.sh | 90
On 01/17/2015 09:35 AM, Michał Górny wrote:
Fix the svn sync module since it doesn't work at all right now. More
specifically:
1. add exists() method that uses 'svn info' to determine whether
the repository was checked out already.
2. Fix the initial clone to use valid svn commands. Do
On Saturday 17 January 2015 13:12:56 Zac Medico wrote:
On 01/17/2015 03:35 AM, Patrick Lauer wrote:
* Portage is too slow
On 'small' hardware emerge -upNDv @world can take enough time
to make updates prohibitive - on an 800Mhz machine it took me
about 3 days to figure out a
On Saturday 17 January 2015 17:25:15 hasufell wrote:
Patrick Lauer:
On Friday 16 January 2015 18:29:08 hasufell wrote:
Patrick Lauer:
On 01/16/15 23:26, hasufell wrote:
Patrick Lauer (patrick):
patrick 15/01/16 04:16:55
Modified: ChangeLog
Added:
Dnia 2015-01-17, o godz. 14:07:46
Zac Medico zmed...@gentoo.org napisał(a):
On 01/17/2015 04:28 AM, Michał Górny wrote:
Discard the git-rev-parse error output to avoid 'fatal: Not a git
repository [...]' errors when checking whether the repository exists.
---
On 01/17/2015 09:36 AM, Michał Górny wrote:
Fix the cvs sync module since it doesn't work at all right now. More
specifically:
1. add exists() method that checks for the 'CVS' sub-directory to determine
whether the repository was checked out already.
2. Do not remove the just-created
On 01/17/2015 04:31 PM, Michał Górny wrote:
Dnia 2015-01-17, o godz. 14:07:46
Zac Medico zmed...@gentoo.org napisał(a):
On 01/17/2015 04:28 AM, Michał Górny wrote:
Discard the git-rev-parse error output to avoid 'fatal: Not a git
repository [...]' errors when checking whether the repository
On 2015-01-17 23:48, Zac Medico wrote:
Actually, Arfrever tells me that the multiprocessing module is not
available if python is built without threading support. So, we need to
handle the ImportError and either do nothing or parse /proc/cpuinfo or
something like that.
Feel free to
When checking for packages that will be matched by an autounmask USE
change, account for package visibility (masking), so that we can
generate more = atoms (as opposed to = atoms that only match very
specific versions). Don't do this for keyword or mask changes, since
that may cause undesired
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/17/2015 05:09 AM, Andrew Savchenko wrote:
On Sat, 17 Jan 2015 08:56:01 +0800 Patrick Lauer wrote:
On Friday 16 January 2015 18:29:08 hasufell wrote:
Patrick Lauer:
On 01/16/15 23:26, hasufell wrote:
Patrick Lauer (patrick):
patrick
Here's a random unsorted list of things that it would make sense to be upset
about. Some issues that people have successfully ignored for a few years ...
In no way exhaustive list, feel free to remember a dozen things I forgot ;)
(If you suggest other things please try to offer constructive
On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer patr...@gentoo.org wrote:
In no way exhaustive list, feel free to remember a dozen things I forgot ;)
(If you suggest other things please try to offer constructive criticism,
i.e. possible strategies to fix issues ... whining by itself is not very
On Saturday 17 January 2015 13:44:21 Dirkjan Ochtman wrote:
On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer patr...@gentoo.org wrote:
* AutoRepoman catches issues, but no one but me seems to care
Fix: Remind people of
On Sat, Jan 17, 2015 at 2:03 PM, Patrick Lauer patr...@gentoo.org wrote:
Most issues are transient, often fixed with either a keywording bug, or
careful
masking of useflags / pruning of old versions. Per-maintainer doesn't really
make sense as most issues are indirect - things like removing
El sáb, 17-01-2015 a las 19:35 +0800, Patrick Lauer escribió:
[...]
* stable genkernel still doesn't enable all useful kernel features
e.g. accounting statistics are absent, so iotop doesn't work ootb
See for example #442936 (from 2012 ?!)
Fix: Stable newer versions
I see there
El sáb, 17-01-2015 a las 13:44 +0100, Dirkjan Ochtman escribió:
[...]
Also, I hate something like
['dev-python/restkit[python_targets_python2_7(-)?,-python_single_target_python2_7(-)]'].
What the hell kind of warning is that? I guess maybe these are the
results of USE_EXPAND trickery and what
On Sat, 17 Jan 2015 21:03:30 +0800
Patrick Lauer patr...@gentoo.org wrote:
Last time I tested paludis it was slower
You've yet to do a like-for-like comparison...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 17 Jan 2015 19:35:09 +0800 Patrick Lauer wrote:
* Portage is too slow
On 'small' hardware emerge -upNDv @world can take enough time
to make updates prohibitive - on an 800Mhz machine it took me
about 3 days to figure out a solution to some silly blockers due to the
On Sat, 17 Jan 2015 17:39:29 +0300
Andrew Savchenko birc...@gentoo.org wrote:
There is some progress here. In portage-2.2.15 profile based
optimizations are included (see bugs 529660, 530010). On my
hardware (Athlon-XP, 2200 MHz and Intel Atom N270, 1600 MHz) they
speed up dependency
Am Samstag, 17. Januar 2015, 01:56:01 schrieb Patrick Lauer:
On Friday 16 January 2015 18:29:08 hasufell wrote:
Patrick Lauer:
On 01/16/15 23:26, hasufell wrote:
Patrick Lauer (patrick):
patrick 15/01/16 04:16:55
Modified: ChangeLog
Added:
On Saturday 17 January 2015 14:32:03 Ciaran McCreesh wrote:
On Sat, 17 Jan 2015 21:03:30 +0800
Patrick Lauer patr...@gentoo.org wrote:
Last time I tested paludis it was slower
You've yet to do a like-for-like comparison...
Hello hostile upstream.
It was as like for like as possible,
On Saturday 17 January 2015 14:45:51 Ciaran McCreesh wrote:
On Sat, 17 Jan 2015 17:39:29 +0300
Andrew Savchenko birc...@gentoo.org wrote:
There is some progress here. In portage-2.2.15 profile based
optimizations are included (see bugs 529660, 530010). On my
hardware (Athlon-XP, 2200 MHz
On Sat, 17 Jan 2015 22:59:08 +0800
Patrick Lauer patr...@gentoo.org wrote:
The problem isn't the constants, though. The problem is the
resolution algorithm. There's not much point tweaking performance
until the resolver is fixed to produce a correct answer...
Patches welcome :)
If I send
On Sat, 17 Jan 2015 22:58:33 +0800
Patrick Lauer patr...@gentoo.org wrote:
On Saturday 17 January 2015 14:32:03 Ciaran McCreesh wrote:
On Sat, 17 Jan 2015 21:03:30 +0800
Patrick Lauer patr...@gentoo.org wrote:
Last time I tested paludis it was slower
You've yet to do a like-for-like
On Sat, 17 Jan 2015 14:45:51 + Ciaran McCreesh wrote:
On Sat, 17 Jan 2015 17:39:29 +0300
Andrew Savchenko birc...@gentoo.org wrote:
There is some progress here. In portage-2.2.15 profile based
optimizations are included (see bugs 529660, 530010). On my
hardware (Athlon-XP, 2200 MHz and
* AutoRepoman catches on average maybe 2 user-visible breakages.
Fix: Make repoman faster (tree-wide scans take ~2 CPU-hours)
Fix: Remind people that using repoman is not optional
Fix: Make more repoman warnings fatal. Please.
Fix: Make the QA team deliver a friendly but stern warning
On Sat, 17 Jan 2015 18:33:45 +0300
Andrew Savchenko birc...@gentoo.org wrote:
Oh, this was discussed so many times already... There is NO single
correct solution to such problems. And some mathematically correct
solutions are impractical (e.g. half of the tree rebuild), so other
ones which are
On Sat, 17 Jan 2015 19:49:24 +0400
Сергей protsero...@gmail.com wrote:
Any random user can tell you: -u means UPDATE, -D means DEEP (follow
dependencies).
And what do those actually mean?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Dnia 2015-01-17, o godz. 19:35:09
Patrick Lauer patr...@gentoo.org napisał(a):
Here's a random unsorted list of things that it would make sense to be upset
about. Some issues that people have successfully ignored for a few years ...
In no way exhaustive list, feel free to remember a dozen
Patrick Lauer wrote:
they can all be fixed.
Let's not tolerate mediocrity.
All you can do is to try to set an example, but you'll likely find
that most of the time, nobody is willing to live with the tradeoffs
for excellence - the obvious one being perceived slower development.
Countless
Patrick Lauer:
On Friday 16 January 2015 18:29:08 hasufell wrote:
Patrick Lauer:
On 01/16/15 23:26, hasufell wrote:
Patrick Lauer (patrick):
patrick 15/01/16 04:16:55
Modified: ChangeLog
Added:libuv-1.2.1.ebuild
Log:
Bump
I expect people to ask
Patrick Lauer wrote:
Do you, as QA team member, think that a review workflow improves quality?
No.
Bureaucracy does not improve quality by itself.
A review workflow isn't about bureaucracy, it's about review. :)
Now, review means different things to different people, and some will
Hi everyone,
It looks like there aren't too many bugs against gcc-4.9 (bug #495124).
There are a couple having to do with lto and one which is hardened
specific, but its probably a good idea to start keywording on the
various arches so we can get more bug reports and not trail behind. So
I
Default MAKEOPTS job number to (number of CPUs + 1) when it is not
provided in the ebuild environment.
Suggested-By: Daniel Robbins drobb...@funtoo.org
---
pym/portage/package/ebuild/doebuild.py | 8 +++-
pym/portage/util/cpuinfo.py| 19 +++
2 files changed, 26
---
pym/portage/util/compression_probe.py | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/pym/portage/util/compression_probe.py
b/pym/portage/util/compression_probe.py
index 1dc3547..74f74b1 100644
--- a/pym/portage/util/compression_probe.py
+++
Support sync-clone-depth with the default set to 1. This allows the user
to reduce the number of historical commits fetched along with the
repository (git --depth).
---
man/portage.5 | 4
pym/portage/repository/config.py| 19 ++-
Observed as a breakage on binutils ebuilds:
ERROR: sys-devel/binutils-2.24-r3::gentoo failed (depend phase):
use() calls are not allowed in global scope
Call stack:
ebuild.sh, line 584: Called source 'binutils-2.24-r3.ebuild,
ebuild.sh, line 7: Called inherit
Discard the git-rev-parse error output to avoid 'fatal: Not a git
repository [...]' errors when checking whether the repository exists.
---
pym/portage/sync/modules/git/git.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pym/portage/sync/modules/git/git.py
Fix module_names enumeration to consider all modules. Before, the first
module on the list was omitted ('cvs' in this case).
Another thing is, the CVS module is completely, utterly and inevitably
broken. And the whole syncing thing is a great pile of terribly
mis-designed, unnecessarily complex
58 matches
Mail list logo
