gosu 1.7-1 source package in Ubuntu

Changelog

gosu (1.7-1) unstable; urgency=medium

  * Update to 1.7 upstream release (Closes: #804469)

 -- Tianon Gravi <email address hidden>  Sun, 08 Nov 2015 13:23:18 -0800

Upload details

Uploaded by:
Debian Go Packaging Team
Uploaded to:
Sid
Original maintainer:
Debian Go Packaging Team
Architectures:
linux-any
Section:
misc
Urgency:
Medium Urgency

See full publishing history Publishing

Series Pocket Published Component Section
Xenial release universe misc

Downloads

File Size SHA-256 Checksum
gosu_1.7-1.dsc 1.9 KiB 492345129ccebe1067f1fc909d7c955c67a833e3a75f5dc49ea2f170c1939767
gosu_1.7.orig.tar.gz 14.9 KiB a010c7e34de69bfc2aa4b104a73c63d09e51caa6a5c8d75e836be6c692e9aae1
gosu_1.7-1.debian.tar.xz 2.7 KiB 08abc37daa3796d30d1d6b3c42fee7e1ad7b296d89e27080e2ab62ce4b5eb6cd

Available diffs

No changes file available.

Binary packages built by this source

gosu: Simple Go-based setuid+setgid+setgroups+exec

 This is a simple tool grown out of the simple fact that "su" and "sudo" have
 very strange and often annoying TTY and signal-forwarding behavior. They're
 also somewhat complex to setup and use (especially in the case of "sudo"),
 which allows for a great deal of expressivity, but falls flat if all you need
 is "run this specific application as this specific user and get out of the
 pipeline".
 .
 The core of how "gosu" works is stolen directly from how Docker/libcontainer
 itself starts an application inside a container (and in fact, is using the
 "/etc/passwd" processing code directly from libcontainer's codebase).
 .
 Once the user/group is processed, we switch to that user, then we "exec" the
 specified process and "gosu" itself is no longer resident or involved in the
 process lifecycle at all. This avoids all the issues of signal passing and TTY,
 and punts them to the process invoking "gosu" and the process being invoked by
 "gosu", where they belong.

gosu-dbgsym: debug symbols for package gosu

 This is a simple tool grown out of the simple fact that "su" and "sudo" have
 very strange and often annoying TTY and signal-forwarding behavior. They're
 also somewhat complex to setup and use (especially in the case of "sudo"),
 which allows for a great deal of expressivity, but falls flat if all you need
 is "run this specific application as this specific user and get out of the
 pipeline".
 .
 The core of how "gosu" works is stolen directly from how Docker/libcontainer
 itself starts an application inside a container (and in fact, is using the
 "/etc/passwd" processing code directly from libcontainer's codebase).
 .
 Once the user/group is processed, we switch to that user, then we "exec" the
 specified process and "gosu" itself is no longer resident or involved in the
 process lifecycle at all. This avoids all the issues of signal passing and TTY,
 and punts them to the process invoking "gosu" and the process being invoked by
 "gosu", where they belong.