Bug 259203 - audio/libamrwb: cleanup
Summary: audio/libamrwb: cleanup
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Daniel Engberg
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-16 09:36 UTC by Tatsuki Makino
Modified: 2021-10-25 05:29 UTC (History)
2 users (show)

See Also:
tatsuki_makino: maintainer-feedback+


Attachments
patch for audio/libamrwb (2.30 KB, patch)
2021-10-16 09:36 UTC, Tatsuki Makino
tatsuki_makino: maintainer-approval+
Details | Diff
poudriere log (80.43 KB, text/plain)
2021-10-16 09:37 UTC, Tatsuki Makino
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tatsuki Makino 2021-10-16 09:36:37 UTC
Created attachment 228745 [details]
patch for audio/libamrwb

Switched from PORTVERSION to DISTVERSION.
PORTREVISION has already been bumped due to changes in pkg query %e results
URLs such as MASTER_SITES have been switched from http to https.
Variable DISTNAME is now close to the default value in bsd.port.mk.
Variables have been sorted to silence portclippy :)
Regenerated distinfo by running make makesum "FORCE_FETCH_ALL=yes" "FETCH_ARGS=-pm".
Comment 1 Tatsuki Makino 2021-10-16 09:37:19 UTC
Created attachment 228746 [details]
poudriere log
Comment 2 commit-hook freebsd_committer 2021-10-24 20:25:25 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=0f895daa66ad65b43aa935bd0c60fe7f4783057d

commit 0f895daa66ad65b43aa935bd0c60fe7f4783057d
Author:     Tatsuki Makino <tatsuki_makino@hotmail.com>
AuthorDate: 2021-10-24 20:19:31 +0000
Commit:     Daniel Engberg <diizzy@FreeBSD.org>
CommitDate: 2021-10-24 20:19:48 +0000

    audio/libamrwb: Makefile adjustment

    Adjust Makefile to follow Porter's Handbook and framework more closely,
    also pet portclippy while at it.

    PR:             259203
    Approved by:    arrowd (mentor)
    Differential Revision:  https://reviews.freebsd.org/D32622

 audio/libamrwb/Makefile  | 14 +++++++-------
 audio/libamrwb/distinfo  |  1 +
 audio/libamrwb/pkg-descr |  2 +-
 3 files changed, 9 insertions(+), 8 deletions(-)
Comment 3 Daniel Engberg freebsd_committer 2021-10-24 20:26:04 UTC
Committed, thanks for your contribution!
Comment 4 Alexey Dokuchaev freebsd_committer 2021-10-25 03:01:14 UTC
USES=+autoreconf part was not explained, ditto for bug 259202.  Attaching build logs, esp. successful, is meaningless, nobody looks at them, so all they do is clutter bugzilla and eat disk space.
Comment 5 Tatsuki Makino 2021-10-25 03:27:43 UTC
Yes, I forgot to write about autoreconf.
The scripts already generated by autotools are supposed to be fine, but I added them to keep up with any changes in the new version of autotools.

The poudriere log of successful builds is used as evidence that there are no problems with the patch.
Some committers require maintainer to submit poudriere log and will not commit without it.
Comment 6 Alexey Dokuchaev freebsd_committer 2021-10-25 04:36:36 UTC
(In reply to Tatsuki Makino from comment #5)
> The poudriere log of successful builds is used as evidence that there are
> no problems with the patch.
Simply saying that "poudriere build ok" is more than enough.  Any committer would have to rebuild the port(s) herself prior to committing anyway.  Last but not least, user-provided build logs simply cannot be trusted.

> Some committers require maintainer to submit poudriere log and will not
> commit without it.
This requirement is nonsense, you can safely ignore it.  Again, any committer must perform the build- and, ideally, run-test before committing anything, and may not shift this responsibility to submitter or maintainer.
Comment 7 Tatsuki Makino 2021-10-25 05:29:41 UTC
(In reply to Alexey Dokuchaev from comment #6)

Okay.
If my log submission is not required, I will not submit it :)

However, there is also the issue of the distribution of time resources between mine(maintainers), yours(commiters), and the build machine's.
I want to help committers save as much time as possible so that they can process as many reports as possible.
I don't know the performance of committer's build machine, but if committer has maintainer's logs, committer can find problems that maintainer missed before using build machine. Committer can just look through that log while build machine is doing other work.