Josh Boyer wrote:
> Encouraging openness and cooperation by threatening verbal abuse in
> the event of a mistake is not something the Fedora project wants to
> condone. Education and cooperative resolution of the problem is.
Uhm, no, bureaucracy and stubborn-by-design software is. :-(
I'd much r
On Sat, Dec 4, 2010 at 10:48 AM, Kevin Kofler wrote:
> Ralf Corsepius wrote:
>> To prevent overzealous maintainers, who believe to understand what they
>> are doing but actually don't, from doing harm to packages.
>
> Trust me, after I'm done yelling at them, they won't do that ever again. ;-)
En
Ralf Corsepius wrote:
> To prevent overzealous maintainers, who believe to understand what they
> are doing but actually don't, from doing harm to packages.
Trust me, after I'm done yelling at them, they won't do that ever again. ;-)
Kevin Kofler
--
devel mailing list
devel@lists.fedora
On 12/03/2010 10:11 PM, Kevin Kofler wrote:
> Adam Williamson wrote:
>> Thanks, Bruno! Reply goes for Ivana too. On the topic of Ivana not being
>> 'superuser' (I guess you meant provenpackager?), does it make sense for
>> anyone who maintains a library that other packages build against to be
>> gi
On 12/03/2010 01:45 PM, Adam Williamson wrote:
> On Fri, 2010-12-03 at 22:11 +0100, Kevin Kofler wrote:
>> Adam Williamson wrote:
>>> Thanks, Bruno! Reply goes for Ivana too. On the topic of Ivana not being
>>> 'superuser' (I guess you meant provenpackager?), does it make sense for
>>> anyone who m
On Fri, 2010-12-03 at 22:11 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > Thanks, Bruno! Reply goes for Ivana too. On the topic of Ivana not being
> > 'superuser' (I guess you meant provenpackager?), does it make sense for
> > anyone who maintains a library that other packages build again
Adam Williamson wrote:
> Thanks, Bruno! Reply goes for Ivana too. On the topic of Ivana not being
> 'superuser' (I guess you meant provenpackager?), does it make sense for
> anyone who maintains a library that other packages build against to be
> given provenpackager privileges, or at least automat
On 12/01/2010 07:19 PM, Adam Williamson wrote:
> On Wed, 2010-12-01 at 09:13 -0600, Bruno Wolff III wrote:
>> On Wed, Dec 01, 2010 at 10:31:59 +0100,
>> Dodji Seketeli wrote:
>>> Indeed. But just curious, how do one "arranges a tag"? Is this
>>> documented somewhere? Or you just have to file a t
On 12/01/2010 07:19 PM, Adam Williamson wrote:
> On Wed, 2010-12-01 at 09:13 -0600, Bruno Wolff III wrote:
>> On Wed, Dec 01, 2010 at 10:31:59 +0100,
>>Dodji Seketeli wrote:
>>>
>>> Indeed. But just curious, how do one "arranges a tag"? Is this
>>> documented somewhere? Or you just have to fil
On Wed, 2010-12-01 at 09:13 -0600, Bruno Wolff III wrote:
> On Wed, Dec 01, 2010 at 10:31:59 +0100,
> Dodji Seketeli wrote:
> >
> > Indeed. But just curious, how do one "arranges a tag"? Is this
> > documented somewhere? Or you just have to file a ticket?
>
> http://fedoraproject.org/wiki/Pack
On Wed, Dec 01, 2010 at 10:31:59 +0100,
Dodji Seketeli wrote:
>
> Indeed. But just curious, how do one "arranges a tag"? Is this
> documented somewhere? Or you just have to file a ticket?
http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo#Requesting_special_dist_tags
--
dev
On 11/30/2010 07:57 PM, Adam Williamson wrote:
> On Tue, 2010-11-30 at 18:03 +0100, Ivana Varekova wrote:
>> Hello,
>>
>> mpfr-3.0.0 is now build to rawhide branch and soname is bumped to 4.0.0
>> there.
>> MPFR 3.0.0 is binary incompatible with previous versions and also is not
>> completely API c
Adam Williamson writes:
[...]
>> The packages which depends on mpfr should be rebuild against the new
>> versio. The list is:
>
> It would be much better to either do the rebuilds yourself or arrange a
> tag for the new soname and ask the packagers of the below packages to
> rebuild them in the
On Tue, 2010-11-30 at 18:03 +0100, Ivana Varekova wrote:
> Hello,
>
> mpfr-3.0.0 is now build to rawhide branch and soname is bumped to 4.0.0
> there.
> MPFR 3.0.0 is binary incompatible with previous versions and also is not
> completely API compatible.
> The most important changes from version
Hello,
mpfr-3.0.0 is now build to rawhide branch and soname is bumped to 4.0.0
there.
MPFR 3.0.0 is binary incompatible with previous versions and also is not
completely API compatible.
The most important changes from versions 2.4.* to version 3.0.0
* MPFR is now distributed under the GNU L
15 matches
Mail list logo
