Bug#877234: schroot: FTBFS with current debhelper: dh_install reports missing files

[Roger Leigh]

On 29/09/17 20:01, Andreas Beckmann wrote:

Source: schroot
Version: 1.7.2-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)


This could be removed from experimental; it's not been updated in years 
and is a development release for testing.



Regards,
Roger

Bug#786566: this is affecting us

[Roger Leigh]

On 05/01/17 10:08, Roger Leigh wrote:



On 05/01/17 09:23, Brian May wrote:

Peter Palfrader <wea...@debian.org> writes:


It's a serious bug that makes it break in many cases, requiring the
sysadmin to clean up and/or reboot the system.  Whether or not it's RC
in the end is the decision of the release team, but this severity was
set after discussing this on #debian-release.


Is anything being done to fix this? What is the hold up? Apparently
there is a patch for this RC bug and the other RC bug #817236.


I'm not personally working on any fix in schroot, since it's not an
schroot bug.


It is kind of looking like stretch will get released without schroot
support, or any packages that depend on it. Maybe time to forgot schroot
and look for alternatives???


schroot is not responsible for setting up device nodes in a
debootstrapped chroot.  We expect them to be set up correctly.  This
isn't a Debian-specific constraint; we expect all chroots of any sort to
be in a sane and directly usable state.

schroot's requirements are not any different here from that of the basic
chroot(8).  Is chroot(8) equally broken here?  The mounts and other
features schroot offers on top of that are entirely optional, and
implementation wise is nothing more than a wrapper around chroot(2) to
perform exactly the same job as chroot(8) with some sudo-like PAM
authentication and authorisation.

While we could add additional mounts to the schroot fstab templates,
it's important to understand that this is optional functionality, and
has always been optional.  It's not a mechanism for working around
external breakage.

Looking for alternatives to schroot is entirely your choice, but
breaking basic system-level functionality which has been working for
over two decades, and used for over 11 years by schroot, is I think
something which needs careful consideration.  I'm prepared to do some
work to ensure that schroot interoperates with contemporary systems, but
working around breakage like this is perhaps a step too far.


Very sorry, replying to the wrong ticket here.  Got confused with #817236.

For this specific issue with mount options, I've been following along 
but so far the discussion and proposed patches in this bug haven't 
reached a definitive conclusion with a consensus, so I'm waiting on an 
informed decision before I apply anything upstream.  I don't myself have 
the expertise to judge what the right action is here, so I'll defer to 
others for what's best.


Speaking frankly, I'm appalled that such gratuitous breakage through 
incompatible changes to the functioning of the base system was and is 
considered at all acceptable.  There's over 20 years of software 
development and admin experience on Debian, 11 for schroot, and there's 
a lot of code, and a lot of sysadmin-related scripting and expectations 
which makes assumptions about how mount(2) and mount(8) will behave. 
schroot is just one tool amongst many which expects them to work in the 
traditional, documented and most of all portable way.  Changing 
fundamental default system-wide behaviour on a whim is not what I would 
expect for a mature and established system.  I'd expect rather more 
considered and measured incremental change, which is something I've 
tried to pay proper attention to in my own work.  As an opt-in option 
for certain mounts, it would be fine, but enforcing it system wide is 
somewhat cavalier and inconsiderate of the multi-decade established 
semantics which we expect.  This significant change in attitude is one 
of the factors behind my no longer actively using or developing on 
Debian.  Like it or not, it's become a mature system, and that brings 
with it some responsibility toward backward compatibility even when we 
might want to rip it all out and start over with something new and exciting.


Too late to fix that now, so I'll consider applying upstream whatever 
makes most sense.  However, I must stress that schroot must remain 
portable to non-systemd-Linux, GNU/Hurd, GNU/kFreeBSD and FreeBSD, and 
any patches must not break this support.



Roger

Bug#786566: this is affecting us

[Roger Leigh]

On 05/01/17 09:23, Brian May wrote:

Peter Palfrader  writes:


It's a serious bug that makes it break in many cases, requiring the
sysadmin to clean up and/or reboot the system.  Whether or not it's RC
in the end is the decision of the release team, but this severity was
set after discussing this on #debian-release.


Is anything being done to fix this? What is the hold up? Apparently
there is a patch for this RC bug and the other RC bug #817236.


I'm not personally working on any fix in schroot, since it's not an 
schroot bug.



It is kind of looking like stretch will get released without schroot
support, or any packages that depend on it. Maybe time to forgot schroot
and look for alternatives???


schroot is not responsible for setting up device nodes in a 
debootstrapped chroot.  We expect them to be set up correctly.  This 
isn't a Debian-specific constraint; we expect all chroots of any sort to 
be in a sane and directly usable state.


schroot's requirements are not any different here from that of the basic 
chroot(8).  Is chroot(8) equally broken here?  The mounts and other 
features schroot offers on top of that are entirely optional, and 
implementation wise is nothing more than a wrapper around chroot(2) to 
perform exactly the same job as chroot(8) with some sudo-like PAM 
authentication and authorisation.


While we could add additional mounts to the schroot fstab templates, 
it's important to understand that this is optional functionality, and 
has always been optional.  It's not a mechanism for working around 
external breakage.


Looking for alternatives to schroot is entirely your choice, but 
breaking basic system-level functionality which has been working for 
over two decades, and used for over 11 years by schroot, is I think 
something which needs careful consideration.  I'm prepared to do some 
work to ensure that schroot interoperates with contemporary systems, but 
working around breakage like this is perhaps a step too far.



Regards,
Roger

Bug#778112: [buildd-tools-devel] Bug#778112: Bug#778112: Bug#778112: schroot: ftbfs with GCC-5

[Roger Leigh]

On 26/07/2015 08:50, Matthias Klose wrote:

On 07/26/2015 12:09 AM, Roger Leigh wrote:

On 25/07/2015 22:07, Roger Leigh wrote:

On 25/07/2015 21:45, Roger Leigh wrote:


OK, some further investigation has shown what the exact error is.  It
looks like a GCC bug.  Please see the attached source file testcase.
This regex is failing:

std::regex(^[a-z0-9][a-z0-9-]*$, std::regex::extended);

however this one works:

std::regex(^[a-z0-9][-a-z0-9]*$, std::regex::extended);


In the same vein, the attached sample using basic rather than extended
expressions fails in the opposite way. In this case both compile but the
latter expression fails to match correctly. Since the expression should
be valid and behave the same in both cases, it looks like there are two
bugs here, the first being unable to compile a valid extended regex, the
second here being unable to match (which is likely also a compile
failure, but not a fatal one).


Note this latter issue is seen with GCC 4.9 but appears to work with GCC 5.


now forwarded as https://gcc.gnu.org/PR67015

however I can't see different behaviour with 4.9 and 5 (making sure to use the
corresponding library using -static-libstdc++). Also I see regex2.cc always
succeeding.


Note I used GCC 4.9.2 in jessie.  This fails every time with or without 
-static-libstdc++.  GCC 4.9.3 in sid does not exhibit this behaviour, so 
it was likely just fixed with the 4.9.3 release.



Regards,
Roger


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789155: [buildd-tools-devel] Bug#789155: schroot: FTBFS: g++-4.8: error: unrecognized command line option '-fstack-protector-strong'

[Roger Leigh]

On 26/07/2015 20:28, Jakub Wilk wrote:

* Roger Leigh rle...@codelibre.net, 2015-07-26, 17:22:

I assume that some other package is providing the
-fstack-protector-strong argument


schroot (1.7.2-1) experimental; urgency=medium
  [...]
  * debian/rules:
- Build using g++-4.8, needed for C++11 compatibility until the
  default compiler for all architectures supports C++11.

Now that GCC 4.9 is the default compiler, I guess this change should be
reverted.


Will be fixed in: https://github.com/codelibre-net/schroot/pull/9/files

Regards,
Roger


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#778112: [buildd-tools-devel] Bug#778112: schroot: ftbfs with GCC-5

[Roger Leigh]

tags 778112 + patch
thanks

On 15/07/2015 14:50, Cyril Brulebois wrote:

Matthias Klose d...@debian.org (2015-02-12):

The following tests FAILED:
Errors while running CTest
  2 - sbuild-chroot-chroot (Failed)
  6 - sbuild-run-parts (Failed)
make[2]: *** [test] Error 8
Makefile:117: recipe for target 'test' failed
make[2]: Leaving directory '/«PKGBUILDDIR»/debian/build'
make[1]: *** [install-arch] Error 2
debian/rules:83: recipe for target 'install-arch' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [binary-arch] Error 2
debian/rules:39: recipe for target 'binary-arch' failed
dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit 
status 2


FWIW this isn't specific to gcc-5, the same happens with 4.9 in a sid
development chroot.


A patch to work around the issue has been merged here:

