On Wed, 18 Feb 2009 23:24:25 +
Ciaran McCreesh wrote:
> http://git.pioto.org/gitweb/paludis.git?a=commitdiff;h=86dc61e
Thanks. I hope it helps.
jer
On Thu, 19 Feb 2009 00:39:28 +0100
Stelian Ionescu wrote:
> could the output of paludis --info be made a little less verbose by
> eliminating repository information - perhaps except then one
> containing the package's ebuild
That's useful information, so no.
> and info about ebuild phases being
On Wed, 2009-02-18 at 23:24 +, Ciaran McCreesh wrote:
> On Thu, 19 Feb 2009 00:03:24 +0100
> Jeroen Roovers wrote:
> > On Wed, 18 Feb 2009 22:55:06 +
> > Ciaran McCreesh wrote:
> > > ...which is why you ask for 'paludis --info pkg', not 'paludis
> > > --info'.
> >
> > Spread the word!
>
On Thu, 19 Feb 2009 00:03:24 +0100
Jeroen Roovers wrote:
> On Wed, 18 Feb 2009 22:55:06 +
> Ciaran McCreesh wrote:
> > ...which is why you ask for 'paludis --info pkg', not 'paludis
> > --info'.
>
> Spread the word!
http://git.pioto.org/gitweb/paludis.git?a=commitdiff;h=86dc61e
--
Ciaran
On Wed, 18 Feb 2009 22:55:06 +
Ciaran McCreesh wrote:
> Heck, Paludis even tells you this if you run --info without a spec:
>
> > No packages were specified on the command line, so detailed
> > information is not available (Paludis can display detailed
> > information for both installed and
On Wed, 18 Feb 2009 22:55:06 +
Ciaran McCreesh wrote:
> ...which is why you ask for 'paludis --info pkg', not 'paludis
> --info'.
Spread the word!
jer
On Wed, 18 Feb 2009 23:22:12 +0100
Jeroen Roovers wrote:
> Paludis users often seem to think that `paludis --info' and `emerge
> --info' are interchangeable, whereas a quick inspection reveals to
> even the most casual user that the former only intends to inform about
> paludis' own compile time a
On Wed, 18 Feb 2009 23:35:00 +0100
Dawid Węgliński wrote:
> On Wednesday 18 of February 2009 23:22:12 Jeroen Roovers wrote:
> > In short, `paludis --info' is not a replacement, and when `emerge
> > --info' is asked for in a bug report, post *that*.
>
> Hi Jeroen.
> If you ask me to post a emerge
On Wednesday 18 of February 2009 23:22:12 Jeroen Roovers wrote:
> In short, `paludis --info' is not a replacement, and when `emerge
> --info' is asked for in a bug report, post *that*.
Hi Jeroen.
If you ask me to post a emerge --info you will get very, but very outdated
info. Not much useful. Kee
Hi folks,
both in #gentoo and more importantly in bug reports, people are often
asked to provide their `emerge --info', which gives a quick and
very useful overview of the most important bits found on the system that
wants support or (allegedly) exhibits a bug. Based on that information
it i
On 19:08 Wed 18 Feb , Ciaran McCreesh wrote:
> On Wed, 18 Feb 2009 14:01:44 -0500
> Michael Sterrett wrote:
> > It's already fixed.
>
> And have you learned not to try such blatantly irresponsible and
> childish behaviour on a tree used by other people?
This email would better be sent in pri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
> The check was committed to repoman right after the meeting. But as there
> hasn't been a release since it's not globally available. zmedico: Is
> there a new release coming or should a new revision be made?
I expect to do a relea
Mike Auty wrote:
> Petteri Räty wrote:
>> So until we have a decision on what the replacement will be I
>> don't see a need to remove current prepalldocs usage but any new usage
>> must be avoided.
>
> If it's simply discouraged, perhaps a repoman check, and some people to
> come forward with a be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
> So until we have a decision on what the replacement will be I
> don't see a need to remove current prepalldocs usage but any new usage
> must be avoided.
If it's simply discouraged, perhaps a repoman check, and some people to
com
There seems to be lot of confusion and discussion on the prepalldocs
issue so let me try to clear the air and present my own view on the
matter. This is effectively what was voted on in the council meeting:
20:35 < dev-zero> prepalldocs should be kept internal and usage should
be avoided
20:36 < d
> On Wed, 18 Feb 2009, Ciaran McCreesh wrote:
> Because if you look at the statistics, it's pretty obvious that it's
> a stupid idea. If you've got USE=doc, somewhere around 4% of managed
> files are in /usr/share/doc, and once you take inode sizes into
> account, you can knock that down to ab
On Wed, 18 Feb 2009 18:36:11 +
Ciaran McCreesh wrote:
> On Wed, 18 Feb 2009 19:28:46 +0100
> Alexis Ballier wrote:
> > > If you don't explicitly need compression, don't do anything.
> >
> > ... and mark relevant stuff as "ok to be compressed with whatever
> > suits you best"... sounds famil
On Wed, 18 Feb 2009 14:01:44 -0500
Michael Sterrett wrote:
> It's already fixed.
And have you learned not to try such blatantly irresponsible and
childish behaviour on a tree used by other people?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Am Mittwoch, den 18.02.2009, 12:26 +0200 schrieb Petteri Räty:
> Michael Sterrett wrote:
> > I added a prepalldocs function to eutils.eclass to provide the
> > functionality. It implements the
> > behavior of the current stable sys-apps/portage-2.1.6.4.
> >
> > Have fun,
> >
> > Michael Sterrett
On Wed, 18 Feb 2009 20:01:04 +0100
Alexis Ballier wrote:
> > If you really, genuinely think you have a case for compression of
> > docs, backed up with statistics showing that it's a relevant change,
>
> I fail to see why you need statistics for something that is clearly a
> waste of space, but t
It's already fixed.
> If you really, genuinely think you have a case for compression of
> docs, backed up with statistics showing that it's a relevant change,
I fail to see why you need statistics for something that is clearly a
waste of space, but this could be a start:
http://archives.gentoo.org/gentoo-dev/msg_9018
On 03:07 Wed 18 Feb , Michael Sterrett wrote:
> I added a prepalldocs function to eutils.eclass to provide the
> functionality. It implements the behavior of the current stable
> sys-apps/portage-2.1.6.4.
FYI, this addition broke a number of X packages. Hopefully it didn't
break much else
On Wed, 18 Feb 2009 19:28:46 +0100
Alexis Ballier wrote:
> > If you don't explicitly need compression, don't do anything.
>
> ... and mark relevant stuff as "ok to be compressed with whatever
> suits you best"... sounds familiar? :)
No. That's entirely the wrong approach, because it relies upon
On Wed, 18 Feb 2009 14:06:46 +
Ciaran McCreesh wrote:
> On Wed, 18 Feb 2009 08:39:58 +0100
> Alexis Ballier wrote:
> > Then, for the nth time, what would be the good solution?
>
> If you explicitly need compression, do it by hand, since there aren't
> any mechanisms for guaranteed compressi
On Wed, 18 Feb 2009 16:46:30 +0100
Ulrich Mueller wrote:
> > Yup. It's a misfeature. You can see this by considering the
> > proportion of ebuilds that honour it...
>
> All ebuilds that install things with "dodoc" at least. That must be
> quite a few.
But it's not universal, nor consistent. That
> On Wed, 18 Feb 2009, Ciaran McCreesh wrote:
>> You mean if the user has requested compression with
>> PORTAGE_COMPRESS, ignore it?
> Yup. It's a misfeature. You can see this by considering the
> proportion of ebuilds that honour it...
All ebuilds that install things with "dodoc" at least.
On Wed, 18 Feb 2009 16:18:03 +0100
Ulrich Mueller wrote:
> > If you don't explicitly need compression, don't do anything.
>
> You mean if the user has requested compression with PORTAGE_COMPRESS,
> ignore it?
Yup. It's a misfeature. You can see this by considering the proportion
of ebuilds that
> On Wed, 18 Feb 2009, Ciaran McCreesh wrote:
> If you don't explicitly need compression, don't do anything.
You mean if the user has requested compression with PORTAGE_COMPRESS,
ignore it? What about FEATURES="nodoc", ignore it too?
> And if you're trying to make a space-critical distributi
On Wed, 18 Feb 2009 08:39:58 +0100
Alexis Ballier wrote:
> Then, for the nth time, what would be the good solution?
If you explicitly need compression, do it by hand, since there aren't
any mechanisms for guaranteed compression anyway.
If you don't explicitly need compression, don't do anything.
On Wed, Feb 11, 2009 at 07:02:12PM +0100, Santiago M. Mola wrote:
> Hello,
> app-vim/exheres-syntax
I can take this one, I use it every day.
--
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-
Thilo Bangert wrote:
> Thomas Anderson said:
>> Hi Everyone,
>>
>> This is a note that in the council meeting on 02/12/2009 the
>> function 'prepalldocs' is banned for use in ebuilds with EAPIs 0 1
>> and 2. If you want some functionality from this function, please
>> propose a new
Michael Sterrett wrote:
> I added a prepalldocs function to eutils.eclass to provide the
> functionality. It implements the
> behavior of the current stable sys-apps/portage-2.1.6.4.
>
> Have fun,
>
> Michael Sterrett
> -Mr. Bones.-
> mr_bon...@gentoo.org
>
I don't think developers should add
* Michael Sterrett :
> Patches welcome.
--- eutils.eclass
+++ eutils.eclass
@@ -1823,21 +1823,3 @@
newbin "${tmpwrapper}" "${wrapper}" || die
fi
}
-
-# @FUNCTION: prepalldocs
-# @USAGE:
-# @DESCRIPTION:
-# Compress files in /usr/share/doc which are not already
-# compresse
> On Wed, 18 Feb 2009, Alexis Ballier wrote:
> Then, for the nth time, what would be the good solution? How would
> one convert prepalldocs usage to something allowed? I've failed to
> find anything about it in the relevant bug and the only answer I've
> seen is "remove it". You can count on m
Patches welcome.
On Wed, Feb 18, 2009 at 3:13 AM, Torsten Veller wrote:
> * Michael Sterrett :
>> I added a prepalldocs function to eutils.eclass to provide the
>> functionality. It implements the
>> behavior of the current stable sys-apps/portage-2.1.6.4.
>
> ecompressdir is more portage intern
* Michael Sterrett :
> I added a prepalldocs function to eutils.eclass to provide the
> functionality. It implements the
> behavior of the current stable sys-apps/portage-2.1.6.4.
ecompressdir is more portage internal than prepalldocs ever was.
This must be fixed.
I added a prepalldocs function to eutils.eclass to provide the
functionality. It implements the
behavior of the current stable sys-apps/portage-2.1.6.4.
Have fun,
Michael Sterrett
-Mr. Bones.-
mr_bon...@gentoo.org
On Fri, Feb 13, 2009 at 4:30 PM, Thomas Anderson wrote:
> Hi Everyone,
>
>T
38 matches
Mail list logo
