Fluidsynth 1.1.2

[Felipe Sateler]

On 12/09/10 19:08, Jonas Smedegaard wrote:
> On Sun, Sep 12, 2010 at 08:31:48PM +0200, David Henningsson wrote:
>> On 2010-09-12 12:32, Alessio Treglia wrote:
>>>> dpkg-buildpackage: full upload; Debian-native package (full source
>>>> is included)
>>>> Now running lintian...
>>>> W: fluidsynth source: debian-watch-file-in-native-package
>>>> W: fluidsynth source: native-package-with-dash-version
>>>> How do I avoid that?
>>>
>>> By switching to format 3.0 (quilt) [1], which allows us to strip
>>> upstream's debian directory without repacking the original tarball.
>>
>> Hmm, upstream (as in the original 1.1.2 tarball) does not have a
>> debian directory...?
>> Second theory, can this be related to that I never updated the
>> changelog? I was unsure of how to that with git-dch and all these
>> semi-automatic tools expecting things to be in a certain way. (will
>> "dch -i" do?)
> 
> Yes, this explains why git-buildpackage failed to generate a tarball
> from upstream + pristine-tar branches, and then (due to the lack of a
> tarball) dpkg-buildpackage assumed it was a native package and generated
> a tarball including (as is normal for native packages) the debian dir.
> 
> And yes, a simple "dch", "dch -i" or "dch -r", possibly with some some
> hand-editing of the changelog file, should do the trick: The topmost
> changelog entry must have an upstream version matching what you want to
> build.
> 
> 
>>>> Third, Squeeze is now frozen. Can this version still go into
>>>> unstable, or
>>>> does it have to go into experimental?
>>>
>>> I see several changes, so experimental would be the right place [2].
>>
>> There are several changes, although seen from my perspective, 1.1.2
>> contain quite important bug fixes, and I find it both more stable and
>> more tested than 1.1.1. Commenting on Launchpad bug #636473, I'm all
>> for having 1.1.2 in Maverick.
> 
> What could help is to file bugreports against the package currently
> targeted testing, and then tag those bugs as closed by the newer
> release.  That is the easiest way to help the release team judge if an
> exception should be made for this package.
> 

No. What would help the release team is an assessment of the impact the
changes between 1.1.1 and 1.1.2. The fact that bugs are reported or not
is not really relevant.

-- 
Saludos,
Felipe Sateler