https://github.com/codelibre-net/schroot/pull/4
(mainline at https://github.com/codelibre-net/schroot/pull/2)

The primary change is to update the cmake regex tests to identify a 
broken std::regex and fall back to boost::regex.  I also updated the 
unit tests for good measure in case anything passes the cmake tests but 
is still broken.  There's also a test tweak to fix an additional issue 
with GCC5 in converting a stream to bool.


Feel free to pick up the above two commits in the first pull request to 
patch schroot in unstable.



Regards,
Roger


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789155: [buildd-tools-devel] Bug#789155: schroot: FTBFS: g++-4.8: error: unrecognized command line option '-fstack-protector-strong'

[Roger Leigh]

On 18/06/2015 11:30, Jakub Wilk wrote:

Source: schroot
Version: 1.7.2-2
Severity: serious
Justification: fails to build from source

schroot FTBFS:
| cd debian/build/gtest/ ; \
|   CXX=g++-4.8 -std=c++11 cmake /usr/src/gtest ; \
|   /usr/bin/make VERBOSE=1
| -- The CXX compiler identification is unknown
| -- The C compiler identification is GNU 4.9.2
| -- Check for working CXX compiler: /usr/bin/g++-4.8
| -- Check for working CXX compiler: /usr/bin/g++-4.8 -- broken

[...]

|   g++-4.8: error: unrecognized command line option
'-fstack-protector-strong'


Was this a historical issue on the buildds e.g. still using GCC 4.8 with 
a newer hardening-wrapper?  I can't reproduce in current unstable.


I assume that some other package is providing the 
-fstack-protector-strong argument and that GCC 4.8 doesn't support it. 
But I'm not sure that it's an schroot problem unless there is some 
versioned build dependency that needs correcting?  Or is it a dependency 
problem is some part of build-essential?



Regards,
Roger


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#778112: [buildd-tools-devel] Bug#778112: Bug#778112: Bug#778112: schroot: ftbfs with GCC-5

[Roger Leigh]

On 25/07/2015 21:45, Roger Leigh wrote:


OK, some further investigation has shown what the exact error is.  It
looks like a GCC bug.  Please see the attached source file testcase.
This regex is failing:

   std::regex(^[a-z0-9][a-z0-9-]*$, std::regex::extended);

however this one works:

   std::regex(^[a-z0-9][-a-z0-9]*$, std::regex::extended);


In the same vein, the attached sample using basic rather than extended 
expressions fails in the opposite way. In this case both compile but the 
latter expression fails to match correctly. Since the expression should 
be valid and behave the same in both cases, it looks like there are two 
bugs here, the first being unable to compile a valid extended regex, the 
second here being unable to match (which is likely also a compile 
failure, but not a fatal one).



Regards,
Roger

#include cassert
#include regex
#include iostream
#include stdexcept

int main()
{
  try
{
  // These three are OK:
  static std::regex lanana_namespace(^[a-z0-9]+$);
  static std::regex lsb_namespace(^_?([a-z0-9_.]+-)+[a-z0-9]+$);
  static std::regex debian_dpkg_conffile_cruft(dpkg-(old|dist|new|tmp)$);
}
  catch(const std::regex_error e)
{
  std::cout E0:   e.what()  std::endl;
}

  try
{
  // This fails with regex_error:
  static std::regex debian_cron_namespace(^[a-z0-9][a-z0-9-]*$);
  assert(std::regex_match(test, debian_cron_namespace));
  assert(!std::regex_match(-a, debian_cron_namespace));
  assert(std::regex_match(a-, debian_cron_namespace));
}
  catch(const std::regex_error e)
{
  std::cout E1:   e.what()  std::endl;
}

  try
{
  // This modified version works by moving the hyphen to the start of
  // the square bracket, even though the meaning is the same:
  static std::regex debian_cron_namespace_ok(^[a-z0-9][-a-z0-9]*$);
  assert(std::regex_match(test, debian_cron_namespace_ok));
  assert(!std::regex_match(-a, debian_cron_namespace_ok));
  assert(std::regex_match(a-, debian_cron_namespace_ok));
}
  catch(const std::regex_error e)
{
  std::cout E2:   e.what()  std::endl;
}
}

Bug#778112: [buildd-tools-devel] Bug#778112: Bug#778112: Bug#778112: schroot: ftbfs with GCC-5

[Roger Leigh]

On 25/07/2015 22:07, Roger Leigh wrote:

On 25/07/2015 21:45, Roger Leigh wrote:


OK, some further investigation has shown what the exact error is.  It
looks like a GCC bug.  Please see the attached source file testcase.
This regex is failing:

   std::regex(^[a-z0-9][a-z0-9-]*$, std::regex::extended);

however this one works:

   std::regex(^[a-z0-9][-a-z0-9]*$, std::regex::extended);


In the same vein, the attached sample using basic rather than extended
expressions fails in the opposite way. In this case both compile but the
latter expression fails to match correctly. Since the expression should
be valid and behave the same in both cases, it looks like there are two
bugs here, the first being unable to compile a valid extended regex, the
second here being unable to match (which is likely also a compile
failure, but not a fatal one).


Note this latter issue is seen with GCC 4.9 but appears to work with GCC 5.


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#778112: [buildd-tools-devel] Bug#778112: Bug#778112: schroot: ftbfs with GCC-5

[Roger Leigh]

On 15/07/2015 15:30, Matthias Klose wrote:

On 07/15/2015 05:21 PM, rle...@codelibre.net wrote:

Matthias Klose d...@debian.org (2015-02-12):

The following tests FAILED:
Errors while running CTest
  2 - sbuild-chroot-chroot (Failed)
  6 - sbuild-run-parts (Failed)
make[2]: *** [test] Error 8
Makefile:117: recipe for target 'test' failed
make[2]: Leaving directory '/«PKGBUILDDIR»/debian/build'
make[1]: *** [install-arch] Error 2
debian/rules:83: recipe for target 'install-arch' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [binary-arch] Error 2
debian/rules:39: recipe for target 'binary-arch' failed
dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error
exit status 2


FWIW this isn't specific to gcc-5, the same happens with 4.9 in a sid
development chroot.


I have tried reproducing this in an unstable VM, and I can certainly do
so.  It's throwing instantiating a static regex instance.

However, I can't reproduce as a minimal testcase.  Constructing the same
regex, either as an auto or static variable in a function scope or as a
global works perfectly.

std::regex was broken in earlier GCC releases, so we used boost::regex,


could you recheck with GCC 5? I won't say that it is completely fixed, but there
were a lot of fixes and updates.


but I thought it was functional in these compiler versions.  The fact that
the minimal testcase works hints that it's a problem in schroot, but I'm
unable to see why the code is problematic.

IIRC it's throwing here:
https://github.com/codelibre-net/schroot/blob/76a85f0fb34d39f796185d296fadde81b79a3948/lib/schroot/util.cc#L157
or here:
https://github.com/codelibre-net/schroot/blob/76a85f0fb34d39f796185d296fadde81b79a3948/lib/schroot/util.cc#L157

We are wrapping the regex implementation here:
https://github.com/codelibre-net/schroot/blob/76a85f0fb34d39f796185d296fadde81b79a3948/lib/schroot/regex.h
(to support boost/tr1/std regex)
but the failure is in the constructor of the wrapped type, and I couldn't
reproduce with the wrapper or a std::regex.


fwiw, I also tried with boost1.57 from experimental, and got the same test 
failures.


OK, some further investigation has shown what the exact error is.  It 
looks like a GCC bug.  Please see the attached source file testcase. 
This regex is failing:


  std::regex(^[a-z0-9][a-z0-9-]*$, std::regex::extended);

however this one works:

  std::regex(^[a-z0-9][-a-z0-9]*$, std::regex::extended);

GCC 4.9 (Debian 8): fails
GCC 5 (Debian sid): fails
clang++ 3.4 (FreeBSD 10.1-RELEASE): works
clang++ 3.4 (FreeBSD ports): works
clang++ 3.5 (FreeBSD ports): works
clang++ 3.6 (FreeBSD ports): works
clang++ 3.6 (MacOS): works

Note it fails when std::regex::extended is used, but works correctly 
without.  So looks like it can be patched with the above change in the 
interim, but this bug should likely be cloned and assigned to gcc?



Regards,
Roger
#include cassert
#include regex
#include iostream
#include stdexcept

int main()
{
  try
{
  // These three are OK:
  static std::regex lanana_namespace(^[a-z0-9]+$, std::regex::extended);
  static std::regex lsb_namespace(^_?([a-z0-9_.]+-, 
std::regex::extended)+[a-z0-9]+$);
  static std::regex debian_dpkg_conffile_cruft(dpkg-(old|dist|new|tmp, 
std::regex::extended)$);
}
  catch(const std::regex_error e)
{
  std::cout E0:   e.what()  std::endl;
}

  try
{
  // This fails with regex_error:
  static std::regex debian_cron_namespace(^[a-z0-9][a-z0-9-]*$, 
std::regex::extended);
  assert(std::regex_match(test, debian_cron_namespace));
  assert(!std::regex_match(-a, debian_cron_namespace));
  assert(std::regex_match(a-, debian_cron_namespace));
}
  catch(const std::regex_error e)
{
  std::cout E1:   e.what()  std::endl;
}

  try
{
  // This modified version works by moving the hyphen to the start of
  // the square bracket, even though the meaning is the same:
  static std::regex debian_cron_namespace_ok(^[a-z0-9][-a-z0-9]*$, 
std::regex::extended);
  assert(std::regex_match(test, debian_cron_namespace_ok));
  assert(!std::regex_match(-a, debian_cron_namespace_ok));
  assert(std::regex_match(a-, debian_cron_namespace_ok));
}
  catch(const std::regex_error e)
{
  std::cout E2:   e.what()  std::endl;
}
}

Bug#763157: initramfs-tools: Mounting /usr by initramfs-tools breaks checkfs.sh

[Roger Leigh]

On Sun, Sep 28, 2014 at 06:49:49PM +0100, Ben Hutchings wrote:
 Roger, please can you look at this?
 
 Ben.
 
 On Sun, 2014-09-28 at 11:41 +0200, Robert Luberda wrote:
  Package: initramfs-tools
  Version: 0.117
  Severity: critical
  Justification: breaks the whole system
  
  Hi
  
  After /usr is being mounted from initramfs, system is no longer
  bootable, because checkfs.sh script fails with:
  
[] Checking file systems...fsck from util-linux 2.20.1
/home2: clean, 166826/610800 files, 2350575/2441880 blocks
/home: clean, 120720/1831424 files, 3611320/3662820 blocks
/dev/sda5 is mounted.
e2fsck: Cannot continue, aborting.
  
  
fsck exited with status code 8
[] File system check failed. A log is being saved in
/var/log/fsck/checkfs if that location is writable. Please repair the
f[FAILystem manually. ... failed!
 
  The contents of /var/log/fsck/checkfs is:
  
Log of fsck -C -R -A -a 

Has there been an update to util-linux to make the above -R option
skip checking /usr in addition to the rootfs?  That was a
prerequisite for mounting /usr in the initramfs.

Looking at the mount options, it occurs to me that maybe we should
use -M in place of -R when we know we have run fsck in the
initramfs.  Then it will skip /usr as a matter of course, but it
would also skip fsck of the rootfs so won't be appropriate when
not using an initramfs.

You could if you wanted try using -M in checkfs as a workaround if
the above is the case.  Or maybe check util-linux is up-to-date in
case it just needs upgrading.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763157: initramfs-tools: Mounting /usr by initramfs-tools breaks checkfs.sh

[Roger Leigh]

On Sun, Sep 28, 2014 at 08:20:52PM +0100, Ben Hutchings wrote:
 On Sun, 2014-09-28 at 19:44 +0100, Roger Leigh wrote:
  On Sun, Sep 28, 2014 at 06:49:49PM +0100, Ben Hutchings wrote:
   Roger, please can you look at this?
   
   Ben.
   
   On Sun, 2014-09-28 at 11:41 +0200, Robert Luberda wrote:
Package: initramfs-tools
Version: 0.117
Severity: critical
Justification: breaks the whole system

Hi

After /usr is being mounted from initramfs, system is no longer
bootable, because checkfs.sh script fails with:

  [] Checking file systems...fsck from util-linux 2.20.1
  /home2: clean, 166826/610800 files, 2350575/2441880 blocks
  /home: clean, 120720/1831424 files, 3611320/3662820 blocks
  /dev/sda5 is mounted.
  e2fsck: Cannot continue, aborting.


  fsck exited with status code 8
  [] File system check failed. A log is being saved in
  /var/log/fsck/checkfs if that location is writable. Please repair the
  f[FAILystem manually. ... failed!
   
The contents of /var/log/fsck/checkfs is:

  Log of fsck -C -R -A -a 
  
  Has there been an update to util-linux to make the above -R option
  skip checking /usr in addition to the rootfs?  That was a
  prerequisite for mounting /usr in the initramfs.
 
 Argh.  No.  And that doesn't fix the problem because we have to
 support partial upgrades.
 
 Where is the bug report on util-linux?

Ah, found it as:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697002

For some reason it's been reassigned to initscripts.  Not sure I
agree with the rationale of not patching util-linux; this looks
like it breaks the non-initramfs boot case since it won't fsck
a mounted rootfs with -M?  It was never the intention of this
work to make an initramfs mandatory.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757335: [buildd-tools-devel] Bug#757335: Bug#757335: postgresql-debversion: No package for postgresql 9.4

[Roger Leigh]

On Fri, Aug 08, 2014 at 02:50:01PM +0100, Roger Leigh wrote:
 On Thu, Aug 07, 2014 at 10:13:54PM +0200, Andreas Tille wrote:
  Hi,
  
  sorry, but the given patch applies to what?  It does not help
  when trying to apply to `apt-get source postgresql-debversion`
  and I also tried
  
gbp-clone git://git.debian.org/git/buildd-tools/postgresql-debversion
  
  just to realise that this is outdated for years. :-(
  
  Is there any current Git repository where impatient people could just
  git-buildpackage??
 
 Hmm, it looks like this might have been reverted back when Alioth got
 restored from backup last year.  I've got a local copy at home; I'll push
 the current state later today.  All the buildd-tools repos are missing
 from the main gitweb page as well.

Actually it was fine, you were just looking on the wrong branch.
master contains the upstream main releases; the debian revisions are
on the debian branch.  Since there were no code changes required to
support new PostgreSQL versions for some time, there hasn't been any
need to make any new upstream release.  We could require extensions
and drop 9.0 support, but there's no pressing need to do so.

I've uploaded a 1.0.7-4 which will support 9.4 (or in fact any
version since this is now generalised).


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757335: [buildd-tools-devel] Bug#757335: postgresql-debversion: No package for postgresql 9.4

[Roger Leigh]

On Thu, Aug 07, 2014 at 10:13:54PM +0200, Andreas Tille wrote:
 Hi,
 
 sorry, but the given patch applies to what?  It does not help
 when trying to apply to `apt-get source postgresql-debversion`
 and I also tried
 
   gbp-clone git://git.debian.org/git/buildd-tools/postgresql-debversion
 
 just to realise that this is outdated for years. :-(
 
 Is there any current Git repository where impatient people could just
 git-buildpackage??

Hmm, it looks like this might have been reverted back when Alioth got
restored from backup last year.  I've got a local copy at home; I'll push
the current state later today.  All the buildd-tools repos are missing
from the main gitweb page as well.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739053: rpcbind LSB initscript runlevels are incorrect

[Roger Leigh]

On Mon, May 05, 2014 at 01:15:48PM -0700, Steve Langasek wrote:
 Control: reopen -1
 
 Roger,
 
  Please could you apply the following patch.  We are planning to upgrade
  the version of insserv, and testing shows that the new version breaks
  on the dependencies declared by rpcbind (which doesn't match the
  dependent nfs-common).  This change adjusts the start runlevels to
  match nfs-common.
 
 What do you mean, it doesn't match?  The nfs-common init script has:
 
 # Default-Start: S
 # Default-Stop:  0 1 6

I'm not sure myself.  I can't recall the details offhand I'm afraid;
I've spent the intervening months dealing with RSI and haven't done any
work on this since then.

 Anibal has reverted my deliberate change to rpcbind's init script, in
 response to this bug report which makes no sense.  Why did you think it was
 appropriate to mark rpcbind for start in both runlevel S and runlevels 2 3 4
 5?

I was asked to test insserv from experimental, sometime before opening
this bug.  I found that the rpcbind LSB headers caused insserv to fail,
and this fixed things.  IIRC I discussed this with the insserv
maintainer but I could be wrong.  The reasons for this I'm not sure.
It may be there needed a corresponding change to nfs-common, but I
don't think that was the case.  During this period I couldn't even hold
the pages of a book open, let alone type properly, so it's possible
I've missed something.

Sorry I can't help more here.  I really can't recall the specifics, and
I'm not able to do more investigation at present due to my hands.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743976: php5-json: Missing package dependencies prevent package removal

[Roger Leigh]

Package: php5-json
Version: 1.3.4-1
Severity: serious
Justification: Broken deps prevent deinstall

% sudo apt-get remove php5-json   
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  php5-common php5-json
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 1,046 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 514336 files and directories currently installed.)
Removing php5-common (5.5.11+dfsg-2) ...
Removing php5-json (1.3.4-1) ...
/var/lib/dpkg/info/php5-json.prerm: 13: /var/lib/dpkg/info/php5-json.prerm: 
php5dismod: not found
dpkg: error processing package php5-json (--remove):
 subprocess installed pre-removal script returned error exit status 127
/var/lib/dpkg/info/php5-json.postinst: 11: 
/var/lib/dpkg/info/php5-json.postinst: php5enmod: not found
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 127
Errors were encountered while processing:
 php5-json
E: Sub-process /usr/bin/dpkg returned an error code (1)


php5-common has a dependency upon php5-json
php5-json does not have a dependency upon php5-common

This results in php5-common being removed first, and php5-json's
prerm failing due to php5dismod not being found: it's already
been removed by this point.  Note that when dpkg tries to
abort the transaction, the rerun of the postinst *also* fails due
to php5enmod also being removed, so this isn't strictly a
removal bug, it's also a bug for installation as well.

I'm not familiar with the php5 packaging, but it's clear that the
dependencies are incorrect here, and this leads to an inability to
deinstall, hence the serious severity.  Suggestions, in decending
order of usefulness:

- can the dependencies be inverted?  That is, make php5-json depend
  on php5-common?
- can the prerm be made to clean up properly in the absence of
  php5dismod?  likewise the prerm and php4enmod
- if the dependencies are mutual, should the packages be merged?


Regards,
Roger

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (550, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages php5-json depends on:
ii  libc62.18-4
ii  libjson-c2   0.11-3
pn  phpapi-20121212  none
ii  ucf  3.0027+nmu1

php5-json recommends no packages.

php5-json suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739604: sysvinit: The new skeleton does not work on kFreeBSD

[Roger Leigh]

On Thu, Feb 20, 2014 at 01:00:45PM +0100, Petter Reinholdtsen wrote:
 [Gergely Nagy]
  The change introduced in sysvinit 2.88dsf-50, which turns
  /etc/init.d/skeleton into a script that has /lib/init/init-d-script
  as interpreter fails on kFreeBSD, because on that platform,
  interpreters cannot be other scripts.
 
 Oh.  I tested on Linux and Hurd, and did not imagine that kFreeBSD was
 that different from these two. :)
 
  If you want to do this kind of thing, you will either need a binary
  wrapper at least on kFreeBSD, or you'll need to use sourcing.
 
 Right.  Back to the drawing board. :)

An alternative solution here would be to have a tiny executable which
runs the shell, i.e. similar to openrc's runscript.  It might be
worth looking at the runscript sources.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739053: rpcbind LSB initscript runlevels are incorrect

[Roger Leigh]

Package: rpcbind
Version: 0.2.1-2
Severity: serious
Tags: patch
Justification: Breaks upgrades

Please could you apply the following patch.  We are planning to upgrade
the version of insserv, and testing shows that the new version breaks
on the dependencies declared by rpcbind (which doesn't match the
dependent nfs-common).  This change adjusts the start runlevels to
match nfs-common.

Marking as serious because this will break upgrades if left unfixed.


Thanks,
Roger

--- /etc/init.d/rpcbind.old 2014-02-10 18:55:20.645945248 +
+++ /etc/init.d/rpcbind 2014-02-15 11:23:32.000400663 +
@@ -6,7 +6,7 @@
 # Provides:  rpcbind
 # Required-Start:$network $local_fs
 # Required-Stop: $network $local_fs
-# Default-Start: S
+# Default-Start: 2 3 4 5 S
 # Default-Stop:  0 1 6
 # Short-Description: RPC portmapper replacement
 # Description:   rpcbind is a server that converts RPC (Remote

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (550, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages rpcbind depends on:
ih  initscripts  2.88dsf-51
ii  insserv  1.16.0-1
ii  libc62.17-97
ii  libtirpc10.2.2-5
ii  libwrap0 7.6.q-25
ii  lsb-base 4.1+Debian12

rpcbind recommends no packages.

rpcbind suggests no packages.

-- Configuration Files:
/etc/init.d/rpcbind changed [not included]

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694986: flash-kernel: postinst modifies /etc/default/rcS

[Roger Leigh]

On Tue, Feb 04, 2014 at 11:43:05AM +0100, Petter Reinholdtsen wrote:
 
 I read this bug report, but fail to understand what exactly it is
 expected for the sysvinit maintainers to do here.  Anyone care to
 explain what more can be done in this case?  Roger, you cloned it
 instead of reassigning it.  What did you have in mind?

Sorry, I can't remember.  Possibly it related to changing the
FSCKFIX default and/or defaulting FSCKFIX if unconfigured
depending upon if we could detect an interactive console.  I
understand the latter isn't always possible on arm systems--
there may be a console but it's not necessarily interactive.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724858: [buildd-tools-devel] Bug#724858: PATCH for sbuild-createschroot

[Roger Leigh]

tags 724858 + pending
thanks

On Sat, Sep 28, 2013 at 04:12:24PM -0400, Alex Chernyakhovsky wrote:
 Please find attached a patch for sbuild-createschroot which allows it
 to work on jessie/sid.

Many thanks for the patch.  I've applied it to git, and it's queued for
the next upload.


Thanks again,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#722012: [buildd-tools-devel] Bug#722012: another Perl problem in sbuild-createchroot

[Roger Leigh]

severity 722012 serious
forcemerge 722012 724858
thanks

On Sun, Sep 08, 2013 at 02:02:34PM +0200, Václav Ovsík wrote:
 Hi,
 I'm not certain to start another bug report...
 
 bobek:~# sbuild-createchroot 
 --make-sbuild-tarball=/var/lib/sbuild/sid-amd64.tar.gz sid `mktemp -d` 
 http://br0.localdomain:/debian
 ...
 Calculating upgrade... Done
 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
 'tempfile' can't be called as a method at /usr/sbin/sbuild-createchroot line 
 395.

Thanks for this patch; merging with #724858 which also contained a
similar patch.  This will be in the next upload.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Bug#717473: BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot

[Roger Leigh]

On Tue, Jul 23, 2013 at 06:05:57PM +0200, Borislav Petkov wrote:
 On Mon, Jul 22, 2013 at 08:19:26PM +0100, Roger Leigh wrote:
  Ben's patch does allow me to boot the system with the memory in this
  configuration on a 3.10 kernel.
 
 Ok, I actually think we can fix it the way below. It should be
 equivalent to Ben's patch in current functionality with the difference
 that it is a bit simpler and keeps the special handling for K8 which I
 want to have there as a future info.
 
 In addition, it still provides for the data structures to be initialized
 so some day, when memory hotplug is supported, it should work out of the
 box when all of a sudden a second channel appears.
 
 I think it should apply cleanly to 3.8 or 3.9 too as we haven't had a
 whole lot of movement in that area :-)

I've tested it against 3.10 and I can confirm that it works.  I've
booted the system with the DRAM on the same channel, and on
separate channels, and it's working without problems in both cases.


Many thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Bug#717473: Acknowledgement (BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot)

[Roger Leigh]

If the bug is in amd64_edac_mod, there are only two possible commits
which could cause the problem:

1eef12825 amd64_edac: Correct DIMM sizes
94c1acf2c amd64_edac: Add Family 16h support

Which are the only commits between 3.8 and 3.9 (and none made since).


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#716923: sysv-rc 2.88dsf-42 breaks {,c}debootstrapping

[Roger Leigh]

tags 716923 + patch
thanks

On Sun, Jul 14, 2013 at 10:41:18PM +0200, Stefan Lippers-Hollmann wrote:
 Trying to bootstrap a system using cdebootstrap (or debootstrap) fails 
 since sysv-rc 2.88dsf-42 entered the archive (it did succeed just 
 minutes before with the previous mirror sync, using sysv-rc 2.88dsf-41)
 with this error message:
 
 # cdebootstrap -v --arch=amd64 --flavour=minimal sid /mnt/ 
 http://ftp.de.debian.org/debian/
 […]
 O: dpkg: warning: ignoring pre-dependency problem!
 O: Unpacking util-linux (from .../util-linux_2.20.1-5.5_amd64.deb) ...
 P: Unpacking package util-linux
 O: Can't locate File/Path.pm in @INC (@INC contains: /etc/perl 
 /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 
 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 
 /usr/local/lib/site_perl .) at /usr/sbin/update-rc.d line 8.
 O: BEGIN failed--compilation aborted at /usr/sbin/update-rc.d line 8.
 O: dpkg: error processing 
 /var/cache/bootstrap/util-linux_2.20.1-5.5_amd64.deb (--unpack):
 O:  subprocess new pre-installation script returned error exit status 2
 O: Selecting previously unselected package e2fsprogs.

Does the following patch help?  It looks like it might have always been
missing the perl dependency.


diff --git a/debian/changelog b/debian/changelog
index d4a5972..07a7426 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+sysvinit (2.88dsf-43) UNRELEASED; urgency=low
+
+  [ Roger Leigh ]
+  * sysv-rc: Add ${perl:Depends} to ensure correct dependency on perl.
+Closes: #716923.
+
+ -- Roger Leigh rle...@debian.org  Sun, 14 Jul 2013 22:02:11 +0100
+
 sysvinit (2.88dsf-42) unstable; urgency=low
 
   [ Roger Leigh ]
diff --git a/debian/control b/debian/control
index 7dd998d..2834f6b 100644
--- a/debian/control
+++ b/debian/control
@@ -58,7 +58,7 @@ Conflicts: file-rc
 Replaces: file-rc
 Suggests: sysv-rc-conf, bum
 Depends:
- ${misc:Depends},
+ ${misc:Depends}, ${perl:Depends},
  sysvinit-utils (= 2.86.ds1-62),
  insserv ( 1.12.0-10)
 Breaks: initscripts ( 2.86.ds1-63)

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#716923: sysv-rc 2.88dsf-42 breaks {,c}debootstrapping

[Roger Leigh]

On Sun, Jul 14, 2013 at 11:35:58PM +0200, Stefan Lippers-Hollmann wrote:
 Hi
 
 On Sunday 14 July 2013, Roger Leigh wrote:
 […]
  Does the following patch help?  It looks like it might have always been
  missing the perl dependency.
 
 I did try cdebootstrap -v --arch=amd64 --flavour=minimal 
 --include=perl-modules sid /mnt/ http://ftp.de.debian.org/debian/;, 
 which had no effect. Unfortunately neither cdebootstrap nor debootstrap
 allow using additional mirrors to supersede or override particular
 packages from the bootstrapping phase, which makes it a little 
 difficult to test; even trying to sneak it into the downloaded packages
 before their respective unpacking didn't help here.

I've had this problem before as well, and had to IIRC make my own
mirror for testing.

Since the missing perl dependency is a bug anyway, I'll make the
upload as in the patch and then it should be testable on the
mirrors tomorrow.  If not, please just reopen the bug and we
can look at it further.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#716923: [Pkg-sysvinit-devel] Bug#716923: sysv-rc 2.88dsf-42 breaks {, c}debootstrapping

[Roger Leigh]

On Sun, Jul 14, 2013 at 02:55:49PM -0700, Steve Langasek wrote:
 On Sun, Jul 14, 2013 at 10:04:54PM +0100, Roger Leigh wrote:
  tags 716923 + patch
  thanks
 
  On Sun, Jul 14, 2013 at 10:41:18PM +0200, Stefan Lippers-Hollmann wrote:
   Trying to bootstrap a system using cdebootstrap (or debootstrap) fails 
   since sysv-rc 2.88dsf-42 entered the archive (it did succeed just 
   minutes before with the previous mirror sync, using sysv-rc 2.88dsf-41)
   with this error message:
 
   # cdebootstrap -v --arch=amd64 --flavour=minimal sid /mnt/ 
   http://ftp.de.debian.org/debian/
   […]
   O: dpkg: warning: ignoring pre-dependency problem!
   O: Unpacking util-linux (from .../util-linux_2.20.1-5.5_amd64.deb) ...
   P: Unpacking package util-linux
   O: Can't locate File/Path.pm in @INC (@INC contains: /etc/perl 
   /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 
   /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 
   /usr/local/lib/site_perl .) at /usr/sbin/update-rc.d line 8.
   O: BEGIN failed--compilation aborted at /usr/sbin/update-rc.d line 8.
   O: dpkg: error processing 
   /var/cache/bootstrap/util-linux_2.20.1-5.5_amd64.deb (--unpack):
   O:  subprocess new pre-installation script returned error exit status 2
   O: Selecting previously unselected package e2fsprogs.
 
  Does the following patch help?  It looks like it might have always been
  missing the perl dependency.
 
 Absolutely not.  sysv-rc is transitively essential as a Pre-Depends of
 sysvinit; making it depend on perl for core functionality will introduce
 dependency loops, because perl is deliberately NOT part of the transitively
 essential set.  update-rc.d should only require interfaces provided by
 perl-base.
 
 The claim in the comment that File::Path is 'in core since Perl 5.001' is
 bogus.  The only modules that are permitted are the ones in perl-*base*. 
 File::Path is in perl-*modules*.  Why are people making changes unsupervised
 to sysvinit without understanding how the Debian base system works?

Michael,

Please could you take a look at this?  In your commit ae90465c you
introduced the File::Path dependency to update-rc.d.  It's only used
for make_path, and it should be fairly simple to implement this in
an alternative manner.  If you don't need recursion (and it looks
like this might be the case), then you can just use plain mkdir.
But if you do, can still use plain mkdir for the recursion, e.g.

my @dirs = ();
my @path = split /\//, $path;
map { push @dirs, $_; mkdir join('/', @dirs), 0777 } @path;

as a starting point; you'd probably want to check if it already
exists before creating and double check the perms you need.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701956: btrfs can't fsck /run/rootdev on boot

[Roger Leigh]

On Wed, Jul 03, 2013 at 11:27:07PM +1000, Ben Klein wrote:
 Bug still occurs with
 * btrfs-tools 0.19+20130315-2
 * sysv-rc 2.88dsf-41
 * sysvinit 2.88dsf-41
 * sysvinit-utils 2.88dsf-41
 * initscripts 2.88dsf-41
 
 I notice this bug has been reduced in severity from critical to
 important again. Sorry, but I have to agree that it IS a critical
 bug, unless systemd has suddenly become the standard init system.

