Debian Bug report logs - #477937
double check for repo type

Package: schroot; Maintainer for schroot is Christoph Biedl <debian.axhn@manchmal.in-ulm.de>; Source for schroot is src:schroot (PTS, buildd, popcon).

Reported by: martin f krafft <madduck@debian.org>

Date: Fri, 25 Apr 2008 20:18:07 UTC

Severity: normal

Tags: fixed-upstream

Found in version schroot/1.1.6-1

Fixed in version schroot/1.5.2-1

Done: Roger Leigh <rleigh@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#477937; Package schroot. (full text, mbox, link).

Message #3 received at submit@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Package: schroot
Version: 1.1.6-1
Severity: normal

I am experimenting with a new backend storage type for schroot: git.

I noticed that setup.d/00check checks the type of the chroot and
errors if the type is unsupported. Thus, I extended the case
statement, but unfortunately found that schroot itself also seems to
check:
  
  $ schroot -vc bpo40-i386-git
  E: /etc/schroot/schroot.conf: Unknown chroot type ‘git’

I'd say the binary shouldn't run this check. If only 00check does
it, then schroot can be freely extended without the need to
recompile.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1+scoflowctrl.1-686 (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages schroot depends on:
ii  libboost-program-options1.34. 1.34.1-11  program options library for C++
ii  libboost-regex1.34.1          1.34.1-11  regular expression library for C++
ii  libc6                         2.7-10     GNU C Library: Shared libraries
ii  libgcc1                       1:4.3.0-3  GCC support library
ii  liblockdev1                   1.0.3-1.2  Run-time shared library for lockin
ii  libpam0g                      0.99.7.1-6 Pluggable Authentication Modules l
ii  libstdc++6                    4.3.0-3    The GNU Standard C++ Library v3
ii  libuuid1                      1.40.8-2   universally unique id library
ii  schroot-common                1.1.6-1    common files for schroot

schroot recommends no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft <madduck@debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

[digital_signature_gpg.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#477937; Package schroot. (full text, mbox, link).

Acknowledgement sent to Roger Leigh <rleigh@whinlatter.ukfsn.org>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (full text, mbox, link).

Message #8 received at 477937@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

martin f krafft <madduck@debian.org> writes:

> I am experimenting with a new backend storage type for schroot: git.
>
> I noticed that setup.d/00check checks the type of the chroot and
> errors if the type is unsupported. Thus, I extended the case
> statement, but unfortunately found that schroot itself also seems to
> check:
>   
>   $ schroot -vc bpo40-i386-git
>   E: /etc/schroot/schroot.conf: Unknown chroot type ‘git’
>
> I'd say the binary shouldn't run this check. If only 00check does
> it, then schroot can be freely extended without the need to
> recompile.

The chroot type is not just something used by the scripts--it's a
class in the source code which defines its properties in the
configuration file as well as some aspects of its behaviour.  To add a
new type you would need to derive a new type e.g. sbuild::chroot_git
and add that into the sbuild::chroot factory function that
instantiates chroot objects.

sbuild::chroot::create (Line 117)
http://git.debian.org/?p=buildd-tools/schroot.git;a=blob;f=sbuild/sbuild-chroot.cc;h=ece51beae88242fb5d4f6af25b9c7fc5d986ef5e;hb=HEAD


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.

[Message part 2 (application/pgp-signature, inline)]

Message #11 received at 477937@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

also sprach Roger Leigh <rleigh@whinlatter.ukfsn.org> [2008.04.26.2248 +0200]:
> The chroot type is not just something used by the scripts--it's a
> class in the source code which defines its properties in the
> configuration file as well as some aspects of its behaviour.  To add a
> new type you would need to derive a new type e.g. sbuild::chroot_git
> and add that into the sbuild::chroot factory function that
> instantiates chroot objects.

Is there actually much that has to happen in the C source?
I understand it's a process:

  1. prepare the base directory of the chroot
  2. chroot into it
  3. run command

1+2 have to be run as root. But is there any reason they shouldn't
just be shell scripts, like 05file?

-- 
 .''`.   martin f. krafft <madduck@debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
the reason that every major university
maintains a department of mathematics
is that it's cheaper than
institutionalizing all those people.

[digital_signature_gpg.asc (application/pgp-signature, inline)]

Message #16 received at 477937@bugs.debian.org (full text, mbox, reply):

On Tue, Apr 29, 2008 at 02:14:45PM +0200, martin f krafft wrote:
> also sprach Roger Leigh <rleigh@whinlatter.ukfsn.org> [2008.04.26.2248 +0200]:
> > The chroot type is not just something used by the scripts--it's a
> > class in the source code which defines its properties in the
> > configuration file as well as some aspects of its behaviour.  To add a
> > new type you would need to derive a new type e.g. sbuild::chroot_git
> > and add that into the sbuild::chroot factory function that
> > instantiates chroot objects.
> 
> Is there actually much that has to happen in the C source?
> I understand it's a process:
> 
>   1. prepare the base directory of the chroot
>   2. chroot into it
>   3. run command
> 
> 1+2 have to be run as root. But is there any reason they shouldn't
> just be shell scripts, like 05file?

2 and 3 need to be run inside the setuid root binary (we need to fork, chroot,
set up the session and environment, drop privs and then execve).  Early steps
(PAM auth) also need to be in the setuid root binary.  The amount of
chroot type-specific stuff is actually quite small; the code is really
just handling parsing of the configuration file and then setting up the
environment.  Pretty much all of the chroot setup is already done in the
shell scripts.

Check out run_impl, setup_chroot, run_chroot and run_child in
sbuild-session.cc for a better idea of what is going on to setup, run
and clean up a session:
http://git.debian.org/?p=buildd-tools/schroot.git;a=blob;f=sbuild/sbuild-session.cc;h=220a4fa972bc4a6fede21afbec2dff486d696175;hb=HEAD

However, one goal I would like to persue is support of virtualisation
with containers like kvm, vservers etc., and also accessing chroots
remotely with SSH (to e.g. build transparently on other architectures).
Some of these approaches would require chroot-specific logic in the
chroot-specific classes which could not go into the shell script.  As an
example, the SSH idea would run as an SSH service like SFTP, so schroot
would run on both the client and server.  (This is at this point only an
idea, however!)

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.

Message #19 received at 477937@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

also sprach Roger Leigh <rleigh@whinlatter.ukfsn.org> [2008.04.29.1452 +0200]:
> just handling parsing of the configuration file and then setting up the
> environment.  Pretty much all of the chroot setup is already done in the
> shell scripts.

In that case, maybe a generic chroot can be used inside C, which
handles all cases not otherwise handled, provided there is a shell
script for it?

-- 
 .''`.   martin f. krafft <madduck@debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
perl -e 'print "The earth is a disk!\n" if ( "a" == "b" );'
                                                   (dedicated to nori)

[digital_signature_gpg.asc (application/pgp-signature, inline)]

Message #24 received at 477937@bugs.debian.org (full text, mbox, reply):

On Tue, Apr 29, 2008 at 03:30:59PM +0200, martin f krafft wrote:
> also sprach Roger Leigh <rleigh@whinlatter.ukfsn.org> [2008.04.29.1452 +0200]:
> > just handling parsing of the configuration file and then setting up the
> > environment.  Pretty much all of the chroot setup is already done in the
> > shell scripts.
> 
> In that case, maybe a generic chroot can be used inside C, which
> handles all cases not otherwise handled, provided there is a shell
> script for it?

This should already be possible, unless I misunderstand what you want.
The "plain" chroot type is the simplest case, and doesn't do any of the
extra stuff the other types do.  You could extend its behaviour in the
setup scripts quite easily, and there is the possibility of doing this
on a per-chroot basis with the script-config parameter, used to
customise the setup scripts.

-- 
  .''`.  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.

Message #27 received at 477937@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

also sprach Roger Leigh <rleigh@whinlatter.ukfsn.org> [2008.04.29.1650 +0200]:
> This should already be possible, unless I misunderstand what you want.
> The "plain" chroot type is the simplest case, and doesn't do any of the
> extra stuff the other types do.  You could extend its behaviour in the
> setup scripts quite easily, and there is the possibility of doing this
> on a per-chroot basis with the script-config parameter, used to
> customise the setup scripts.

I am failing to see how I would have a Git repository type this way,
without resorting to a hack as I currently do...

-- 
 .''`.   martin f. krafft <madduck@debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"although occasionally there is something to be said for solitude."
                                          -- special agent dale cooper

[digital_signature_gpg.asc (application/pgp-signature, inline)]

Message #32 received at 477937@bugs.debian.org (full text, mbox, reply):

On Tue, Apr 29, 2008 at 04:58:47PM +0200, martin f krafft wrote:
> also sprach Roger Leigh <rleigh@whinlatter.ukfsn.org> [2008.04.29.1650 +0200]:
> > This should already be possible, unless I misunderstand what you want.
> > The "plain" chroot type is the simplest case, and doesn't do any of the
> > extra stuff the other types do.  You could extend its behaviour in the
> > setup scripts quite easily, and there is the possibility of doing this
> > on a per-chroot basis with the script-config parameter, used to
> > customise the setup scripts.
> 
> I am failing to see how I would have a Git repository type this way,
> without resorting to a hack as I currently do...

This is what I would suggest:

Copy /etc/schroot/script-defaults to /etc/schroot/foo-defaults and add
any additional customisation parameters you want in your setup scripts.
[You can also edit the script-defaults directly, and special case things
based on e.g. CHROOT_TYPE and CHROOT_NAME]  (the full list of variables
is in schroot-setup(5)).

In schroot.conf, set

[foo]
type=plain
script-config=foo-defaults

Create a new setup script e.g. 05git which sources the defaults as all
the other scripts do.  You can then do all your stuff here.  Because all
setup tasks run all scripts, you'll need to do something like

if [ "$USE_GIT" = true ]; then
   ...
fi

(and add USE_GIT=true to your foo-defaults file).

This is still a little hacky.  This is where writing the chroot_git
class would make things a little nicer--it would allow customisation
directly in schroot.conf with extra keys, and set them up in the
environment for the setup scripts to use.  However, I added
script-config to allow users to extend the setup scripts on a per-chroot
basis as they saw fit, without needing to hack the C++ sources.  See
schroot-script-config(5).

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.

Message #35 received at 477937@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

also sprach Roger Leigh <rleigh@whinlatter.ukfsn.org> [2008.04.29.1922 +0400]:
> This is still a little hacky.

Less so than my approach¸ anyway.

> This is where writing the chroot_git class would make things
> a little nicer--it would allow customisation directly in
> schroot.conf with extra keys, and set them up in the environment
> for the setup scripts to use.

All I am saying is that why make this specific to git? Why can't
file and git and whatever else might be created not be handled by
chroot_custom, which is instantiated when no better chroot type
handler exists. It sets $CHROOT_TYPE according to what type=
parameter says and populates the environment with any additional
parameters in schroot.conf. Now it's up to 05file, 05git, 05whatever
to set up the chroot. If I wanted to add 05hg or 05bzr, I could,
without any hacks or C++ hackery.

-- 
 .''`.   martin f. krafft <madduck@debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"nothing can cure the soul but the senses,
 just as nothing can cure the senses but the soul."
                                                        -- oscar wilde

[digital_signature_gpg.asc (application/pgp-signature, inline)]

Message #40 received at 477937@bugs.debian.org (full text, mbox, reply):

On Wed, Apr 30, 2008 at 11:57:49AM +0400, martin f krafft wrote:
> also sprach Roger Leigh <rleigh@whinlatter.ukfsn.org> [2008.04.29.1922 +0400]:
> > This is still a little hacky.
> 
> Less so than my approach¸ anyway.
> 
> > This is where writing the chroot_git class would make things
> > a little nicer--it would allow customisation directly in
> > schroot.conf with extra keys, and set them up in the environment
> > for the setup scripts to use.
> 
> All I am saying is that why make this specific to git? Why can't
> file and git and whatever else might be created not be handled by
> chroot_custom, which is instantiated when no better chroot type
> handler exists. It sets $CHROOT_TYPE according to what type=
> parameter says and populates the environment with any additional
> parameters in schroot.conf. Now it's up to 05file, 05git, 05whatever
> to set up the chroot. If I wanted to add 05hg or 05bzr, I could,
> without any hacks or C++ hackery.

Ah, I see where you are coming from.  This would be quite possible to
do.  The configuration would be somewhat harder to validate than what is
currently allowed (we would probably just s/[a-z]/[A-Z]/ and s/-/_/ to
upcase and convert - to _.  The names would have to be valid shell
variables.

I'll certainly look at adding this--it shouldn't be too much work.


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.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Tue, 08 May 2012 23:15:03 GMT) (full text, mbox, link).

Message #45 received at 477937@bugs.debian.org (full text, mbox, reply):

On Wed, Apr 30, 2008 at 02:54:33PM +0100, Roger Leigh wrote:
> On Wed, Apr 30, 2008 at 11:57:49AM +0400, martin f krafft wrote:
> > also sprach Roger Leigh <rleigh@whinlatter.ukfsn.org> [2008.04.29.1922 +0400]:
> > > This is still a little hacky.
> > 
> > Less so than my approach¸ anyway.
> > 
> > > This is where writing the chroot_git class would make things
> > > a little nicer--it would allow customisation directly in
> > > schroot.conf with extra keys, and set them up in the environment
> > > for the setup scripts to use.
> > 
> > All I am saying is that why make this specific to git? Why can't
> > file and git and whatever else might be created not be handled by
> > chroot_custom, which is instantiated when no better chroot type
> > handler exists. It sets $CHROOT_TYPE according to what type=
> > parameter says and populates the environment with any additional
> > parameters in schroot.conf. Now it's up to 05file, 05git, 05whatever
> > to set up the chroot. If I wanted to add 05hg or 05bzr, I could,
> > without any hacks or C++ hackery.
> 
> Ah, I see where you are coming from.  This would be quite possible to
> do.  The configuration would be somewhat harder to validate than what is
> currently allowed (we would probably just s/[a-z]/[A-Z]/ and s/-/_/ to
> upcase and convert - to _.  The names would have to be valid shell
> variables.
> 
> I'll certainly look at adding this--it shouldn't be too much work.

Just FYI, we're now half way there.  I've recently added support for
custom properties to chroots, which is to say you can do
  foo.bar=baz
in the chroot definition, which will result in
  FOO_BAR=baz
in the setup script environment.

This of course means it's possible to set arbitrary values (with
some restrictions) in the setup scripts.

The next part is to create the chroot_custom class as above.  This
is easy: it will do nothing at all by default, so the user is free
to write their own setup scripts to do what they please.  You
would probably want to set
  custom.type=mytype
to permit the possibility of multiple custom types, then in the
setup script you can do the equivalent of

  if [ "$CHROOT_TYPE" = custom ] && [ "$CUSTOM_TYPE" = mytype ]; then
    my_setup_here
  fi

So this part shouldn't take too long to implement.  We could always
allow any unknown name to be automatically used by the custom class,
which would mean you can use any type=value value, but this might
break as we introduce new types, so the above is probably safer and
more likely to remain backward compatible.

The user defined settings also means it's possible to expose a
greater number of tweakable knobs which can be used by the setup
scripts to customise their behaviour, and without the need for
any C++ code.

Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://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

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Wed, 09 May 2012 23:57:06 GMT) (full text, mbox, link).

Message #50 received at 477937@bugs.debian.org (full text, mbox, reply):

tags 477937 + pending fixed-upstream
thanks

On Wed, May 09, 2012 at 12:13:02AM +0100, Roger Leigh wrote:
> On Wed, Apr 30, 2008 at 02:54:33PM +0100, Roger Leigh wrote:
> > On Wed, Apr 30, 2008 at 11:57:49AM +0400, martin f krafft wrote:
> > > also sprach Roger Leigh <rleigh@whinlatter.ukfsn.org> [2008.04.29.1922 +0400]:
> > > > This is still a little hacky.
> > > 
> > > Less so than my approach¸ anyway.
> > > 
> > > > This is where writing the chroot_git class would make things
> > > > a little nicer--it would allow customisation directly in
> > > > schroot.conf with extra keys, and set them up in the environment
> > > > for the setup scripts to use.
> > > 
> > > All I am saying is that why make this specific to git? Why can't
> > > file and git and whatever else might be created not be handled by
> > > chroot_custom, which is instantiated when no better chroot type
> > > handler exists. It sets $CHROOT_TYPE according to what type=
> > > parameter says and populates the environment with any additional
> > > parameters in schroot.conf. Now it's up to 05file, 05git, 05whatever
> > > to set up the chroot. If I wanted to add 05hg or 05bzr, I could,
> > > without any hacks or C++ hackery.
> > 
> > Ah, I see where you are coming from.  This would be quite possible to
> > do.  The configuration would be somewhat harder to validate than what is
> > currently allowed (we would probably just s/[a-z]/[A-Z]/ and s/-/_/ to
> > upcase and convert - to _.  The names would have to be valid shell
> > variables.
> > 
> > I'll certainly look at adding this--it shouldn't be too much work.
> 
> The next part is to create the chroot_custom class as above.

Completed and on git master.  This will be in the 1.5.2 upload to
experimental later this week, following some testing of the
release as a whole (the custom type is now fully functional).

It's taken four years to get to this point (PhDs do get in the way
of hacking!) but hopefully you'll find it useful, and I'm sure it
will be useful for others.  If you're still interested in a git
chroot type, this will be one way of experimenting with it
without the need to write any C++ code while prototyping the
concept.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://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

Added tag(s) fixed-upstream and pending. Request was from Roger Leigh <rleigh@codelibre.net> to control@bugs.debian.org. (Wed, 09 May 2012 23:57:07 GMT) (full text, mbox, link).

Reply sent to Roger Leigh <rleigh@debian.org>:
You have taken responsibility. (Tue, 15 May 2012 22:39:08 GMT) (full text, mbox, link).

Notification sent to martin f krafft <madduck@debian.org>:
Bug acknowledged by developer. (Tue, 15 May 2012 22:39:08 GMT) (full text, mbox, link).

Message #57 received at 477937-close@bugs.debian.org (full text, mbox, reply):

Source: schroot
Source-Version: 1.5.2-1

We believe that the bug you reported is fixed in the latest version of
schroot, which is due to be installed in the Debian FTP archive:

dchroot-dsa_1.5.2-1_amd64.deb
  to main/s/schroot/dchroot-dsa_1.5.2-1_amd64.deb
dchroot_1.5.2-1_amd64.deb
  to main/s/schroot/dchroot_1.5.2-1_amd64.deb
libsbuild-dev_1.5.2-1_amd64.deb
  to main/s/schroot/libsbuild-dev_1.5.2-1_amd64.deb
libsbuild-doc_1.5.2-1_all.deb
  to main/s/schroot/libsbuild-doc_1.5.2-1_all.deb
schroot-common_1.5.2-1_all.deb
  to main/s/schroot/schroot-common_1.5.2-1_all.deb
schroot-dbg_1.5.2-1_amd64.deb
  to main/s/schroot/schroot-dbg_1.5.2-1_amd64.deb
schroot_1.5.2-1.debian.tar.gz
  to main/s/schroot/schroot_1.5.2-1.debian.tar.gz
schroot_1.5.2-1.dsc
  to main/s/schroot/schroot_1.5.2-1.dsc
schroot_1.5.2-1_amd64.deb
  to main/s/schroot/schroot_1.5.2-1_amd64.deb
schroot_1.5.2.orig.tar.xz
  to main/s/schroot/schroot_1.5.2.orig.tar.xz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 477937@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Roger Leigh <rleigh@debian.org> (supplier of updated schroot package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 14 May 2012 23:29:22 +0100
Source: schroot
Binary: schroot-common libsbuild-dev schroot-dbg libsbuild-doc schroot dchroot dchroot-dsa
Architecture: source all amd64
Version: 1.5.2-1
Distribution: experimental
Urgency: low
Maintainer: Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>
Changed-By: Roger Leigh <rleigh@debian.org>
Description: 
 dchroot    - Execute commands in a chroot environment
 dchroot-dsa - Execute commands in a chroot environment
 libsbuild-dev - development files for the Debian source builder
 libsbuild-doc - development documentation for the Debian source builder
 schroot    - Execute commands in a chroot environment
 schroot-common - common files for schroot
 schroot-dbg - schroot, dchroot and dchroot-dsa debugging symbols
Closes: 477937 588962 625202 625205 648450 653732 658544 659524 659967 660040 661514 666274 666497 670881 672113
Changes: 
 schroot (1.5.2-1) experimental; urgency=low
 .
   * New upstream development release.
   * Build with current Boost libraries (1.49).
   * debian/control:
     - Fix typo (debuggging, Closes: #653732).  Thanks to Vincent Blut.
     - Build-Depend on debhelper 9, and po4a 0.40.
     - Upgrade to Standards-Version 3.9.3.
   * schroot preinst: Remove default (script-config) conffiles on
     upgrade.  These are deprecated and support will be dropped in
     the future.
   * /etc/default/schroot supports ending sessions on stop
     (Closes: #625202).  The existing SESSIONS_RECOVER option has been
     renamed to START_ACTION, and an additional STOP_ACTION option has
     been added.  Both of these may be set to "end" to cause all
     sessions to be ended when run with a "start" or "stop" argument,
     respectively.
   * Support translation of the documentation with po4a
     (Closes: #588962).  A French translation of the manual pages has
     been added, and translated manual pages are built, but is not yet
     installed.  Thanks to David PrÃ©vot.
   * Support for overlayfs has been added in addition to aufs and
     unionfs (Closes: #648450).  Thanks to Evan Broder.
   * Arbitrary options may now be set in a chroot definition in
     schroot.conf.  These options are also set in the environment when
     running setup scripts, making this a simple means by which setup
     scripts may be customised without writing code.  As part of this
     change, the error message for invalid keys has been reworded to
     make it more helpful (Closes: #666274).
   * The gshadow database is now copied into the chroot using the
     nssdatabases setup script, rather than copyfiles.
   * Services may be started and stopped inside the chroot on session
     creation and session ending (Closes: #625205).  These are specified
     using the new setup.services key, and are started and stopped using
     invoke-rc.d.  See schroot.conf(5) for further details.
   * 15killprocs kills processes under CHROOT_PATH rather than
     CHROOT_MOUNT_LOCATION (Closes: #672113).  Thanks to Julien Viard de
     Galbert.
   * The above options may be set (where permitted) on the schroot
     command-line by using the new --option command-line option to set
     the option to a user-defined value, which will permit users to
     customise the behaviour of setup scripts.  Note that only keys
     specified in the new user-modifiable-keys or root-modifiable-keys
     settings are permitted to be set, for security reasons.
   * A new "custom" chroot type has been added (Closes: #477937).  This
     permits the testing and development of new specialised chroot
     types without the need to write any C++ chroot modules.  It just
     requires a custom setup script, which can use arbitrary options
     set in your schroot.conf for configuration.  Options are provided
     to set up the session cloning and purging behaviour for the custom
     chroot.  See schroot.conf(5) for further details.
   * Exceptions thrown for command-line options validation errors no
     longer use the Boost validation_error exception, which formatted
     the exception reason text badly (Closes: #666497).
   * schroot(1): Update overview text, including explaining the
     restriction of the plain chroot type not running setup scripts
     (Closes: #670881).
   * PATH is now set when running setup scripts.
   * Updated translations:
     - da (Closes: #658544).  Thanks to Joe Hansen.
     - de (Closes: #659524).  Thanks to Holger Wansing.
     - fr (Closes: #661514).  Thanks to Thomas Blein.
     - pt (Closes: #660040).  Thanks to Pedro Ribeiro.
     - zh_CN (Closes: #659967).  Thanks to Ji ZhengYu.
Checksums-Sha1: 
 46d95ae57ef81ae04d2bb942011a034791913c4e 2424 schroot_1.5.2-1.dsc
 40377167864c508901882951a1c18ad65cbf744a 718344 schroot_1.5.2.orig.tar.xz
 9eaf97eac6c0635ea18a37224b3e86255107b5c5 26764 schroot_1.5.2-1.debian.tar.gz
 ea69f4484ca60bf980e71fc4fb4fc5c59f9610a6 252632 schroot-common_1.5.2-1_all.deb
 b39961b61ce9d66f7263f622c882ed448b5e4dcc 2289162 libsbuild-dev_1.5.2-1_amd64.deb
 b507d22255106284de74fcf04fd5eefc083180de 29677682 schroot-dbg_1.5.2-1_amd64.deb
 0bbfcaa044a879c89a0f2a59e9914380c30b8eb6 7763476 libsbuild-doc_1.5.2-1_all.deb
 4f055759337a3fd59358c1c03bfb50bcbaba028d 953368 schroot_1.5.2-1_amd64.deb
 1ad84ef5033632d2ac6d3b6719bd6531811390db 370280 dchroot_1.5.2-1_amd64.deb
 ebaace85d3790af293b5bad0f216099a02650a14 369528 dchroot-dsa_1.5.2-1_amd64.deb
Checksums-Sha256: 
 985e7a881b2a3e8b6060418c7b1a5601180986d1a7a0cab4dc2ac325622d8672 2424 schroot_1.5.2-1.dsc
 14ea4c1fcd13fbccc4ac287d33e70ef26a804d85b803b60ee9d75a8f2c8eb9fc 718344 schroot_1.5.2.orig.tar.xz
 70bc839e0671412f741d3cbf6a7553102464b0267e00bc744a4fcce24ce7f054 26764 schroot_1.5.2-1.debian.tar.gz
 6d8610683e68a1df86c3b34cc563c832c8bae2c8cbaee3ab94c9032e61bc723f 252632 schroot-common_1.5.2-1_all.deb
 ab4a95e673ee7a40b690d41cf78af152c2512a828fa5792acbb69b60876da779 2289162 libsbuild-dev_1.5.2-1_amd64.deb
 5f9336e5b57b068be3c9402710dc4214dca940a547b0a860e66e38c43afa6a3a 29677682 schroot-dbg_1.5.2-1_amd64.deb
 c01b9db96f89bf82ad216f24fad5bb006fa5069ad9bc983d6d14c35ae41125b8 7763476 libsbuild-doc_1.5.2-1_all.deb
 06f8da78707c2296ee7c6e6df901f514155261d4747de74007faa8a5e351f9e5 953368 schroot_1.5.2-1_amd64.deb
 cadf5c34c73eb39f834decc5f810bb7b4f82a929ffb9ca656a10019e46b291ca 370280 dchroot_1.5.2-1_amd64.deb
 65edb882f2439af91bed0f558c8680ecc0160d1dacf0e3903c2b35a09f255897 369528 dchroot-dsa_1.5.2-1_amd64.deb
Files: 
 b6a925b56f5088359e2656a98cae4d0c 2424 admin optional schroot_1.5.2-1.dsc
 7504d34970697b951896a4e36bb07bd3 718344 admin optional schroot_1.5.2.orig.tar.xz
 92721f1e16d859c2373217a444d64f5d 26764 admin optional schroot_1.5.2-1.debian.tar.gz
 4b568fe66dec35daca987dbaf8396e2a 252632 admin optional schroot-common_1.5.2-1_all.deb
 1655225f16ac6632e0d04827b06c2173 2289162 libdevel optional libsbuild-dev_1.5.2-1_amd64.deb
 48188da135046620adea7a2b6e88caee 29677682 debug extra schroot-dbg_1.5.2-1_amd64.deb
 ff44d0b8eacc08ad16ec99b1f2e10f83 7763476 doc optional libsbuild-doc_1.5.2-1_all.deb
 980c18a88ff2a6d2d0cbb29b2fea87f7 953368 admin optional schroot_1.5.2-1_amd64.deb
 5d615c646ece726b00c420e72b9b1be4 370280 admin optional dchroot_1.5.2-1_amd64.deb
 1fc394e3a7065f9661eefde1f0db6178 369528 admin optional dchroot-dsa_1.5.2-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJPstEUAAoJEOJSSsUKn1xZwBIQALGJpz3JiKJK2xe2zAO9d5OT
PFdr3OzbjmFFVGnZHHde/0KohZ9OdAlMDUNr5CiDT73CcMkUOwSJJkSIhFsAUi5M
1awCYcsejTAUxSyKXimqDPdvI+e2jkWZ5xwaQX5fmCJ8fwN6pFyNizE83TepdiOU
jV0o6kJKKbXYtQCRGufxQPuxQAMWn8r4zdGLnLX8sucvznnFQoH33OhhJwhdaDj5
u3tJATFGvpcgoJ4G6OXHpeEc6t/S14Pm8XybFV03uFjQy/8WVSPLG5zYjvTnm2qx
5TZpUyIo9BMCzJgil1ZSa2Kw86nt/wwwmTa+ARDPokZIkHhh9hld9ma8P5EKkyqh
aNfPejbHm4xZ8s0zEWKjwK+Y+A5Dqdhf7oM7nMjewfgdrGSpPiVXuAbF2xImjt/T
iOzqoz+qRQ/PHLmPLfEZd1o3R84hN1kwPP9m0v8alUs8lAZahXHgpYIK0zrMMj2C
QjCcRLY3tU5Qbmh+XH5znSrdaRrnzOLggnT0Zl3/OXuZ0BYW/yEELvkb3fwC9dqO
6DrJu0kbcmU7QJudAQZs/nFXPrPGOmZLRHlo/nOl72k9Pvy/wvHVm4nQU2W3+YlE
BCiuc6M6u6CGChlmlIh9DSWCBLhyQsxnUxZ122ozROxgIEJiTzd1FbWKaFMwHDS5
ef8AeAx73TI91bVK4rpG
=r2bS
-----END PGP SIGNATURE-----

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 28 Jun 2012 07:42:07 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Tue Jan 30 06:51:53 2024; Machine Name: bembo

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Debian Bug report logs - #477937 double check for repo type

Debian Bug report logs - #477937
double check for repo type