• Bug#1109072: mlock: Package mlock missing in trixie

    From Lloyd@21:1/5 to Santiago Vila on Fri Jul 11 00:30:01 2025
    Hi Santiago,

    Santiago Vila wrote:

    Oddly enough, a copy of uw-imap (thus mlock) ship with Alpine source but are not compiled as part of the package.


    But mlock is compiled as part of the alpine package, under the name alpine-mlock.

    I missed this due to the renaming of the binary, and thus assumed it wasn't included. It could be the alpine package I examined was the older (unpatched) version.

    Do you miss mlock because you are still using it,
    or only because you believed alpine still needed it?

    The latter.

    If it's the second, I think this bug could be closed. If it's
    the first, I think mlock as a standalone package is very unlikely
    to come back, because no other package is using it.

    Am I wrong for thinking there should have been an apt-listchanges NEWS bulletin about this?

    FWIW I did due diligence before opening this bug, somehow I missed the new binary when running strings on alpine. Was the renaming to avert any package conflict?

    The first I realized something was wrong when I saw mlock in the list of packages to be removed, with no replacement identified.

    While I agree there is no bug, maybe there is a bug in the documentation? If two packages are being merged, the change should have been publicized better unless I'm overlooking something. I can't be the only one that will have this concern post-upgrade.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Santiago Vila@21:1/5 to Lloyd on Fri Jul 11 01:30:02 2025
    reassign 1109072 src:alpine
    found 1109072 2.26+dfsg-3
    thanks

    On Thu, Jul 10, 2025 at 10:08:01PM +0000, Lloyd wrote:
    But mlock is compiled as part of the alpine package, under the name alpine-mlock.

    I missed this due to the renaming of the binary, and thus assumed it wasn't included. It could be the alpine package I examined was the older (unpatched) version.

    Do you miss mlock because you are still using it,
    or only because you believed alpine still needed it?

    The latter.

    If it's the second, I think this bug could be closed. If it's
    the first, I think mlock as a standalone package is very unlikely
    to come back, because no other package is using it.

    Am I wrong for thinking there should have been an apt-listchanges NEWS bulletin about this?

    It depends on where we put the threshold for such kind of things (see below).

    While I agree there is no bug, maybe there is a bug in the
    documentation? If two packages are being merged, the change should
    have been publicized better unless I'm overlooking something. I can't
    be the only one that will have this concern post-upgrade.

    I think that's what the changelog is for:

    alpine (2.26+dfsg-3) unstable; urgency=medium

    [ Santiago Vila ]
    * Add debian/salsa-ci.yml.
    * Add patch to build with gettext 0.23.x.
    * Build with --max-parallel=1. Closes: #1089250.
    * Build and use alpine-mlock, drop dependency on mlock. Closes: #1091777.

    [ Unit 193 ]
    * Update Standards-Version to 4.7.2.

    -- Unit 193 <[email protected]> Tue, 01 Apr 2025 02:54:29 -0400

    In my opinion, warning the user about this via NEWS would be
    unnecessary, because alpine works the same before and after the change
    and no action from the end user is required at all. My own policy for
    NEWS is to use it when it's really important that the user reads it.

    FWIW I did due diligence before opening this bug, somehow I missed
    the new binary when running strings on alpine. Was the renaming to
    avert any package conflict?

    Yes. Keeping mlock would involve adding extra conflicts/replaces
    for no particular gain. The alpine program will work the same,
    so this was the most simple way to implement the feature.

    But I'm not the alpine maintainer, I just helped to deprecate mlock
    (which is why this bug drew my attention), so I will leave the
    alpine maintainers to handle this bug as they see it fits.

    (I'm adding them to Cc and reassigning the bug).


    BTW: sending a gpg-encrypted copy for a message which is also
    sent to [email protected] and publically archived here:

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109072

    is a little bit misleading. If you can and it's possible, please find
    the way to tell protonmail not to send me encrypted emails related
    with the Debian bug system.

    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)