Bug#679751: Lintian now detect package pointing to /home

[Michael Biebl]

Am 18.09.2017 um 02:18 schrieb Michael Biebl:
> It's not as simple as that. You might still have running processes with
> that uid in which case usermod complains and exists.
> So to successfully run usermod you'd have to kill a processes running
> under that uid.

Fwiw, I ran into this issue when an upstream of mine switched runtimedir
from /var/run to /run and my postinst so far has created a system user
with --home /var/run/foo which I now wanted to change to --home /run/foo.
As the package starts a (socket activated) daemon, this needs some
dedicated code to disable socket activation, then stop the daemon, then
change the home directory via usermod, then re-enable socket activation.

Or I just don't try to anticipate all possible corner cases and simply
use the new home directory only on new installations.

Not sure what's better.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#679751: Lintian now detect package pointing to /home

[Michael Biebl]

On Fri, 31 Jul 2015 13:16:24 +0200 Guillem Jover  wrote:
> Hi!
> 
> On Fri, 2015-07-31 at 11:34:20 +0200, Bastien ROUCARIES wrote:
> > On Fri, Jul 31, 2015 at 11:04 AM, Bastien ROUCARIES wrote:
> > > Lintian now detect script creating user pointing to /home.
> 
> > After a chat under #debian-qa it appear that canonical path for non
> > existant home dir is /nonexistant could be documented ?
> > 
> > Moreover how can a developper could correct a mistake in previous
> > package ? Rip the /home directory correct hte passd file ?
> 
> To fix a wrong home path you can do something like:
> 
> ,---
> # Fix the home directory name created by an old package.
> u_home=$(getent passwd USERNAME | cut -d: -f6)
> if [ "$u_home" = "OLDHOME" ] ; then
>   usermod --home NEWHOME USERNAME >/dev/null || true
> fi
> `---
> 

It's not as simple as that. You might still have running processes with
that uid in which case usermod complains and exists.
So to successfully run usermod you'd have to kill a processes running
under that uid.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#876055: Environment variable handling for reproducible builds

[Russ Allbery]

Package: debian-policy
Version: 4.1.0.0
Severity: normal

Currently, Debian Policy requires all environment variables be held the
same across builds for the build to be expected to be reproducible.
However, the current approach of some reproducible build tools is to
instead enumerate a set of fixed environment variables and allow other
variables to vary.

We should ideally converge on a single approach to environment variables
and build reproducibility and make it easy for tools to implement that
approach.

I think the alternatives are:

1. Enumerate environment variables to hold fixed.  This is better in
   the sense that it allows packages to be reproducible under more
   situations, but it's unstable in the sense that we'll never be able to
   enumerate all environment variables that might possibly affect the
   build.  It's also not testable in the sense that we can't set every
   possible environment variable.

2. Set the entire environment to the environment specified in buildinfo
   when doing a reproducible build.  I think this is conceptually the
   simplest, but it means that we should make every tool that builds
   official Debian packages use the same environment variable logic so
   that the buildinfo file completely captures the environment (without
   leaking random, inappropriate things into buildinfo).  It also means
   effectively giving up on debian/rules build being a path for making a
   reproducible build, since we don't have control over that environment,
   but I think it will be hard to make that work anyway.

3. List a set of environment variables that are permitted to vary in the
   reproducible build policy, and then have reproducible builds clean the
   environment except for that set and then apply the buildinfo environment
   variable set.  This is very similar to 2.  I think the primary advantage
   is that it lets us require packages build reproducibly in the presence
   of some settings that logically should not affect the build (USER, HOME,
   etc.), at the cost of making reproducible builds harder to achieve.
   It's mostly testable, in that one can try reproducible builds with
   various settings for those variables, although it would be hard to catch
   corner cases where only a specific setting causes issues.

I personally lean towards 2, which is consistent with what's in Policy
right now, but I can see definite merits in 3.  I believe the reproducible
builds project is currently sort of doing 1, but I have a hard time seeing
how to make that viable on the testing side.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.6.3-2

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information

Processed: Re: Bug#873125: debian-policy: FTBFS with Sphinx 1.6: Needs build-dep on latexmk

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #873125 [src:debian-policy] debian-policy: FTBFS with Sphinx 1.6: Needs 
build-dep on latexmk
Added tag(s) pending.

-- 
873125: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873125
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#873125: debian-policy: FTBFS with Sphinx 1.6: Needs build-dep on latexmk

[Russ Allbery]

Control: tag -1 pending

Dmitry Shachnev  writes:

> debian-policy fails to build with Sphinx 1.6, currently available in
> experimental:

>   sphinx-build -M latexpdf policy policy/_build
>   Running Sphinx v1.6.3
>   [...]
>   build succeeded.
>   make[2]: Entering directory '/<>/policy/_build/latex'
>   make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> rule.
>   latexmk -pdf -dvi- -ps-  'policy.tex'
>   make[2]: latexmk: Command not found
>   Makefile:33: recipe for target 'policy.pdf' failed
>   make[2]: *** [policy.pdf] Error 127

> Since Sphinx 1.6, latexmk is required to build the LaTeX documentation [1].
> Adding a build-dependency on latexmk should help.

Thanks, fixed in Git.  We'll need to make a new upload shortly.

-- 
Russ Allbery (r...@debian.org)   

Processed: Bumping Sphinx 1.6 bugs severity

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # sphinx 1.6 is now in unstable
> severity 871313 serious
Bug #871313 [src:sphinxcontrib-programoutput] sphinxcontrib-programoutput: 
FTBFS with Sphinx 1.6: tests failures
Severity set to 'serious' from 'important'
> severity 872157 serious
Bug #872157 [src:debomatic] debomatic: FTBFS with Sphinx 1.6: Needs build-dep 
on latexmk
Severity set to 'serious' from 'important'
> severity 872159 serious
Bug #872159 [src:highlight.js] highlight.js: FTBFS with Sphinx 1.6: Needs 
build-dep on latexmk
Severity set to 'serious' from 'important'
> severity 872160 serious
Bug #872160 [src:php-guzzlehttp-ringphp] php-guzzlehttp-ringphp: FTBFS with 
Sphinx 1.6: Needs build-dep on latexmk
Severity set to 'serious' from 'important'
> severity 872202 serious
Bug #872202 [src:hamradio-maintguide] hamradio-maintguide: FTBFS with Sphinx 
1.6: Needs build-dep on latexmk
Severity set to 'serious' from 'important'
> severity 872203 serious
Bug #872203 [src:knot] knot: FTBFS with Sphinx 1.6: Needs build-dep on latexmk
Severity set to 'serious' from 'important'
> severity 872204 serious
Bug #872204 [src:libgnatcoll] libgnatcoll: FTBFS with Sphinx 1.6: Needs 
build-dep on latexmk
Severity set to 'serious' from 'important'
> severity 872230 serious
Bug #872230 [src:libtemplates-parser] libtemplates-parser: FTBFS with Sphinx 
1.6: Needs build-dep on latexmk
Severity set to 'serious' from 'important'
> severity 872231 serious
Bug #872231 [src:libxmlada] libxmlada: FTBFS with Sphinx 1.6: Needs build-dep 
on latexmk
Severity set to 'serious' from 'important'
> severity 872234 serious
Bug #872234 [src:mlpy] mlpy: FTBFS with Sphinx 1.6: Needs build-dep on latexmk
Severity set to 'serious' from 'important'
> severity 872236 serious
Bug #872236 [src:pygtkmvc] pygtkmvc: FTBFS with Sphinx 1.6: Needs build-dep on 
latexmk
Severity set to 'serious' from 'important'
> severity 872240 serious
Bug #872240 [src:python-expyriment] python-expyriment: FTBFS with Sphinx 1.6: 
Needs build-dep on latexmk
Severity set to 'serious' from 'important'
> severity 872241 serious
Bug #872241 [src:python-networkx] python-networkx: FTBFS with Sphinx 1.6: Needs 
build-dep on latexmk
Severity set to 'serious' from 'important'
> severity 872242 serious
Bug #872242 [src:python-pymzml] python-pymzml: FTBFS with Sphinx 1.6: Needs 
build-dep on latexmk
Severity set to 'serious' from 'important'
> severity 872246 serious
Bug #872246 [src:rdkit] rdkit: FTBFS with Sphinx 1.6: Needs build-dep on latexmk
Severity set to 'serious' from 'important'
> severity 872248 serious
Bug #872248 [src:sfepy] sfepy: FTBFS with Sphinx 1.6: Needs build-dep on latexmk
Severity set to 'serious' from 'important'
> severity 872259 serious
Bug #872259 [src:sagemath] sagemath: FTBFS with Sphinx 1.6: TypeError: 
frompickle() takes exactly 3 arguments (4 given)
Severity set to 'serious' from 'important'
> severity 872261 serious
Bug #872261 [src:matplotlib] matplotlib: FTBFS with Sphinx 1.6: Warning, 
treated as error: Footnote [2] is not referenced.
Severity set to 'serious' from 'important'
> severity 872264 serious
Bug #872264 [src:squirrel3] squirrel3: FTBFS with Sphinx 1.6: Needs build-dep 
on latexmk
Severity set to 'serious' from 'important'
> severity 872270 serious
Bug #872270 [src:celery] celery: FTBFS with Sphinx 1.6: AttributeError: 
'Sphinx' object has no attribute 'domains'
Severity set to 'serious' from 'important'
> severity 872314 serious
Bug #872314 [src:pytables] pytables: FTBFS with Sphinx 1.6: Needs build-dep on 
latexmk
Severity set to 'serious' from 'important'
> severity 872708 serious
Bug #872708 [src:python-asdf] python-asdf: FTBFS with Sphinx 1.6: 
AttributeError: 'Sphinx' object has no attribute '_extensions'
Severity set to 'serious' from 'important'
> severity 873125 serious
Bug #873125 [src:debian-policy] debian-policy: FTBFS with Sphinx 1.6: Needs 
build-dep on latexmk
Severity set to 'serious' from 'important'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
871313: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871313
872157: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872157
872159: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872159
872160: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872160
872202: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872202
872203: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872203
872204: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872204
872230: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872230
872231: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872231
872234: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872234
872236: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872236
872240: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872240
872241: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872241
872242: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872242
872246: