On Mon, 24 Jan 2011 02:23:41 +0100
Kevin Kofler kevin.kof...@chello.at 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
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
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 trying
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]
2011/1/24 Kevin Kofler kevin.kof...@chello.at:
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
On Sun, 23 Jan 2011 06:11:30 +0100
Kevin Kofler kevin.kof...@chello.at 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
On Sun, 23 Jan 2011 06:16:05 +0100
Kevin Kofler kevin.kof...@chello.at 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
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 scripts,
Kevin Fenzi wrote:
On Mon, 17 Jan 2011 09:28:10 +0100
Thomas Moschny thomas.mosc...@gmail.com 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
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
2011/1/18 Toshio Kuratomi a.bad...@gmail.com:
+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
On Mon, 17 Jan 2011 09:28:10 +0100
Thomas Moschny thomas.mosc...@gmail.com wrote:
2011/1/17 Kevin Fenzi ke...@scrye.com:
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
On Mon, 17 Jan 2011 09:28:10 +0100
Thomas Moschny thomas.mosc...@gmail.com 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
2011/1/17 Simo Sorce sso...@redhat.com:
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
On Tue, Jan 18, 2011 at 01:06:53AM +0100, Thomas Moschny wrote:
2011/1/17 Simo Sorce sso...@redhat.com:
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
--
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].
2011/1/16 Jon Ciesla l...@jcomserv.net:
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
On Sun, Jan 16, 2011 at 10:16:37PM +0100, Thomas Moschny wrote:
2011/1/16 Jon Ciesla l...@jcomserv.net:
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
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
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
20 matches
Mail list logo
