I assume many of us have wrapper scripts to automatically generate
matching ChangeLog and CVS commit messages. When we eventually move to
git the plan is for the ChangeLog to be automatically generated from
git. To unify developer practices and to ease the transition to git it
has been proposed to
On 09/19/10 15:10, Petteri Räty wrote:
I assume many of us have wrapper scripts to automatically generate
matching ChangeLog and CVS commit messages. When we eventually move to
git the plan is for the ChangeLog to be automatically generated from
git. To unify developer practices and to ease
On Sun, Sep 19, 2010 at 15:20, Krzysztof Pawlik nelch...@gentoo.org wrote:
On 09/19/10 15:10, Petteri Räty wrote:
I assume many of us have wrapper scripts to automatically generate
matching ChangeLog and CVS commit messages. When we eventually move to
git the plan is for the ChangeLog to be
On 19-09-2010 16:10:15 +0300, Petteri Räty wrote:
I assume many of us have wrapper scripts to automatically generate
matching ChangeLog and CVS commit messages. When we eventually move to
git the plan is for the ChangeLog to be automatically generated from
git. To unify developer practices and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It should be possible to still maintain this distinction, something like:
Version bump. Added feature foo.
- --
Feature foo required a complete rewrite of src_install.
And then the ChangeLog generation can happen separately. The problem
with this
On Sun, 19 Sep 2010 16:10:15 +0300
Petteri Räty betelge...@gentoo.org wrote:
One open question is what should repoman do if there is already a
modification to the ChangeLog file.
I suggest reverting the ChangeLog modification. That's what my
sunrise-commit [1] does, and it works quite well.
I'm a couple weeks late with this, but here goes:
from my failed attempts at reviving GLEP33 grow a discussion with
ferringb on IRC about how to get what I wanted anyway :)
We agreed that having eclasses specific to a package located someplace
near the actual ebuilds was beneficial and should be
Wouldn't it also make sense to have per-category eclasses? This seems much
more useful for me.
Examples where this would already make sense today: kde-meta, latex-package, ...
Best, Andreas
On Sunday 19 September 2010 21:14:56 Matti Bickel wrote:
I'm a couple weeks late with this, but here
On Sun, Sep 19, 2010 at 12:14 PM, Matti Bickel m...@gentoo.org wrote:
I'm a couple weeks late with this, but here goes:
from my failed attempts at reviving GLEP33 grow a discussion with
ferringb on IRC about how to get what I wanted anyway :)
I've placed my immediate feedback in CVS:
Matti Bickel posted on Sun, 19 Sep 2010 21:14:56 +0200 as excerpted:
It is made a requirement that per-package eclasses can not modify the
``EAPI`` variable. It is assumed ``EAPI``, if it set, is set before
calling pkg-inherit.
Backwards Compatibility
===
The current
many man pages exist merely as a redirect to another man page:
$ xzcat /usr/share/man/man1/zcat.1.xz
.so man1/gzip.1
compressing these tiny (always?) results in a larger file. that means we
arent saving space, and we're adding overhead at runtime.
two options which we can do transparently:
On 09/19/2010 04:43 PM, Mike Frysinger wrote:
many man pages exist merely as a redirect to another man page:
$ xzcat /usr/share/man/man1/zcat.1.xz
.so man1/gzip.1
compressing these tiny (always?) results in a larger file. that means we
arent saving space, and we're adding overhead at
On Sunday, September 19, 2010 19:50:57 Zac Medico wrote:
On 09/19/2010 04:43 PM, Mike Frysinger wrote:
many man pages exist merely as a redirect to another man page:
$ xzcat /usr/share/man/man1/zcat.1.xz
.so man1/gzip.1
compressing these tiny (always?) results in a larger file. that
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2010-09-19 23h59 UTC.
Removals:
media-gfx/kst 2010-09-13 16:37:23 ayoy
dev-libs/linux-fusion 2010-09-13 19:06:07 mr_bones_
dev-java/jmp
On Mon, Sep 20, 2010 at 5:57 AM, William Hubbs willi...@gentoo.org wrote:
I suppose one question I need to ask is the oldnet vs newnet question.
The git repository defaults to building and installing the newnet
option, and we make oldnet the default in the ebuild.
People migrating from stable
This patch for python.eclass has been divided into 3 subpatches to simplify
review.
Subpatch #1 fixes preservation of whitespace.
Subpatch #2 renames 2 local arrays in python_mod_optimize() function:
site_packages_absolute_dirs - dirs
site_packages_absolute_files - files
Subpatch #3 adds
On Mon, Sep 20, 2010 at 06:05:46AM +0530, Nirbheek Chauhan wrote:
On Mon, Sep 20, 2010 at 5:57 AM, William Hubbs willi...@gentoo.org wrote:
I suppose one question I need to ask is the oldnet vs newnet question.
The git repository defaults to building and installing the newnet
option, and we
On Sunday, September 19, 2010 21:22:06 William Hubbs wrote:
On Mon, Sep 20, 2010 at 06:05:46AM +0530, Nirbheek Chauhan wrote:
On Mon, Sep 20, 2010 at 5:57 AM, William Hubbs wrote:
I suppose one question I need to ask is the oldnet vs newnet question.
The git repository defaults to
On Sunday, September 19, 2010 21:18:51 Arfrever Frehtes Taifersar Arahesis
wrote:
-evaluated_PYTHONPATH=$(eval echo -n ${PYTHONPATH_template})
+eval evaluated_PYTHONPATH=\${PYTHONPATH_template}\
the quotes in the 2nd one are useless. this should work the same:
eval
2010-09-20 03:45:14 Mike Frysinger napisał(a):
On Sunday, September 19, 2010 21:18:51 Arfrever Frehtes Taifersar Arahesis
wrote:
-evaluated_PYTHONPATH=$(eval echo -n ${PYTHONPATH_template})
+eval evaluated_PYTHONPATH=\${PYTHONPATH_template}\
the quotes in the 2nd one are useless. this
On Sunday, September 19, 2010 22:53:31 Arfrever Frehtes Taifersar Arahesis
wrote:
2010-09-20 03:45:14 Mike Frysinger napisał(a):
while you're in the process of cleaning things up, i know we dont have a
rule anywhere in terms of line length, but python.eclass has always
struck me as a file
On Sat, 18 Sep 2010 23:49:29 -0600
Ryan Hill dirtye...@gentoo.org wrote:
# Ryan Hill dirtye...@gentoo.org (19 Sep 2010)
# Mask for removal 20101019 (bug #304621).
# Use font-cronyx-cyrillic instead.
media-fonts/cronyx-fonts
Turns out font-cronyx-cyrillic isn't a suitable replacement.
В Вск, 19/09/2010 в 16:17 +0100, Mike Auty пишет:
It should be possible to still maintain this distinction, something like:
Version bump. Added feature foo.
- --
Feature foo required a complete rewrite of src_install.
And then the ChangeLog generation can happen separately. The problem
23 matches
Mail list logo
