[Dev] libretools 20140119 release announcement

Luke T. Shumaker lukeshu at sbcglobal.net
Sun Jan 19 22:37:35 GMT 2014

I just pushed libretools 20140119 to [libre-testing].

Important changes from 20140106.1 to 20140119

When running `libremakepkg`, the current working directory, as well as
makepkg.conf:SRCDEST (the current working directory, by default), must
be readable by the user `nobody`.  If that's not the case, it will
print an error message saying so, and exit.  This means that users
might need to change the permissions of a couple directories.

This should be a pretty non-invasive change, but it will affect users.

In v20140106 and v20140106.1, the requirement was the same, but it
wouldn't print the error message, and instead have mysterious errors
later in the run.  In prior versions, the requirement on the
directories did not exist.

Why this one is going to [libre-testing] first

On the 6th, I pushed v20140106 to [libre], and in doing so, found a
bug in `librerelease`.  I quickly fixed this, and pushed the fix as
v20140106.1.  There was only one release announcement for the two, and
it didn't mention there being the two versions.

However, users started reporting weird problems with `libremakepkg`.
I couldn't replicate them, but multiple users were having them, so I
moved v20140106.1 to [libre-testing] and rolled the version on [libre]
back to the previous version, v20131112.

This release, v20140119, is mostly a bug-fix release for several
issues.  However, there was one minor feature addition.

Because of the issues introduced in the last release, I am cautiously
pushing this to [libre-testing] first.  It is my hope that this
release proves stable, and will finally give users the exciting new
features from v20140106

About the bug, and directory permission requirements

So, about the weird bug that others were experiencing that I couldn't
replicate.  Basically, needed files were in directories that got
bind-mounted into the chroot, but the directories had file permissions
set such that the files in them couldn't be read by `nobody`.  The
reason this didn't affect users before now is that due to a bug in
libremakepkg (that got fixed in v20140106), in the chroot, root was
copying the files into other directories, instead of symlinking them,
making the permissions of the directory the were in irrelevant.

The "fix" is to first make sure that the directories are such that
`nobody` can read them, and bail with a descriptive error message if
they aren't.  That means that some users will have to adjust the
permissions on their directories.  It should be a pretty non-invasive
change.  This is a reduction in functionality, though.  I could have
made it adjust the permissions, but doing that behind the users' backs
feels dirty, as well as getting complicated if we consider FACLs and

If a file in them that needs to be read by `nobody` has restrictive
permissions itself, the error should be less mysterious.  Plus,
changing their permissions is *really* overstepping the bounds.

Detailed changelog

Changes from 20140106.1 to 20140119:
Feature additions:
 * libremakepkg: Support the -r and -w flags, same as librechroot.
Bug fixes:
 * libremakepkg:
   * Check the file permissions of the directories that get bind
     mounted by default.  This "fixes" the bug that users reported to
   * Actually support $SRCPKGDEST/--source/--allsource.  This was
     supposedly added in version 20140106, but not all of the code was
   * A couple of theoretical fixes with quoting in the distcc support
     module, that could probably be triggered if $copydir contained
     either single quotes, or a space.
Documentation fixes:
 * librechroot: Fix grammar in the usage text.
 * libremessages: The man page was updated to reflect additions made
   in version 20140106.
 * libremakepkg: Document the support for LOGDEST, which was added in
   version 20130914.

Happy hacking,
~ Luke Shumaker

More information about the Dev mailing list