Bug#1085594: reposurgeon: Missing build dependency on tzdata-legacy

[Adrian Bunk]

Source: reposurgeon
Version: 4.38-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=reposurgeon&ver=4.38-1%2Bb3

...
=== RUN TestReadAuthorMap
reposurgeon: in readAuthorMap, while parsing line 3: [ill-formed timezone offset EST]
reposurgeon_test.go:1417: expected 3 people but got 2
--- FAIL: TestReadAuthorMap (0.00s)
...


EST is now in tzdata-legacy.

Additionally, a runtime dependency on tzdata-legacy might
also be appropriate?

[Santiago Vila]

please find the debdiff attached

Hi. Can you post the debdiff? (or just say what you did)

NMUs are messy for my taste. I could fix the FTBFS problem and let Anthony
(the usual uploader) to decide (for a later upload) if he wants
to use a depends, a recommends, or a suggest for the binary dependency
on tzdata-legacy (or even nothing).

Thanks.

[Aurelien Jarno]

Post by Santiago Vila

please find the debdiff attached

Hi. Can you post the debdiff? (or just say what you did)

Oops sorry about that. Please find it attached.

Post by Santiago Vila
NMUs are messy for my taste. I could fix the FTBFS problem and let Anthony
(the usual uploader) to decide (for a later upload) if he wants
to use a depends, a recommends, or a suggest for the binary dependency
on tzdata-legacy (or even nothing).

I can cancel it no problem if you think you have a better fix.

Regards
Aurelien

[Santiago Vila]

Post by Aurelien Jarno

Post by Santiago Vila

please find the debdiff attached

Hi. Can you post the debdiff? (or just say what you did)

Oops sorry about that. Please find it attached.

Thank you. I've made a team upload with those changes.

Post by Aurelien Jarno

Post by Santiago Vila
NMUs are messy for my taste. I could fix the FTBFS problem and let Anthony
(the usual uploader) to decide (for a later upload) if he wants
to use a depends, a recommends, or a suggest for the binary dependency
on tzdata-legacy (or even nothing).

I can cancel it no problem if you think you have a better fix.

My aim was to be "conservative". This is the "dilemma" I had in mind:

- For these kind of team uploads, I try to follow the spirit of a NMU,
i.e. minimal changes (in fact, I joined this team to do QA work).
- In this case, the minimal change to solve the FTBFS problem
would have been to fix the build-depends only.
- However, given than tzdata has been split into
tzdata + tzdata-legacy, the change which really keeps things
"as similar as before" is to add both depends and build-depends.

So that's what I did in the end (i.e. apply the same changes
in the nmudiff) to be "neutral".

(And of course, after this upload, Anthony can still relax the
dependency on tzdata-legacy if he considers it appropriate).

Thanks.

[Santiago Vila]

Control: tag -1 pending

Hello,

Bug #1085594 in reposurgeon reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/reposurgeon/-/commit/6f5887940a1bb8c380913b2794f5a9a2c99e9570

------------------------------------------------------------------------
Build-Depends and Depends on tzdata-legacy to support obsolete System V names. Closes: #1085594.
------------------------------------------------------------------------

(this message was generated automatically)

[Debian Bug Tracking System]

Post by Santiago Vila
tag -1 pending

Bug #1085594 [src:reposurgeon] reposurgeon: Missing build dependency on tzdata-legacy
Added tag(s) pending.

[Debian Bug Tracking System]

Your message dated Tue, 05 Nov 2024 11:35:16 +0000
with message-id <E1t8Hq8-006VA9-***@fasolo.debian.org>
and subject line Bug#1085594: fixed in reposurgeon 4.38-2
has caused the Debian Bug report #1085594,
regarding reposurgeon: Missing build dependency on tzdata-legacy
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)