Totally agreed; it's been set back to critical.  I've been suffering
from it also.

 Even worse, systemd is behaving incorrectly in this case, as it is
 SKIPPING fsck instead of finding the root device some other way and
 running fsck on that (though this would still trigger bug #712078). So
 ultimately, the issue is either:
 * in mountpoint's syscall for getting the device node, or
 * in checkroot.sh which needs some btrfs-specific method to find the
 correct argument to pass to btrfsck/btrfs check (taking subvolumes
 into account)
 
 I've attached an alternative patch for checkroot.sh that explicitly
 checks for btrfs and, more importantly, triggers a warning when it is
 detected.

I didn't see an attachment.  I'll be happy to look over it and apply it
--it needs to be worked around in the short term irrespective of it
being fixed down the line.  Though I hope the btrfs tools are fixed
since they are currently horribly broken.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#707996: util-linux: Needs rebuild against new glibc; causes other packages to FTBFS

[Roger Leigh]

Package: util-linux
Version: 2.20.1-5.4
Severity: serious
Justification: ftbfs

From the e2fsprogs build:

make[1]: Entering directory `/«PKGBUILDDIR»/debian/BUILD-STD/e2fsck'
gcc -Wl,-z,relro -static -o e2fsck.static crc32.o dict.o unix.o e2fsck.o 
super.o pass1.o pass1b.o pass2.o pass3.o pass4.o pass5.o journal.o b
adblocks.o util.o dirinfo.o dx_dirinfo.o ehandler.o problem.o message.o quota.o 
recovery.o region.o revoke.o ea_refcount.o rehash.o profile.o
 prof_err.o logfile.o sigcatcher.o  ../lib/libquota.a ../lib/libext2fs.a 
../lib/libcom_err.a -lpthread -lblkid -luuid   -luuid-luuid 
../lib/libe2p.a 
logfile.o: In function `expand_percent_expression':
/«PKGBUILDDIR»/e2fsck/logfile.c:133: warning: Using 'getpwuid_r' in statically 
linked applications requires at runtime the shared libraries f
rom the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libblkid.a(env.o): 
In function `safe_getenv':
(.text+0x1be): undefined reference to `__secure_getenv'
collect2: error: ld returned 1 exit status
make[1]: *** [e2fsck.static] Error 1

This is due to util-linux having libblkid.a built against the old glibc
and this is no longer compatible with the new glibc.  It just needs a
rebuild.

According to jcristau this needs a sourceful upload, i.e. not a binNMU,
due to it being m-a: same.


Regards,
Roger

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (550, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages util-linux depends on:
ii  debconf [debconf-2.0]  1.5.50
ii  dpkg   1.16.10
ii  initscripts2.88dsf-41+jessie1
ii  install-info   5.1.dfsg.1-3
ii  libblkid1  2.20.1-5.4
ii  libc6  2.17-1
ii  libncurses55.9+20130504-1
ii  libselinux12.1.13-1
ii  libslang2  2.2.4-15
ii  libtinfo5  5.9+20130504-1
ii  libuuid1   2.20.1-5.4
ii  lsb-base   4.1+Debian9
ii  tzdata 2013b-2
ii  zlib1g 1:1.2.8.dfsg-1

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  3.0.16-2
ii  kbd 1.15.5-1
ii  util-linux-locales  2.20.1-5.4

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701385: Block

[Roger Leigh]

block 701385 by 707996
thanks

This is due to libblkid.a using a symbol removed in the new glibc.
It needs either a straight rebuild and/or updating to the latest
upstream.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701385: Block

[Roger Leigh]

On Sun, May 12, 2013 at 02:35:07PM -0400, Theodore Ts'o wrote:
 On Sun, May 12, 2013 at 03:09:42PM +0100, Roger Leigh wrote:
  
  This is due to libblkid.a using a symbol removed in the new glibc.
  It needs either a straight rebuild and/or updating to the latest
  upstream.
 
 Any reason to keep this open?  Once util-linux is recompiled, the
 FTBFS will be resolved automatically.  Or is eglibc buggy by not being
 backwards compatible, such that binaries compiled against the old
 glibc won't run if eglibc is installed, requiring a rebuild from
 source of the entire universe, and meaning that any old binaries from
 say, Steam, will all break?
 
 If so, I'd call this a huge, horrendous eglibc bug that should
 disqualify it from being installed as the default C library until it
 is fixed.  Though Shalt Not Break Backwards Compatibility.

That's a good question.  It may well be the case that whatever
e2fsprogs linked statically against libblkid.a is broken until
rebuilt due to the missing symbol.  I think it's fair to say that
util-linux was using what appears to be an internal symbol, so
questionable whether it was using public API/ABI; what was
__secure_getenv is now secure_getenv.  If it's clear that this
has caused breakage then __secure_getenv should probably be
re-introduced.

If the existing packages are still fully functional, and it's only
an issue for rebuilding, then I think the bug should be safe to
close.

If I don't get a reply from the (inactive) maintainer of util-linux
by tonight, I'll NMU it--it's just a rebuild with no source changes.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701385: Block

[Roger Leigh]

On Sun, May 12, 2013 at 02:35:07PM -0400, Theodore Ts'o wrote:
 On Sun, May 12, 2013 at 03:09:42PM +0100, Roger Leigh wrote:
  
  This is due to libblkid.a using a symbol removed in the new glibc.
  It needs either a straight rebuild and/or updating to the latest
  upstream.
 
 Any reason to keep this open?  Once util-linux is recompiled, the
 FTBFS will be resolved automatically.  Or is eglibc buggy by not being
 backwards compatible, such that binaries compiled against the old
 glibc won't run if eglibc is installed, requiring a rebuild from
 source of the entire universe, and meaning that any old binaries from
 say, Steam, will all break?
 
 If so, I'd call this a huge, horrendous eglibc bug that should
 disqualify it from being installed as the default C library until it
 is fixed.  Though Shalt Not Break Backwards Compatibility.

I've uploaded an NMU of util-linux.  This fixes the immediate issue.
I'll also file a bug against eglibc.

There's an additional issue with e2fsprogs:

texi2html -split_chapter /tmp/bt/e2fsprogs-1.42.5/doc/libext2fs.texinfo
** menu entry without previous node: Introduction to the EXT2FS Library (l. 110)
** menu entry without previous node: EXT2FS Library Functions (l. 111)
** menu entry without previous node: Concept Index (l. 112)
** menu entry without previous node: Function Index (l. 113)
** node_up `Top' for `Introduction to the EXT2FS Library' not found 
** node_prev `Top' for `Introduction to the EXT2FS Library' not found 
** node_up `Top' for `Introduction to the EXT2FS Library' not found 
** node_prev `Top' for `Introduction to the EXT2FS Library' not found 
** node_up `Top' for `EXT2FS Library Functions' not found 
** node_up `Top' for `Concept Index' not found 
** node_up `Top' for `Function Index' not found 
** `EXT2FS Library Functions' doesn't appear in menus
** `Concept Index' doesn't appear in menus
** `Function Index' doesn't appear in menus
if test -d libext2fs ; then \
mv libext2fs/* . ; rmdir libext2fs ; \
fi
make[1]: Leaving directory `/tmp/bt/e2fsprogs-1.42.5/debian/BUILD-STD/doc'
( cd /tmp/bt/e2fsprogs-1.42.5/debian/BUILD-STD/lib/et  /usr/bin/make V=1 
com_err.info com_err_abt.html )
make[1]: Entering directory `/tmp/bt/e2fsprogs-1.42.5/debian/BUILD-STD/lib/et'
makeinfo  /tmp/bt/e2fsprogs-1.42.5/lib/et/com_err.texinfo -o com_err.info
/tmp/bt/e2fsprogs-1.42.5/lib/et/com_err.texinfo:309: warning: missing name for 
@deftypefun
/tmp/bt/e2fsprogs-1.42.5/lib/et/com_err.texinfo:324: warning: missing name for 
@deftypefun
/tmp/bt/e2fsprogs-1.42.5/lib/et/com_err.texinfo:141: raising the section level 
of @section which is too low
make[1]: *** [com_err.info] Error 1

This is presumably the result of some texinfo or some related package
in unstable being updated.  Note that it also affects the e2fsprogs in
experimental.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#708061: libc6: ABI breakage: loss of symbol __secure_getenv

[Roger Leigh]

Package: libc6
Version: 2.17-1
Severity: serious
Justification: ABI breakage

__secure_getenv is being used by util-linux in libblkid.a.
Any program linked against libblkid.a will have a dependency
upon this symbol.  This includes e2fsprogs, which currently
FTBFSes.  There may be additional users; this is just the
one I'm aware of.

The new glibc has secure_getenv to replace __secure_getenv
but the old symbol is not retained.

I've NMUed util-linux to force it to be rebuilt.  This
should fix the immediate issues.  But the wider question is
how widespread was usage of this symbol, and do we need to
rebuild everything or could the symbol be restored for
backward compatibility?


Regards,
Roger

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (550, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  debconf [debconf-2.0]  1.5.50
ii  libgcc11:4.8.0-6

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  glibc-doc  2.17-1
ii  locales2.17-1
ii  locales-all [locales]  2.17-1

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#705649: Document solutions for re-enabling static mtab

[Roger Leigh]

tags 705649 + patch

On Tue, Apr 16, 2013 at 10:37:37PM +0100, Roger Leigh wrote:
 I've not made any changes as yet.  Given that this will only affect
 users who are using e.g. nbd as their rootfs, and not any regular
 use of network nfsroot etc., the best option may be to simply
 document how to re-enable a static mtab in the release notes, for
 users who are dependent upon _netdev working.  This would
 essentially be to
 - comment out the mtab_migrate conditional in /etc/init.d/checkroot.sh
 - rm /etc/mtab
 - cat /proc/mounts  /etc/mtab
 and to reboot; the _netdev flag will then be stored in mtab correctly.

Patch for the release notes attached.  I've gone through the process
locally and confirmed that this all works as documented.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Index: en/issues.dbk
===
--- en/issues.dbk	(revision 9741)
+++ en/issues.dbk	(working copy)
@@ -186,6 +186,73 @@
 
 /section
 
+section id=mtab
+titlefilename/etc/mtab/filename and literal_netdev/literal/title
+
+para
+The file filename/etc/mtab/filename, used to store the list of
+currently mounted filesystems, has been changed to be a symbolic link
+to filename/proc/mounts/filename.  For almost every case, this
+change will result in a more robust system since the list can never
+become inconsistent with reality.  However, if you use the
+literal_netdev/literal option in filename/etc/fstab/filename
+to indicate that a filesystem is a network filesystem requiring
+special handling, this will no longer be set in
+filename/proc/mounts/filename after rebooting.  This will
+emphasisnot/emphasis cause problems for standard network
+filesystems such as acronymNFS/acronym, which do not rely on the
+literal_netdev/literal option.  Filesystems which are
+emphasisunaffected/emphasis by this issue are
+literalceph/literal, literalcifs/literal,
+literalcoda/literal, literalgfs/literal,
+literalncp/literal, literalncpfs/literal,
+literalnfs/literal, literalnfs4/literal,
+literalocfs2/literal and literalsmbfs/literal.  For
+filesystems which emphasisdo/emphasis rely on
+literal_netdev/literal for correct unmounting at shutdown, for
+example when using an acronymNBD/acronym, a static mtab will be
+the only way to use literal_netdev/literal in wheezy.  If you have
+such a setup, then after completing the upgrade to wheezy restore a
+static filename/etc/mtab/filename by doing the following:
+/para
+itemizedlist
+listitem
+para
+Edit filename/etc/init.d/checkroot.sh/filename, and comment out
+these lines:
+/para
+screen
+if [ $rootmode != ro ]; then
+mtab_migrate
+fi
+/screen
+para
+/para
+/listitem
+listitem
+para
+If you have rebooted the system, and filename/etc/mtab/filename is
+now a symbolic link:
+/para
+screen
+# rm /etc/mtab
+# cp /proc/mounts /etc/mtab
+/screen
+para
+Re-add the literal_netdev/literal option by remounting the
+affected filesystems:
+/para
+screen
+# mount -o remount replaceablefilesystem/replaceable
+/screen
+para
+filename/etc/mtab/filename will be recreated fully next time you
+reboot the system.
+/para
+/listitem
+/itemizedlist
+/section
+
 !--Wheezy--
 section id=mksh
   titleThe pdksh to mksh transition/title
Index: en/release-notes.dbk
===
--- en/release-notes.dbk	(revision 9741)
+++ en/release-notes.dbk	(working copy)
@@ -394,6 +394,10 @@
 glossdefparaMail Transport Agent/para/glossdef
   /glossentry
   glossentry
+glosstermNBD/glossterm
+glossdefparaNetwork Block Device/para/glossdef
+  /glossentry
+  glossentry
 glosstermNFS/glossterm
 glossdefparaNetwork File System/para/glossdef
   /glossentry

Bug#702935: 'mount -f' does not update /run/mount/utab

[Roger Leigh]

On Tue, Apr 16, 2013 at 07:43:32PM +0100, Adam D. Barratt wrote:
  The attached patch does the latter.  It looks to see if _netdev is in
  use, and if so will refuse to migrate to a symlink.  Though it will
  do nothing if a symlink already exists, so it won't revert back to
  a static file (this could be added easily; I'm just attaching what I've
  done so far prior to going away for the week in case you want to push
  a fix for this before I get back).
 
 What's the current status here?

I've not made any changes as yet.  Given that this will only affect
users who are using e.g. nbd as their rootfs, and not any regular
use of network nfsroot etc., the best option may be to simply
document how to re-enable a static mtab in the release notes, for
users who are dependent upon _netdev working.  This would
essentially be to
- comment out the mtab_migrate conditional in /etc/init.d/checkroot.sh
- rm /etc/mtab
- cat /proc/mounts  /etc/mtab
and to reboot; the _netdev flag will then be stored in mtab correctly.

If we want to do anything more sophisticated, I'm happy to look at
something like the proposed patch.  This would be a relatively safe
change to make.  Likewise if there are any alternative proposals,
I'll be happy to look at that.  But if the release notes are an
acceptable stopgap, I'll draft something.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.

[Roger Leigh]

On Thu, Mar 21, 2013 at 01:26:30PM +, Roger Leigh wrote:
 On Thu, Mar 21, 2013 at 06:50:51AM +0100, Alexander Wirt wrote:
  On Wed, 20 Mar 2013, Roger Leigh wrote:
   Alexander, is this approach OK with you?  If you're happy with
   what this is doing, can this go into wheezy?
  its basically your feature, so if you think its working - I am happy with 
  it. 
 
 Yes, I'm happy that this allows file-rc to sysv-rc migration.
 Would you prefer to upload with the patch applied, or should I
 do it?

I'm away for the next week, so would you be able to upload this
in the meantime?


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#702935: 'mount -f' does not update /run/mount/utab

[Roger Leigh]

On Tue, Mar 12, 2013 at 09:19:06PM -0700, Steve Langasek wrote:
 The use of a symlink for /etc/mtab in wheezy means that 'mount -f' no longer
 works.  As a consequence, extra mount options that libmount *should* record
 in /run/mount/utab are not recorded for any filesystem that is mounted
 before the rootfs is marked rw, including but not limited to _netdev.  This
 potentially leaves the system with no way to cleanly unmount some
 network-dependent filesystems at shutdown time.
[...]
 This is a significant regression in handling of network-based block devices,
 such as iscsi and nbd, compared with squeeze.  I think it's important that
 this be resolved before release.

Hi Steve,

I'm afraid I'm away and without internet access until next weekend.
I've attached what I've done so far to work around this in
initscripts.

While bugs in mount/libmount/findmnt are certainly the cause of the
lack of _netdev, I'm doubtful that these are addressable in time for
wheezy.  And we would have to adapt the initscripts to use mount or
findmnt in order to merge in the utab content rather than looking
at mtab directly (which is easy--I've already done it locally, but
it needs the changes in util-linux from newer upstream releases, and
possibly additional work).  Certainly do-able for jessie.

In initscripts, we make the choice of a dynamic or static mtab in the
mtab_migrate function called from checkroot.sh.  This is only ever
run on read-write root, since it's not possible to change things if
it's read-only (here, the admin is responsible).  As discussed on IRC,
we can't realistically change this at upgrade time due to loss of
information such as nfs/cifs extended mount options.

At boot time, we currently migrate mtab to a symlink where possible.
Other alternatives are
- migrating back to a static file (not recommended; this would
  reintroduce more problems than it solves)
- making the choice of symlink or static file based upon particular
  criteria

The attached patch does the latter.  It looks to see if _netdev is in
use, and if so will refuse to migrate to a symlink.  Though it will
do nothing if a symlink already exists, so it won't revert back to
a static file (this could be added easily; I'm just attaching what I've
done so far prior to going away for the week in case you want to push
a fix for this before I get back).

This isn't an ideal solution, and I certainly wouldn't want to keep it
for jessie, but it will cover the majority of the _netdev usecases
fairly simply as an immediate workaround for wheezy.  I'm not sure of
the scope of this problem, but given that it took around 15-16 months
before this came up as an issue, I don't think it's particularly large,
especially when considering the scope of the bugs affecting static
mtab files, which was vastly larger and could cause worse problems.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
diff --git a/debian/src/initscripts/lib/init/mount-functions.sh b/debian/src/initscripts/lib/init/mount-functions.sh
index 2ad4528..c5e0386 100644
@@ -414,6 +420,28 @@ run_migrate ()
 #
 # Migrate /etc/mtab to a compatibility symlink
 #
+_mtab_migrate ()
+{
+	echo netdev=false
+	fstab_files | while read file; do
+if [ -f $file ]; then
+while read MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK; do
+case $MNT_FSNAME in
+  |\#*)
+	continue;
+	;;
+esac
+case $MNT_OPTS in
+  _netdev|_netdev,*|*,_netdev|*,_netdev,*)
+echo netdev=true
+break
+	;;
+esac
+			done  $file
+		fi
+	done
+}
+
 mtab_migrate ()
 {
 	# Don't symlink if /proc/mounts does not exist.
@@ -421,6 +449,11 @@ mtab_migrate ()
 		return 1
 	fi
 
+	eval $(_mtab_migrate)
+	if [ $netdev = true ]; then
+		return 1
+	fi
+
 	# Create symlink if not already present.
 	if [ -L /etc/mtab ]  [ $(readlink /etc/mtab) = /proc/mounts ]; then
 		:

Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.

[Roger Leigh]

On Thu, Mar 21, 2013 at 06:50:51AM +0100, Alexander Wirt wrote:
 On Wed, 20 Mar 2013, Roger Leigh wrote:
  Alexander, is this approach OK with you?  If you're happy with
  what this is doing, can this go into wheezy?
 its basically your feature, so if you think its working - I am happy with it. 

Yes, I'm happy that this allows file-rc to sysv-rc migration.
Would you prefer to upload with the patch applied, or should I
do it?


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.

[Roger Leigh]

On Wed, Mar 20, 2013 at 12:22:52PM +0100, Michael Stapelberg wrote:
 Hi Roger,
 
 Roger Leigh rle...@codelibre.net writes:
  So maybe what's missing is a call to insserv to recreate the
  default links, or to create the links and run insserv to
  correctly reorder them in dependency order.  The old link
  recreation behaviour used the pre-insserv static ordering IIRC,
  and that's certainly wrong.
 I’m not too sure if I understood you right, and I certainly don’t get
 all the details of how this stuff works, but this is my proposed fix:
 
 --- file-rc-0.8.14/debian/changelog   2012-08-19 20:56:20.0 +0200
 +++ file-rc-0.8.15/debian/changelog   2013-03-20 12:12:49.0 +0100
 @@ -1,3 +1,11 @@
 +file-rc (0.8.15) unstable; urgency=low
 +
 +  * Non-maintainer upload.
 +  * Call rcfile2link.sh followed by insserv to properly restore links when
 +removing file-rc (Closes: #688140)
 +
 + -- Michael Stapelberg stapelb...@debian.org  Wed, 20 Mar 2013 12:12:48 
 +0100
 +
  file-rc (0.8.14) unstable; urgency=low
  
* Depend on insserv, this prevents upgrade problems with systems
 diff -Nru file-rc-0.8.14/debian/prerm file-rc-0.8.15/debian/prerm
 --- file-rc-0.8.14/debian/prerm   2012-07-30 07:49:08.0 +0200
 +++ file-rc-0.8.15/debian/prerm   2013-03-20 12:21:39.0 +0100
 @@ -19,6 +19,8 @@
  
  case $1 in
  remove)
 +/usr/share/file-rc/rcfile2link.sh
 +/sbin/insserv
  ;;
  upgrade|deconfigure)
   ;;
 
 I’ve tested installing file-rc in squeeze, then upgrading to wheezy,
 upgrading to file-rc 0.8.15, then installing sysv-rc, and the links come
 back correctly.
 
 Roger, what do you think? Is this an acceptable fix?

I /think/ so, but IIRC there were some corner cases where this
previously caused problems.  Possibly with disabled services,
where the K links should exist but not S.  Maybe disable some
services, and then check that you can round trip from
sysv-rc to file-rc and back to sysv-rc maintaining the state.
And likewise for disabling/enabling a service in file-rc and
preserving this when moving to sysv-rc.

You might want to look at
/var/lib/dpkg/info/sysv-rc.postinst to see how it expects the
links to appear before running insserv (rcfile2link.sh could
be updated to match the behaviour if it hasn't been already).
This is basically
- no S links in rc0/rc6
- no K links in any runlevel containing an equivalent S link
or else insserv might complain.  This may be rectified after
running insserv, but is worth checking.  Maybe take a copy of
/etc at each stage then you can diff the changes.

Some state might be lost going back to sysv-rc since any
manual edits to the file-rc config not done via update-rc.d
will not be preserved since they aren't in the LSB script
header.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.

[Roger Leigh]

On Wed, Mar 20, 2013 at 05:04:57PM +0100, Michael Stapelberg wrote:
 Hi,
 
 at this point I cannot spend any more time on this bug report.
 
 Given that the bug report is without maintainer reply since more than
 half a year, and there are merely 160 people voting for it via popcon, I
 wonder if we should just drop file-rc from Debian in order to reduce
 init system complexity.
 
 release-team: what do you think?

I don't want to speak for the file-rc maintainers, but just from the
POV of sysvinit and jessie:

- in wheezy, we switched to requiring insserv for dependency-based
  boot; previously it was the default (but optional) and prior to
  that it was opt-in.  So we've got to the point of dependency-based
  boot being required over several stable releases.
- we have retained static runlevel ordering in maintainer scripts and
  update-rc.d for backward compatibility.  These are going to be
  removed in jessie, since we now no longer use them at all (file-rc
  was the last user).
- file-rc was converted (by me) to use insserv in its update-rc.d
  implementation, primarily to allow the removal of static ordering
  since it's now bitrotting badly--no one is using or testing the
  static ordering.  I'll be adding lintian checks and updating
  update-rc.d and dh_installinit etc. to initially ignore and
  ultimately (jessie+1/2) error out if static ordering is used.

Given the low number of users, and that fact that it's pretty much
tied to static runlevel ordering, even with the insserv usage, file-rc
will not work gracefully with dependency-based boot (if you do manual
edits, but if you don't why not just use sysv-rc?), I'm unsure if it
can remain viable.  That is to say it will only work reliably if you
don't edit the runlevel ordering, which is pretty much equivalent to
sysv-rc but without any parallelisation.

I'm very sure that for jessie we will have a large discussion about
which init system (or systems) we will be supporting for the future.
Of all the major contenders, all of them support dynamic boot ordering
and none support static ordering, and for good reason.  As far as I'm
aware, file-rc is the only system using static ordering (even when the
ordering is now generated from insserv).  The other problem is Hurd,
which doesn't use an init system at all (which is a major issue in its
own right).

WRT this bug, I think your patch is better included even if there are
corner cases it doesn't currently handle--we can always fix those
later.  It's more important that migration back to sysv-rc is
working, even if it's imperfect.  The admin can always fix up any
problems after, whereas the alternative is an unbootable system.  It
would be good if the file-rc maintainers could take the time to make
sure if this is working properly; I'll be happy to make any changes
to the sysv-rc maintainer scripts if required to assist in this.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.

[Roger Leigh]

On Wed, Mar 20, 2013 at 05:04:57PM +0100, Michael Stapelberg wrote:
 at this point I cannot spend any more time on this bug report.

I've tested your patch, and it appears to work correctly in all
the cases I've tried.  I've updated it slightly (attached) to
log what's happening during transition to dependency-based boot,
particularly if things go wrong, but it's otherwise functionally
identical to your patch.  It also runs insserv in verbose mode
so that any errors/warnings are not hidden (as for sysv-rc).

Alexander, is this approach OK with you?  If you're happy with
what this is doing, can this go into wheezy?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
diff -urN file-rc-0.8.14.original/debian/changelog file-rc-0.8.15/debian/changelog
--- file-rc-0.8.14.original/debian/changelog	2012-08-19 19:56:20.0 +0100
+++ file-rc-0.8.15/debian/changelog	2013-03-20 22:39:54.191661297 +
@@ -1,3 +1,16 @@
+file-rc (0.8.15) unstable; urgency=low
+
+  [ Michael Stapelberg ]
+  * Call rcfile2link.sh followed by insserv to properly restore links
+when removing file-rc. (Closes: #688140)
+
+  [ Roger Leigh ]
+  * When migrating to dependency-based boot in the prerm, log
+what's happening, and if insserv fails issue an informative
+message (taken from sysv-rc postinst).
+
+ -- Roger Leigh rle...@debian.org  Wed, 20 Mar 2013 21:31:30 +
+
 file-rc (0.8.14) unstable; urgency=low
 
   * Depend on insserv, this prevents upgrade problems with systems
diff -urN file-rc-0.8.14.original/debian/prerm file-rc-0.8.15/debian/prerm
--- file-rc-0.8.14.original/debian/prerm	2012-07-30 06:49:08.0 +0100
+++ file-rc-0.8.15/debian/prerm	2013-03-20 22:35:07.459268780 +
@@ -16,12 +16,32 @@
 # for details, see http://www.debian.org/doc/debian-policy/ or
 # the debian-policy package
 
+# Make sure insserv is in path
+PATH=/sbin:$PATH
 
 case $1 in
 remove)
+echo info: restoring rc.d links 12
+/usr/share/file-rc/rcfile2link.sh
+echo info: running insserv 12
+if insserv -v ; then
+echo success: Enabled dependency based boot system. 12
+else
+echo error: Something failed while migrating. 12
+cat 12 EOF
+
+error: Unable to migrate to dependency based boot sequencing.
+
+See http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot for
+more information about dependency based boot sequencing. To
+reattempt the migration process run 'insserv -v' after correcting
+the cause of the problem, and then retry removing file-rc.
+
+EOF
+fi
 ;;
 upgrade|deconfigure)
-	;;
+;;
 failed-upgrade)
 ;;
 *)

Bug#701936: Bug#701956: btrfs can't fsck /run/rootdev on boot

[Roger Leigh]

On Sun, Mar 17, 2013 at 01:56:22PM +0100, Nis Martensen wrote:
 On Fri, Mar 01, 2013 at 07:50:37AM +0100, Daniel Baumann wrote:
  works with systemd, it's sysvinit specific.
 
 Systemd skips the root file system check if the major device number of
 the root file system is 0 (which is what btrfs reports):
 http://cgit.freedesktop.org/systemd/systemd/tree/src/fsck/fsck.c#n297
 
 The same could be done in sysvinit. Possible (untested) patch attached.

Thanks for the patch.  This will have to be deferred until after
wheezy is released, but if we have to work around the btrfs fsck
issues in this way, it looks like a reasonable approach.  I would
hope however that this would not be necessary, and that the btrfs
fsck will become compatible with the standard /sbin/fsck options
and behaviour, including being able to fsck a read-only mount, or
else some users of btrfs won't be able to check their filesystems.

Daniel, if you haven't done do already, it would be great if these
issues could be brought to the attention of the upstream developers.
As it stands, fsck.btrfs is not a compatible fsck, and this will
break any tool expecting it to work like /sbin/fsck, not just
sysvinit.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701936: btrfs can't fsck /run/rootdev on boot

[Roger Leigh]

On Wed, Mar 06, 2013 at 09:16:01PM +0100, Daniel Baumann wrote:

  2) fsck.btrfs fails to fsck a mounted filesystem
  
  fsck.btrfs won't check a mounted filesystem, even if mounted
  read-only.  We need to be able to do this, since we are running
  fsck from the rootfs.  We do this for all other filesystem types.
 
 the common workaround that e.g. other distributions do is to do this in
 initramfs. probably debian should do that for all filesystems in future too.

What about *right now*, today.  What we should do is irrelevant
to the problem right now.  And it's not like doing it in the
initramfs is the only correct way to do this.  We've done it
the existing way since forever.  And you broke that.  That's
unacceptable.

  3) fsck.btrfs does not support the standard fsck options
 
 easy fixable, but hasn't much to do with the current remaining problem
 in sid.

Yes, it does.  We use those options.  And that breaks things.

  4) fsck.btrfs error codes
  
  I haven't tested this due to point (2) above
 
 me neither, but that's easy fixable too and hasn't much to do with the
 current remaining problem in sid.

Yes, it does.  If they don't work, then it will again break the
checkroot script.  Please do check this.

  • systems with a btrfs root filesystem are currently *unbootable*
without using fastboot to skip fsck
 
 *iff* sysvinit is used.

It's the default init system for crying out loud.  You broke
booting with the default init system for all people using a
btrfs rootfs.  And even if it was not the default, it's still
massively broken.  Would breaking booting with systemd or
upstart be any more acceptable?  No, it would not.  End this
ridiculous line of reasoning right now.

  • even if the checkroot script is fixed, fsck.btrfs remains
broken and all the unbootable systems remain unbootable
 
 the current package works fine on systems with systemd (not yet fixed
 points 3 and 4 from above are not breaking it).

That does not solve the problem for the vast majority who are not
using systemd.  Think for a minute about how much breakage you've
just caused.

  I would recommend that this be immediately reverted in unstable.
 
 i disagree.

If you are not going to revert this, then please tell me what
you are going to do to fix this, today.  Leaving people's
systems in a broken state is not on.  It must be fixed, and
fixed very quickly.  There are lots of people who can't boot
their computers thanks to this recklessness.

Please, revert it today.


Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.

[Roger Leigh]

On Tue, Mar 05, 2013 at 08:28:32PM +0100, Michael Stapelberg wrote:
 Roger Leigh rle...@codelibre.net writes:
  The reason for this change is that with file-rc now using insserv
  to maintain the links in part, it is not really meaningful to
  restore the links.  Both file-rc and sysv-rc use insserv, and so
 Could you elaborate on that, please? I don’t see where the file-rc
 package invokes insserv to maintain any links. On the contrary, after
 installing file-rc, /etc/rc*.d/ is deleted and there are no links at
 all.

It /should/ all be contained within update-rc.d.  The file-rc
version of update-rc.d takes its defaults from /sbin/insserv -s.
Looking more closely, this is from the files in /etc/init.d, but
will also use the rc?.d links as well if present.  So if the links
are deleted, you'll just get the defaults from the scripts, I think.

So maybe what's missing is a call to insserv to recreate the
default links, or to create the links and run insserv to
correctly reorder them in dependency order.  The old link
recreation behaviour used the pre-insserv static ordering IIRC,
and that's certainly wrong.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701776: fsck.btrfs do not accept -a so the system will not boot anymore

[Roger Leigh]

On Thu, Feb 28, 2013 at 07:16:25AM -0600, Tim Cuthbertson wrote:
 I confirm Axel Beckert's statement in message #60. My system cannot boot
 with the latest patch  0.19+20130131-2

Note that for compatibility with fsck you must support at a
minimum (even if you ignore them) the following options:

-y
-a
-C
-V

which are all required by checkroot.sh.  However, you should
really accept *all* options which can be passed to fsck; we
could well use additional options in the future, so you can't
guarantee that the minimal set required right now will be all
that is required.  For such a critical tool, this needs to be
done right.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#700047: sysvinit: fails to create /etc/inittab from a fresh debootstrap

[Roger Leigh]

On Thu, Feb 07, 2013 at 03:58:16PM -0500, David Comeau (SaturnNiGHTS) wrote:
 It appears that with the new package that has been pushed to
 sid/unstable [sysvinit 2.88dsf-40], performing a debootstrap install
 results in an installation with no /etc/inittab.  This appears to
 occur due to a section of sysvinit.postinst not running, due to
 being in a fakeroot/chroot/install environment, and having no init
 process to reinitialize.  That section of the postinst looks like it
 doesn't execute [do_restart()], which unfortunately also includes:
 
 if [ ! -f /etc/inittab ]
 then
 cp -p /usr/share/sysvinit/inittab /etc/inittab
 fi

Awfully sorry that this has happened, this is certainly wrong.
I'll have a -41 upload done later this evening.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#700051: Acknowledgement (sysvinit: fails to create /etc/inittab from a fresh debootstrap)

[Roger Leigh]

forcemerge 700048 700051
thanks

On Thu, Feb 07, 2013 at 05:11:00PM -0500, David Comeau (SaturnNiGHTS) wrote:
 i don't know why this created again.  really sorry about that.
 please close as already filed.

No worries, I'll just merge them so they are closed together.

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change

[Roger Leigh]

On Wed, Feb 06, 2013 at 04:59:04PM +0100, Michael Stapelberg wrote:
 On Sun, 2 Dec 2012 23:47:37 +
 Roger Leigh rle...@codelibre.net wrote:
  Please don't apply it just yet--we'll presumably need to get
  approval from the release team to change this in initscripts
  at the same time.  I'll have a patch for initscripts shortly;
  might be a bit later in the week to allow for comprehensive
  testing.
 What’s the status on this? It’s been 2 months :-).

I did send a mail to -release a week or so back, but haven't
seen a response yet.  Doing the change in initscripts is
fairly trivial, but introducing a configuration file change
at this point is probably not a great idea.  If it's needed,
I'll be happy to do it though.

While editing a conffile isn't a good idea in general, the actual
impact here is very low, and it's limited to ARM users, so if
the consensus is that it's ignorable for wheezy, I'll be equally
happy to postpone this for jessie and we can do the needed changes
early in the jessie release cycle.

Bottom line: I'll be happy to do whatever is needed.  Just need
some feedback on what is acceptable here.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688140: file-rc: File-rc doesn't restore rcX.d dirs at remove, breaks sysv-rc installation.

[Roger Leigh]

On Wed, Feb 06, 2013 at 12:49:02AM +0100, Michael Stapelberg wrote:
 On Tue, 6 Nov 2012 20:46:25 +0100
 Andreas Beckmann deb...@abeckmann.de wrote:
  On Wednesday, 19. September 2012 21:05:03 Piotr Borkowski wrote:
   File-rc doesn't restore rcX.d dirs at remove. This breaks sysv-rc
   legacy_bootordering postinst function. After sysv-rc installation
   this leads to empty rcX.d dirs and broken system. Maybe file-rc
   should call
  
  I can reproduce this problem in piuparts distupgrade tests, e.g.
setup squeeze (or wheezy) chroot
switch to file-rc
distupgrade to wheezy (or sid)
switch back to sysv-rc
  
  but not within a distro:
setup a squeeze (or wheezy or sid) chroot
switch to file-rc
switch back to sysv-rc
  
  curiously it also happens after a wheezy-sid distuprade, even if the
  versions of sysv-rc and file-rc are the same in both sid and wheezy
 I haven’t tried to reproduce this issue yet, but I have figured out
 that in file-rc 0.8.13, the call to rcfile2link.sh was removed from
 debian/prerm:
 
 --- file-rc-0.8.12/debian/prerm   2010-04-07 21:30:54.0 +0200
 +++ file-rc-0.8.13/debian/prerm   2012-07-30 07:49:08.0 +0200
 @@ -19,7 +19,6 @@
  
  case $1 in
  remove)
 - /usr/share/file-rc/rcfile2link.sh
  ;;
  upgrade|deconfigure)
   ;;
 
 
 The changelog mentions:
 
* Removed long obsolete logic (prior to oldstable) from maintainer
  scripts, which is no longer useful for upgrades.
 
 Roger: Your name was above the changes in the changelog of file-rc
 0.8.13. Was this change intentional? If so, could you explain how the
 conversion from file to links is supposed to work in the current
 version so that we can debug further?

Hi Michael,

I'm afraid I can't remember the specifics off the top of my head;
I'd have to review this work again to refresh my memory of the
details.

The reason for this change is that with file-rc now using insserv
to maintain the links in part, it is not really meaningful to
restore the links.  Both file-rc and sysv-rc use insserv, and so
when we switch between them, the state should remain identical.  That
is to say, that the changes effected by insserv (wrapped by
update-rc.d/file-rc) are the state which should be preserved,
which in practice means not doing anything at all.  However... my
memory may be bad here--I can't recall the extent to which we use
insserv in file-rc for handling the links.

I think the question to ask here is, why does the pattern of links
make legacy_bootordering true, and why does activate_insserv fail?
Is this at the point of running convert_rc_s_to_k or when running
insserv?  A little more detail about exactly what is failing here
would be helpful.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#699090: base-files: nsswitch.conf does not include gshadow entry

[Roger Leigh]

Package: base-files
Version: 7.1
Severity: serious
Tags: patch

Hi Santiago,

I've attached a patch for adding support for the gshadow
(group shadow) NSS database to nsswitch.conf.  Without this,
the libc getsg* family of functions will not work, hence
marking serious or else these functions will be broken for
new installations; would also be nice if it was possible to
add for upgrades as well?  Do we have any mechanism for
making NSS updates?

Note that it's using the files service rather than compat
here because compat does not support gshadow, but files
does (can be tested by running getent gshadow as root).


Thanks,
Roger

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32.33-kvm-i386-2028-dirty (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages base-files depends on:
ii  gawk [awk]  1:4.0.1+dfsg-2
ii  mawk [awk]  1.3.3-17

base-files recommends no packages.

base-files suggests no packages.

-- no debconf information
diff -urN base-files-7.1.original/share/nsswitch.conf base-files-7.1/share/nsswitch.conf
--- base-files-7.1.original/share/nsswitch.conf	2013-01-27 11:59:40.147903916 +
+++ base-files-7.1/share/nsswitch.conf	2013-01-27 12:04:44.534176087 +
@@ -7,6 +7,7 @@
 passwd: compat
 group:  compat
 shadow: compat
+gshadow:	files
 
 hosts:  files dns
 networks:   files

Bug#699090: base-files: nsswitch.conf does not include gshadow entry

[Roger Leigh]

On Sun, Jan 27, 2013 at 12:18:30PM +, Roger Leigh wrote:
 Hi Santiago,
 
 I've attached a patch for adding support for the gshadow
 (group shadow) NSS database to nsswitch.conf.  Without this,
 the libc getsg* family of functions will not work, hence
 marking serious or else these functions will be broken for
 new installations; would also be nice if it was possible to
 add for upgrades as well?  Do we have any mechanism for
 making NSS updates?
 
 Note that it's using the files service rather than compat
 here because compat does not support gshadow, but files
 does (can be tested by running getent gshadow as root).

Updated patch attached.  This will upgrade nsswitch.conf in-place
on upgrade to add support for gshadow for existing installations,
while new installs will get the new nsswitch.conf by default.
Note that it's only run for upgrades from base-files  7.2, so
will only be run once.

The sed script will insert the new entry after the shadow entry
if present, to make it identical to the default nsswitch.conf,
otherwise it will be inserted after the group entry which it
matches.

On #debian-devel, we discussed the security implications of
enabling this by default, but the consensus was that since this
is only readable by root, it's not an issue (restricting the
upgrade to only group:(compat|files) was considered, but thought
to not be worthwhile over enabling it for all cases).


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
diff -urN base-files-7.1.original/debian/changelog base-files-7.2/debian/changelog
--- base-files-7.1.original/debian/changelog	2013-01-27 11:59:40.147903916 +
+++ base-files-7.2/debian/changelog	2013-01-27 13:55:10.111292346 +
@@ -1,3 +1,13 @@
+base-files (7.2) unstable; urgency=low
+
+  * Add an entry for the gshadow database to the nsswitch.conf;
+also add this entry to existing nsswitch.conf files on upgrade.
+This is needed for the glibc getsg* family of functions which
+operate on the group shadow database to function correctly.
+Closes: #699090.
+
+ -- Roger Leigh rle...@debian.org  Sun, 27 Jan 2013 13:51:41 +
+
 base-files (7.1) unstable; urgency=low
 
   * Added Multi-Arch: foreign. This is needed even if base-files is
diff -urN base-files-7.1.original/debian/postinst.in base-files-7.2/debian/postinst.in
--- base-files-7.1.original/debian/postinst.in	2013-01-27 11:59:40.147903916 +
+++ base-files-7.2/debian/postinst.in	2013-01-27 14:01:37.541714235 +
@@ -122,3 +122,17 @@
   install_from_default /usr/share/base-files/staff-group-for-usr-local \
 /etc/staff-group-for-usr-local
 fi
+
+# Add gshadow to nsswitch.conf on upgrade
+if dpkg --compare-versions $2 lt-nl 7.2; then
+  if ! grep -q '^[[:space:]]*gshadow:[[:space:]]' /etc/nsswitch.conf; then
+match=group
+if grep -q '^[[:space:]]*shadow[[:space:]]*:' /etc/nsswitch.conf; then
+  match=shadow
+fi
+sed -i -e 1,/^[[:space:]]*$match[[:space:]]*:.*\$/ {/^[[:space:]]*$match[[:space:]]*:.*\$/a\
+gshadow:	files
+} /etc/nsswitch.conf
+echo Updating /etc/nsswitch.conf to add the gshadow database.
+  fi
+fi
diff -urN base-files-7.1.original/share/nsswitch.conf base-files-7.2/share/nsswitch.conf
--- base-files-7.1.original/share/nsswitch.conf	2013-01-27 11:59:40.147903916 +
+++ base-files-7.2/share/nsswitch.conf	2013-01-27 12:04:44.534176087 +
@@ -7,6 +7,7 @@
 passwd: compat
 group:  compat
 shadow: compat
+gshadow:	files
 
 hosts:  files dns
 networks:   files

Bug#663009: happens on all upgrades

[Roger Leigh]

On Wed, Jan 16, 2013 at 08:12:13PM +0100, Bastian Blank wrote:
 Control: found -1 2.88dsf-34
 Control: severity -1 serious
 
 I upgraded several machines in the last days and _every_ one failed to
 reboot after that:

Does the following patch help with this?
Also, it would help greatly to have some information about the
systems you upgraded.  Were these running native, or using some
form of container/virtualisation?  This patch should help for
environment where pidof fails to detect init, but unless I
understand the problem better, I'm not going to be able to
just guess.  Does pidof /sbin/init work on these systems?
Does it have a nonzero exit status?


--- a/debian/postinst
+++ b/debian/postinst
@@ -19,7 +19,7 @@ do_restart() {
 
# PID of init; may not always be 1.  Use for sending signals
# and checking if init is running.
-   PID=$(pidof /sbin/init || true)
+   PID=$(pidof /sbin/init || echo 1)
 
# Create /run/initctl if not present, and also create compatibility
# symlinks
--- a/debian/src/initscripts/etc/init.d/mountall.sh
+++ b/debian/src/initscripts/etc/init.d/mountall.sh
@@ -55,7 +55,7 @@ do_start() {
mknod -m 600 $INITCTL p
 
# Reopen control channel.
-   PID=$(pidof /sbin/init || true)
+   PID=$(pidof /sbin/init || echo 1)
[ -n $PID ]  kill -s USR1 $PID
fi
 

Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#663009: happens on all upgrades

[Roger Leigh]

On Wed, Jan 16, 2013 at 08:12:13PM +0100, Bastian Blank wrote:
 Control: found -1 2.88dsf-34
 Control: severity -1 serious
 
 I upgraded several machines in the last days and _every_ one failed to
 reboot after that:
 
 | # reboot
 |   
 | Broadcast message from root@s1 (pts/23) (Wed Jan 16 20:07:09 2013):
 | 
 | The system is going down for reboot NOW!
 | shutdown: timeout opening/writing control channel /run/initctl
 | init: timeout opening/writing control channel /run/initctl
 
 Adding a symlink from /dev/initctl to /run/initctl makes reboot work
 again.

Do you have a transcript of any of the upgrades?  It would be useful
to know what when wrong here, since we do take care to make
init reopen the control channel.
See /var/lib/dpkg/info/sysvinit.postinst lines 9-44 in do_restart().

One question would be if all these systems were running in some
type of container, since we determine the PID of init using
PID=$(pidof /sbin/init || true)
Is this failing on your systems?  If so, it would be very helpful
to know why, and what we could do to make this more robust.
Should probably be changed to || echo 1 as a fallback on failure.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.

[Roger Leigh]

On Mon, Dec 10, 2012 at 11:34:47PM +, Roger Leigh wrote:
 On Mon, Dec 10, 2012 at 09:47:39PM +, Roger Leigh wrote:
  On Sun, Dec 09, 2012 at 05:24:50PM +0100, Jozsef Marton wrote:
   Thank you, Roger, for your comments.
   
   You're right that the test Oracle XE applies is badly broken. See
   details inline your comment below.
   
   This has not been reported to Oracle as Debian Linux is not a
   supported platform for running their Database product. (I will make
   a try reporting this.)
   
   Though I understand that dev/shm is an implementation detail, it was
   user for ages and would using bind mount would simplify Debian
   users' life when they intend to use Oracle Database.
   
   I'm attaching a patch[1] I have tested that makes this behaviour
   configurable in /etc/default/tmpfs leaving symlink as the default
   value. I hope that this can be intergated in Wheezy.
  
  Thanks very much for the patch.  I'll look at merging this, or
  something very similar to it--there are some other details which
  also need taking care of.
 
 Preliminary patch is at
   
 http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=9be900ce3dc679f3f49b86b439b90f6937a159aa

A fixed version of sysvinit has now been uploaded.  Note that it's
much simpler than the above patch.  All you need to do is add an
entry for /dev/shm in /etc/fstab as documented in fstab(5), i.e.

tmpfs /dev/shm  tmpfs nosuid,nodev,size=40%,mode=177700

and it will all just work.  Note that /run/shm will then be linked
to /dev/shm, so it won't preclude us switching the default to
/run/shm down the line.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694379: initscripts: Symlinking /dev/shm to /run/shm makes Oracle Database XE unable to start. Bind mount makes it work.

[Roger Leigh]

On Mon, Dec 10, 2012 at 11:34:47PM +, Roger Leigh wrote:
 tags 694379 + serious
 thanks
 
 On Mon, Dec 10, 2012 at 09:47:39PM +, Roger Leigh wrote:
  On Sun, Dec 09, 2012 at 05:24:50PM +0100, Jozsef Marton wrote:
   Thank you, Roger, for your comments.
   
   You're right that the test Oracle XE applies is badly broken. See
   details inline your comment below.
   
   This has not been reported to Oracle as Debian Linux is not a
   supported platform for running their Database product. (I will make
   a try reporting this.)
   
   Though I understand that dev/shm is an implementation detail, it was
   user for ages and would using bind mount would simplify Debian
   users' life when they intend to use Oracle Database.
   
   I'm attaching a patch[1] I have tested that makes this behaviour
   configurable in /etc/default/tmpfs leaving symlink as the default
   value. I hope that this can be intergated in Wheezy.
  
  Thanks very much for the patch.  I'll look at merging this, or
  something very similar to it--there are some other details which
  also need taking care of.
 
 Preliminary patch is at
   
 http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=9be900ce3dc679f3f49b86b439b90f6937a159aa
 
 This fits in with the existing script logic, and will simply mount the
 tmpfs on /dev/shm rather than /run/shm if RAMSHM_ON_DEV_SHM=yes.  Note
 that this is currently not tested, so it's not ready for use yet.  And
 (note to me), needs to default RAMSHM=yes if RAMSHM_ON_DEV_SHM=yes since
 there's no underlaying /run to fall back on.  We don't use a bind mount
 because with this approach it's firstly not needed, and also because
 bind mounts don't play well in chroot environments. (Another note to
 me: check chroot upgrade logic in case /run/shm is hardcoded in the
 maintainer scripts.)

With some further additions and testing, the current patch for this
is here:
  
http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff_plain;h=f208974e295f187238d2ef6831ebc35d72b3c7de

If you'd like to try this out, I'd be grateful for any feedback.  If
you would prefer prebuilt packages for testing, just let me know, and
I'll make them available for download.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools

[Roger Leigh]

On Thu, Dec 13, 2012 at 09:15:12AM +0100, Adrin wrote:
 This is the find output:
 # find /etc -name '*vpnagentd_init*'
 /etc/rc5.d/K25vpnagentd_init
 /etc/rc5.d/S85vpnagentd_init
 /etc/init.d/vpnagentd_init
 /etc/rc4.d/K25vpnagentd_init
 /etc/rc4.d/S85vpnagentd_init
 /etc/rc2.d/K25vpnagentd_init
 /etc/rc2.d/S85vpnagentd_init
 /etc/rc3.d/K25vpnagentd_init
 /etc/rc3.d/S85vpnagentd_init

OK, I've solved the problem.  If you adjust your symlinks like this:

(sid)root@hufflepuff:/# find /etc -name '*vpnagentd_init' | sort | xargs ls -l
-rwxr-xr-x 1 root root 1153 Dec  4 08:46 /etc/init.d/vpnagentd_init
lrwxrwxrwx 1 root root   24 Dec 14 22:52 /etc/rc0.d/K01vpnagentd_init - 
../init.d/vpnagentd_init
lrwxrwxrwx 1 root root   24 Dec 14 22:52 /etc/rc1.d/K01vpnagentd_init - 
../init.d/vpnagentd_init
lrwxrwxrwx 1 root root   26 Dec  4 08:46 /etc/rc2.d/S21vpnagentd_init - 
/etc/init.d/vpnagentd_init
lrwxrwxrwx 1 root root   26 Dec  4 08:46 /etc/rc3.d/S21vpnagentd_init - 
/etc/init.d/vpnagentd_init
lrwxrwxrwx 1 root root   26 Dec  4 08:46 /etc/rc4.d/S21vpnagentd_init - 
/etc/init.d/vpnagentd_init
lrwxrwxrwx 1 root root   26 Dec  4 08:46 /etc/rc5.d/S21vpnagentd_init - 
/etc/init.d/vpnagentd_init
lrwxrwxrwx 1 root root   24 Dec 14 22:52 /etc/rc6.d/K01vpnagentd_init - 
../init.d/vpnagentd_init

And then run insserv:

(sid)root@hufflepuff:/# insserv
insserv: warning: script 'K01vpnagentd_init' missing LSB tags and overrides
insserv: warning: script 'vpnagentd_init' missing LSB tags and overrides

It will then adjust the links and all will be well.  Not entirely sure
why this shows two warnings though.

I think the cryptic errors you were getting were a result of S85 being
higher than the biggest runlevel S21 in used by insserv.  This then
makes it get placed after $all and hence the dependency loop.  That's
my theory anyway--I haven't looked at the code yet.  The stop number
is adjusted to be first, and has also been removed from runlevels
2-5 and added to runlevels 0, 1 and 6.

However, it does look like there's room for improvement here.  If
we haven't got an LSB header, why does the number get used at all?
Isn't its presence in this runlevel sufficient?  If so, we could
just ignore the number and have insserv assign it one appropriately.
Likewise for stop links.

I hope this makes some degree of sense.  I'm still not entirely
sure about how the internals work here.  I didn't notice issues
like this testing upgrades, possibly due to there always being
a script at S99.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools

[Roger Leigh]

On Thu, Dec 13, 2012 at 09:15:12AM +0100, Adrin wrote:
 This is the find output:
 # find /etc -name '*vpnagentd_init*'
 /etc/rc5.d/K25vpnagentd_init
 /etc/rc5.d/S85vpnagentd_init
 /etc/init.d/vpnagentd_init
 /etc/rc4.d/K25vpnagentd_init
 /etc/rc4.d/S85vpnagentd_init
 /etc/rc2.d/K25vpnagentd_init
 /etc/rc2.d/S85vpnagentd_init
 /etc/rc3.d/K25vpnagentd_init
 /etc/rc3.d/S85vpnagentd_init
 
 And the attached is what you asked for.

Thanks.  With this, I can reproduce the issue in a chroot environment.
I don't see this with just the script alone, so I can only assume this
is a result of the symlinks you have in the rc.d directories.

If I delete all the rc?.d/*vpnagentd_init links, insserv runs without
error.  Also, if I create a Snnvpnagentd_init link in rcS.d, it also
works without error.  But, if I create an S link in rc[2345].d, the
error is then triggered.  So this looks like the implicit $all
dependency is only working in the context of rcS.

Small note: You don't need the K links in rc[2345].d; restricting
them to rc[016] is fine.  This doesn't have any effect on the
problem in question.

One thing I'm not entirely clear on is how $all interacts with
runlevels.  Is there a $all at the end of every runlevel, or is
this restricted to rcS?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools

[Roger Leigh]

On Wed, Dec 12, 2012 at 01:41:26PM +0100, Adrin wrote:
 Hi,
 
 Thanks for the fast follow up. Two files are attached and this is the more
 comprehensive report by adding set -x:

Thanks for the files.  The trigger for the problem is vpnagentd_init,
which lacks LSB headers.  But there's nothing strictly wrong with this
in and of itself.  And there's nothing explicitly tying it to laptop-mode.

/etc/init.d/laptop-mode contains:
# Should-Start:  $all
# Required-Start:$remote_fs

Could you change this to
# Should-Start:  
# Required-Start:$remote_fs $all

and then retry the apt-get install -f command?

I think the reason this is causing problems is that Should-Start:  $all
isn't strict enough, which leads to the loop in the dependency graph;
making it required should fix things (I hope).


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695751: gdm: gdm3 update fails due to conflict with laptop-mode-tools

[Roger Leigh]

On Wed, Dec 12, 2012 at 01:41:26PM +0100, Adrin wrote:
 Hi,
 
 Thanks for the fast follow up. Two files are attached and this is the more
 comprehensive report by adding set -x:

I've tried to reproduce the failure on a clean wheezy install this
evening using the /etc/init.d directory you provided.  I'm afraid
that I can't reproduce the failure at all.  I just get a warning,
and insserv completes without error.  Possibly this is also dependent
upon the links in the rcn.d directories.  What does
  find /etc -name '*vpnagentd_init*' show?

Would it be possible to have the entire content of your initscripts
e.g.
  tar cfvz /tmp/initfiles.tar.gz /etc/rc?.d /etc/insserv* /etc/init.d
so I can try to reproduce with the exact setup you have?


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#687396: [buildd-tools-devel] Bug#687396: Bug#687396: Bug#687396: sbuild: building pyca fails silently

[Roger Leigh]

On Wed, Dec 05, 2012 at 02:25:45PM +, Roger Leigh wrote:
 On Wed, Dec 05, 2012 at 03:17:11PM +0100, Roland Stigge wrote:
  On 12/05/2012 03:11 PM, Roland Stigge wrote:
   But don't worry - it's just a minor change and at least fixes the issue
   for the protocol. ;-) So others won't be disturbed by it during bug
   squashing.
  
  So please consider sbuild 0.63.2-1.1 for wheezy (freeze exemption).
  (Maybe Roger will override the package which is now in the DELAYED queue.)
 
 I'd certainly want some careful testing first.  Are there any corner
 cases where this breaks anything?  I'll review it later in the week
 as I said earlier.  And do note that this does not match the behaviour
 on the buildds, so while it will fix things for local builds, it won't
 work on the buildds until the patch is committed into git and merged
 onto the buildd branch and then deployed.

I just saw this uploaded; I thought you said this was in DELAYED/5
yesterday?

Even small changes can do with some level of review and testing,
which I said yesterday I would do this week.  I don't think this
warranted such a high severity, nor NMUing it as I was replying
to your mail yesterday.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#687396: [buildd-tools-devel] Bug#687396: sbuild: building pyca fails silently

[Roger Leigh]

On Wed, Dec 05, 2012 at 02:40:20PM +0100, Roland Stigge wrote:
 Hi Andreas,
 
 On 12/05/2012 01:57 PM, Andreas Tille wrote:
  what about NMUing the package right now once you have found a proper
  patch?  If there are any reasons that might prevent you from uploading
  just ping me about this.
 
 I just wanted to see if any buildd-tools developer wanted to upload.

I've not yet had time to review and apply the patch you sent, but
thanks for making it.  Hopefully I'll have time later in the week.
However, even if I fix and upload it now, it won't be deployed
on the buildds immediately, so it won't resolve the problem you
have with the -0 version right now.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#687396: [buildd-tools-devel] Bug#687396: Bug#687396: sbuild: building pyca fails silently

[Roger Leigh]

On Wed, Dec 05, 2012 at 03:17:11PM +0100, Roland Stigge wrote:
 On 12/05/2012 03:11 PM, Roland Stigge wrote:
  But don't worry - it's just a minor change and at least fixes the issue
  for the protocol. ;-) So others won't be disturbed by it during bug
  squashing.
 
 So please consider sbuild 0.63.2-1.1 for wheezy (freeze exemption).
 (Maybe Roger will override the package which is now in the DELAYED queue.)

I'd certainly want some careful testing first.  Are there any corner
cases where this breaks anything?  I'll review it later in the week
as I said earlier.  And do note that this does not match the behaviour
on the buildds, so while it will fix things for local builds, it won't
work on the buildds until the patch is committed into git and merged
onto the buildd branch and then deployed.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694961: initscripts: Boot hangs cause of Init: job_process_handler ignored event 1 ....

[Roger Leigh]

reassign 694961 upstart
thanks

On Sun, Dec 02, 2012 at 08:14:00PM +0100, Peschae wrote:
 Package: initscripts
 Version: 2.88dsf-34
 Severity: critical
 Justification: breaks the whole system
 
 Dear Maintainer,
 
 after an update, I got the error message Init: job_process_handler ignored 
 event 1  on three different system.
 But I´m not really shure if the problem is in initscripts or an other package.
 
 One (this here) i386 , two amd64 - all Debian testing. One of the amd64 is 
 brand new after a Netinstall. Then I made 
 an update and got the error (boot stops).
 i386:  upstart 0.6.6-2
 amd64: upstart 0.6.6-2
 amd64 (brand new): sysvinit
 
 here´s the aptitude log of the update (brand new system):
 [AKTUALISIERUNG] initscripts:amd64 2.88dsf-32 - 2.88dsf-34
 [AKTUALISIERUNG] klibc-utils:amd64 2.0.1-3 - 2.0.1-3.1
 [AKTUALISIERUNG] libc-bin:amd64 2.13-35 - 2.13-37
 [AKTUALISIERUNG] libc6:amd64 2.13-35 - 2.13-37
 [AKTUALISIERUNG] libgnutls26:amd64 2.12.20-1 - 2.12.20-2
 [AKTUALISIERUNG] libklibc:amd64 2.0.1-3 - 2.0.1-3.1
 [AKTUALISIERUNG] liblzma5:amd64 5.1.1alpha+20120614-1 - 5.1.1alpha+20120614-2
 [AKTUALISIERUNG] libusb-0.1-4:amd64 2:0.1.12-20 - 2:0.1.12-20+nmu1
 [AKTUALISIERUNG] locales:amd64 2.13-35 - 2.13-37
 [AKTUALISIERUNG] multiarch-support:amd64 2.13-35 - 2.13-37
 [AKTUALISIERUNG] sysv-rc:amd64 2.88dsf-32 - 2.88dsf-34
 [AKTUALISIERUNG] sysvinit:amd64 2.88dsf-32 - 2.88dsf-34
 [AKTUALISIERUNG] sysvinit-utils:amd64 2.88dsf-32 - 2.88dsf-34
 [AKTUALISIERUNG] xz-utils:amd64 5.1.1alpha+20120614-1 - 5.1.1alpha+20120614-2
 
 My workaround is: update the systems to upstart upstart 1.6.x  
 
 Please let me know if you need additonal information. I´ve also got an other 
 system (upstart 0.6.6-2) which I can kill.

Reassigning the bug to upstart.  The actual error message
(job_process_handler) is definitely upstart.  If there's anything
initscripts-related then I'll certainly look further into that,
but I don't personally have the expertise to investigate the
upstart side of things further.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change

[Roger Leigh]

clone 694928 -1
reassign -1 initscripts
thanks

On Sun, Dec 02, 2012 at 12:23:07PM +0100, Martin Zobel-Helas wrote:

Please find attached an example patch for flash-kernel to
support old and new (rcS and fsck) locations for FSCKFIX
as discussed on #debian-devel earlier.

Please don't apply it just yet--we'll presumably need to get
approval from the release team to change this in initscripts
at the same time.  I'll have a patch for initscripts shortly;
might be a bit later in the week to allow for comprehensive
testing.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change

[Roger Leigh]

On Sun, Dec 02, 2012 at 11:47:37PM +, Roger Leigh wrote:
 clone 694928 -1
 reassign -1 initscripts
 thanks
 
 On Sun, Dec 02, 2012 at 12:23:07PM +0100, Martin Zobel-Helas wrote:
 
 Please find attached an example patch for flash-kernel to
 support old and new (rcS and fsck) locations for FSCKFIX
 as discussed on #debian-devel earlier.

Hmm, actually attached now.

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
From 300eb0dcd6abc4ced0596f87a33d3165d46779e5 Mon Sep 17 00:00:00 2001
From: Roger Leigh rle...@debian.org
Date: Sun, 2 Dec 2012 23:34:57 +
Subject: [PATCH] debian: Update /etc/default/fsck in flash-kernel-installer
 postinst

---
 debian/changelog   |   10 ++
 debian/flash-kernel-installer.postinst |7 ++-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 68c673b..526f1ec 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+flash-kernel (3.4) UNRELEASED; urgency=low
+
+  [ Roger Leigh ]
+  * flash-kernel-installer postinst: Update FSCKFIX in
+/etc/default/fsck as well as /etc/default/rcS for backward
+compatibility.  The purpose is to use /etc/default/fsck for
+new installations.
+
+ -- Roger Leigh rle...@debian.org  Sun, 02 Dec 2012 23:33:24 +
+
 flash-kernel (3.3) unstable; urgency=low
 
   * Replace XC-Package-Type by Package-Type
diff --git a/debian/flash-kernel-installer.postinst b/debian/flash-kernel-installer.postinst
index c07dee5..311615d 100755
--- a/debian/flash-kernel-installer.postinst
+++ b/debian/flash-kernel-installer.postinst
@@ -35,7 +35,12 @@ db_progress INFO flash-kernel-installer/prepare
 
 # Stop fsck from prompting the user for input since most users don't
 # have a serial console.
-sed -i s/^FSCKFIX=no$/FSCKFIX=yes/ /target/etc/default/rcS || true
+if [ -e /target/etc/default/rcS ]; then
+	sed -i -e s/^FSCKFIX=no$/FSCKFIX=yes/ /target/etc/default/rcS || true
+fi
+if [ -e /target/etc/default/fsck ]; then
+	sed -i -e s/^FSCKFIX=no$/FSCKFIX=yes/ /target/etc/default/fsck || true
+fi
 
 if ! apt-install flash-kernel; then
 	error apt-install flash-kernel failed
-- 
1.7.10.4

Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change

[Roger Leigh]

On Sun, Dec 02, 2012 at 11:49:44PM +, Roger Leigh wrote:
 On Sun, Dec 02, 2012 at 11:47:37PM +, Roger Leigh wrote:
  clone 694928 -1
  reassign -1 initscripts
  thanks
  
  On Sun, Dec 02, 2012 at 12:23:07PM +0100, Martin Zobel-Helas wrote:
  
  Please find attached an example patch for flash-kernel to
  support old and new (rcS and fsck) locations for FSCKFIX
  as discussed on #debian-devel earlier.
 
 Hmm, actually attached now.

Slight update to cope with commented-out lines (as provided
by default).

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
From 4db3a50a7bd6b11f3a4fa425e5e2c9b7cf1c9673 Mon Sep 17 00:00:00 2001
From: Roger Leigh rle...@debian.org
Date: Sun, 2 Dec 2012 23:34:57 +
Subject: [PATCH] debian: Update /etc/default/fsck in flash-kernel-installer
 postinst

---
 debian/changelog   |   10 ++
 debian/flash-kernel-installer.postinst |7 ++-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 68c673b..526f1ec 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+flash-kernel (3.4) UNRELEASED; urgency=low
+
+  [ Roger Leigh ]
+  * flash-kernel-installer postinst: Update FSCKFIX in
+/etc/default/fsck as well as /etc/default/rcS for backward
+compatibility.  The purpose is to use /etc/default/fsck for
+new installations.
+
+ -- Roger Leigh rle...@debian.org  Sun, 02 Dec 2012 23:33:24 +
+
 flash-kernel (3.3) unstable; urgency=low
 
   * Replace XC-Package-Type by Package-Type
diff --git a/debian/flash-kernel-installer.postinst b/debian/flash-kernel-installer.postinst
index c07dee5..e9b88c7 100755
--- a/debian/flash-kernel-installer.postinst
+++ b/debian/flash-kernel-installer.postinst
@@ -35,7 +35,12 @@ db_progress INFO flash-kernel-installer/prepare
 
 # Stop fsck from prompting the user for input since most users don't
 # have a serial console.
-sed -i s/^FSCKFIX=no$/FSCKFIX=yes/ /target/etc/default/rcS || true
+if [ -e /target/etc/default/rcS ]; then
+	sed -i -e s/^FSCKFIX=no$/FSCKFIX=yes/ /target/etc/default/rcS || true
+fi
+if [ -e /target/etc/default/fsck ]; then
+	sed -i -e s/^#FSCKFIX=no$/FSCKFIX=yes/ -e s/^FSCKFIX=no$/FSCKFIX=yes/ /target/etc/default/fsck || true
+fi
 
 if ! apt-install flash-kernel; then
 	error apt-install flash-kernel failed
-- 
1.7.10.4

Bug#693371: insserv: Please update insserv.conf to ensure mountall-bootclean is run

[Roger Leigh]

Package: insserv
Version: 1.14.0-4
Severity: serious
Tags: patch
Justification: Breaks boot

See also:
#677097
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677097

When we added mountall-bootclean to initscripts, I didn't realise
at the time that the dependencies were insufficient, and $local_fs
requires mountall-bootclean to be run, or it can be mis-ordered
and delete /run.

The attached patch fixes up insserv to add mountall-bootclean to
$local_fs.  I've included the change to both debian/patches and
to insserv.conf so you can apply whatever you feel best.

Flagged as serious since this does prevent systems from booting.
I'm going to also make the change to sysvinit to add
X-Start-Before: bootmish.sh to mountall_bootclean
but it would be good to have it here as well to make it less
easy to break your system.


Thanks,
Roger

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32.33-kvm-i386-2028-dirty (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages insserv depends on:
ii  libc6  2.13-35

insserv recommends no packages.

Versions of packages insserv suggests:
pn  bootchart2  none

-- no debconf information
diff -urN insserv-1.14.0.original/debian/patches/11_debian_conf.patch insserv-1.14.0/debian/patches/11_debian_conf.patch
--- insserv-1.14.0.original/debian/patches/11_debian_conf.patch	2012-11-15 20:28:53.639644555 +
+++ insserv-1.14.0/debian/patches/11_debian_conf.patch	2012-11-15 20:32:27.459921674 +
@@ -9,7 +9,7 @@
  # All local filesystems are mounted (done during boot phase)
  #
 -$local_fs	boot.localfs +boot.crypto
-+$local_fs	+mountall +mountoverflowtmp +umountfs
++$local_fs	+mountall +mountall-bootclean +mountoverflowtmp +umountfs
  
  #
  # Low level networking (ethernet card)
diff -urN insserv-1.14.0.original/insserv.conf insserv-1.14.0/insserv.conf
--- insserv-1.14.0.original/insserv.conf	2012-11-15 20:28:53.639644555 +
+++ insserv-1.14.0/insserv.conf	2012-11-15 20:30:57.778120460 +
@@ -1,7 +1,7 @@
 #
 # All local filesystems are mounted (done during boot phase)
 #
-$local_fs	+mountall +mountoverflowtmp +umountfs
+$local_fs	+mountall +mountall-bootclean +mountoverflowtmp +umountfs
 
 #
 # Low level networking (ethernet card)

Bug#677097: mountall-bootclean.sh nukes udev's data in /run

[Roger Leigh]

On Thu, Nov 08, 2012 at 12:44:09PM +0100, Jakub Wilk wrote:
 * Roger Leigh rle...@codelibre.net, 2012-11-08, 00:22:
 
 Would it be possible to debug this in a bit more detail on your
 system? /lib/init/bootclean.sh's clean function must be failing
 all these checks:
 
 Thu Nov  8 12:17:30 2012: Cleaning up temporary files
 Thu Nov  8 12:17:30 2012: BEFORE BOOTMISC: [ .tmpfs dhclient.eth0.pid initctl 
 initramfs lock mount network sendsigs.omit.d shm udev utmp ]
 Thu Nov  8 12:17:30 2012: AFTER BOOTMISC: [ dhclient.eth0.pid initctl 
 initramfs lock mount network sendsigs.omit.d shm udev utmp ]
 Thu Nov  8 12:17:31 2012: Setting up X socket directories... /tmp/.X11-unix 
 /tmp/.ICE-unix.
 Thu Nov  8 12:17:31 2012: BEFORE MOUNTALL-BOOTCLEAN: [ dhclient.eth0.pid 
 initctl initramfs lock mount network sendsigs.omit.d shm udev utmp ]
 Thu Nov  8 12:17:31 2012: Cleaning up temporary files... /tmp /lib/init/rw 
 /run /run/lock /run/shm.
 Thu Nov  8 12:17:31 2012: AFTER MOUNTALL-BOOTCLEAN: [ .clean initramfs lock 
 mount network sendsigs.omit.d shm udev utmp ]
 Thu Nov  8 12:17:31 2012: INIT: Entering runlevel: 2
 
 (This is on a VM on which I had to impose a sleep to make the bug
 trigger. However, the bug also triggers naturally on my development
 machine, which I can't reboot right know, though I'm pretty sure the
 cause is the same there.)
 
 As I understand it, bootmisc is supposed to be run _after_
 mountall-bootclean, though this order doesn't seem to be enforced in
 any way.

So it's looking like we may be just missing a dependency here, so the
bug would be present all the time, but the parallelism is exposing it
more frequently.

Would be worth checking the /etc/init.d/depend files and running
/usr/share/insserv/make-testsuite to see exactly where bootmisc is
being placed in the depdendency graph.  The intention is that this
won't run until after mountall-bootclean.  I /think/ that the
$remote_fs is supposed to ensure this, but this might not be good
enough.  Maybe we need to add mountall_bootclean to $local_fs, or
add X-Start-Before: bootmish.sh to mountall_bootclean.

Could you possible try both of those, rerun insserv, and see if this
prevents the problem from occuring?


Thanks again,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#677097: mountall-bootclean.sh nukes udev's data in /run

[Roger Leigh]

On Wed, Nov 07, 2012 at 08:03:39PM +0100, Jakub Wilk wrote:
 Control: reopen -1 Control: found -1 2.88dsf-32
 
 * Jakub Wilk jw...@debian.org, 2012-06-11, 18:20:
 mountall-bootclean.sh removes files from /run, but these may
 include files created by init scripts earlier in the same boot
 process. I observed this because the script nuked files in
 /run/udev/, leaving my X server without any input devices.
 
 I can still reproduce this bug.

That's a bit frustrating, I thought we had this nailed now.

Would it be possible to debug this in a bit more detail on
your system?  /lib/init/bootclean.sh's clean function must
be failing all these checks:

# Does not exist
[ -d $dir ] || return 1
# tmpfs does not require cleaning
[ -f $dir/.tmpfs ]  return 0
# Can clean?
checkflagfile $dir || return 0
# Already cleaned
[ -f ${dir}/.clean ]  return 0
# Can't clean yet?
which find /dev/null 21 || return 1

Could you possibly put some print statements in there and find
out if all these pass?  If so, is the .tmpfs file missing?
Or the .clean flag file?  If that's the case, we really need
to know why they aren't present, since they should have been
created before this point.

If the init scripts are being run in the wrong order, these
could potentially be run after the files were deleted.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691376: schroot: session recovery mounts $device, not $mount-device, for LVM snapshots

[Roger Leigh]

Package: schroot
Version: 1.6.3-1
Severity: serious
Tags: security
Justification: Security violation and potential for dataloss

Originally reported here:
https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1070008

Calling --recover-session on a session using an LVM snapshot, it
remounts using the original LV rather than the snapshot LV.

This is due to this check failing:
sbuild::chroot_block_device_base::set_device():

  /// @todo: This may not be appropriate for derived classes such as
  /// lvm_snapshot, since re-setting the device could overwrite the
  /// mount device.
  chroot_facet_mountable::ptr pmnt
(get_facetchroot_facet_mountable());
#ifdef SBUILD_FEATURE_LVMSNAP
  if (!dynamic_castchroot_lvm_snapshot *(this))
#endif
pmnt-set_mount_device(this-device);

This is due to the use of dynamic_cast in this method.  This is
not in itself wrong, but because this method is called from the
constructor, the dynamic_cast returns null due to the vptr not
yet having any knowledge of the derived class--it will work fine
once the base class is constructed.

This was already commented in several places to refactor to clean
this up, but the presence of this issue will require this to be
done immediately.

I've tagged this security due to the potential for a user to access
the original source chroot.  However, the scope is relatively
limited since the filesystem permissions will prevent them from
doing anything they should not (unless you granted them root
access, in which case they already had the ability to do this).


Regards,
Roger

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32.33-kvm-i386-2028-dirty (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages schroot depends on:
ii  libboost-filesystem1.49.0   1.49.0-3.1
ii  libboost-iostreams1.49.01.49.0-3.1
ii  libboost-program-options1.49.0  1.49.0-3.1
ii  libboost-regex1.49.01.49.0-3.1
ii  libboost-system1.49.0   1.49.0-3.1
ii  libc6   2.13-35
ii  libgcc1 1:4.7.1-7
ii  liblockdev1 1.0.3-1.5
ii  libpam0g1.1.3-7.1
ii  libstdc++6  4.7.1-7
ii  libuuid12.20.1-5.2
ii  schroot-common  1.6.3-1

schroot recommends no packages.

Versions of packages schroot suggests:
pn  aufs-modules | unionfs-modules  none
pn  btrfs-tools none
ii  debootstrap 1.0.42
pn  lvm2none
pn  qemu-user-staticnone

-- Configuration Files:
/etc/schroot/schroot.conf changed [not included]

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#691376: [buildd-tools-devel] Bug#691376: schroot: session recovery mounts $device, not $mount-device, for LVM snapshots

[Roger Leigh]

tags 1.6.3-1 + patch pending
thanks

On Wed, Oct 24, 2012 at 10:23:27PM +0100, Roger Leigh wrote:

Patch to address this issue.  Note that this is not yet completely
tested for all the other block-device-using chroot types.  **Do
not apply until tested.**

commit 19293f7a7b0943997397ef30465cd11686990a9b
Author: Roger Leigh rle...@debian.org
Date:   Wed Oct 24 23:25:10 2012 +0100

sbuild: Don't call set_mount_device indirectly from ctor

See #691376.

sbuild::chroot_block_device_base::set_device was called from
the chroot_block_device_base ctor, and called
sbuild::chroot_facet_mountable::set_mount_device for all chroot
types except lvm-snapshot.  However, dynamic_cast fails during
construction, leading to the mount device being overwritten, and
--recover-session mounting the source LV rather than the snapshot
LV.  This patch moves the call to set_mount_device to the session
clone operation in sbuild::chroot_facet_session_clonable, which
is where the equivalent operation is done for lvm-snapshot.  This
is done prior to lvm-snapshot to ensure that the snapshot is not
overwritten here either.

diff --git a/sbuild/sbuild-chroot-block-device-base.cc 
b/sbuild/sbuild-chroot-block-device-base.cc
index 2f2f958..86f3af6 100644
--- a/sbuild/sbuild-chroot-block-device-base.cc
+++ b/sbuild/sbuild-chroot-block-device-base.cc
@@ -46,12 +46,8 @@ chroot_block_device_base::chroot_block_device_base ():
 chroot_block_device_base::chroot_block_device_base
 (const chroot_block_device_base rhs):
   chroot(rhs),
-  device()
+  device(rhs.device)
 {
-  /// @todo Required to set mount_device.  Remove once no longer
-  /// needed.
-  if (!rhs.device.empty())
-set_device(rhs.device);
 }
 
 chroot_block_device_base::~chroot_block_device_base ()
@@ -71,16 +67,6 @@ chroot_block_device_base::set_device (std::string const 
device)
 throw error(device, DEVICE_ABS);
 
   this-device = device;
-
-  /// @todo: This may not be appropriate for derived classes such as
-  /// lvm_snapshot, since re-setting the device could overwrite the
-  /// mount device.
-  chroot_facet_mountable::ptr pmnt
-(get_facetchroot_facet_mountable());
-#ifdef SBUILD_FEATURE_LVMSNAP
-  if (!dynamic_castchroot_lvm_snapshot *(this))
-#endif
-pmnt-set_mount_device(this-device);
 }
 
 std::string
diff --git a/sbuild/sbuild-chroot-facet-session-clonable.cc 
b/sbuild/sbuild-chroot-facet-session-clonable.cc
index 408e9ab..1d924ad 100644
--- a/sbuild/sbuild-chroot-facet-session-clonable.cc
+++ b/sbuild/sbuild-chroot-facet-session-clonable.cc
@@ -19,6 +19,7 @@
 #include config.h
 
 #include sbuild-chroot.h
+#include sbuild-chroot-facet-mountable.h
 #include sbuild-chroot-facet-session.h
 #include sbuild-chroot-facet-session-clonable.h
 #include sbuild-chroot-facet-source-clonable.h
@@ -138,6 +139,19 @@ chroot_facet_session_clonable::clone_session_setup 
(chroot::ptr   clone,
  format(Mount Location: %1%) % clone-get_mount_location()
  endl;
 
+  /* Block devices need the mount device name specifying. */
+  /* Note that this will be overridden by LVM snapshot, below, so the
+ order here is important. */
+  std::shared_ptrchroot_block_device_base 
blockdevbase(std::dynamic_pointer_castchroot_block_device_base(clone));
+  if (blockdevbase)
+{
+  chroot_facet_mountable::ptr pmnt
+   (clone-get_facetchroot_facet_mountable());
+  if (pmnt)
+   pmnt-set_mount_device(blockdevbase-get_device());
+}
+
+
 #ifdef SBUILD_FEATURE_LVMSNAP
   /* LVM devices need the snapshot device name specifying. */
   std::shared_ptrchroot_lvm_snapshot 
snapshot(std::dynamic_pointer_castchroot_lvm_snapshot(clone));


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#686148: [buildd-tools-devel] Bug#686148: schroot: Does not unmount /run/shm

[Roger Leigh]

severity 686148 serious
tags 686148 + fixed-upstream pending
thanks

On Wed, Aug 29, 2012 at 09:42:16AM +0200, Daniel Dehennin wrote:
 I noticed several “/run/shm” in my mount since a moment but did not
 figure out where they came from.
   tmpfs on /run/shm type tmpfs (rw,relatime)
 
 After quitting the schroot, the “/run/shm” is still here.

Thanks for reporting this.  I've made this RC severity due to this
giving an end user the ability to mount over the host /run/shm,
which could cause problems on the host system.  They can't alter
the content of the fstab, but if they have root access in the
chroot, they could place symlinks to arbitrary places on the
host.

In git, I've updated schroot-mount to use realpath(3) to
canonicalise the path, which will remove all symlinks.  We then
ensure that any links outside the chroot will be resolved
inside before mounting.  This does have a limitation: we call
realpath(3) on the host, so complex nested symlinks may resolve
differently.  But anyone using complex sets of nested links as
mountpoints is insane!  And even in this case, they will all
get mounted inside the chroot, so there's no danger of
compromising the host.

This will fix the problem you reported.

This might also need backporting to 1.4 and squeeze.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#673676: [buildd-tools-devel] Bug#673676: sbuild-createchroot: broken due to debian-archive-keyring changes

[Roger Leigh]

On Thu, Aug 16, 2012 at 05:16:23PM +0200, Cyril Brulebois wrote:
 Roger Leigh rle...@codelibre.net (04/07/2012):
  This was fixed in 4bc2072701ddd last week, and is pending upload.
  (Should already be tagged pending.)
  
  I have a few other bugs to fix in sbuild, but should be uploading it
  in the next week or so.
 
 “Next month”-ly-ping?

This was done over the weekend.  Hope this addresses all the
outstanding issues.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#679409: lightdm: Fails to start on boot, invoke-rc.d lightdm start fails

[Roger Leigh]

On Sun, Aug 19, 2012 at 12:53:21PM -0700, Steve Langasek wrote:
 On Sun, Aug 12, 2012 at 09:48:02AM +0100, Roger Leigh wrote:
  On Sun, Aug 12, 2012 at 03:37:52PM +1000, James Tocknell wrote:
 
  I've patched startpar to special-case lightdm as for gdm/kdm, but this
  doesn't appear to have any effect here (but is probably generally a good
  thing to have).
 
 The change that was committed has nothing at all to do with this bug, and to
 me it looks like an unnecessary divergence from startpar upstream; so I've
 reverted those changes from the git repo.  IMHO it's not something that's
 worth carrying a delta from upstream over.  But feel free to reinstate if
 you disagree.

My thinking here was that if startpar is special casing the priorities
of display managers, shouldn't it be behaving the same for all the
common ones?  That said, I am not certain /why/ it's special casing
them in the first place; certainly lightdm appears to function
perfectly well without the patch.  I don't have strong feelings either
way here--personally I'd prefer them all removed if this is solely to
hack in something better expressed through dependencies.

 BTW, Roger, could you please run 'echo DEBCHANGE_RELEASE_HEURISTIC=changelog
  ~/.devscripts' on your development machine?  This is the only sensible
 behavior to use with dch in a shared VCS; it's very frustrating to have to
 check the archive or look at git tags each time to figure out whether the
 changes I'm looking at on trunk are uploaded or not...

I've done this, but isn't it the documented default behaviour?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#672959: [patch] Bug#672959: kfreebsd-*: panic: vm_fault_copy_wired

[Roger Leigh]

On Tue, Aug 21, 2012 at 10:47:57AM +0200, Axel Beckert wrote:
 Hi,
 
 Petr Salinger wrote:
  I'm beginning to think that startpar is malfunctioning in some way
  (after checkroot.sh returns, but before it runs the next script).
  
  Thanks to Steven for excelent hint.
 
 Indeed. That fits perfectly with my observation that always the last
 thing I saw before the crash was the : from the last line of
 checkroot.sh. No trace of another init.d script being started.
 
  The patch bellow fixes it for me.
  Please could also other people verify it.
 
 Will do this evening. Thanks Petr!

Many thanks Petr for the patch, and everyone else for testing and
investigating.

I've put a test package here:
  http://people.debian.org/~rleigh/sysvinit/sysvinit_2.88dsf-33.dsc

I'd be grateful if anyone could build this and double-check that this
is correct, and fixes the bug.  I'll upload this as soon as that's
done.


Thanks again,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#673676: [buildd-tools-devel] Bug#673676: sbuild-createchroot: broken due to debian-archive-keyring changes

[Roger Leigh]

On Thu, Aug 16, 2012 at 05:16:23PM +0200, Cyril Brulebois wrote:
 Roger Leigh rle...@codelibre.net (04/07/2012):
  This was fixed in 4bc2072701ddd last week, and is pending upload.
  (Should already be tagged pending.)
  
  I have a few other bugs to fix in sbuild, but should be uploading it
  in the next week or so.
 
 “Next month”-ly-ping?

Sorry, got caught up with other things.  I'll upload it this weekend.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#672066: Still broken in unstable

[Roger Leigh]

 at the point 
of instantiation [-fpermissive]
Printer.cpp:42:26: note: ‘IceProxy::Ice::Object* 
IceInternal::upCast(IceProxy::Demo::Printer*)’ declared here, later in the 
translation unit
In file included from /usr/include/Ice/LocalObjectF.h:15:0,
 from ./Printer.h:24,
 from Printer.cpp:21:
/usr/include/Ice/Handle.h: In instantiation of 
‘IceInternal::HandleT::Handle(const IceInternal::HandleT) [with T = 
Ice::Object; IceInternal::HandleT = IceInternal::HandleIce::Object]’:
Printer.cpp:241:12:   required from here
/usr/include/Ice/Handle.h:98:13: error: ‘upCast’ was not declared in this 
scope, and no declarations were found by argument-dependent lookup at the point 
of instantiation [-fpermissive]
Printer.cpp:42:26: note: ‘IceProxy::Ice::Object* 
IceInternal::upCast(IceProxy::Demo::Printer*)’ declared here, later in the 
translation unit
In file included from /usr/include/Ice/LocalObjectF.h:15:0,
 from ./Printer.h:24,
 from Printer.cpp:21:
/usr/include/Ice/Handle.h: In instantiation of 
‘IceInternal::HandleT::~Handle() [with T = Demo::Printer]’:
Printer.cpp:387:43:   required from here
/usr/include/Ice/Handle.h:106:13: error: ‘upCast’ was not declared in this 
scope, and no declarations were found by argument-dependent lookup at the point 
of instantiation [-fpermissive]
Printer.cpp:42:26: note: ‘IceProxy::Ice::Object* 
IceInternal::upCast(IceProxy::Demo::Printer*)’ declared here, later in the 
translation unit
In file included from /usr/include/Ice/LocalObjectF.h:15:0,
 from ./Printer.h:24,
 from Printer.cpp:21:
/usr/include/Ice/Handle.h: In instantiation of ‘IceInternal::HandleT 
IceInternal::HandleT::operator=(const IceInternal::HandleT) [with T = 
Demo::Printer; IceInternal::HandleT = IceInternal::HandleDemo::Printer]’:
Printer.cpp:387:43:   required from here
/usr/include/Ice/Handle.h:178:17: error: ‘upCast’ was not declared in this 
scope, and no declarations were found by argument-dependent lookup at the point 
of instantiation [-fpermissive]
Printer.cpp:42:26: note: ‘IceProxy::Ice::Object* 
IceInternal::upCast(IceProxy::Demo::Printer*)’ declared here, later in the 
translation unit
In file included from /usr/include/Ice/LocalObjectF.h:15:0,
 from ./Printer.h:24,
 from Printer.cpp:21:
/usr/include/Ice/Handle.h:186:17: error: ‘upCast’ was not declared in this 
scope, and no declarations were found by argument-dependent lookup at the point 
of instantiation [-fpermissive]
Printer.cpp:42:26: note: ‘IceProxy::Ice::Object* 
IceInternal::upCast(IceProxy::Demo::Printer*)’ declared here, later in the 
translation unit
In file included from /usr/include/Ice/LocalObjectF.h:15:0,
 from ./Printer.h:24,
 from Printer.cpp:21:
/usr/include/Ice/Handle.h: In instantiation of 
‘IceInternal::HandleT::Handle(T*) [with T = Demo::Printer]’:
/usr/include/Ice/Handle.h:198:47:   required from ‘static 
IceInternal::HandleT IceInternal::HandleT::dynamicCast(const 
IceUtil::HandleBaseY) [with Y = Ice::Object; T = Demo::Printer; 
IceInternal::HandleT = IceInternal::HandleDemo::Printer]’
Printer.cpp:387:43:   required from here
/usr/include/Ice/Handle.h:66:13: error: ‘upCast’ was not declared in this 
scope, and no declarations were found by argument-dependent lookup at the point 
of instantiation [-fpermissive]
Printer.cpp:42:26: note: ‘IceProxy::Ice::Object* 
IceInternal::upCast(IceProxy::Demo::Printer*)’ declared here, later in the 
translation unit
In file included from /usr/include/Ice/LocalObjectF.h:15:0,
 from ./Printer.h:24,
 from Printer.cpp:21:
/usr/include/Ice/Handle.h: In instantiation of 
‘IceInternal::HandleT::Handle(const IceInternal::HandleT) [with T = 
Demo::Printer; IceInternal::HandleT = IceInternal::HandleDemo::Printer]’:
/usr/include/Ice/Handle.h:198:47:   required from ‘static 
IceInternal::HandleT IceInternal::HandleT::dynamicCast(const 
IceUtil::HandleBaseY) [with Y = Ice::Object; T = Demo::Printer; 
IceInternal::HandleT = IceInternal::HandleDemo::Printer]’
Printer.cpp:387:43:   required from here
/usr/include/Ice/Handle.h:98:13: error: ‘upCast’ was not declared in this 
scope, and no declarations were found by argument-dependent lookup at the point 
of instantiation [-fpermissive]
Printer.cpp:42:26: note: ‘IceProxy::Ice::Object* 
IceInternal::upCast(IceProxy::Demo::Printer*)’ declared here, later in the 
translation unit

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#679409: lightdm: Fails to start on boot, invoke-rc.d lightdm start fails

[Roger Leigh]

On Sun, Aug 12, 2012 at 03:37:52PM +1000, James Tocknell wrote:
 I've tested the patch, and it doesn't fix the issue I'm having. I'm
 using Upstart
 as my init daemon, and lightdm still fails, with no useful output in
 /var/log/boot. However, lightdm does start when I use sysvinit as the init
 daemon, with the patch. Could this be a Upstart issue? I know lightdm has
 some association with Ubuntu, and Upstart is Ubuntu's default init daemon,
 could the issue be with the very different versions of Upstart in Ubuntu and
 Debian? The problem could lie in the fix for the bug #660824, which was a
 change between the version of sysvinit-utils that works for me and don't work
 for me, as it's Upstart related.

I'll have to ask Steve Langasek, who was responsible for that change.

Steve, it appears that lightdm won't start using upstart with the
recent sysvinit upstart bridge stuff.  I'm not sure if this is an
issue in sysvinit, startpar-upstart-inject, or upstart.  I've
patched startpar to special-case lightdm as for gdm/kdm, but this
doesn't appear to have any effect here (but is probably generally
a good thing to have).


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#672959: kfreebsd-*: panic: vm_fault_copy_wired

[Roger Leigh]

On Sun, Jul 22, 2012 at 02:06:11PM +0100, Roger Leigh wrote:
 On Sat, Jul 21, 2012 at 11:47:24PM +0200, Carlos Alberto Lopez Perez wrote:
  On 21/07/12 23:32, Roger Leigh wrote:
   Looking at the screenshot you attached, I can't see any obvious
   reason for fsck to make the kernel panic.  There's no indication
   of odd scripts (other than geli) running in parallel here.  This
   really needs investigation from a kfreebsd person; I'm not
   sufficiently knowledgeable to look into it myself.
  
  I guess this is reproducible by simply installing Debian/kFreeBSD AMD64
  on a virtual machine and forcing and unclean shutdown (killing the qemu
  process when the virtual machine is running).
 
 I'm sure it is, but it needs someone with kfreebsd familiarity to
 do this, and that's not me.  I don't have the time or skills to fix
 kfreebsd issues, but I can test, review and apply patches that any
 kfreebsd people wish to provide.

Hi debian-bsd people,

This bug is still RC for wheezy.  It really needs looking at by a
kfreebsd expert, if someone could take a look at this.

Given that this is only being experienced on kfreebsd, I would
suggest starting with any kfreebsd-specific init scripts which
could be running ahead of time if the dependencies aren't
correct.


Many thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#679409: lightdm: Fails to start on boot, invoke-rc.d lightdm start fails

[Roger Leigh]

On Wed, Jul 11, 2012 at 02:06:52PM +1000, James Tocknell wrote:
 On Mon, Jul 2, 2012 at 6:04 PM, Yves-Alexis Perez cor...@debian.org wrote:
  On lun., 2012-07-02 at 10:02 +0200, Petter Reinholdtsen wrote:
  [Yves-Alexis Perez]
   James, in any case, I think providing /etc/init.d/.depend.* might
   help solving this.
 
  Actually, it is better to provide the output from
  /usr/share/insserv/make-testsuite, which allow the boot sequence to be
  reproduced using dummy init.d scripts.
 
   Please keep me on CC: so I'm informed of the development. It might
   be interesting to provide /var/log/lightdm.log and
   /var/log/lightdm-gtk-greeeter.log, although the fact it works with
   startx might means it won't show anything.
 
  To debug this, try to disable concurrent booting (and keep dependency
  based boot sequencing), and see if it work better.  Also, it would be
  useful to get the boot log (/var/log/boot.log) after enabling
  bootlogd.

lightdm uses the following dependencies:

# Should-Start:  console-screen kbd acpid dbus hal consolekit
# Required-Start:$local_fs $remote_fs x11-common
# Required-Stop: $local_fs $remote_fs

gdm uses:

# Should-Start:  console-screen dbus network-manager
# Required-Start:$local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs

kdm uses:

# Required-Start:$local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Should-Start:  console-screen kbd acpid dbus hal krb5-kdc
# Should-Stop:   console-screen kbd


While sysvinit has changed quite a few things since the last
version which worked with lightdm, there's very little there to
indicate anything which would affect lightdm.  It's most likely
that there's something wrong with the lightdm dependencies above.
Please do see if there's something missing, or should rather
than required.

Is the x11-common dependency needed? --why do gdm and kdm omit this?
Are there any lightdm dependencies missing?

I've installed lightdm on my system, and I do see the occasional
failure to start.  This would indicate some race in parallelisation
which would be indicative of a missing dependency.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#684607: [buildd-tools-devel] Bug#684607: Chroot setup failed: stage=setup-start

[Roger Leigh]

On Sat, Aug 11, 2012 at 08:23:28PM +0200, Christoph Egger wrote:
   Nothing changed in config for almost a year, schroot fails to set up
 a chroot now. Log attached.

 D(2): run_parts: executing 50chrootname, setup-start, ok
 I: Executing ‘50chrootname setup-start ok’
 I: 50chrootname: Setting chroot name to unstable-amd64-sbuild
 D(2): run_parts: 50chrootname failed with status 1
 D(3): Chroot setup scripts, exec scripts or session failed

OK, so it's the 50chrootname script failing here.  The only change
to that script in the last year has been the addition of a single
line:

  d04e32dd etc/setup.d/50chrootname   (Roger Leigh 2012-04-03 23:29:40 
+0100 24) . $SETUP_DATA_DIR/common-config

  
http://anonscm.debian.org/gitweb/?p=buildd-tools/schroot.git;a=commitdiff;h=d04e32dd3cc39ea641fc2848957292fe94751925

However, as you can see by looking at the diff, that line was added
to all the other scripts as well, and you should have the script here:

  % ls /usr/share/schroot/setup 
  common-config  common-data  common-functions

Since you get the Setting chroot name... message, the only other line
in the file which can fail is:

  echo ${CHROOT_NAME}  ${CHROOT_PATH}/etc/debian_chroot

Which would imply that this failed.  It doesn't give an error why--did
your debug log also capture stderr?  If not, a copy with stderr included
would be useful here.  All the variables like CHROOT_NAME and
CHROOT_PATH look correct.  SETUP_DATA_DIR is likewise correct for
sourcing the shell scripts at the top.  Is /etc/debian_chroot writable
by the setup script?  / and /etc must be writable by root.

So it would be very useful to know
- the stderr (e.g. run with script or 21)
- if you can check the filesystem permissions or anything else that
  might interfere with writing (e.g. free blocks/inodes)


I'm not sure the grave severity is justified here.  From what you've
shown, this can only be a single line in the 50chrootname setup script
failing.  All the values set in the script are correct AFAICT, so it's
most likely down to a filesystem issue or some other problem making
that single echo statement fail.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#679409: lightdm: Fails to start on boot, invoke-rc.d lightdm start fails

[Roger Leigh]

On Sat, Aug 11, 2012 at 05:26:29PM +0100, Roger Leigh wrote:
 On Wed, Jul 11, 2012 at 02:06:52PM +1000, James Tocknell wrote:
  On Mon, Jul 2, 2012 at 6:04 PM, Yves-Alexis Perez cor...@debian.org wrote:
   On lun., 2012-07-02 at 10:02 +0200, Petter Reinholdtsen wrote:
   [Yves-Alexis Perez]
James, in any case, I think providing /etc/init.d/.depend.* might
help solving this.
  
   Actually, it is better to provide the output from
   /usr/share/insserv/make-testsuite, which allow the boot sequence to be
   reproduced using dummy init.d scripts.
  
Please keep me on CC: so I'm informed of the development. It might
be interesting to provide /var/log/lightdm.log and
/var/log/lightdm-gtk-greeeter.log, although the fact it works with
startx might means it won't show anything.
  
   To debug this, try to disable concurrent booting (and keep dependency
   based boot sequencing), and see if it work better.  Also, it would be
   useful to get the boot log (/var/log/boot.log) after enabling
   bootlogd.
 
 I've installed lightdm on my system, and I do see the occasional
 failure to start.  This would indicate some race in parallelisation
 which would be indicative of a missing dependency.

Please could you try sysvinit with the patch attached here?  This special
cases lightdm in startpar, since gdm/kdm/xdm are already special cased
here.

http://anonscm.debian.org/gitweb/?p=collab-maint/sysvinit;a=commitdiff;h=34ee13ba8d509183b568c70511289f7f7579502b

If you're unable to build yourself, let me know and I'll prepare some
packages.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
From 34ee13ba8d509183b568c70511289f7f7579502b Mon Sep 17 00:00:00 2001
From: Roger Leigh rle...@debian.org
Date: Sat, 11 Aug 2012 22:16:00 +0100
Subject: [PATCH 1/2] startpar: Add patch to special case lightdm

---
 debian/patches/78_startpar_lightdm.patch |   15 +++
 debian/patches/series|1 +
 2 files changed, 16 insertions(+), 0 deletions(-)
 create mode 100644 debian/patches/78_startpar_lightdm.patch

diff --git a/debian/patches/78_startpar_lightdm.patch b/debian/patches/78_startpar_lightdm.patch
new file mode 100644
index 000..e110b8a
--- /dev/null
+++ b/debian/patches/78_startpar_lightdm.patch
@@ -0,0 +1,15 @@
+Purpose: Add lightdm to list of special cased *dms
+Fixes:   Intermittent failure to start lightdm
+Author:  Roger Leigh
+Status:  Not yet submitted upstream
+---
+--- a/startpar/makeboot.c	2012-08-11 21:58:53.0 +0100
 b/startpar/makeboot.c	2012-08-11 22:00:57.0 +0100
+@@ -273,6 +273,7 @@
+ 		if (! strcmp(node-name, xdm)
+ 		|| ! strncmp(node-name, gdm, 3)
+ 		|| ! strncmp(node-name, kdm, 3)
++		|| ! strncmp(node-name, lightdm, 7)
+ 		|| ! strcmp(node-name, boot.udev)
+ 		|| ! strcmp(node-name, udev))
+ 			importance = 100;
diff --git a/debian/patches/series b/debian/patches/series
index e4139b0..b70da91 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -16,6 +16,7 @@
 75_man_startpar_see_also.patch
 76_startpar_ldflags.patch
 77_startpar_skip_reason.patch
+78_startpar_lightdm.patch
 91_sulogin_lockedpw.dpatch
 92_kfreebsd_ifdown.patch
 93_run_initctl.patch
-- 
1.7.2.5

Bug#683103: mkdir: cannot create directory `/run/shm': File exists

[Roger Leigh]

On Tue, Aug 07, 2012 at 09:18:39AM +0200, Vincent Danjean wrote:
   I've just been hit by this bug in a schroot.
   The host has initscripts 2.88dsf-28 installed.
   When upgrading my sid schroot, I got the error:
 mkdir: cannot create directory `/run/shm': File exists
 dpkg: error processing initscripts (--configure):
 
   Looking at the situation on this system, I see:
 atsina:/users/huron/danjean# mountpoint /dev
 /dev is a mountpoint
 atsina:/users/huron/danjean# mountpoint /dev/shm
 mountpoint: /dev/shm: not a directory
 atsina:/users/huron/danjean# ls -ld /dev/shm /run/shm
 lrwxrwxrwx 1 root root 8 Jul  6 18:58 /dev/shm - /run/shm
 lrwxrwxrwx 1 root root 8 May 22  2011 /run/shm - /dev/shm
 
   I do not know from where the circular symlink come from.
 The schroot worked well (up-to-date) before I go to holidays, 3 weeks ago.

I think vorlon's patch to improve the shm upgrade broke some
particular cases.  I've got a patch to fix it in progress.
However, I do need to work out how to deal with all
possible combinations of:

/dev being a mountpoint
/dev/shm being a mountpoint
/run being a mountpoint
/dev/shm being a symlink or directory
/run/shm being a symlink or directory

We need to take special care never to alter the bind mounted
host environment, so as to not alter any state where a mountpoint
is present.  I should hopefully have time for this tonight.  It's
not such a combinatorial explosion as indicated above--if any
mountpoints are present it restricts what we can do.  So e.g.
if /dev is a mountpoint and /dev/shm is a symlink, then /run/shm
must be a directory since we can't alter the symlink.  And vice
versa if it's a directory, then /run/shm must be a symlink.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#683103: mkdir: cannot create directory `/run/shm': File exists

[Roger Leigh]

On Sat, Jul 28, 2012 at 09:42:53PM +0200, Cyril Brulebois wrote:
 Package: initscripts
 Version: 2.88dsf-13.1+squeeze1
 Severity: serious
 Justification: fails to upgrade
 
 Hi,
 
 during the sid chroot dist-upgrade on harris.debian.org, initscripts
 failed to upgrade due to:
 | Setting up initscripts (2.88dsf-29) ...
 | mkdir: cannot create directory `/run/shm': File exists
 | dpkg: error processing initscripts (--configure):
 |  subprocess installed post-installation script returned error exit status 1
 | Errors were encountered while processing:
 |  initscripts
 | E: Sub-process /usr/bin/dpkg returned an error code (1)
 
 Not fun…

Hmm, that's due to vorlon's recent change, I think.  Is this inside
a chroot?  If so, it's this logic failing:

# Symlink /dev/shm from /run/shm
# Note that it's really /var/run/shm
if mountpoint -q /dev  mountpoint -q /dev/shm; then
compat_link /dev/shm /run/shm
else
[ -d /run/shm ] || mkdir -p /run/shm
mountpoint -q /dev || compat_link /run/shm /dev/shm
fi

What is the output of
  % ls -ld /dev /dev/shm /run /run/shm
on this system?


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#683103: mkdir: cannot create directory `/run/shm': File exists

[Roger Leigh]

On Sat, Jul 28, 2012 at 11:12:52PM +0100, Roger Leigh wrote:
 On Sat, Jul 28, 2012 at 09:42:53PM +0200, Cyril Brulebois wrote:
  Package: initscripts
  Version: 2.88dsf-13.1+squeeze1
  Severity: serious
  Justification: fails to upgrade
  
  Hi,
  
  during the sid chroot dist-upgrade on harris.debian.org, initscripts
  failed to upgrade due to:
  | Setting up initscripts (2.88dsf-29) ...
  | mkdir: cannot create directory `/run/shm': File exists
  | dpkg: error processing initscripts (--configure):
  |  subprocess installed post-installation script returned error exit status 
  1
  | Errors were encountered while processing:
  |  initscripts
  | E: Sub-process /usr/bin/dpkg returned an error code (1)
  
  Not fun…
 
 Hmm, that's due to vorlon's recent change, I think.  Is this inside
 a chroot?  If so, it's this logic failing:
 
   # Symlink /dev/shm from /run/shm
   # Note that it's really /var/run/shm
   if mountpoint -q /dev  mountpoint -q /dev/shm; then
   compat_link /dev/shm /run/shm
   else
   [ -d /run/shm ] || mkdir -p /run/shm
   mountpoint -q /dev || compat_link /run/shm /dev/shm
   fi
 
 What is the output of
   % ls -ld /dev /dev/shm /run /run/shm
 on this system?

Actually, just seen it myself, and I have:

% ls -ld /dev /dev/shm /run /run/shm
drwxr-xr-x 13 root root 3680 Jul 28 22:57 /dev
lrwxrwxrwx  1 root root8 Jul 28 11:45 /dev/shm - /run/shm
drwxr-xr-x 21 root root  840 Jul 28 22:57 /run
drwxrwxrwt  2 root root   40 Jul 28 11:45 /run/shm

So that's all set up correctly.  Unless my shell-fu is missing
something tonight, I'm not sure what's causing the mkdir to be
run here, given that the directory already exists.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#672959: kfreebsd-*: panic: vm_fault_copy_wired

[Roger Leigh]

On Sat, Jul 21, 2012 at 11:47:24PM +0200, Carlos Alberto Lopez Perez wrote:
 On 21/07/12 23:32, Roger Leigh wrote:
  Looking at the screenshot you attached, I can't see any obvious
  reason for fsck to make the kernel panic.  There's no indication
  of odd scripts (other than geli) running in parallel here.  This
  really needs investigation from a kfreebsd person; I'm not
  sufficiently knowledgeable to look into it myself.
 
 I guess this is reproducible by simply installing Debian/kFreeBSD AMD64
 on a virtual machine and forcing and unclean shutdown (killing the qemu
 process when the virtual machine is running).

I'm sure it is, but it needs someone with kfreebsd familiarity to
do this, and that's not me.  I don't have the time or skills to fix
kfreebsd issues, but I can test, review and apply patches that any
kfreebsd people wish to provide.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#680861: aiccu: Breaks dist-upgrade if not correctly configured

[Roger Leigh]

On Fri, Jul 20, 2012 at 09:52:11AM +0200, Reinier Haasjes wrote:
 On 7/5/2012 8:14 PM, Roger Leigh wrote:
  I have deliberately commented out some of the fields in aiccu.conf.
  This means that the service fails to start.
  However, this is not a reason to completely break
  apt-get upgrade|dist-upgrade.  Please continue if invoke-rc.d start fails
  by using || true or a similar construct.
 
 This is not a aiccu-bug, it happens to other packages also. I borked the
 sshd config and tried to upgrade:
 
 Personaly I think you shouldn't bork the config to not get the service
 started but use something like: update-rc.d disable aiccu

While this is true, aiccu causes problems due to its unique requirement
that you must have a valid username/password etc. for your tunnel
broker.  ssh does not--by default it works without error, unless you
take deliberate steps to break it.

When I install aiccu, I might not yet have these details due to needing
to sign up, or not having the details to hand.  I don't think it's a
reasonable expectation to require these.

The other point is that if I don't have these details, then it's not
worth starting up.  There's a difference between a broken configuration
and being unconfigured.  If it's broken, then it's legitimate to fail
on startup; if it's not yet been configured, then by all means print
a warning, but please don't error out.

  Also, please don't ask debconf questions for the username and password,
  when these are trivially editable in the configuration file.  It serves
  no purpose other than to annoy, because it interrupts upgrading by
  requiring interactive prompting.  It's annoying because it's entirely
  unnecessary and wastes everyone's time.  We have dpkg conffile
  handling to deal with configuration file updates; please don't add
  additional work on top of that.
 
 This will be handled in #680593.

Thanks, that would be much appreciated.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#681876: [buildd-tools-devel] Bug#681876: Acknowledgement (dchroot: Bad upgrade path)

[Roger Leigh]

On Tue, Jul 17, 2012 at 03:35:37PM +0200, Kurt Roeckx wrote:
 After actually trying this from a squeeze version, I end up with:
 W: line 13 [i386-sid]: Deprecated key 'script-config' used
 I: This option will be removed in the future; please update your configuration
 W: line 10 [i386-sid]: Obsolete key 'priority' used

These are expected: dchroot --config will create a configuration
using the keys it knows about, which are deprecated in the new
version.

 I: This option has been removed, and no longer has any effect
 E: Access not authorised
 I: You do not have permission to access the schroot service.
 I: This failure will be reported.

This is, I think, due to the fact that dchroot (and dchroot-dsa)
have different authentication/authorisation semantics than schroot.
They override the authorisation logic used by schroot when using
dchroot.conf (when using schroot.conf they use the schroot
semantics); in 1.6 they always use the schroot.conf and hence the
schroot semantics (the dchroot code having been removed).

This is due to dchroot allowing all users to use the service by
default, while schroot requires all users/groups allowed to use
it to be specified in the configuration.  The configuration that
dchroot dumps is valid, but only when used with the dchroot
authorisation/authentication semantics; it still requires the
admin to manually edit to allow users to use the service.

We can certainly dump the dchroot configuration to
/etc/schroot/chroot.d/dchroot-XX in the preinst (so the old
dchroot is used to dump).  For the allowed users/groups, we can't
currently represent dchroot behavour in the schroot.conf format
(users/groups don't currently allow wildcards; I have a patch
to allow regex matching, but this is not currently merged (it's
on my wildcard-auth branch).  So for the time being, we would have
to document this and add to NEWS.Debian.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#680861: aiccu: Breaks dist-upgrade if not correctly configured

[Roger Leigh]

Package: aiccu
Version: 20070115-15.1
Severity: serious
Justification: Breaks upgrades

Setting up aiccu (20070115-15.1) ...
Files /usr/share/aiccu/conf-templates/aiccu.conf and /etc/aiccu.conf differ
[FAIL] AICCU is not configured, edit /etc/aiccu.conf first ... failed!
invoke-rc.d: initscript aiccu, action start failed.
dpkg: error processing aiccu (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 aiccu
E: Sub-process /usr/bin/dpkg returned an error code (1)

I have deliberately commented out some of the fields in aiccu.conf.
This means that the service fails to start.
However, this is not a reason to completely break
apt-get upgrade|dist-upgrade.  Please continue if invoke-rc.d start fails
by using || true or a similar construct.

Also, please don't ask debconf questions for the username and password,
when these are trivially editable in the configuration file.  It serves
no purpose other than to annoy, because it interrupts upgrading by
requiring interactive prompting.  It's annoying because it's entirely
unnecessary and wastes everyone's time.  We have dpkg conffile
handling to deal with configuration file updates; please don't add
additional work on top of that.


Thanks,
Roger

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (550, 'unstable'), (500, 'testing'), (400, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages aiccu depends on:
ii  debconf [debconf-2.0]  1.5.45
ii  iproute20120521-3
ii  iputils-ping   3:20101006-1+b1
ii  iputils-tracepath  3:20101006-1+b1
ii  libc6  2.13-34
ii  libgnutls262.12.20-1
ii  lsb-base   4.1+Debian7
ii  ucf3.0025+nmu3

Versions of packages aiccu recommends:
ii  bind9-host  1:9.8.1.dfsg.P1-4.1
ii  dnsutils1:9.8.1.dfsg.P1-4.1
ii  ntp 1:4.2.6.p5+dfsg-2

aiccu suggests no packages.

-- Configuration Files:
/etc/aiccu.conf [Errno 13] Permission denied: u'/etc/aiccu.conf'

-- debconf information excluded



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#673676: [buildd-tools-devel] Bug#673676: sbuild-createchroot: broken due to debian-archive-keyring changes

[Roger Leigh]

On Wed, Jul 04, 2012 at 12:56:14PM +0200, Cyril Brulebois wrote:
 found 673676 0.63.1-1
 severity 673676 serious
 thanks
 
 Philipp Kern pk...@debian.org (20/05/2012):
  debian-archive-keyring does no longer include Debian archive keys in
  /etc/apt/trusted.gpg.  sbuild-createchroot calls debootstrap
  specifying it explictly:
  
  I: Running debootstrap --arch=amd64 --variant=buildd --verbose 
  --include=fakeroot,build-essential,debfoster --components=main 
  --keyring=/etc/apt/trusted.gpg --resolve-deps sid /srv/chroots/sid-sbuild 
  http://ftp.de.debian.org/debian/
  
  debootstrap itself copes quite well without that setting.  I'd suggest
  to only pass on --keyring if it got passed to the script itself.
 
 not being able to run sbuild-createchroot by default looks like a
 serious bug in the sbuild package. Bumping severity accordingly.

This was fixed in 4bc2072701ddd last week, and is pending upload.
(Should already be tagged pending.)

I have a few other bugs to fix in sbuild, but should be uploading it
in the next week or so.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#679523: initscripts: 2.88dsf-28 version (unstable) creates issues with udev

[Roger Leigh]

On Mon, Jul 02, 2012 at 01:03:17PM +0200, Eloi COUTANT wrote:
 Hi,
 
 Here is the result of the ls -ld /run /var/run command:
 --
 lrwxrwxrwx  1 root root   8 oct.  25  2011 /run - /var/run
 drwxr-xr-x 21 root root 900 juil.  2 12:49 /var/run
 --

Thanks.  I fixed this issue in git yesterday, and it will be
uploaded soon.  In the interim, you may find fixed versions of
the packages here:

  http://people.debian.org/~rleigh/sysvinit/


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#671124: initscripts: Fails to update due to mountoverflowtmp

[Roger Leigh]

On Sun, Jun 24, 2012 at 03:09:12AM +0200, Cyril Brulebois wrote:
 severity 671124 serious
 tag 671124 - moreinfo
 thanks
 
 Roger Leigh rle...@codelibre.net (05/06/2012):
  I have not had any other reports of this, and I can't reproduce it
  myself.  As I stated above, this file and maintainer scripts
  pertaining to it were not changed for several years, so in the
  absence of further information or being able to reproduce, I can't
  really do much more with this at the present.  I'm downgrading the
  severity for the time being--if this is a reproducible bug, it's
  already in stable and testing.
 
 That's trivially reproducible.
 
 Install squeeze, rm /etc/init.d/mountoverflowtmp, replace squeeze with
 wheezy in sources.list, apt-get update, apt-get dist-ugprade.
 
 Hint: the postinst's being set -e, and your calling update-rc.d
 unconditionally on scripts that can go away (they're conffiles) is
 probably a bad idea.

Thanks.  This begins to make sense, though it is not by any means a
new bug (it's most likely been present since 4b9dd323 in 2009 which
removed the updatercd shell function, which skipped running
update-rc.d if the script wasn't present).

Petter, maybe we should add that function back, doing just this single
check?  Since this affects all initscripts (despite it being very
unusual to want to delete critical initscripts), we should probably
do this for all scripts.


Regards,
Roger
-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#671124: initscripts: Fails to update due to mountoverflowtmp

[Roger Leigh]

On Sun, Jun 24, 2012 at 06:39:25PM +0200, Petter Reinholdtsen wrote:
 [Roger Leigh]
  Petter, maybe we should add that function back, doing just this single
  check?  Since this affects all initscripts (despite it being very
  unusual to want to delete critical initscripts), we should probably
  do this for all scripts.
 
 The function was removed because it was not handling dependency based boot
 sequencing, and I suspect it is better to work with the tools currently
 available instead of trying to use the old function.

How does the following look to you?  (I only wanted to put the
check for whether the script exists in the shell function, BTW, not
to keep any of the old logic.)

diff --git a/debian/bootlogd.postinst b/debian/bootlogd.postinst
index 381fb69..d07cd8d 100644
--- a/debian/bootlogd.postinst
+++ b/debian/bootlogd.postinst
@@ -1,8 +1,14 @@
 #!/bin/sh
 set -e
 
-update-rc.d bootlogd start 05 S . /dev/null || exit $?
-update-rc.d stop-bootlogd-single start 99 S . /dev/null || exit $?
-update-rc.d stop-bootlogdstart 99 2 3 4 5 . /dev/null || exit $?
+if [ -x /etc/init.d/bootlogd ]; then
+update-rc.d bootlogd start 05 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/stop-bootlogd-single ]; then
+update-rc.d stop-bootlogd-single start 99 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/stop-bootlogd ]; then
+update-rc.d stop-bootlogdstart 99 2 3 4 5 . /dev/null || exit $?
+fi
 
 #DEBHELPER#
diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst
index 7235100..b6b319e 100755
--- a/debian/initscripts.postinst
+++ b/debian/initscripts.postinst
@@ -150,34 +150,83 @@ fi
 #
 # Links in runlevel S
 #
+if [ -x /etc/init.d/mountkernfs.sh ]; then
 update-rc.d mountkernfs.sh start 02 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/hostname.sh ]; then
 update-rc.d hostname.shstart 02 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/mountdevsubfs.sh ]; then
 update-rc.d mountdevsubfs.sh   start 04 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/checkroot.sh ]; then
 update-rc.d checkroot.sh   start 10 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/mtab.sh ]; then
 update-rc.d mtab.shstart 12 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/checkroot-bootclean.sh ]; then
 update-rc.d checkroot-bootclean.sh start 13 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/checkfs.sh ]; then
 update-rc.d checkfs.sh start 30 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/mountall.sh ]; then
 update-rc.d mountall.shstart 35 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/mountall-bootclean.sh ]; then
 update-rc.d mountall-bootclean.sh  start 36 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/mountnfs.sh ]; then
 update-rc.d mountnfs.shstart 45 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/mountnfs-bootclean.sh ]; then
 update-rc.d mountnfs-bootclean.sh  start 46 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/bootmisc.sh ]; then
 update-rc.d bootmisc.shstart 55 S . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/urandom ]; then
 update-rc.d urandomstart 55 S . start 30 0 6 . /dev/null || 
exit $?
+fi
+
 #
 # Links in runlevels other than S
 #
+if [ -x /etc/init.d/halt ]; then
 update-rc.d halt   start 90 0 . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/reboot ]; then
 update-rc.d reboot start 90 6 . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/umountroot ]; then
 update-rc.d umountroot start 60 0 6 . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/umountfs ]; then
 update-rc.d umountfs   start 40 0 6 . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/umountnfs.sh ]; then
 update-rc.d umountnfs.sh   start 31 0 6 . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/sendsigs ]; then
 update-rc.d sendsigs   start 20 0 6 . /dev/null || exit $?
+fi
 
+if [ -x /etc/init.d/killprocs ]; then
 update-rc.d killprocs  start 30 1 . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/single ]; then
 update-rc.d single start 90 1 . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/motd ]; then
 update-rc.d motd   start 70 1 2 3 4 5 . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/rc.local ]; then
 update-rc.d rc.local   start 99 2 3 4 5 . /dev/null || exit $?
+fi
+if [ -x /etc/init.d/rmnologin ]; then
 update-rc.d rmnologin  start 99 2 3 4 5 . /dev/null || exit $?
+fi
 
 #
 # Remove scripts that were left behind by older glibc ( 2.3.2.ds1-12)

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas

Bug#669949: (no subject)

[Roger Leigh]

On Sat, Jun 09, 2012 at 07:34:14PM +0200, Luca wrote:
 Hi Everyone,
  I red the problem began on April. In my case that happened just two days 
 ago, even if I upgrade my sid on regular basis.
 
  I do not have a separate /var or /run partion, just the root one and /home.
 
  Removing symlink /run - /var/run and creating a new /run DIRECTORY (not 
 symlink) works.
 
  I am wondering how many PCs will have this serious problem

Did you create the /run symlink sometime in the past?  Or was it
created automatically?


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#676560: mysql-5.5: Serious system breakage as a result of using /run

[Roger Leigh]

severity 676560 critical
thanks

(It breaks upgrading of the entire system.)

On Thu, Jun 07, 2012 at 07:40:29PM +0100, Roger Leigh wrote:
 You have two options:
 1) Revert to using /var/run
 2) Add a versioned dependency as described in the above reference
 
 This does not include working out how to undo the damage you have
 caused, if this is safe or possible.

You must additionally make sure that you do not provide the
/run directory in your package, or create it.  Both these
actions will break squeeze upgrades.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#676669: initscripts - Fails to install

[Roger Leigh]

tags 676669 + pending
thanks

On Fri, Jun 08, 2012 at 07:18:27PM +0200, Bastian Blank wrote:
 The initscripts package fails to upgrade without error message:
 The functions ram_size and swap_size in /lib/init/tmpfs.sh checks for the
 existance of /proc/meminfo, but fails to handle errors. Adding || : helps.

Thanks, fixed in git.  Out if interest, why was /proc/meminfo not
available?

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#676463: me too and more info

[Roger Leigh]

On Fri, Jun 08, 2012 at 02:16:58PM -0600, Gordon Haverland wrote:
 I have the same packages triggering init script warnings.
 
 In addition, I get a warning from insserv files about K20scsi-idle 
 and scsi-idle missing LSB tags and overrides.

Could you possibly attach a copy of each failing script?


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#676520: [sysv-rc] System unsuitable for dep-based boot cannot configure

[Roger Leigh]

On Thu, Jun 07, 2012 at 05:34:33PM +0300, David Baron wrote:
 I have an older init scripted system which will not configure for dep-based 
 boot due to man missing lsb tags and overrides (what can I do about this?).

From NEWS.Debian:

+sysv-rc (2.88dsf-23) experimental; urgency=low
+
+  Dependency based boot ordering is now required.
+
+  Most systems will already be using dependency based boot ordering.
+  This includes all squeeze and later releases, unless you have taken
+  deliberate action to disable it.  Installations upgraded from etch,
+  lenny or earlier releases will have enabled dependency based booting
+  when upgrading to squeeze and later releases.  However, it was
+  previously possible to opt out of migrating to dependency based
+  booting and retain static boot ordering.  This is no longer the case.
+
+  If your system is still using static boot ordering, migrating to
+  dependency based boot ordering will be performed when sysv-rc is
+  configured.  If this is not possible for any reason, you will have to
+  correct the problem before upgrading can continue.  It will not be
+  possible to complete the upgrade until insserv is configured.
+
+  The most commonly encountered problem preventing migration is the
+  presence of obsolete init scripts from removed (but unpurged)
+  packages.  If this is the case, you will be prompted with
+  instructions detailing how to purge these old packages.
+
+  If you have custom init scripts, please ensure that these have the
+  correct dependency information in an LSB header so that they will be
+  run at the correct point in the boot sequence.
+
+ -- Roger Leigh rle...@debian.org  Wed, 18 Apr 2012 23:30:37 +0100

 Additonally, as per bug #676463, there are numerous complaints about init 
 scripts for removed applications and some that are not removed!

These are, as said above, obsolete init scripts from removed (but
not purged) conffiles.  They lack LSB headers, and the packages
need purging to remove them.

 In the past, sysv-rc would configure for the old boot correctly and upgrades 
 went merrily on their way. Now, it gives an error return.
 
 Sysv-rc is left unconfigured and NO other apt operations are possible!

This is intentional.  Previously, you had the option to either enable
dynamic dependency-based ordering, or stick with static legacy
ordering.  We now require dependency-based ordering, and static is
no longer supported.  So we can't continue until you've fixed the
system by removing the broken scripts.  We haven't really changed the
logic of the scripts here--we've just removed the choice of retaining
the legacy ordering.

For the next upload, I need to see if we can just enable it
unconditionally, irrespective of whether the broken scripts are
present or not.  If you can possibly mail me a copy of all the
broken scripts it identified, I'll test that possibility.  It will
make the transition much smoother.

Note that this only affects upgrades from older releases which lacked
LSB init scripts.  The reason for doing this is because the static
ordering is bitrotting, and is no longer being actively tested since
we are all now using dynamic ordering.  Rather than have systems start
to break as the ordering becomes progressively wrong, this will ensure
all systems will use a single correct ordering.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#676560: mysql-5.5: Serious system breakage as a result of using /run

[Roger Leigh]

Package: mysql-5.5
Version: 5.5.23-2
Severity: serious
Justification: Breaks /run transition

 ql-5.5 (5.5.23-2) unstable; urgency=low
 
  * Changed /var/run to /run as required by Debian Policy 3.9.3 (9.1.1)

No, it's not required by policy.  /var/run continues to exist, and
you should continue to use it.  The new directory is available, but
that does not mean you should use it blindly.

Please **carefully** read
http://wiki.debian.org/ReleaseGoals/RunDirectory

You've broken the /run transition.  You **can not use /run without
a versioned initscripts dependency**.  Without it, /run does not
exist, and you certainly shouldn't be creating it yourself.


You have two options:
1) Revert to using /var/run
2) Add a versioned dependency as described in the above reference

This does not include working out how to undo the damage you have
caused, if this is safe or possible.


Regards,
Roger

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (550, 'unstable'), (500, 'testing'), (400, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#669949: sysvinit: Break X11: no more mouse and keyboard

[Roger Leigh]

On Thu, Jun 07, 2012 at 10:45:44PM +0200, Jakub Moc wrote:
 Definitely caused by /run - /var/run symlink here. After getting rid
 of that and creating /run dir in /, I have my keyboard, mouse and
 sound back. Extremely weird bug, also only got this recently, been
 running unstable for quite a while on LMDE.

Thanks all for investigating.  It looks like we need to cater
for the directory and symlink being the wrong way around, and to
rectify that if possible.  Other than for chroots, where we don't
have a choice, and no means to effectively upgrade to the correct
configuration, this has never been an officially supported
configuration.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#671124: initscripts: Fails to update due to mountoverflowtmp

[Roger Leigh]

severity 671124 important
tags 671124 + moreinfo
thanks

On Tue, May 08, 2012 at 10:49:06PM +0100, Roger Leigh wrote:
 On Wed, May 02, 2012 at 01:15:42AM +0200, Cyril Brulebois wrote:
  Preparing to replace initscripts 2.88dsf-22 (using 
  .../initscripts_2.88dsf-22.1_amd64.deb) ...
  Unpacking replacement initscripts ...
  Processing triggers for man-db ...
  Setting up initscripts (2.88dsf-22.1) ...
  update-rc.d: error: unable to read /etc/init.d/mountoverflowtmp
  dpkg: error processing initscripts (--configure):
   subprocess installed post-installation script returned error exit status 1
 
 This is quite odd, because there were no changes to mountoverflowtmp
 between 2.88dsf-22 and 2.88dsf-22.1.  It was an NMU of debconf
 template translations only, and there were no changes to
 mountoverflowtmp for a long time (years) prior to this.
[...] 
 I've not received any other reports of this problem to date, and
 I can't yet reproduce the problem on my own systems--I never had
 any problem with the 22.1 upgrade, and the -23 and -24 upgrades
 from experimental have never caused any upgrade problems on my
 test systems either.

Hi,

I have not had any other reports of this, and I can't reproduce it
myself.  As I stated above, this file and maintainer scripts
pertaining to it were not changed for several years, so in the
absence of further information or being able to reproduce, I can't
really do much more with this at the present.  I'm downgrading the
severity for the time being--if this is a reproducible bug, it's
already in stable and testing.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org