2011/1/24 Kevin Kofler :
> Simo Sorce wrote:
>> You are free to volunteer to do that, I am not going to do it for
>> samba4, I simply do not have the time to waste on such a thing.
>> (Samba4 people are in strict contact with the waf author and use
>> regularly the svn version du jour to fix build
On Mon, 2011-01-24 at 16:52 +0100, Kevin Kofler wrote:
> Simo Sorce wrote:
> > We can easily test for rpath,
>
> But who does it on all packages regularly? AutoQA is still vaporware.
Because you haven't taken the time to familiarize yourself with a
project doesn't make it vaporware. AutoQA [1] w
Simo Sorce wrote:
> You are free to volunteer to do that, I am not going to do it for
> samba4, I simply do not have the time to waste on such a thing.
> (Samba4 people are in strict contact with the waf author and use
> regularly the svn version du jour to fix build bugs they found, good
> luck tr
Simo Sorce wrote:
> We can easily test for rpath,
But who does it on all packages regularly? AutoQA is still vaporware.
> Then you should love waf, as it ships only source code, no generated
> code at all. In this it is much better than autoconf/automake/libtool
> I guess this is a point in favor
On Mon, 24 Jan 2011 02:23:41 +0100
Kevin Kofler wrote:
> But all that's really required is to get the existing build scripts
> to work with the system version of waf.
You are free to volunteer to do that, I am not going to do it for
samba4, I simply do not have the time to waste on such a thing.
On Mon, 24 Jan 2011 02:49:04 +0100
Kevin Kofler wrote:
> Simo Sorce wrote:
> > A build system is not a a shared library, and it is not code that
> > runs on the built system.
>
> But it can affect the built code, i.e. the one "that runs on the
> built system", in several ways, e.g. it can mishan
Simo Sorce wrote:
> A build system is not a a shared library, and it is not code that runs
> on the built system.
But it can affect the built code, i.e. the one "that runs on the built
system", in several ways, e.g. it can mishandle our compiler flags (ending
up e.g. with broken or missing debug
Simo Sorce wrote:
> Bring out technical deficiencies and real reasons why you can have a
> mile long makefile in your project and not a mile long set of python
> scripts, and then we can start discussing on the merits of each
> solution.
The issue isn't that there's "a mile long set of python scri
On Sun, 23 Jan 2011 06:16:05 +0100
Kevin Kofler wrote:
> Toshio Kuratomi wrote:
> > It's possible that it could be shown to be a copylib:
> > https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Copylibs
>
> That whole CONCEPT of a "copylib" is broken and it's sad that we're
> making ex
On Sun, 23 Jan 2011 06:11:30 +0100
Kevin Kofler wrote:
> Simo Sorce wrote:
> > As far as I know the waf author himself considers embedding the
> > right way to go for projetcs.
>
> That shows that that upstream is completely wacky and it's idiotic
> for ANY project to rely on his code!
Dear Kev
Toshio Kuratomi wrote:
> It's possible that it could be shown to be a copylib:
> https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Copylibs
That whole CONCEPT of a "copylib" is broken and it's sad that we're making
exceptions for those.
> But waf does make periodic releases so that m
Simo Sorce wrote:
> As far as I know the waf author himself considers embedding the right
> way to go for projetcs.
That shows that that upstream is completely wacky and it's idiotic for ANY
project to rely on his code!
> Samba4 (and soon talloc, tdb tevent, we are building them these days)
> do
Kevin Fenzi wrote:
> On Mon, 17 Jan 2011 09:28:10 +0100
> Thomas Moschny wrote:
>> It's not a matter of 'forcing' updates: As I said in my first post,
>> waf had, and has incompatible api changes (1.4 -> 1.5 in the bug
>> mentioned, and 1.5 -> 1.6 in this thread). Our policies explicitly
>> *forb
2011/1/18 Toshio Kuratomi :
> +1 to FPC blessing. Like I said, we can probably carve up something that
> explains both the waf POV and configure scripts here... but it'll need
> someone who knows waf to be able to explain, for instance, how waf differs
> from autoconf which has both a non-bundled
On Tue, Jan 18, 2011 at 01:06:53AM +0100, Thomas Moschny wrote:
> 2011/1/17 Simo Sorce :
> > The best thing is to not package waf on and in itself, and let package
> > embed the right version. At least until waf becomes mature enough that
> > the rate of change slows down to the point that option 1
2011/1/17 Simo Sorce :
> The best thing is to not package waf on and in itself, and let package
> embed the right version. At least until waf becomes mature enough that
> the rate of change slows down to the point that option 1 becomes
> feasible.
>
> Option 2 is just begging for maintenance nightm
On Mon, 17 Jan 2011 09:28:10 +0100
Thomas Moschny wrote:
> So we have these options (from hard to easy):
> - force packagers to patch their packages to run with system's waf
> - start packaging multiple versions of waf (e.g. waf16 for F-13 and
> F-14)
> - allow packages to embed a copy of waf
As
On Mon, 17 Jan 2011 09:28:10 +0100
Thomas Moschny wrote:
> 2011/1/17 Kevin Fenzi :
> > I can't speak to the other packages, but I can to midori.
> >
> > There have been at least 2 times that I can recall where midori
> > upstream updated the bundled version of waf they ship with, and the
> > fedo
2011/1/17 Kevin Fenzi :
> I can't speak to the other packages, but I can to midori.
>
> There have been at least 2 times that I can recall where midori
> upstream updated the bundled version of waf they ship with, and the
> fedora waf no longer builds it. This means we either have to use the
> bund
I can't speak to the other packages, but I can to midori.
There have been at least 2 times that I can recall where midori
upstream updated the bundled version of waf they ship with, and the
fedora waf no longer builds it. This means we either have to use the
bundled waf or force a update to the s
On Sun, 2011-01-16 at 13:31 -0800, Toshio Kuratomi wrote:
> But waf does make periodic releases so that might not be the right
> exception. If you could draw parallels between the autotools and waf, that
> might be a way to look at it. I'll note, though, that the autotools have
> a layer that is
On Sun, Jan 16, 2011 at 10:16:37PM +0100, Thomas Moschny wrote:
> 2011/1/16 Jon Ciesla :
> > Would you be so kind as to file BZs against midori and xiphos indicating
> > that they either need to switch to using system waf or file a Trac with
> > FPC for an exception if there's a really good reason
2011/1/16 Jon Ciesla :
> Would you be so kind as to file BZs against midori and xiphos indicating
> that they either need to switch to using system waf or file a Trac with
> FPC for an exception if there's a really good reason to bundle?
Could do that, but I think we should ask FPC for a general e
--
in your fear, seek only peace
in your fear, speak only love
-d. bowie
On Sun, 16 Jan 2011, Thomas Moschny wrote:
> Hi,
>
> just to let you know that I am going to update waf to 1.6.2 in rawhide and
> el-6.
> waf 1.6 is not fully compatible with 1.5. A migration guide is
> available here [1]
Hi,
just to let you know that I am going to update waf to 1.6.2 in rawhide and el-6.
waf 1.6 is not fully compatible with 1.5. A migration guide is
available here [1].
The following packages in Fedora have BRs set on waf:
midori-0:0.2.9-4.fc15.src
valide-0:0.7.0-7.20100923bzr557.fc15.src
xiphos-
25 matches
Mail list logo
