Hello,
I would like to propose a new attempt at Manifest signatures. Instead
of using a single per-Manifest signature, we would keep separate
signatures for each of the files, as an additional (optional) hash
type.
Motivation
--
The current signing approach gives all the responsibility f
On 3 October 2010 13:28, Michał Górny wrote:
> Hello,
>
> I would like to propose a new attempt at Manifest signatures. Instead
> of using a single per-Manifest signature, we would keep separate
> signatures for each of the files, as an additional (optional) hash
> type.
>
>
> Motivation
> ---
Hi all,
As a step towards minor version slotting of PHP, we need allow PHP
extensions to compile against multiple versions of PHP and the attached
eclasses allow for just that. In addition, there are numerous cleanups,
such as the merging of php-ext-base and php-ext-source, dropping
dependency on
On 2 October 2010 20:54, Jorge Manuel B. S. Vicetto
wrote:
> Given the recent activity around .la files and conflict about how to
> deal with them, I propose we discuss this issue in this mailing list,
> and take this issue to the council.
> That way, we can make a global decision, taking into acc
On 10/03/2010 07:53 AM, David Leverton wrote:
> Would it be too much trouble to have a standardised variable that
> means .la files should be kept? It maybe /shouldn't/ be exposed as a
> USE flag because very few people will need it, but if it's easy to
> implement (maybe by having an eutils funct
On 3 October 2010 14:20, Richard Freeman wrote:
> Such a solution would also have the virtue of allowing the use of USE
> dependencies. So, you would only install the .la files from a
> particular library if another package actually needed them. Packages
> could also have USE defaults as seems l
On 10/02/2010 06:26 PM, Nirbheek Chauhan wrote:
My opinions haven't changed one bit in the past week. I don't see how
not breaking the stable tree can be called being "overly
conservative".
you have a quite broad definition of "breaking".
- clean slate emerge works before and after.
- adding a
On 10/03/2010 01:53 PM, David Leverton wrote:
While I do agree that the underlying problem we're trying to solve is
worth solving, I do have a couple of small concerns about how it's
being done. The first is that it seems people are judging whether a
particular .la file is "needed" by checking w
On Sun, Oct 3, 2010 at 7:41 PM, Luca Barbato wrote:
> On 10/02/2010 06:26 PM, Nirbheek Chauhan wrote:
>>
>> My opinions haven't changed one bit in the past week. I don't see how
>> not breaking the stable tree can be called being "overly
>> conservative".
>
> you have a quite broad definition of "
On 3 October 2010 15:29, Luca Barbato wrote:
> I think the simpler solution is that if it needs .la, before reaching the
> tree it has to be fixed...
What I'm not keen about that is that using the .la files isn't really
"broken" - if libfoo uses libtool, and some other software uses
libfoo's .la
On 03-10-2010 12:53, David Leverton wrote:
> On 2 October 2010 20:54, Jorge Manuel B. S. Vicetto
> wrote:
>> Given the recent activity around .la files and conflict about how to
>> deal with them, I propose we discuss this issue in this mailing list,
>> and take this issue to the council.
>> That
On 03-10-2010 15:29, Luca Barbato wrote:
> On 10/03/2010 01:53 PM, David Leverton wrote:
>> While I do agree that the underlying problem we're trying to solve is
>> worth solving, I do have a couple of small concerns about how it's
>> being done. The first is that it seems people are judging wheth
On Sunday 03 October 2010 10:32:38 Andreas HAttel (dilfridge) wrote:
> dilfridge10/10/03 14:32:38
>
> Modified: ChangeLog
> Added:latex-beamer-3.10.ebuild
> Log:
> Version bump
>
dev-tex/translator is included in this release and should be handled better
The patch for distutils.eclass is divided into 2 subpatches:
Subpatch #1 fixes a typo in a regular expression and removes needless '/'
characters.
Subpatch #2 replaces checks for SUPPORT_PYTHON_ABIS variable with more portable
calls
to _python_package_supporting_installation_for_multiple_python_a
I discussed this ~half an hour ago with radhermit on #gentoo-dev, and we
agreed to mask -3.10 for a few days until it is sorted out.
That's already done, he forwarded me your e-mail with recommendations and I'll
follow it and check the translator files in detail during the week.
Cheers, Andr
On Sunday 03 October 2010 16:13:17 Andreas K. Huettel wrote:
> I discussed this ~half an hour ago with radhermit on #gentoo-dev, and we
> agreed to mask -3.10 for a few days until it is sorted out.
>
> That's already done, he forwarded me your e-mail with recommendations and
> I'll follow it and c
On Sun, Oct 03, 2010 at 09:58:48AM +0200, Micha?? G??rny wrote:
> The current signing approach gives all the responsibility for Manifest
> signature to the developer who committed last update to the ebuild
> directory regardless of the actual commit significance.
>
> Consider the following: Dev A
Le 03/10/2010 16:29, Luca Barbato a écrit :
> I think the simpler solution is that if it needs .la, before reaching
> the tree it has to be fixed...
Using libltdl (libtool's dlopen wrapper) is a *legitimate* use of .la
files. Those programs do not need to be fixed as they are not broken.
The disc
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2010-10-03 23h59 UTC.
Removals:
app-admin/conary2010-09-27 07:25:16 djc
app-admin/conary-policy 2010-09-27 07:32:39 djc
app-admin/rmake 2010-09-
On 10/04/2010 12:00 AM, Rémi Cardona wrote:
Using libltdl (libtool's dlopen wrapper) is a*legitimate* use of .la
files. Those programs do not need to be fixed as they are not broken.
To my knowledge ltdl would load just fine the .so if the .la isn't found.
lu
--
Luca Barbato
Gentoo/linux
ht
On 10/03/2010 06:57 PM, Angelo Arrifano wrote:
Was libtool deprecated or something? Judging by your reply, it really
made me think so.
once everybody moves to scons/ffconf/whatever sure
The farther we walk from upstream, the greater is the quantity of work
we have to do to maintain their
David Leverton posted on Sun, 03 Oct 2010 16:39:39 +0100 as excerpted:
> Also, not every piece of software that people might want to use is going
> to go into the main tree - people can use Gentoo to develop their own
> software (and might have their own ideas (or their company/project's
> ideas)
22 matches
Mail list logo