Hi Ana, Alexander, Thanks a lot for looking into this! I guess I should explain a bit of the context to make it clear why we don't want to just disable this entirely ...
On Tue, Sep 09, 2008 at 01:14:14AM +0200, Ana Guerrero wrote: > On Tue, Sep 09, 2008 at 12:21:57AM +0200, Ana Guerrero wrote: > > On Mon, Sep 08, 2008 at 10:34:53PM +0200, Alexander Reichle-Schmehl wrote: > > > Hi! > > > > > > Ana Guerrero schrieb: > > > > DEBIAN_WXFLAVOUR := $(shell pwd | sed -e '[EMAIL > > > > PROTECTED]/wxwidgets[0-9.]\+-\?\(.*\)[EMAIL PROTECTED]@') > > > [..] > > > > Ideal fix would be fixing the whole debian/rules, At a first glance the ideal fix might be fixing sbuild :) but I don't know why it changed to do what it's doing now, and I somehow doubt that will happen too. It does seem independently ugly and troublesome that it's mangling directory names in ways that other build mechanisms don't though ... > > > > Anyway, I guess this version of wxwidgets is meant to dissapear post > > > > lenny? Hard to say. Both this and 2.8 are probably candidates to vanish for squeeze. Which one vanishes first depends a lot on the app authors. There are stable apps which have not been able to be forward ported from wx2.4 still -- and from the sounds of how 3.x is going that's going to be repeated again when it finally arrives on the scene. So this is very much 'wait and see' material ... > > > Did you see Matt Kraai fix for #489077? Seems to be the same Problem, > > > and his fix is a oneliner, just changing how the content of that > > > variable is generated. > > > > > > Should work here, too. > > > > I did not fully read that bug report, but yes the second problem listed > > there > > is the same. That fix will work as well because it creates an empty > > DEBIAN_WXFLAVOUR value, if you still keep a build log of your upload, please > > check if the options: --with-flavour= are followed by something. (My guess > > is > > they don't) > > > > I just took a look to the amd64 buildd upload of your NMU [1] and > DEBIAN_WXFLAVOUR does not take a value with this solution either. > > You just can check in the debian/rules that the lines that contains: > --with-flavour=$(DEBIAN_WXFLAVOUR) \ > are replaced by: > --with-flavour= > in the buildd log :) > > Actually, this worked as expected (generating the "flavour" string) before > patching it when using sbuild, it is just the rest of the rules is wrong. > My patch is meant to be a work around instead of change the rest of the > debian/rules that is what it should be done. The flavour string _is_ supposed to come up empty for the default package builds, and likewise _is_ supposed to have a value if the build has been locally flavoured. The reason for this is two-fold: - The 'flavoured' packages are constructed so as to be able to be installed concurrently with distro packages of the same version. - The flavoured packages can be selected at build time by using the --flavour option of wx-config. This is important because wx can be built in many optional configurations not all of which are suitable for the distro, but some of which are essential for particular applications and use cases. Some optional components would taint the lib with a different licence, some would bring in other deps that apps in the distro don't need, and most users probably don't want. The only way to handle that well is to let people build their own. But since they may not be binary compatible with the distro libs, forcing people to uninstall or rebuild (if even possible) all the distro apps they use seems unworkable. Since it only seems to be the python -dbg build that is failing here, and the changes to add it and the pycentral support are relatively new and may not have been tested properly with this mechanism, then if they are buggy we should either remove or fix them. Changing the regex to read the flavour from the changelog instead of the dir name was the first thing that occurred to me when I read your initial report too -- my main doubt about that is why didn't I do it that way in the first place... especially since I'm reading the release version from the changelog immediately below that ... Unfortunately, this has been stable for a very long time now, so it's going to take a while to recall the details, if I can at all. I'll have a look through some old history and see what memories it jogs. It does seem to me that any fix here should not just cripple the flavour mechanism though. I need to look in a bit more detail to understand why you think 'the rest of the rules (are) wrong'... Since this is failing in things that were added relatively recently and not by myself, that may be true -- and if the fallout of the sbuild changes are localised to those changes, then they should probably be fixed while we have a clear example and test of why they are broken... this won't get easier later either. In the meantime, I'll try to recall why the decision to check both the dir name and changelog version was made, but if the dirname is now unreliable and can be mangled by autobuilders, we probably don't have a lot of choice but to get the flavour from the changelog ... I suspect the reason may be if you change the flavour in the changelog without also changing the dirname, then it will break in not totally dissimilar ways to what sbuild has done by changing just the dirname -- has anyone checked that the patched wx2.8 can still build with a flavour? I'll put a beer on (even though it's too early in my morning to be gambling on hunches or drinking beer) that this has just removedi one sanity check for users building local flavoured packages in favour of accommodating sbuild more tolerantly. So yeah. UGH. But we know a bit more about this now than we did last week, so that's a start ... does anyone have a pointer for me about why sbuild has done this? Cheers, Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
