Hi Andreas,
On 11-11-14 07:44, Andreas Tille wrote:
> Hi Lennart,
>
> first of all I have uploaded
Much appreciated!
> (after `cme fix dpkg-control` which bumpes
> the Standards-Version and does some other polishing - I'd recommend
> running this command when intending to upload a new package revision.
>
Thanks for the tip. I've added it to my "publish-to-Debian-med-workflow"
document :-).
> On Mon, Nov 10, 2014 at 04:50:05PM +0100, L.C. Karssen wrote:
>> Hi Andreas,
>>
>> Thanks for having a look at my request.
>>
>> On 10-11-14 14:45, Andreas Tille wrote:
>>> Hi Lennart,
>>>
>>> could you please commit the pristine-tar branch as per Debian Med policy?
>>
>> Done. My apologies for forgetting that, I'm still struggling a bit with
>> git.
>
> I'd recommend to put Debian Med policy under your pillow. It helped me
> a lot when I started to learn the necessary Git bits with this document
> which was kindly written by some fellow team members. If you *always*
> use what is written there
>
> git import-orig --pristine-tar /path/to/package_version.orig.tar.gz
>
> you will most probably never face any trouble with missing pristine-tar.
Indeed, that's what I did. No problems there. I only forgot to push the
pristine-tar branch (at least I didn't do that explicitly).
>
>> I did the following:
>> git checkout pristine-tar
>>
>> Since it turned out that there were merge conflicts when I did a regular
>> 'git pull' I ran:
>> git pull -X theirs
>> git push
>>
>> Is this (checkout, pull, push) the correct way to do it? Or should I
>> have run `gbp-pull` to get all branches in and then run `git push --all
>> --tags` to push everything?
>
> There is no point at all to ever checkout pristine-tar. Usually
> everything works perfectly automatically even with a simple `git push`.
That's weird, because that was what I did until this v0.4.4 release, but
as I got the message about the conflicting branches I assumed that for
the previous pristine tars' I should have pushed them explicitly (my
assumption being that the v0.4.2 and v0.4.3 pristine-tars were added by
you (although I didn't check that)).
>
>> In fact, when I run `git push --tags` I get the following error:
>>
>> To git+ssh://git.debian.org/git/debian-med/probabel.git
>> ! [rejected] upstream/0.4.2 -> upstream/0.4.2 (already exists)
>> error: failed to push some refs to
>> 'git+ssh://git.debian.org/git/debian-med/probabel.git'
>> hint: Updates were rejected because the tag already exists in the remote.
>>
>> Is there a way to sync the tags (or to let my copy accept the one on
>> git.debian.org?
>
> As far as I can see the remote repository is OK now.
Glad to hear that!
> If your local clone
> is broken you might want to
>
> gbp-clone ssh://git.debian.org/git/debian-med/probabel.git
>
That sounds like a good plan. I'll do that.
>>> Please also note that the upload will be happen to experimental instead
>>> of unstable since we are in Freeze (feel free to ask if you do not
>>> understand this).
>>
>> I've read about the Freeze (and unfortunately couldn't get the fix done
>> in time). Since v0.4.4 fixes an important bug (which rendered one third
>> of the package useless) I was wondering about how to get a freeze
>> exception. Reading https://release.debian.org/jessie/freeze_policy.html
>> it seems to me that bug fix like this can be considered under:
>>
>> ii. fixes for severity: important bugs in packages of priority: optional
>> or extra, only when this can be done via unstable (until the 5th of
>> December 2014);
>>
>> However, when I read the section 'How to get an unblock' I'm wondering
>> if this applies to bugs in the software or bugs in the packaging (i.e.
>> where it says: "Only make changes that are necessary to fix the bug".
>>
>> Any suggestions as to how to move forward (if this is possible at all)?
>
> You were stating above that 0.4.4 fixes an "important" bug. The
> category "important" is not release critical. On the other hand you
> write "rendered one third of the package useless".
ProbABEL contains three regression modules and one of these turned out
to have broken checks for singularities, resulting in NaNs in the output
of real-world users (though not in our regular tests, unfortunately).
> You should simply
> check whether this would fit one of the severities grave, serious or
> critical[1].
Thank you for the link, I wasn't aware of the exact definitions of the
severity levels. I've gone through it and to me it seems that either
'serious' ("in the package maintainer's (...) opinion, makes the package
unsuitable for release") or 'grave' ("makes the package unusable or
mostly so").
> If the new upstream release would fix this *and* *only*
> *this*
No new features have been added. It fixes this bug and a smaller one in
an Automake file (sed -i -> sed -i -e) that prevented installation on
MacOS X and FreeBSD. I'm willing to remove that fix from src/Makefile.am
if necessary (although it seems a bit silly to me to do so).
> I might see some chances that the release team can be convinced.
> However, it really needs to be an RC bug and no trick to get the latest
> upstream in.
>
> May be you could discuss this with debian-release@lists.debian.org in
> advance.
Thanks for the pointer. I'll drop them a line and see what they think
about 'serious', 'grave' or another classification.
Thanks a lot for all the guidance! I really appreciate the time you
spend on on making things clear.
Lennart.
>
> Kind regards
>
> Andreas.
>
> [1] https://www.debian.org/Bugs/Developer#severities
>
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
Utrecht
The Netherlands
lennart@karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Attachment:
signature.asc
Description: OpenPGP digital signature