> On Mon, 20 Sep 2010, Mike Frysinger wrote:
>> Isn't it better to skip compression on all tiny files (not only man
>> pages)? In such case some other functions will need to be updated
>> too (e.g. ecompress --suffix)...
> perhaps, but i think it should only be done on automatic dirs like
> d
On Monday, September 20, 2010 01:59:33 Peter Volkov wrote:
> В Вск, 19/09/2010 в 19:43 -0400, Mike Frysinger пишет:
> > 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
> On Sun, 19 Sep 2010, 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 a
В Пнд, 20/09/2010 в 04:53 +0200, Arfrever Frehtes Taifersar Arahesis
пишет:
> > 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 with incredibly excessive line length.
В Вск, 19/09/2010 в 19:43 -0400, Mike Frysinger пишет:
> 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 ove
В Вск, 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
On Sat, 18 Sep 2010 23:49:29 -0600
Ryan Hill wrote:
> # Ryan Hill (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. Reverted.
--
fonts, gcc-porting,
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
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 u
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 evaluated_
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 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 building and installing the newnet
> > option, and we make oldnet
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 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 building and installing the newnet
> option, and we make oldnet the default in the ebuild.
>
> People migrating from stable will know the
All,
looking at the tracker, I see that only two bugs remain which block
stabilization of openrc:
http://bugs.gentoo.org/213988
http://bugs.gentoo.org/302116
What does everyone think? Are there any other bugs we should fix before
targeting a release for stabilization?
I suppose one question
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/jmp2
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 fil
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
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:
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
On Sun, Sep 19, 2010 at 12:14 PM, Matti Bickel 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:
http://sources.gentoo
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 her
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 s
On Sun, 19 Sep 2010 16:10:15 +0300
Petteri Räty 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.
On the other side, sh
-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 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
On Sun, Sep 19, 2010 at 15:20, Krzysztof Pawlik 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 automatically g
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
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
29 matches
Mail list logo
