On 6/24/11 11:35 PM, Michał Górny wrote:
> Hello,
>
> git-2.eclass is in the tree for a while now, and there's still awful
> lot of packages using old & deprecated git.eclass.
>
> Why migrate?
Hi,
What are the pitfalls during migration? Or is it just /git/git-2/ ?
Thanks jusitn
signature.as
Hi,
I was signing my commits since I am a dev, but I just discovered that I
only do sha1 signing. How do I switch to sha256 signing?
justin
signature.asc
Description: OpenPGP digital signature
On Sat, 25 Jun 2011 09:11:16 +0200
justin wrote:
> On 6/24/11 11:35 PM, Michał Górny wrote:
> > Hello,
> >
> > git-2.eclass is in the tree for a while now, and there's still awful
> > lot of packages using old & deprecated git.eclass.
> >
> > Why migrate?
>
> What are the pitfalls during migra
On Sat, 25 Jun 2011 09:37:55 +0200
justin wrote:
> I was signing my commits since I am a dev, but I just discovered that
> I only do sha1 signing. How do I switch to sha256 signing?
$ grep digest ~/.gnupg/gpg.conf
personal-digest-preferences sha256,sha512,sha1,ripemd160,md5
--
Best regards,
M
On 06/25/2011 12:35 AM, Michał Górny wrote:
Hello,
git-2.eclass is in the tree for a while now, and there's still awful
lot of packages using old& deprecated git.eclass.
I think I remember seeing deprecation warnings in the past when an
ebuild was using a deprecated eclass (right at the begi
On Sat, Jun 25, 2011 at 02:49, Kent Fredric wrote:
> I'm strongly of the mind that by making the tag system arbitrarily
> flat, you might be prematurely limiting yourself, as well as risking a
> future where the "tag index" is a sea of meaningless words.
>
> Tags in my mind, should be grouped by t
On Tuesday 21 of June 2011 16:24:07 Michał Górny wrote:
> Hello,
>
> As we discussed for a while, the media-sound/ category has grown very
> large and it may be a good idea to split it.
>
> Right now, it contains audio players, editing software, converters,
> sound systems and a lot of other util
On Friday 24 of June 2011 09:55:19 Ciaran McCreesh wrote:
> On Fri, 24 Jun 2011 09:52:03 +0200
>
> Jesús J. Guerrero Botella wrote:
> > You might not like it, but Gentoo categories have always been
> > directories, not words into metadata.xml.
>
> So tags are in some way related to categories th
On 25 June 2011 23:55, Maciej Mrozowski wrote:
>
> IMHO the best approach is to forget about categories and:
>
> - make package names unique identifiers (it's not that hard, renaming stuff in
> app-xemacs mostly) - categories would serve no purpose as id anymore (though
> may need to be provided a
On Sat, 25 Jun 2011 13:55:40 +0200
Maciej Mrozowski wrote:
> On Friday 24 of June 2011 09:55:19 Ciaran McCreesh wrote:
> > On Fri, 24 Jun 2011 09:52:03 +0200
> >
> > Jesús J. Guerrero Botella wrote:
> > > You might not like it, but Gentoo categories have always been
> > > directories, not words
Hi all,
so I solved my signing question. With a 1024 DSA key you need to add
enable-dsa2
personal-digest-preferences SHA256
to your gpg.conf.
Another question, do we have a rule, how the metadata.xml has to be
indented? Tabs or n spaces?
thanks justin
signature.asc
Description: OpenPGP
On Sun, 26 Jun 2011 00:22:39 +1200
Kent Fredric wrote:
> Perhaps we need a new way to apply metadata to a whole host of
> packages?
>
> Also, categories have extra use for simple convenience of their native
> groupings, ie: I've been known to set USE flags/KEYWORDS that apply to
> an entire cate
On Sat, Jun 25, 2011 at 1:26 PM, Nikos Chantziaras wrote:
> On 06/25/2011 12:35 AM, Michał Górny wrote:
>>
>> Hello,
>>
>> git-2.eclass is in the tree for a while now, and there's still awful
>> lot of packages using old& deprecated git.eclass.
>
> I think I remember seeing deprecation warnings i
On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
> Another question, do we have a rule, how the metadata.xml has to be
> indented? Tabs or n spaces?
>
There's no rule, but we should follow the same rule as ebuilds —
indentation should be with a tab that's displayed as 4 spaces in
editors (no expans
On Sat, Jun 25, 2011 at 08:22, Kent Fredric wrote:
> I think something else that may be important to consider if one is
> eliminating category directories is how we'll replace the utility
> currently provided by category/metadata.xml
>
> Some things are simply grossly impractical to maintain indiv
Maciej Mrozowski posted on Sat, 25 Jun 2011 13:55:40 +0200 as excerpted:
> On Friday 24 of June 2011 09:55:19 Ciaran McCreesh wrote:
>> So tags are in some way related to categories then?
>
> IMHO the best approach is to forget about categories and:
>
> - make package names unique identifiers (
On Saturday 25 of June 2011 17:19:47 Duncan wrote:
> Maciej Mrozowski posted on Sat, 25 Jun 2011 13:55:40 +0200 as excerpted:
> > On Friday 24 of June 2011 09:55:19 Ciaran McCreesh wrote:
> >> So tags are in some way related to categories then?
> >
> > IMHO the best approach is to forget about cat
On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
> On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
>> Another question, do we have a rule, how the metadata.xml has to be
>> indented? Tabs or n spaces?
>
> There's no rule, but we should follow the same rule as ebuilds —
> indentation should be
> On Sat, 25 Jun 2011, Maciej Mrozowski wrote:
> Assuming package names are unique identifiers, tags are not
> necessary to be available for ebuild.sh so metadata.xml is the best
> place.
But we know that package names are _not_ unique. There are many cases
in the Portage tree where two or ev
On Sat, Jun 25, 2011 at 10:54 PM, Mike Frysinger wrote:
> On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
>> On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
>>> Another question, do we have a rule, how the metadata.xml has to be
>>> indented? Tabs or n spaces?
>>
>> There's no rule, but we s
On Saturday 25 of June 2011 19:29:58 Ulrich Mueller wrote:
> > On Sat, 25 Jun 2011, Maciej Mrozowski wrote:
> > Assuming package names are unique identifiers, tags are not
> > necessary to be available for ebuild.sh so metadata.xml is the best
> > place.
>
> But we know that package names are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 25-06-2011 14:23, Nirbheek Chauhan wrote:
> On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
>> Another question, do we have a rule, how the metadata.xml has to be
>> indented? Tabs or n spaces?
>>
>
> There's no rule, but we should follow the sam
On 26 June 2011 05:29, Ulrich Mueller wrote:
>> On Sat, 25 Jun 2011, Maciej Mrozowski wrote:
>
>> Assuming package names are unique identifiers, tags are not
>> necessary to be available for ebuild.sh so metadata.xml is the best
>> place.
>
> But we know that package names are _not_ unique. Th
Hi all,
I've been busy for the past month or two, busy updating some of my
systems. In particular, the Yeeloong I have, hasn't seen attention in a
very long time. Soon as I update one part however, I find some swath of
packages break because of a soname change, anything Python-related stops
work
On Sat, Jun 25, 2011 at 21:47, Kent Fredric wrote:
> Package names themselves can be thusly arbitrary , and could be a SHA
> sum or something obscure, as long as all internals and dependencies
> used the same arbitrary name, things would work as intended.
>
I mentioned this idea of internally refe
Stuart Longland posted on Sun, 26 Jun 2011 12:59:05 +1000 as excerpted:
> Currently we have three packages that handle this separately:
> - revdep-rebuild (handles packages broken by soname changes, etc)
> - python-updater (handles Python module rebuilds after upgrading Python)
> - perl-cleaner (h
On 26 June 2011 15:49, Wyatt Epp wrote:
> As for the latter part, the size of a git repo becoming umanageable
> over time had not occurred to me, I'm afraid-- would it work to use
> shallow clones? Otherwise, the herd-wise division is probably
> acceptable. Need to think about that one more.
On Sun, Jun 26, 2011 at 4:59 AM, Stuart Longland wrote:
> - revdep-rebuild (handles packages broken by soname changes, etc)
solved by preserved-libs in portage-2.2
> - python-updater (handles Python module rebuilds after upgrading Python)
> - perl-cleaner (handles Perl module rebuilds after upgr
On 26 June 2011 17:44, Benedikt Böhm wrote:
> these just exist because python and perl ebuilds are horribly broken.
> take a look at RUBY_TARGETS or PHP_TARGETS for an example of how to do
> it right. this would also fix all the failures that python and perl
> introduce to binary packages.
Perl d
On 26 June 2011 14:59, Stuart Longland wrote:
> Hi all,
>
> I've been busy for the past month or two, busy updating some of my
> systems. In particular, the Yeeloong I have, hasn't seen attention in a
> very long time. Soon as I update one part however, I find some swath of
> packages break beca
30 matches
Mail list logo
