Bug#992430: schroot: user password does not match

[Roger Leigh]

Hi,

I'm not personally familiar with the changes in the latest Debian release, but 
please check that all the password, shadow password files etc. are all copied 
into the chroot and are self-consistent with one another.  Are the host files 
using a hash type not supported by the chroot environment?

Regards,
Roger

On 18/08/2021, 14:54, "Sergey Vlasov"  wrote:

Package: schroot
Version: 1.6.10-12
Severity: important
X-Debbugs-Cc: ser...@vlasov.me

Dear Maintainer,

When doing schroot into a buster chroot environment, sudo
commands fail due to password not matching the current user password.
There is no such problem for bullseye chroot environment.

Bug#983087: sbuild-createchroot misses usr/libexec/qemu-binfmt/ directory

[Roger Leigh]

On 25 Feb 2021, at 12:00, Christoph Biedl  
wrote:
> 
> Roger Leigh wrote...
> 
>> I was having a think about this last night.  To be completely
>> realistic, schroot maintenance is very low on my list of my
>> priorities.  Work on it is sporadic at best.  My interest in it is
>> also fairly low.  I’ve moved on to other things.
> 
> That's sad to hear.

Well, yes and no.  Yes, in that I was quite proud of the impact and utility 
this small tool had, and didn’t want to let it go.  But no, in that everything 
has its time, and schroot was obsoleted quite a few years ago now.  It’s time 
to move on.

schroot was designed as a single-purpose tool.  It’s original name was 
“sbuild-chroot-helper” (-> “schroot”).  Its purpose was virtualising build 
environments solely for sbuild’s benefit, and it did that fairly well.  The 
only reason it was separated was because Perl scripts can’t be setuid root.  
But the simple fact here is this: Docker exists.  It’s better, it’s more 
flexible, and it’s backed by funding and resources I don’t have.  I did 
consider making schroot a daemon with a socket interface and doing a number of 
other changes to bring it up to a level with what Docker offers.  But, again to 
be quite realistic, I don’t have the time, the resources or the desire to 
expend that effort when there’s a much simpler option: switch to Docker.  
systemd has also broken some of the core assumptions we rely on through use of 
basic standard POSIX interfaces.  That also requires time and effort I don’t 
have to work around.  schroot will continue to be less usable on a 
systemd-based system.

The other uses for schroot were implemented as niceties after the fact.  They 
were never part of the core requirements.  Some were heavily used at various 
points, for example running 32-bit code on 64-bit systems, but now we’re all 
migrated to 64-bit systems that’s much less common.

Don’t get me wrong.  I don’t actually like Docker particularly.  But it’s here, 
it does the job, and schroot can’t match its functionality.  schroot users 
should migrate to Docker where possible.

>> I don’t think that something which is not maintained or well supported
>> should be used as a critical part of the Debian build infrastructure,
>> and honestly, | think you should take steps to remove it entirely.  It
>> was a nice tool, it served its purpose, but it is dated and limited,
>> and has been completely eclipsed by Docker.  If you can switch over to
>> using Docker, I think you should make an active effort to do so.
> 
> And those who cannot or don't want to because of the consequences?

When I integrated schroot support into sbuild I created an abstraction to leave 
the original (privileged) chroot support in place.  Adding a third 
implementation of this interface to enable docker support would be relatively 
simple.  Just a few dozen lines of Perl to tell it how to create, run commands 
in, and tear down a container.

> The highly convenient feature of schroot are simplicity, maturity and
> therefore reliability in its usage. So it's a tool that "just works",
> something people value once they've grown into a greybeard and/or want
> to be sure the workflow around a tool doesn't break every now and then.
> I can live with some shortcomings otherwise, or might even try to work
> on them.

I sent this email as a courtesy simply to explain what the situation is, 
similarly to when I left the Debian project six years ago.  You are of course 
welcome to continue to use the tool.  But when it comes to being a part of 
Debian, that’s a different matter, and I am encouraging you all to think about 
and expedite its removal.  Having unmaintained and abandoned tools hang around 
past their sell-by date will cause problems, and schroot hasn’t been maintained 
actively for at least that long.  It would be for the best if you removed it.

I do not have any written or unwritten obligations to anyone when it comes to 
free software maintenance.  My time is limited, and maintaining a niche tool is 
very costly, particularly when I derive zero benefit from it myself, and it has 
been obsoleted by other tools.  It’s time to retire it completely.

> Also, there are more usecases than just package building: I use schroot
> to manage interactive chroots where I can check the behaviour of other
> distributions and (to some extent) other architectures.

You can do most of that in Docker as well.

The only thing which is unique is the support for non-native architectures with 
qemu-user.  But that was just discovered as a side-effect of the command-prefix 
feature.  It worked, but it was never a requirement or designed-in feature.  
You can always use qemu-user via binfmt-misc.  I don’t think this one 
super-niche aspect of the tool is a reason to keep it.  There are alternatives.

>> Now that yo

Bug#983087: sbuild-createchroot misses usr/libexec/qemu-binfmt/ directory

[Roger Leigh]

On 23 Feb 2021, at 22:51, Johannes Schauer Marin Rodrigues  
wrote:
> 
> Hi Roger,
> 
> Quoting Roger Leigh (2021-02-23 22:41:32)
>> On 22 Feb 2021, at 12:00, Johannes Schauer Marin Rodrigues 
>>  wrote:
>>> 
>>>>> Michael, your change in qemu introduced this problem. Schroot is currently
>>>>> orphaned. Since you are responsible for this change in qemu, could you 
>>>>> make an
>>>>> NMU of schroot with above fix? Thanks!
>>>> 
>>>> Oww.. orphan.. that's pity.
>>> 
>>> Indeed. On the plus side, it means we can just NMU things without waiting 
>>> for
>>> maintainer action. ;)
>> 
>> You can always open a MR against the upstream GitLab repo (branch
>> schroot-1.6) for any modifications you make to the code (not the Debian
>> packaging).  https://gitlab.com/codelibre/schroot
>> <https://gitlab.com/codelibre/schroot <https://gitlab.com/codelibre/schroot>>
> 
> cool to hear from you again! And nice to see that there are new commits in the
> upstream git repo. :)
> 
> Also feel free to ping me once there is a new schroot upstream version that
> needs packaging.

I was having a think about this last night.  To be completely realistic, 
schroot maintenance is very low on my list of my priorities.  Work on it is 
sporadic at best.  My interest in it is also fairly low.  I’ve moved on to 
other things.

I don’t think that something which is not maintained or well supported should 
be used as a critical part of the Debian build infrastructure, and honestly, | 
think you should take steps to remove it entirely.  It was a nice tool, it 
served its purpose, but it is dated and limited, and has been completely 
eclipsed by Docker.  If you can switch over to using Docker, I think you should 
make an active effort to do so.

I would also make the same case for sbuild and buildd.  They are also 
thoroughly obsolete and could be removed.

Now that you have GitLab on salsa, how much work would it be to:

* create a “package-build” group owned by the current buildd admins.
* hook up all the current build slaves as “runners” owned by that group.  
* create a “build-image” project which will use GitLab CI to build a minimal 
docker image for each architecture as separate jobs (can be stored in the 
gitlab docker registry).  Have it regenerate the image weekly.  Have branches 
for stable/testing/unstable.
* create a “build” project which will do the package build.  Use GitLab CI, 
with the container images from the previous job, install build-deps, do the 
build and upload.

The latter can be parameterised and triggered for a given suite/package/version 
with a webhook.

That would be several orders of magnitude simpler and more maintainable than 
sbuild and buildd.  Just a handful of lines in a .gitlab-ci.yml and supporting 
shell script.  If you can do that, I think that would be a much better strategy 
for the future.  The existing tools are over 25 years old and long past due for 
complete replacement.  schroot was an means to extend their life back in 2005.  
The current GitLab CI capabilities make most of their functionality redundant, 
and it would make sense to take advantage of that where possible.  It will 
handle job scheduling, build log storage and browsing, everything that buildd 
currently does.  No need for a separate database to track the archive state.  
Simply have the archive call a webhook when a new source package is uploaded 
and trigger a full build.  It would also remove polling from the equation and 
have every action be an immediately schedulable push action.  GitLab CI can 
make full use of all the connected runners, including parallelisation.

Please feel free to forward to anyone else who might be relevant like 
buildd-tools or archive people.


Kind regards,
Roger

Bug#983087: sbuild-createchroot misses usr/libexec/qemu-binfmt/ directory

[Roger Leigh]

On 22 Feb 2021, at 12:00, Johannes Schauer Marin Rodrigues  
wrote:
> 
>>> Michael, your change in qemu introduced this problem. Schroot is currently
>>> orphaned. Since you are responsible for this change in qemu, could you make 
>>> an
>>> NMU of schroot with above fix? Thanks!
>> 
>> Oww.. orphan.. that's pity.
> 
> Indeed. On the plus side, it means we can just NMU things without waiting for
> maintainer action. ;)

You can always open a MR against the upstream GitLab repo (branch schroot-1.6) 
for any modifications you make to the code (not the Debian packaging).  
https://gitlab.com/codelibre/schroot  

Regards,
Roger

Bug#981219: schroot overwrites cpuset

[Roger Leigh]

On 27 Jan 2021, at 20:39, David Bremner  wrote:
> 
> Package: schroot
> Version: 1.6.10-11+b1
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> As you can see with session below, schroot throws away the processor
> affinities present in the parent process.  This breaks a common
> strategy (used e.g. by slurm) for sharing multi-processor machines.

We don’t actively do anything within schroot to change this, so it must be a 
side-effect of some action it takes during session setup.

The main actions under our control are basic fork/chroot/setuid/setgid/exec and 
I doubt these are responsible.

The PAM auth and session handling is I think the most likely culprit, and this 
is not under our direct control.  Is there a particular PAM module which can 
change these cpusets?  If so, can you edit the schroot PAM configuration and 
see if it can be disabled this way?  Possibly in @common-session?


Thanks,
Roger

Bug#921282: sbuild: emits many messages “Alias ‘[...]’ already associated with ‘[...]’ chroot”

[Roger Leigh]

On 2 Dec 2020, at 08:46, Anthony Fok  wrote:
> 
> And, sure enough, we can find in /usr/bin/sbuild-debian-developer-setup:
> 
>
> https://sources.debian.org/src/sbuild/0.80.0/bin/sbuild-debian-developer-setup/#L56-L57
> 
> when it calls sbuild-createchroot, it indiscriminately adds the flags
> 
>--alias=UNRELEASED
>--alias=sid
> 
> which are appropriate for unstable only.
> 
> So, perhaps this bug should be re-assigned to the
> sbuild-debian-developer-setup binary package?  :-)

Yes, I think so.  This is not a schroot bug: the warnings are simply due to it 
being misconfigured, not due to a problem in schroot itself.

Kind regards,
Roger

Bug#975603: New upstream release 1.12.0

[Roger Leigh]

close 975603
thanks

It can be closed; I filed it incorrectly and opened one against the correct 
package.

> On 24 Nov 2020, at 08:52, Andrei POPESCU  wrote:
> 
> Control: reassign -1 src:xalan 1.11-9
> Control: severity -1 wishlist
> 
> On Lu, 23 nov 20, 22:50:31, Roger Leigh wrote:
>> Package: xalan-c
>> Version: 1.11-9
>> 
>> Hi Bill,
>> 
>> This was mentioned on the upstream mailing list earlier in the year.  Just 
>> opening a bug to track this.
>> 
>> New upstream release 1.12 was made a few months back 
>> (https://github.com/apache/xalan-c/releases/tag/Xalan-C_1_12_0).  This could 
>> be packaged to replace the decade-old 1.11 release.  Note that the new 
>> release brings with it a new CMake-based build system to match Xerces-C.  
>> All the configuration options of the old build system are exposed via CMake 
>> options.  It's all documented in the manual: 
>> https://apache.github.io/xalan-c/build.html
>> 
>> Kind regards,
>> Roger
> 
> Reassigning to correct package, though as far as I can tell 1.12 is 
> already in experimental.
> 
> Kind regards,
> Andrei
> -- 
> Looking after bugs assigned to unknown or inexistent packages

Bug#975603: New upstream release 1.12.0

[Roger Leigh]

Package: xalan-c
Version: 1.11-9

Hi Bill,

This was mentioned on the upstream mailing list earlier in the year.  Just 
opening a bug to track this.

New upstream release 1.12 was made a few months back 
(https://github.com/apache/xalan-c/releases/tag/Xalan-C_1_12_0).  This could be 
packaged to replace the decade-old 1.11 release.  Note that the new release 
brings with it a new CMake-based build system to match Xerces-C.  All the 
configuration options of the old build system are exposed via CMake options.  
It's all documented in the manual: https://apache.github.io/xalan-c/build.html

Kind regards,
Roger

Bug#975600: New upstream release 1.12.0

[Roger Leigh]

Package: xalan
Version: 1.11-9

Hi Bill,

This was mentioned on the upstream mailing list earlier in the year.  Just 
opening a bug to track this.

New upstream release 1.12 was made a few months back 
(https://github.com/apache/xalan-c/releases/tag/Xalan-C_1_12_0).  This could be 
packaged to replace the decade-old 1.11 release.  Note that the new release 
brings with it a new CMake-based build system to match Xerces-C.  All the 
configuration options of the old build system are exposed via CMake options.  
It's all documented in the manual: https://apache.github.io/xalan-c/build.html

Kind regards,
Roger

Bug#967045: libtinyxml2-dev: Missing cmake configuration files

[Roger Leigh]

Package: libtinyxml2-dev
Version: 8.0.0+dfsg-2
Severity: normal


i
├── include
│   └── tinyxml2.h
└── lib
    ├── cmake
    │   └── tinyxml2
    │   ├── tinyxml2Config.cmake
    │   ├── tinyxml2Targets.cmake
    │   └── tinyxml2Targets-noconfig.cmake
    ├── libtinyxml2.so -> libtinyxml2.so.6
    ├── libtinyxml2.so.6 -> libtinyxml2.so.6.2.0
    ├── libtinyxml2.so.6.2.0
    └── pkgconfig
    └── tinyxml2.pc

The dev package is not including lib/cmake/tinyxml2 with its three
configuration files.  This is needed to be able to import the
tinyxml2 configuration with cmake find_package.

Please could these files be added?

Thanks,
Roger


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF8, LC_CTYPE=en_GB.UTF8 (charmap=UTF-8), 
LANGUAGE=en_GB:en

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libtinyxml2-dev depends on:
ii  libtinyxml2-8  8.0.0+dfsg-2

libtinyxml2-dev recommends no packages.

libtinyxml2-dev suggests no packages.

-- no debconf information

Bug#947919: schroot: Support for ZFS snapshotting

[Roger Leigh]

On 05/01/2020 19:54, Steve Langasek wrote:


On Sun, Jan 05, 2020 at 09:16:34AM +, Roger Leigh wrote:

sbuild::chroot::ptr
chroot_zfs_snapshot::clone_source () const
{
   ptr clone(new chroot_zfs_snapshot(*this));

...

should be

chroot_zfs_snapshot::clone_source () const
{
   ptr clone(new chroot_directory(*this));

   chroot_facet_source_clonable::const_ptr psrc
     (get_facet());
   assert(psrc);

   psrc->clone_source_setup(*this, clone);

   return clone;
}

I did look into this as an option, but got tangled up because the source of
a zfs clone is not a directory, it's a dataset - which means it is not an
absolute filesystem path and is not stat()able.  Rather than hacking the
directory implementation to relax these constraints and make it compatible
with zfs, I decided to keep the zfs implementation self-contained.


Sure, that's completely understandable, but you could set the path to be 
the mountpoint of the dataset and have it work correctly this way.


The problem that I see with the current approach is that the source 
chroot session is using a cloned copy of the dataset, just like a 
regular session, and when you end that session, you'll lose the 
changes.  They won't be preserved in the original dataset.  I might be 
misreading things, but that's what it looks like would happen.  That 
looks fundamentally incompatible with how source chroot sessions are 
supposed to work.  It must work on the source dataset or else it's not 
going to change it as intended.


If the 05zfs script special-cased source chroots, then you could keep 
the existing approach on the C++ side, but skip the snapshot/clone in 
the script and work directly with the original dataset.  But I don't 
currently see any logic to handle this; it's snapshotting and cloning 
unconditionally.


I see two possible approaches:

1) Keep the current code, but unset the clone/snapshot settings and use 
05zfs to special-case the snapshot/clone creation and deletion for 
chroot sessions only, and skip entirely for source sessions.  You could 
do this if the source dataset and clone dataset names are the same.  Set 
the variables so that it will use the mountpoint for the source dataset.


2) Use a directory chroot.  Obtain the mountpoint path of the source 
dataset from zfs so it can be stat()ed


(1) looks simplest to do; it's just a single conditional in 05zfs to 
skip the snapshot/clone stuff.



Regards,

Roger

Bug#947919: schroot: Support for ZFS snapshotting

[Roger Leigh]

On 05/01/2020 02:23, Steve Langasek wrote:


Hi Roger,

On Sat, Jan 04, 2020 at 12:54:56PM +, Roger Leigh wrote:

When you clone a source snapshot, we want to make that snapshot the 
default

state for the original dataset when you end the session.  The "file" chroot
type is the most comparable here; the LVM and Btrfs snapshots operate
directly on the original copy. Right now the ZFS source chroot clone looks
as ephemeral as a regular cloned session, so I'm not sure the current
behaviour is corect.  We want the saving of the updated source chroot to be
done such that it appears atomic for any concurrent usage to clone the old
state or the new state, and never an intermediate state as the original is
updated.  It's this part that I wasn't sure about.  I don't see an
equivalent to "zfs promote" which would allow copying back a clone (or
snapshot of a clone) to the source dataset, and I don't see any
source-chroot-specific logic in 05zfs which would preserve any source chroot
changes.

Ok, you're right that I haven't done anything wrt 'zfs promote'.  Prior to
switching to zfs, all of my schroot work used the lvm-snapshot type, which
has the same limitation you describe here: session clones taken while the
source chroot is in the process of being updated end up cloning some
intermediate state.  I have never had a problem with this limitation in
practice, since my usage of schroot is entirely human-driven, so it's very
easy for me to avoid launching new schroots while in the middle of a
"maintenance window".

Being able to update the source atomically certainly seems like a nice
enhancement, but given that the implementation is currently at parity with
the lvm-snapshot type, I am not likely to invest effort in this myself at
this time.


In this case, I think you should copy the btrfs-snapshot approach and 
make the source chroot a "directory" chroot type.  Then it will operate 
directly on the source dataset.  That is to say:


sbuild::chroot::ptr
chroot_zfs_snapshot::clone_source () const
{
  ptr clone(new chroot_zfs_snapshot(*this));

...

should be

chroot_zfs_snapshot::clone_source () const
{
  ptr clone(new chroot_directory(*this));

  chroot_facet_source_clonable::const_ptr psrc
    (get_facet());
  assert(psrc);

  psrc->clone_source_setup(*this, clone);

  return clone;
}

This isn't quite as elegant as doing an atomic update, but if it's 
primarily under the user's control rather than being scripted and done 
automatically then it should be good enough, and it matches the 
constraints the other chroot snapshot types have operated under.


I would certainly be happy to see a more sophisticated approach in the 
future which provides some form of atomic update and guarantees cloning 
new sessions will always use a known good state, but this will clearly 
need more work to do properly.



Kind regards,

Roger

Bug#947919: schroot: Support for ZFS snapshotting

[Roger Leigh]

On 04/01/2020 12:54, Roger Leigh wrote:

When you clone a source snapshot, we want to make that snapshot the 
default state for the original dataset when you end the session. The 
"file" chroot type is the most comparable here; the LVM and Btrfs 
snapshots operate directly on the original copy. Right now the ZFS 
source chroot clone looks as ephemeral as a regular cloned session, so 
I'm not sure the current behaviour is corect.  We want the saving of 
the updated source chroot to be done such that it appears atomic for 
any concurrent usage to clone the old state or the new state, and 
never an intermediate state as the original is updated.  It's this 
part that I wasn't sure about.  I don't see an equivalent to "zfs 
promote" which would allow copying back a clone (or snapshot of a 
clone) to the source dataset, and I don't see any 
source-chroot-specific logic in 05zfs which would preserve any source 
chroot changes.


I should also have written that I did also consider if we could use "zfs 
promote" as intended.  It should be fine for its intended purpose, but 
it would change the dataset name which would then require an update of 
schroot.conf.  I ruled this out because it doesn't fit into the existing 
design.  However, were schroot to eventually become a service, we could 
create and manage chroots similar to docker and not have the chroot 
configuration in /etc at all; it would be all stored as data under /var.

Bug#947919: schroot: Support for ZFS snapshotting

[Roger Leigh]

On 03/01/2020 20:44, Steve Langasek wrote:


Package: schroot
Followup-For: Bug #947919
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Attached is an updated patch which implements source chroots as well.


Dear Steve,


I've had a look over the patch, and have a few comments on it.


Firstly, it looks really great.  I've no major criticisms to make of it, 
so many thanks for taking the time and effort to implement this, it's a 
great addition.



If you hadn't already seen it, there's an existing implementation here:

https://gitlab.com/rleigh/schroot/commit/08751fdff2db4d11731983faf8e9868dffbd5dbf

on this branch:

  https://gitlab.com/rleigh/schroot/tree/zfs-snapshot

I don't know if your work was using this as a basis for your work on top 
of the 1.6 branch (the work here is against master, which is a bit 
different).  If you haven't already, it might be worth looking though.  
I think, overall, your implementation is better in terms of the options 
it provides and the environment it sets, but it might be useful to 
compare just in case it has any interesting bits you want to pick up.  
Note that I didn't complete this work; the C++ side was mostly done but 
the scripting side for setting up the ZFS snapshots was not.  At the 
time, I wasn't entirely sure on how best to use ZFS to implement source 
chroots reliably, which I think you've done better but I think not 
completely (as detailed below).



When you clone a snapshot, you're getting an ephemeral dataset and 
snapshot which the 05zfs script is correctly creating and destroying.  
No problems here that I can see.



When you clone a source snapshot, we want to make that snapshot the 
default state for the original dataset when you end the session.  The 
"file" chroot type is the most comparable here; the LVM and Btrfs 
snapshots operate directly on the original copy. Right now the ZFS 
source chroot clone looks as ephemeral as a regular cloned session, so 
I'm not sure the current behaviour is corect.  We want the saving of the 
updated source chroot to be done such that it appears atomic for any 
concurrent usage to clone the old state or the new state, and never an 
intermediate state as the original is updated.  It's this part that I 
wasn't sure about.  I don't see an equivalent to "zfs promote" which 
would allow copying back a clone (or snapshot of a clone) to the source 
dataset, and I don't see any source-chroot-specific logic in 05zfs which 
would preserve any source chroot changes.


One possible method would be to create an @latest snapshot which would 
be used in preference to creating a new snapshot should it exist, so 
that we could copy the content over while this snapshot exists.  The 
implementation would have to cope with races if it's deleted before 
cloning, however, by falling back to creating a new snapshot.  And only 
the original creator should be deleting it, so it would also have to 
cope with deleting it if the original process aborted without deleting it.


Another alternative which springs to mind is to make the source chroot a 
directory chroot type, so it's working directly on the source dataset.  
But snapshot with @latest-source and when others start a session, clone 
that tag.  When you end the session, update that tag.  There's also the 
option of rollback if you want to throw away the changes.  This would 
restrict you to one source chroot session at a time, but it's simpler 
and has less to deal with in terms of races, and fits in a bit better 
with how ZFS wants things done.


I'm sure some strategy could be worked out; these considerations were 
the primary reason I never merged in that branch and made a new major 
release of schroot.  If you or anyone else has better expertise on how 
to safely implement this, I'd be happy to work on merging your work into 
the master branch and releasing this.  Note however, that the master 
schroot branch did made some incompatible configuration changes.  The 
biggest change was dropping support for the lvm-snapshot and 
btrfs-snapshot chroot types, which in practice have proven quite 
unreliable due to kernel and other implementation bugs, including races 
in udev when using LVM and filesytem unbalancing and dataloss with 
Btrfs.  zfs-snapshot should be free of all these irritations.



Another comment regarding updating of the source chroot.  With the 
current methods, primarily 05file, the source is unconditionally updated 
(repacked) when the session is ended. I've always been a little unhapy 
with this, in case you mess things up and want to throw it away.  This 
would require an additional option adding to schroot to pass through 
with --end-session.  It would be a session option like --session-name. 
Maybe --save-session to require the overwriting.  Or a negative option 
if you want the default to be to save.  Or a Boolean option to make it 
explicit and mandatory.  With the @latest-source, above, this could 
invoke "zfs rollback".

Bug#948119: [schroot] does not work for non-root user

[Roger Leigh]

On 04/01/2020 08:35, Giovanni Mascellani wrote:


Package: schroot
Version: 1.6.10-7
Severity: important

Hi,

with today's update (1.6.10-7), schroot does not work anymore for
non-root users (which are still authorized by mean of the "users"
directive)




I suspect the problem might be related to the fact that /usr/bin/schroot
is not set-uid anymore, while it was before. Executing

  # chmod u+s /usr/bin/schroot

fixes the problem for me.


schroot absolutely requires being installed setuid root.  Like sudo and 
su, it's required for PAM auth and setuid() and setgid() calls, as well 
as the chroot() call and performing privileged actions like mounting and 
unmounting filesystems.


In the past, I did consider making it a service accessed via a socket, 
so that we could have an unprivileged client binary and a privileged 
server process.  It's still a reasonable approach to take, but it 
requires time and effort to design and implement which I haven't had to 
spare.



Kind regards,

Roger

Bug#898949: schroot: PAM config should use common-session-noninteractive

[Roger Leigh]

On 07/09/2019 10:30, Simon McVittie wrote:


On Thu, 17 May 2018 at 19:36:11 +0200, Ansgar Burchardt wrote:

On systems with libpam-systemd installed using common-session will
create a logind session which schroot should not do.

In particular, creating a logind session results in $XDG_RUNTIME_DIR
being set inside the chroot, to a path that only exists outside the chroot.


Should this path be bound into the chroot?

Which Debian version introduced common-session-noninteractive?


Regards,

Roger

Bug#686442: initscripts: This failed update completely breaks dpkg

[Roger Leigh]

On 20/02/2019 01:56, Pierre Ynard wrote:

This isn't an issue in initscripts, and I think it wouldn't even be
possible to add Breaks statements against offending unpurged packages;
so not much can be done here. The offending initscripts are either from
the local administrator or from obsolete package versions, so I don't
see any point in reassigning the bug either.


Given the number of warnings about the lack of LSB headers,h the init 
scripts themselves.  It's solely due to update-rc.d/insserv erroring out 
when *configuring* the initscripts.  It would have broken for any 
package configuration step which invoked update-rc.d.


It's clear this system was using nonconforming scripts, be they custom 
ones, customised Debian scripts, or out of date Debian scripts from 
older versions of the packages.  In this timeframe (2012), we had made 
LSB headers essentially mandatory.  The cause is a dependency loop from 
the xfree86-common package, which hasn't existed for a long time now 
with the switch to xorg.


The solution here would have been to purge the system (dpkg --purge) of 
all *obsolete* packages, thereby removing all the LSB dependency 
warnings from stale init scripts hanging around.  And if there are any 
custom packages, to add an LSB header to them.


As far as I can tell, this bug never had anything to do with initscript 
itself, and the correct action was for the admin to tidy the system, so 
I think this can be safely closed at this point.



Kind regards,
Roger

Bug#692559: Debian-init-diversity Digest, Vol 3, Issue 63

[Roger Leigh]

On 29/12/2018 18:36, 
debian-init-diversity-requ...@chiark.greenend.org.uk wrote:

Regarding RAMTMP, I am not sure whether it is actually useful. Really,
if you want /tmp in tmpfs, just add entry into /etc/fstab. There should
be one, and only one oblivious way to do it.


RAMTMP was added primarily for completeness.  If you read mount_tmp in 
mount-functions, you'll see that there are circumstances where we 
override it under certain conditions, e.g. read-only root fs or lack of 
space on root fs.  These mitigations are intended to allow booting on a 
system which would otherwise be broken due to the lack of a functional /tmp.


In general, the tmpfs handling in the initscripts was deliberately 
intended to allow direct configuration in /etc/fstab, which takes 
precedence over the /etc/default/tmpfs settings.  The reason for the 
default settings was to expose some of the variables used in the scripts 
which were useful to configure all of the standard tmpfs filesystems. 
This includes all the size limits.  Unlike for fstab (which does allow 
absolute size or percentage), here you can compute the limits on the fly 
based upon the system memory and whatever other factors you desire.


It's not expected that this will be commonly used, but it's there for 
those that wish to safely use multiple tmpfs filesystems with strict and 
intelligently-set limits, with no chance of OOMing the system by 
accident or malicious intent.



Regards,
Roger

Bug#688412: Debian-init-diversity Digest, Vol 3, Issue 63

[Roger Leigh]

On 29/12/2018 18:36, 
debian-init-diversity-requ...@chiark.greenend.org.uk wrote:

The result was:
domount: mount tmpfs shmfs /tmp tmpfs -onodev,nosuid,size=512m,mode=1777

So configuration options are recognized by the initialization scripts and
passed to the "mount" utility, but somehow get lost later. There are similar
/etc/fstab records for other tmpfs mounts (/run, /run/lock and /run/shm) but
only /tmp doesn't work as expected.

Confirmed. I do not see bug at glance, but I will definitely take a
closer look. Sorry for very late reply.


Might be worth checking if this is being overridden by anything in 
/etc/default/tmpfs.  The above output should account for that, though. 
 If an fstab entry is present, then this should always take priority 
over the default/tmpfs variables, by design.In mount-functions:


if read_fstab_entry /tmp; then
if [ "$MNT_TYPE" = "tmpfs" ] ; then
RAMTMP="yes"
else
RAMTMP="no"
fi
fi

The else case might need to set TMP_OPT="" so that when an fstab entry 
exists the options can't be overridden.  Looks like we only avoid 
overriding mounting or not, not the default options.


This applies to all of the various tmpfs mount functions (run, lock, 
shm, tmp).



Regards,
Roger

Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Roger Leigh]

On 19/12/2018 23:40, Dmitry Bogatov wrote:


control: tags -1 +moreinfo

[2015-12-01 23:07] Petter Reinholdtsen 

In my view, /etc/init.d/rc and /etc/init.d/rcS should not be
conffiles.  They should be moved to /lib/init/ instead.


Dear co-maintainers, what about actually moving /etc/init.d/{rc,rcS}
into /lib/init and adding symbolic links?

Any objections to this approach?


Not from me.  They aren't conffiles, and /lib/init is as good a place as 
any, unless you wanted to put them into /bin.  Ideally they would be 
best placed in /libexec, but this is banned in Debian for some dubious 
historical reasons.



Regards,
Roger

Bug#797781: [buildd-tools-devel] Bug#797781: diffoscope does not seem to work with schroot]

[Roger Leigh]

On 12/12/2018 15:25, Aurelien Jarno wrote:

On 2018-12-12 10:06, Helmut Grohne wrote:

Hi Aurelien,

On Sun, Sep 06, 2015 at 07:28:40PM +0200, Aurelien Jarno wrote:

The buildd flavour of the configuration mount a tmpfs in /dev/shm. AFAIK
this is not done for the default flavour as too options are possible
there:
- Bind mount like above. This means sharing the shm directory with the
   outside world. This might have some security implications, and
   unwanted consequences.
- Empty tmpfs like for buildds. This means the processes do not have
   accesses to shared memory from processes outside of the chroot.

Depending on how the user want to use schroot, one or the other
configuration should be used. I don't know how we should choose the
default one.


Essentially, we have three options (for the default and desktop
profiles) now:

(A) Status quo: Don't mount /dev/shm.
(B) Bind mount /dev/shm.
(C) Mount a tmpfs on /dev/shm.

As you point out, each of (B) and (C) breaks some people's workflows
(either isolation or stuff doesn't work).

Either (B) or (C) fixes what many users (e.g. diffoscope, ghc, my own
itch, ...) want. (C) doesn't regress on isolation compared to (A).
Therefore I argue that (C) is strictly "better" than (A), but (B) isn't.


(C) might give users the possibility to trigger an OOM and DoS system.
/dev/shm is writable by any user. If users have no limit on the number
of chroots they can run, they might be able to fill the whole memory
(RAM + swap), leading to an OOM, potentially killing essential services
as the memory from a tmpfs can't be killed. This does not happen on a
normal system, as the default size of a tmpfs is half of the size of the
RAM.

So I am not sure that (C) is "strictly better".


It should perhaps be combined with some sensible default size 
limitations like we used to provide in (IIRC) /etc/default/tmpfs.


For the (B) case, do we have any defined use case for sharing shm 
between host and chroot?  It's useless for anonymous (unlinked) 
mappings, because they won't be propagated.  So the only use case is 
named mappings.  If we don't have any concrete use case for that, I'd be 
tempted to drop this possibility entirely.


For (A) if you don't mount /dev/shm, is there still some risk due to 
using the underlying devtmpfs mount and causing problems, including 
security problems, as a result?  You might still get shared data between 
host and chroots stored there, which might have security and privacy 
implications?  And you could affect the /dev mountpoint if using all the 
space prevents device node or other file creation under /dev on the host?


I think (C) is vastly preferable from the security point of view. 
However, it does as you point out, have problems if you overcommit 
resources across multiple chroots.


One possible mitigation would be to not mount a tmpfs at all.  There is 
no technical requirement that /dev/shm be a tmpfs.  It could be backed 
by disk, e.g. creating and bind mounting chroot/shm to chroot/dev/shm 
would make it use the same disc backing as the chroot itself.  Or create 
a session-specific private dir under [/var]/tmp and bind mount that (it 
will avoid serialising and storing session state for source chroots). 
There will of course be a potential performance cost in using a real 
disc, but it takes all of the resource exhaustion and privacy questions 
completely out of the picture.



Regards,
Roger

Bug#911087: schroot: --preserve-environment does not preserve env vars set to ""

[Roger Leigh]

On 15/10/18 19:43, Peter Maydell wrote:

Roger Leigh wrote:

Please see https://gitlab.com/codelibre/schroot/merge_requests/38 for a
patch containing the fixes.  This looks like an oversight/mis-design
which is corrected by this merge request to make the behaviour
consistent for all environment handling methods.


Wow, thanks for the incredibly fast response -- I appreciate it.


No problem!  Note that I've tweaked that change slightly.  I added 
GitLab CI support to test a range of distributions and found that the 
1.6 backport needed a couple of additional tweaks, which I've now made, 
tested and merged as https://gitlab.com/codelibre/schroot/merge_requests/39.



Regards,
Roger

Bug#911087: schroot: --preserve-environment does not preserve env vars set to ""

[Roger Leigh]

tags 911087 + patch
forwarded 911087 https://gitlab.com/codelibre/schroot/merge_requests/38
thanks

On 15/10/18 15:00, Peter Maydell wrote:


The schroot --preserve-environment is supposed to preserve the
user's environment variables. However it does not pass through
environment variables which are set to the empty string:

mnementh$ FOO=bar schroot --preserve-environment -c buster-amd64-sbuild env | 
grep FOO
FOO=bar
mnementh$ FOO= schroot --preserve-environment -c buster-amd64-sbuild env | grep 
FOO


Compare the results without schroot:
mnementh$ FOO=bar env | grep FOO
FOO=bar
mnementh$ FOO= env | grep FOO
FOO=
indicating that 'env' distinguishes variables which are unset from
those which are set to the empty string, but that when we run env
under schroot schroot has dropped the setting of FOO.

This matters because some programs treat "set to empty string" specially.
For instance gcc uses "GCC_COLORS is set to the empty string" to mean
"don't use color in error messages", but "GCC_COLORS is unset" to mean
"use whatever the default is (for debian that means use colors)".


Please see https://gitlab.com/codelibre/schroot/merge_requests/38 for a 
patch containing the fixes.  This looks like an oversight/mis-design 
which is corrected by this merge request to make the behaviour 
consistent for all environment handling methods.


Will need backporting to the 1.6 branch for Debian.  Please see 
https://gitlab.com/codelibre/schroot/merge_requests/39 for the patch.



Kind regards,
Roger

Bug#909202: xerces-c: New upstream release

[Roger Leigh]

Source: xerces-c
Version: 3.2.1
Severity: normal

New upstream release 3.2.2 made today.  It's a patch release, so no major 
surprises.

Note that the new upstream cmake build system could be used in place of the 
autotools.


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

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

Bug#891841: xerces-c: New upstream release 3.2.1

[Roger Leigh]

Package: xerces-c
Version: 3.2.0
Severity: normal

A new version of xerces-c was made recently, and it would be
great if the Debian package could be updated to use it.

http://www.apache.org/dist/xerces/c/3/sources/xerces-c-3.2.1.tar.gz

The changes include one security update for CVE-2017-12627 and a
few minor bugfixes.  Most of the changes are for the CMake build
system.

Note that in debian/rules, the manual steps to build the HTML
documentation and Doxygen documentation are automated with the
CMake build; you can use the createdocs and createapidocs
targets to do this automatically.  If you repack the sources to
remove the embedded jars in tools/jars, the createdocs target
in docs/CMakeLists.txt might need the classpath adjusting, but
it might work just fine with the system copies.


Kind regards,
Roger

Bug#876703: schroot: Can't run schroot as normal user

[Roger Leigh]

On 03/10/2017 19:43, APT Gatuno MX wrote:
Ok, I still can't schroot as normal user, but adding some debugging 
messages to schroot found that a chdir call fails, even if the directory 
exists (example /, /tmp).


Running getcwd BEFORE doing the chdir return "/". That means that the 
chroot call actually worked, but the next calls to chdir fails. Any 
suggestions?


What are the permissions on the root directory of the chroot?  You might 
have permission to access it as root for the chroot call, but that might 
not apply to the user after we call setuid/setgid to switch the user and 
group.  But does the user or group have permission to access it?  The 
problem might possibly even lie in a higher up directory (not 100% sure, 
but worth checking to be certain).


If you're also using bind mounts, I'd suggest checking the permissions 
of the directories here as well.



Regards,
Roger

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#874193: xml-security-c: Does not build with C++11 enabled, required for Xerces 3.2.0

[Roger Leigh]

On 07/09/2017 19:03, Ferenc Wágner wrote:

Anyway, could you please give me instructions to reproduce the build
failure with C++11?  Adding in CXXFLAGS=-std=c++11 did not break the
1.7.3-4 build for me.  And what will I have to change once Xerces 3.2
enters the archive?


It might be that the failure is only reproducible with clang++ (I found 
the issue originally on FreeBSD 11.1 with clang 4.0.0).


No other changes should be required to build with Xerces 3.2.  It's API 
compatible with 3.1, so will need a binary rebuild but that's about it. 
Upstream will be making a new xml-security-c release soon containing 
these patches anyway, plus a soname bump, so if Debian is already 
building fine with C++11 then there's likely not much that needs doing.



Regards,
Roger

Bug#874193: xml-security-c: Does not build with C++11 enabled, required for Xerces 3.2.0

[Roger Leigh]

Package: xml-security-c
Version: 1.7.3-4
Tags: patch

Please see the patches I attached to the upstream ticket here: 
https://issues.apache.org/jira/browse/SANTUARIO-471 which resolve a 
number of defects in the source which prevent it building.


They are safe to apply even when C++11 is not in use.


Regards,
Roger

Bug#874189: Patch for Xerces 3.2.0

[Roger Leigh]

Package: xqilla
Version: 2.3.3-2
Tags: patch

Xerces-C 3.2.0 removed castToNode (which relied on undefined behaviour) 
with a cleaner way of getting information about a node's containing 
node: a new fContainingNode member.


The attached patchs have conditionals for the 3.2.0 and earlier 
behaviour, so should be safe to apply without any breakage.
Tested on FreeBSD 11.1 and 10.3 for the xqilla port, and Debian unstable 
for the Debian package.


See also: https://sourceforge.net/p/xqilla/bugs/48/


Regards,
Roger
diff -urN XQilla-2.3.3.orig/src/dom-api/impl/XPathDocumentImpl.cpp XQilla-2.3.3/src/dom-api/impl/XPathDocumentImpl.cpp
--- XQilla-2.3.3.orig/src/dom-api/impl/XPathDocumentImpl.cpp	2015-05-18 18:38:59.0 +0100
+++ XQilla-2.3.3/src/dom-api/impl/XPathDocumentImpl.cpp	2017-09-03 22:15:41.999739206 +0100
@@ -62,7 +62,11 @@
 if (thisNodeImpl->isReadOnly())
 throw DOMException(DOMException::NO_MODIFICATION_ALLOWED_ERR, 0, getMemoryManager());
 
+#if _XERCES_VERSION >= 30200
+DOMNode* thisNode = fParent.fContainingNode;
+#else
 DOMNode* thisNode = castToNode(&fParent);
+#endif
 if (newChild->getOwnerDocument() != thisNode)
 throw DOMException(DOMException::WRONG_DOCUMENT_ERR, 0, getMemoryManager());
 
diff -urN XQilla-2.3.3.orig/src/dom-api/impl/XPathNamespaceImpl.cpp XQilla-2.3.3/src/dom-api/impl/XPathNamespaceImpl.cpp
--- XQilla-2.3.3.orig/src/dom-api/impl/XPathNamespaceImpl.cpp	2015-05-18 18:39:00.0 +0100
+++ XQilla-2.3.3/src/dom-api/impl/XPathNamespaceImpl.cpp	2017-09-03 22:15:46.031991028 +0100
@@ -33,7 +33,11 @@
 
 XPathNamespaceImpl::XPathNamespaceImpl(const XMLCh* const nsPrefix, 
 		const XMLCh* const nsUri, DOMElement *owner, DOMDocument *docOwner) 
+#if _XERCES_VERSION >= 30200 
+	: fNode(this, docOwner)
+#else
 	: fNode(docOwner)
+#endif
 {
 DOMNodeImpl *argImpl = castToNodeImpl(this);
 
@@ -54,7 +58,13 @@
 }
 
 XPathNamespaceImpl::XPathNamespaceImpl(const XPathNamespaceImpl &other) 
-	: fNode(other.fNode), uri(other.uri), prefix(other.prefix)
+#if _XERCES_VERSION >= 30200 
+	: fNode(this, other.fNode),
+#else
+	: fNode(other.fNode), 
+
+#endif
+	  uri(other.uri), prefix(other.prefix)
 {
 }
 
@@ -196,7 +206,11 @@
 
 //if it is a custom node and bigger than us we must ask it for the order
 if(otherType > DOMXPathNamespace::XPATH_NAMESPACE_NODE) {
+#if _XERCES_VERSION >= 30200 
+DOMNodeImpl tmp(const_cast(this), 0);
+#else
 DOMNodeImpl tmp(0);
+#endif
 #if _XERCES_VERSION >= 3
 return tmp.reverseTreeOrderBitPattern(other->compareDocumentPosition(this));
 #else

Bug#873669: xerces-c: New upstream release 3.2.0

[Roger Leigh]

Source: xerces-c
Severity: normal

https://marc.info/?l=xerces-c-users&m=150396606201867&w=2

Note that this release includes a replacement of the autotools build
with CMake.  The autotools build still exists, but the CMake build
includes pkg-config and cmake configuration, and also builds and run
the unit tests correctly on all platforms, which was tested
extensively during the development (the autotools unit tests fail due
to erroneous newlines in the output, which can vary depending upon the
compiler and other unknowns).  In practice, this means the cmake build
is preferable if you would like to switch and enable the unit tests as
part of the package build.

The CMake build also conditionally enables C++11 features including
use of char16_t string literals.  This means you can use u"string"
literals wherever XMLCh* is used, making the API much easier to use.
This is fully backward compatible (though some packages may be making
buggy assumptions about XMLCh==uint16 and relying upon implicit
casts).

The release includes a rather large number of bugfixes.  While it's
API compatible with 3.1.4 and earlier, it has a new soname and will
require a rebuild of all reverse dependencies.


Regards,
Roger

Bug#873666: libxalan-c111: Patch to correct erroneous assumptions about XMLCh type

[Roger Leigh]

Package: libxalan-c111
Version: 1.11-6
Severity: important
Tags: patch

The attached patch corrects some broken assumptions about the nature of 
XMLCh* in the xalan source.


See https://issues.apache.org/jira/browse/XALANC-773

This is required for xerces 3.2.0 where XMLCh == char16_t.


Regards,
Roger
diff -urN xalan-c-1.11.orig/c/src/xalanc/PlatformSupport/DirectoryEnumerator.hpp xalan-c-1.11/c/src/xalanc/PlatformSupport/DirectoryEnumerator.hpp
--- xalan-c-1.11.orig/c/src/xalanc/PlatformSupport/DirectoryEnumerator.hpp	2012-03-19 16:18:10.0 +
+++ xalan-c-1.11/c/src/xalanc/PlatformSupport/DirectoryEnumerator.hpp	2017-08-09 12:05:08.604342028 +0100
@@ -84,7 +84,7 @@
 const XalanDOMChar*
 getName() const
 {
-return name;
+return const_cast(reinterpret_cast(&name[0]));
 }
 
 /**
@@ -261,7 +261,7 @@
 #pragma warning(disable: 4244)
 theHandleType   theSearchHandle =
 _wfindfirst(
-const_cast(theConversionFunction(theFullSearchSpec)),
+reinterpret_cast(const_cast(theConversionFunction(theFullSearchSpec))),
 &theFindData);
 #pragma warning(pop)
 
diff -urN xalan-c-1.11.orig/c/src/xalanc/PlatformSupport/DOMStringHelper.cpp xalan-c-1.11/c/src/xalanc/PlatformSupport/DOMStringHelper.cpp
--- xalan-c-1.11.orig/c/src/xalanc/PlatformSupport/DOMStringHelper.cpp	2012-03-19 16:18:10.0 +
+++ xalan-c-1.11/c/src/xalanc/PlatformSupport/DOMStringHelper.cpp	2017-08-09 12:05:08.604342028 +0100
@@ -868,7 +868,7 @@
 const XalanDOMChar* theRHS)
 {
 #if defined(XALAN_USE_WINDOWS_COLLATION)
-return _wcscoll_l(theLHS, theRHS, s_locale);
+return _wcscoll_l(reinterpret_cast(theLHS), reinterpret_cast(theRHS), s_locale);
 #else
 return doCollationCompare(
 theLHS,
diff -urN xalan-c-1.11.orig/c/src/xalanc/PlatformSupport/XalanFileOutputStream.cpp xalan-c-1.11/c/src/xalanc/PlatformSupport/XalanFileOutputStream.cpp
--- xalan-c-1.11.orig/c/src/xalanc/PlatformSupport/XalanFileOutputStream.cpp	2012-03-19 16:18:10.0 +
+++ xalan-c-1.11/c/src/xalanc/PlatformSupport/XalanFileOutputStream.cpp	2017-08-09 12:05:08.604342028 +0100
@@ -123,7 +123,7 @@
 
 #if defined(XALAN_WINDOWS)
 HandleType  theFileHandle = CreateFileW(
-theFileName.c_str(),
+reinterpret_cast(theFileName.c_str()),
 GENERIC_WRITE,
 0,
 0,

Bug#868883: schroot: btrfs-snapshot requires btrfs-snapshot-directory= but doesn't use it

[Roger Leigh]

On 19/07/17 13:56, Uwe Kleine-König wrote:

I have:

$ cat /etc/schroot/chroot.d/unstable-amd64-default-237842
[unstable-amd64-default]
description=Debian unstable/amd64 chroot
groups=root,sbuild
root-groups=root,sbuild
profile=default
type=btrfs-snapshot
btrfs-source-subvolume=/srv/chroot/unstable-amd64-default
btrfs-snapshot-directory=/srv/chroot/unstable-amd64-default-snaps

and it works as expected. However the snapshots are created below
/run/schroot/mount/.


Is it *created* below /run/schroot/mount or is it later *mounted* below 
this location?


Looking at the program logic, the session should be snapshotted under 
the specified snapshot directory:


  if (btrfs_snapshot && !btrfs_snapshot->get_snapshot_directory().empty())
{
  std::string snapname(btrfs_snapshot->get_snapshot_directory());
  snapname += "/" + clone->get_name();
  btrfs_snapshot->set_snapshot_name(snapname);
}

in sbuild/sbuild-chroot-facet-session-clonable.cc.  Would it be possible 
to double-check exactly what is where?



An unrelated FYI: On the schroot master branch, Btrfs snapshot support 
has been removed.  The repeated Btrfs filesystem unbalancing with 
intensive snapshotting made this feature unsuitable for production use. 
I will be replacing it with ZFS snapshot support.



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  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#840883: Please work around gnupg agents

[Roger Leigh]

On 15/10/2016 19:47, Ian Jackson wrote:

If some program is run within an schroot which invokes gpg (for
example, as part of a package build, or a DEP-8 test suite), schroot
can fail to tear the chroot down.  As an example, dgit's DEP-8 test
suite currently fails for this reason when run with adt-virt-schroot
specifying an lvm snapshot sid chroot.

(See #840669 for more details.)

I suggest that schroot ought to kill gpg-agents when tearing down the
chroot.  On my own computer I have done this with the attached script,
which might serve as a starting point.

I suspect that this script is not quite what is needed.  Things which
are perhaps wrong with it:
 * It always prints output (good for me to help debug this problem,
   but not good for a default shipped with schroot)
 * I am not sure whether the --exec test will DTRT.  ISTM that it
   will almost certainly do a wrong thing for tarball chroots, but
   it's probably right for lvm snapshot ones (or any other that has
   its own separately mounted /usr filesystem).
 * Other things I haven't thought of.


Thanks, I'll take a look at the script.

However, I wonder why the existing killprocs script isn't finding and 
killing the agent on session end.  It should take care of any processes 
running inside the chroot whether or not they are daemons.



Regards,
Roger

Bug#829125: schroot: schroot doesn't clean up its bind mounts if used concurrently

[Roger Leigh]

On 30/06/2016 18:02, Dima Kogan wrote:


Then I enter a schroot:

  $ schroot -c xxx zsh



Then with this schroot open, I enter it again from a different terminal:

  $ schroot -c xxx zsh

  $ [ in chroot. again. ]

Looking at the mounts, I now see this:
  devpts on /run/schroot/mount/xxx-5a4ddce3-2bbd-41ef-a415-d1d1c5e79d15/dev/pts 
type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)



  devpts on /run/schroot/mount/xxx-aeef8a02-8d83-4159-9916-75597e00b42d/dev/pts 
type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
  devpts on /run/schroot/mount/xxx-5a4ddce3-2bbd-41ef-a415-d1d1c5e79d15/dev/pts 
type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)



So this is a bug. /dev/pts shouldn't have been mounted a second time,
especially not with the first UUID.

Now I go back to the first schroot, and exit it.

  $ exit
  E: 10mount: umount: 
/run/schroot/mount/xxx-5a4ddce3-2bbd-41ef-a415-d1d1c5e79d15/dev/pts: target is 
busy
  E: 10mount: (In some cases useful info about processes that
  E: 10mount:  use the device is found by lsof(8) or fuser(1).)
  E: xxx-5a4ddce3-2bbd-41ef-a415-d1d1c5e79d15: Chroot setup failed: 
stage=setup-stop

This is a bug, but maybe it makes some sense given what we saw before. The
second chroot mounted /dev/pts a second time, so it maybe looked busy.
However if I look at what is still mounted at this point, I see that
NOTHING got cleaned up


[...]

These are the UUIDs from the first schroot (the second one we exited).
So exiting the first schroot cleaned up the mounts from the SECOND
schroot, but left its own ones alone. This is a bug too.

Hopefully this is helpful. Thanks!


While I don't have a concrete solution to hand, some thoughts:

Are you running systemd?
Does the problem occur when you run sysvinit?
Have you altered any of the setup scripts to do rbind in place of bind? 
(not that this should be a problem; we only removed it because of 
systemd breaking it with autofs on /dev mountpoints)


Can you reproduce this by hand by starting a session, then creating a 
temporary directory and bind mounting the same stuff into it?  That is, 
to recreate the 10mount setup script actions step by step.


My suspicion here is that systemd is changing the mount behaviour and 
that you're getting this erroneous mount as a side effect.  The point of 
the above test is to check whether this is a schroot issue or a more 
general problem with mount(8).  Since schroot isn't doing anything more 
than a series of mount invocations in a shell script and mount helper, 
it's unlikely to cause bizarre side effects in and of itself.



Regards,
Roger

Bug#789694: [buildd-tools-devel] Bug#789694: schroot: Please consider patch to fix it on hurd-i386

[Roger Leigh]

On 15/02/2016 22:31, Samuel Thibault wrote:

Hello,

Samuel Thibault, on Thu 30 Jul 2015 20:34:49 +0200, wrote:

Roger Leigh, le Sun 26 Jul 2015 16:26:22 +, a écrit :

Regarding Samuel's commit to the alioth master branch: this is no longer the
canonical upstream repo for schroot,


Aow, ok.


If you're happy with both of the above pull requests, I'll merge them and
make a new 1.6 release.


Yes, please.


Are there any news about this?


Hi,

These were merged into the 1.6 and master branches, but I've yet to make 
a new release.  There are some other pending PRs to finish review and 
test, and I can make a release after that now that I have some Debian 
VMs to build and test in.



Regards,
Roger

Bug#802849: [buildd-tools-devel] Bug#802849: schroot: please allow to unshare the network

[Roger Leigh]

On 24/10/2015 09:02, Johannes Schauer wrote:

Package: schroot
Version: 1.6.10-2
Severity: wishlist

Hi,

Debian packages must be buildable without network access. For this
purpose it would be extremely useful if schroot would add an option that
unshares the network namespace before entering the chroot and executing
dpkg-buildpackage.

The unsharing has to be done by schroot itself and cannot be done
earlier because sbuild is usually run as non-root. Non-root users don't
have the privileges to unshare the network namespace, so they would
first have to create a new user namespace as well. But after having done
so, schroot refuses to work because it requires that
/etc/schroot/schroot.conf is owned by the root user (which it is not
anymore for a process that unshared the user namespace).

So could schroot instead get an option like --unshare-net which, while
schroot still has root privileges makes an unshare(CLONE_NEWNET) and
then runs `ip link set lo up` to activate the loopback interface?


The code already exists on the master branch.


https://github.com/codelibre-net/schroot/blob/master/lib/schroot/chroot/facet/unshare.cc

https://github.com/codelibre-net/schroot/blob/master/etc/setup.d/60unshare

You just run with "-o unshare.net=true" and it will be done.

Unfortunately I don't think the master branch is quite ready for release 
yet, and it's not a current priority for me.  Primarily it requires 
testing, but if you wanted to give it a try this feature should be working.



Regards,
Roger

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 , 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-dist-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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#789694: [buildd-tools-devel] Bug#789694: schroot: Please consider patch to fix it on hurd-i386

[Roger Leigh]

On 23/06/2015 13:42, Gabriele Giacone wrote:



attached patch makes schroot working on hurd, has been being tested on
exodar porterbox since many months.
It works around #763932 bug.


Dear Gabriele and Samuel,

I just want to check on the state of this patch and add a few notes.

I'm not familiar with the hurd details, so really just wanted to check 
if any changes were required before it was merged.  Note that I've 
opened pull requests here:


  https://github.com/codelibre-net/schroot/pull/7 (master)
  https://github.com/codelibre-net/schroot/pull/6 (1.6 branch)

Please feel free to add any comments there if needed.

Regarding Samuel's commit to the alioth master branch: this is no longer 
the canonical upstream repo for schroot, so committing here is not a 
great idea; it's now basically a mirror of the actual github repo, so 
and commits are liable to be lost.  The above two pull requests are your 
commit split into two and rebased onto the 1.6 branch (which is what's 
currently in Debian unstable).


If you're happy with both of the above pull requests, I'll merge them 
and make a new 1.6 release.



Kind regards,
Roger


--
To UNSUBSCRIBE, email to debian-bugs-dist-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  (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-dist-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 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-dist-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 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-dist-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 
#include 
#include 
#include 

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: 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  (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 
#include 
#include 
#include 

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#786566: [buildd-tools-devel] Bug#786566: schroot: Should mark bind mounts in the schroot as private

[Roger Leigh]

On 15/07/2015 17:47, Tyler Hicks wrote:

Hello - I'm sending a friendly poke in hopes that I can get a review for
my proposed patch. The unpatched behavior is a considerable usability
issue on systems that use systemd, schroot, and a filesystem mounted at
/home/$USER. I'd prefer upstream review before I apply the patch to
schroot in Ubuntu. Thanks!


It looks reasonable for you to apply in Ubuntu, but I'm not yet sure if 
it's safe to apply upstream.  It might well be safe for Debian as well, 
but I can't make that determination myself.


Is this safe to use on systems not using systemd?

Does it require a specific version of util-linux for the 
--make-[r]private options to mount?  If so, it probably needs a proper 
functional check for them, and using those as conditionals rather than 
just __linux__.



Regards,
Roger


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

Bug#790097: New Ice stable release 3.6.0 available

[Roger Leigh]

Source: zeroc-ice
Version: 3.5.1-6

If this could be packaged at some point, it would be greatly appreciated.

The upstream source releases have been moved to github; the 3.6.0 
release is here:

https://github.com/zeroc-ice/ice/archive/v3.6.0.tar.gz

And upstream Debian packaging is here for reference: 
https://zeroc.com/download/apt/ubuntu15.04/pool/main/z/zeroc-ice3.6/


The main change of note seems to be the dropping of python.  That might 
need packaging separately for python 2 and 3?


The other thing is the switching of the java build to use gradle.  That 
might need some checking to be sure it's not downloading stuff during 
the build that should be satisfied through build dependencies.


If there's anything particular I can do to assist, or you want any help 
testing, please just let me know.



Kind regards,
Roger


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

Bug#736642: [buildd-tools-devel] Bug#736642: Reassign to libpam-ssh?

[Roger Leigh]

On Sun, May 03, 2015 at 01:52:07AM -0400, Allan Wind wrote:
> I am seeing this issue with libpam-ssh as well.  Can we reassign, 
> or shall I file a new defect against libpam-ssh?

Please reassign; this is unlikely to be a schroot-specific bug.


-- 
  .''`.  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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#779180: [buildd-tools-devel] Bug#779180: Bug#779180: Honor chroot personality in setup (service) scripts

[Roger Leigh]

On Thu, Apr 16, 2015 at 01:15:06AM +0200, Jan-Marek Glogowski wrote:
> Hi Roger,
> 
> Am 15.04.2015 um 00:25 schrieb Roger Leigh:
> > On Wed, Feb 25, 2015 at 09:42:59AM +0100, Jan-Marek Glogowski wrote:
> >> schroot allows to set a Linux personality for chroots, e.g. to run a
> >> 32bit chroot on a 64bit system. And there is a schroot setup script to
> >> start services when entering the schroot. But these service setup script
> >> ignores the personality; that's my problem.
> > 
> > Sorry for the delay, I just wanted to let you know that I do appreciate
> > you doing this work and that I have looked over your patches.  I've
> > unfortunately not had time to test it and commit it, due to a
> > combination of work deadlines and RSI still preventing me doing as
> > much typing as I would like.  I hope that the work side of things will
> > improve towards the end of the month.
> 
> Have you thought about the more general approach to include the chroot
> call in the helper?
> 
> The patch currently does:
> 
> -  chroot "$CHROOT_PATH" /usr/sbin/invoke-rc.d ...
> +  "$LIBEXEC_DIR"/schroot-impersonate -- $(which chroot) "$CHROOT_PATH"
> /usr/sbin/invoke-rc.d ...
> 
> Would be nice to get this down to something like:
> 
>   "$LIBEXEC_DIR"/schroot-run /usr/sbin/invoke-rc.d ...

Definitely makes sense.

I was thinking about the possibility of moving the logic from
schroot's session exec function here and then execing this
helper from schroot as well.  The main concern would be passing
the session details in the environment or with appropriate
command-line options before running the command.  It would
probably make sense to call it schroot-exec in that case!

That level of support doesn't need to be done now though; it
could be updated/renamed later.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#779180: [buildd-tools-devel] Bug#779180: Honor chroot personality in setup (service) scripts

[Roger Leigh]

On Wed, Feb 25, 2015 at 09:42:59AM +0100, Jan-Marek Glogowski wrote:
> Package: schroot
> Version: 1.6.10-1
> Severity: important
> Debian Release: 8.0
> Tags: patch
> 
> schroot allows to set a Linux personality for chroots, e.g. to run a
> 32bit chroot on a 64bit system. And there is a schroot setup script to
> start services when entering the schroot. But these service setup script
> ignores the personality; that's my problem.

Dear Jan-Marek,

Sorry for the delay, I just wanted to let you know that I do appreciate
you doing this work and that I have looked over your patches.  I've
unfortunately not had time to test it and commit it, due to a
combination of work deadlines and RSI still preventing me doing as
much typing as I would like.  I hope that the work side of things will
improve towards the end of the month.


Kind 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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#675788: [buildd-tools-devel] Bug#675788: Solution found

[Roger Leigh]

On Wed, Feb 04, 2015 at 07:12:57PM +, Martín Ferrari wrote:
> Although this is not the right solution (as the XDG vars might point to
> some other location), the problem with the systemd-related mounts is
> solved if instead of using bind-mounts one uses rbind-mounts (recursive
> bind).

We deliberately removed the use of rbind mounts because it broke
systemd users' systems.  Until then they used to be the default.

The bug is that rbinding a directory containing an autofs mount
results in a deadlocked system due to a kernel bug.  Maybe that's
fixed now.  This used to be the case for /dev and /sys.

I'd not be averse to restoring the use of rbind mounts.  HOWEVER,
we can't do this unconditionally.  We do need to know, if it is
fixed, which kernel version fixed it so that we can degrade to
a plain bind mount in the face of a buggy kernel version.  Since
it system is completely unusable shortly after doing the rbind
with autofs, it's not acceptable to do this blindly.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774856: [buildd-tools-devel] Bug#774856: Bug#774856: buildd: undeclared dependency on sudo

[Roger Leigh]

On Thu, Jan 08, 2015 at 04:00:17PM +, Wookey wrote:
> +++ Adam Borowski [2015-01-08 13:46 +0100]:
> > Package: buildd
> > Version: 0.65.0-1
> > Severity: normal
> > 
> > Hi!
> > Installed buildd spams the following cron mail:
> > ,
> > Error reading configuration: SUDO binary 'sudo' does not exist or is not
> > executable at /usr/share/perl5/Buildd/Conf.pm line 77.
> > `
> > Installing 'sudo' manually makes it happy.
> 
> That should be a 'recommends', I think? As it will operate without it (but 
> whinge)?
> 
> Or does it in fact also fail to operate?

Required only if not using schroot, so should be a suggests really.

This might be niggly to solve since it's only an error conditionally
(if using sudo).


-- 
  .''`.  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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#675788: [buildd-tools-devel] Bug#675788: Additional info

[Roger Leigh]

On Tue, Jan 06, 2015 at 05:44:34PM +, Martín Ferrari wrote:
> The problem now is that schroot does not seem to have any way to tell it
> to mount directories based on environment variables.. I don't know the
> code to suggest a workaround, but maybe one option would be to add a
> configuration value that enables automatic mounting of the user's XDG_*
> directories?

Such logic isn't built in to schroot.  But it's easy to add support using
a custom setup script.  It can look at the environment and ensure that
XDG_XXX_DIR is bind mounted into the chroot.  This should probably be done
by default for the desktop profile if it's set.  However, this type of
thing is going to be fraught with problems due to the way systemd
deletes the directory when the session ends, since a schroot session can
persist for much longer.  XDG_XXX_DIR is quite poorly-specified and it's
likely we won't be able to do a good job of supporting it.  That said,
any improvements, even if imperfect, would be welcome.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#771235: [buildd-tools-devel] Bug#771235: [PATCH] sbuild: Fails to build a few valid packages that are arch all plus others

[Roger Leigh]

tags 771235  + pending
thanks

On Thu, Nov 27, 2014 at 04:45:50PM -0500, Lennart Sorensen wrote:
> I was trying to do a rebuild of some of the packages in jessie, and
> sbuild refuses to try building hsqldb1.8.0 which is a bit odd (but valid)
> in that the architecture field is:
> Architecture: all kfreebsd-i386 kfreebsd-amd64
> 
> Unfortunately sbuild incorrectly refuses to build this package even when
> told it should build architecture all packages.

Applied, thanks.

-- 
  .''`.  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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#762597: [buildd-tools-devel] Bug#762597: Bug#762597: Bug#762597: /var/lib/schroot/mounts should be in /var/run for --one-file-system

[Roger Leigh]

On Wed, Nov 26, 2014 at 04:39:00PM +, Roger Leigh wrote:
> On Mon, Nov 24, 2014 at 06:00:23PM +, Ian Jackson wrote:
> > Roger Leigh writes ("Re: [buildd-tools-devel] Bug#762597: 
> > /var/lib/schroot/mounts should be in /var/run for --one-file-system"):
> > > Hmm, this is an interesting problem.  Your proposed solution would
> > > certainly provide a boundary to stop traversal, but I'm not sure it
> > > would help in all situations, since e.g. for file-based chroots we
> > > unpack them under /var/lib/schroot.  Putting the mounts themselves
> > > under /var/run should be safe enough though.
> > 
> > Yes, you're right, I hadn't properly considered file-based chroots.  I
> > don't know how to fix those.  But as you say, my proposal at least
> > won't hurt them.
> > 
> > > I'll need to do some testing of this to make sure it doesn't
> > > break anything.  If you have any further thoughts or ideas, please
> > > do let me know!
> > 
> > Thanks for your attention!
> 
> http://www.codelibre.net/~rleigh/schroot/ contains a sample amd64 build
> and sources if you need to rebuild.  This
> 
> - switches SCHROOT_MOUNT_DIR to /var/run/schroot/mount
> - adds a compatibility symlink on upgrade to transition smoothly
> 
> The packaging might need a little extra polishing, but works for me
> and I'd be grateful if you could try testing it.  Things to tidy:
> 
> - make SCHROOT_MOUNT_DIR recursively in 10mount rather than hardcoding path
> - don't install SCHROOT_MOUNT_DIR in upstream build scripts
> - look at how to remove /var/lib/schroot/mount; it may have stuff
>   underneath it, so removal is possibly highly unsafe; maybe just
>   leave it?

These are now also taken care of.  Just uploading an updated copy of the
build.


-- 
  .''`.  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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#762597: [buildd-tools-devel] Bug#762597: Bug#762597: /var/lib/schroot/mounts should be in /var/run for --one-file-system

[Roger Leigh]

On Mon, Nov 24, 2014 at 06:00:23PM +, Ian Jackson wrote:
> Roger Leigh writes ("Re: [buildd-tools-devel] Bug#762597: 
> /var/lib/schroot/mounts should be in /var/run for --one-file-system"):
> > Hmm, this is an interesting problem.  Your proposed solution would
> > certainly provide a boundary to stop traversal, but I'm not sure it
> > would help in all situations, since e.g. for file-based chroots we
> > unpack them under /var/lib/schroot.  Putting the mounts themselves
> > under /var/run should be safe enough though.
> 
> Yes, you're right, I hadn't properly considered file-based chroots.  I
> don't know how to fix those.  But as you say, my proposal at least
> won't hurt them.
> 
> > I'll need to do some testing of this to make sure it doesn't
> > break anything.  If you have any further thoughts or ideas, please
> > do let me know!
> 
> Thanks for your attention!

http://www.codelibre.net/~rleigh/schroot/ contains a sample amd64 build
and sources if you need to rebuild.  This

- switches SCHROOT_MOUNT_DIR to /var/run/schroot/mount
- adds a compatibility symlink on upgrade to transition smoothly

The packaging might need a little extra polishing, but works for me
and I'd be grateful if you could try testing it.  Things to tidy:

- make SCHROOT_MOUNT_DIR recursively in 10mount rather than hardcoding path
- don't install SCHROOT_MOUNT_DIR in upstream build scripts
- look at how to remove /var/lib/schroot/mount; it may have stuff
  underneath it, so removal is possibly highly unsafe; maybe just
  leave it?


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#771001: [buildd-tools-devel] Bug#771001: schroot: [INTL:de] Updated German PO translation

[Roger Leigh]

On Tue, Nov 25, 2014 at 09:34:20PM +0100, Chris Leick wrote:
> Package: schroot
> Version: 1.6.11-1
> Severity: wishlist
> Tags: l10n patch
> 
> 
> Hi Roger,
> 
> please find attached the updated German translation of schroot.
> There's a typo (marked with »FIXME« in the po file).

Hi Chris,

Many thanks, much appreciated!

I've committed this including the typo fix--thanks for pointing it out.


Kind 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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#675788: [buildd-tools-devel] Bug#675788: schroot: PulseAudio not working in a default desktop schroot

[Roger Leigh]

severity 675788 wishlist
tags 675788 + moreinfo wontfix
thanks

On Tue, Jun 05, 2012 at 10:16:15AM +0100, Roger Leigh wrote:
> On Sun, Jun 03, 2012 at 01:06:33PM +0200, Luca Capello wrote:
> > With the latest upgrade, /etc/schroot/desktop/fstab gained PulseAudio
> > support (BTW, there is an extra space before the target folder):
> > 
> > Mounting /run/dbus let paplay start, but there is no sound.  Mounting
> > /run/udev gives sound, exactly as explained at #649884 (affect added,
> > sorry for the being late).
> > 
> > So, basically, I would say that mounting /var/lib/dbus alone is useless.
> > Actually, I would even say that it is counter-productive, given that it
> > gives the false assumption that /var/lib/dbus/ is the only mounting
> > needed for PulseAudio, while it is not (I would be happy to stand
> > corrected).
> > 
> > Moreover, please also note that some applications (at least Empathy, see
> > #652487) does not work as expected with /var/lib/dbus/ mounted.
> 
> The desktop profile was user-contributed, and I don't use it myself
> other than trivial testing that it works for basic stuff.  If you
> could let me know what's needed, I'll be happy to update the profile.
> Note that if it's backward-compatible with earlier distributions, then
> that's even better.

In the absence of the needed information to make things work, I won't
be able to fix this bug.  Did you get this working at all?  If you have
an updated configuration to share that would be very useful.

Marking as moreinfo/wontfix for the time being, and reducing the
severity since desktop stuff inside schroot is not something we can
support well, unfortunately, and it's only got more complex and
fragile.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#764785: [buildd-tools-devel] Bug#764785: Bug#764785: schroot: setup script to copy apt archives from host to chroot

[Roger Leigh]

On Mon, Nov 24, 2014 at 11:00:03AM -0300, Felipe Sateler wrote:
> On Mon, Nov 24, 2014 at 10:50 AM, Roger Leigh  wrote:
> > On Sun, Nov 09, 2014 at 09:44:38PM -0300, Felipe Sateler wrote:
> >> On Sun, Nov 9, 2014 at 3:33 PM, Roger Leigh  wrote:
> >> > On Sat, Oct 11, 2014 at 12:24:38AM -0300, Felipe Sateler wrote:
> >> >> Package: schroot
> >> >> Version: 1.6.10-1+b1
> >> >> Severity: wishlist
> >> >> Tags: patch
> >> >>
> >> >> For systems without an apt proxy the local apt cache can be very useful
> >> >> to avoid downloading stuff multiple times. Thus I created a small
> >> >> script (attached) to copy the local apt cache contents into the chroot,
> >> >> and then copy them back to the host on stop. pbuilder does this as well.
> >> >>
> >> >> This probably shouldn't be enabled by default. So perhaps this could be
> >> >> shipped as a contrib script, or another variable added to
> >> >> /etc/default/schroot (I can update the script if required).
> >> >
> >> > I think this is perfect for a contrib script; thanks for sending it.
> >>
> >> :)
> >>
> >> >
> >> > One thing which might need correction: when it copies the files back
> >> > on setup-stop, it's not checking for glob failure before doing the
> >> > copy (which you do for setup-start).  Would it be possible to add this
> >> > additional check?
> >>
> >> Yes, indeed this causes problems when the cache is empty (for example
> >> after a sbuild-update -c). Attached is a version that only copies
> >> files when they exist.
> >
> > Great, thanks.
> >
> > Would it be OK for me to add a GPL3 copyright header to match the rest of
> > the project?
> 
> Yes, of course. I see the copyright file actually says GPLv3+, so that
> would be OK with me too.
> 
> In more general words, I submit the file with whatever license the
> project normally uses for such files.

Cool, thanks.  I always ask because I don't like to assume, and in the
past one person did actually refuse, so it keeps things clear and
unambiguous on all sides!


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#606415: [buildd-tools-devel] Bug#606415: Back to the Future II

[Roger Leigh]

On Thu, Apr 24, 2014 at 12:49:14AM -0700, Ivan Kohler wrote:
> So, in the fullness of (not even all that much) time...
> 
> It looks like the distro-info-data package now provides up-to-date
> information that could be used to generate the config file with correct
> release names (both before and after release).
> 
> Not that it is of particular severity (hence, minor, and perhaps should 
> be wishlist), but with the metainfo/chicken-and-egg problems solved in a 
> distribution-wide rather than schroot-specific fashion, perhaps we could 
> now keep this bug open?  It might pique someone's interest enough to 
> submit a good patch.  :)

I can certainly take a look when I have some spare time.  However, schroot
isn't Debian-specific so it's not something I'd like to have a hard
dependency upon.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#762597: [buildd-tools-devel] Bug#762597: /var/lib/schroot/mounts should be in /var/run for --one-file-system

[Roger Leigh]

On Tue, Sep 23, 2014 at 03:55:40PM +0100, Ian Jackson wrote:
> If you have a directory schroot chroot whose source directory is the
> same as /, schroot's bind mount in /var/lib/schroot/mounts is
> invisible to file tree walking tools.
> 
> That is, rsync --one-file-system (rsync -x), cp --one-file-system
> (cp -x), find -xdev, etc., do not notice the mount point, and
> typically traverse through it.
> 
> This is far from ideal.  Now arguably this is a bug in bind mounts
> (perhaps a design bug).  But as it happens it is easy to work around
> this problem in schroot in a way that is both correct and will fix
> almost all the problems:
> 
> Move /var/lib/schroot/mounts to /var/run/schroot/mounts or some such.
> 
> Typically /var/run is a tmpfs.  As a result there will be a filesystem
> with a different devid between / and the chroot.  So to all the file
> tree walkers, it will look like two mount points.  Backup tools,
> find, etc., will not descend into schroot's bind mount because they'll
> stop at /var/run.

Hmm, this is an interesting problem.  Your proposed solution would
certainly provide a boundary to stop traversal, but I'm not sure it
would help in all situations, since e.g. for file-based chroots we
unpack them under /var/lib/schroot.  Putting the mounts themselves
under /var/run should be safe enough though.

In recent years, I've put the chroot directories in btrfs subvolumes,
where the subvolumes have a separate devid, and had that as a
separate filesytem (don't trust it enough for the rootfs).  Currently
implementing support for ZFS snapshots.

I'll need to do some testing of this to make sure it doesn't
break anything.  If you have any further thoughts or ideas, please
do let me know!


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#764785: [buildd-tools-devel] Bug#764785: Bug#764785: schroot: setup script to copy apt archives from host to chroot

[Roger Leigh]

On Sun, Nov 09, 2014 at 09:44:38PM -0300, Felipe Sateler wrote:
> On Sun, Nov 9, 2014 at 3:33 PM, Roger Leigh  wrote:
> > On Sat, Oct 11, 2014 at 12:24:38AM -0300, Felipe Sateler wrote:
> >> Package: schroot
> >> Version: 1.6.10-1+b1
> >> Severity: wishlist
> >> Tags: patch
> >>
> >> For systems without an apt proxy the local apt cache can be very useful
> >> to avoid downloading stuff multiple times. Thus I created a small
> >> script (attached) to copy the local apt cache contents into the chroot,
> >> and then copy them back to the host on stop. pbuilder does this as well.
> >>
> >> This probably shouldn't be enabled by default. So perhaps this could be
> >> shipped as a contrib script, or another variable added to
> >> /etc/default/schroot (I can update the script if required).
> >
> > I think this is perfect for a contrib script; thanks for sending it.
> 
> :)
> 
> >
> > One thing which might need correction: when it copies the files back
> > on setup-stop, it's not checking for glob failure before doing the
> > copy (which you do for setup-start).  Would it be possible to add this
> > additional check?
> 
> Yes, indeed this causes problems when the cache is empty (for example
> after a sbuild-update -c). Attached is a version that only copies
> files when they exist.

Great, thanks.

Would it be OK for me to add a GPL3 copyright header to match the rest of
the project?


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#763896: [buildd-tools-devel] Bug#763896: schroot: infinite allocation on uid/gid entry errors.

[Roger Leigh]

tags 763896 + pending fixed-upstream
thanks

On Fri, Oct 03, 2014 at 11:19:22AM -0300, Daniel Serpell wrote:
> The attached patch fixes an infinite allocation loop inside the
> passwd::query_name, passwd::query_uid, group::query_gid and
> group::query_name functions.
> 
> Current code simply fails with std::bad_alloc on any error,
> because it always retries with a bigger buffer.

Applied to git on the 1.6 and master branch:

https://github.com/rleigh-codelibre/schroot/commit/83bc6d3f99b1aa04a4864faeeb867ed09bae8e55
https://github.com/rleigh-codelibre/schroot/commit/76a85f0fb34d39f796185d296fadde81b79a3948


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#764785: [buildd-tools-devel] Bug#764785: schroot: setup script to copy apt archives from host to chroot

[Roger Leigh]

On Sat, Oct 11, 2014 at 12:24:38AM -0300, Felipe Sateler wrote:
> Package: schroot
> Version: 1.6.10-1+b1
> Severity: wishlist
> Tags: patch
> 
> For systems without an apt proxy the local apt cache can be very useful
> to avoid downloading stuff multiple times. Thus I created a small
> script (attached) to copy the local apt cache contents into the chroot,
> and then copy them back to the host on stop. pbuilder does this as well.
> 
> This probably shouldn't be enabled by default. So perhaps this could be
> shipped as a contrib script, or another variable added to
> /etc/default/schroot (I can update the script if required).

I think this is perfect for a contrib script; thanks for sending it.

One thing which might need correction: when it copies the files back
on setup-stop, it's not checking for glob failure before doing the
copy (which you do for setup-start).  Would it be possible to add this
additional check?


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#765886: [buildd-tools-devel] Bug#765886: sbuild: [PATCH] Replaced all unicode-printed chars with plain ASCII

[Roger Leigh]

tags 765886 - patch
thanks

On Sat, Oct 18, 2014 at 03:56:35PM -0700, Dima Kogan wrote:
> Sbuild likes to print out unicode characters, which improves the process
> very little, but is extremely annoying when it fails (when running on a
> non-unicode terminal, say). This patch replaces the unicode with ascii.

It's 2014; we've been using unicode by default for over a decade.  If your
terminal doesn't support UTF-8 input, it's in need for replacement.  Part
of the reason for doing this in sbuild was to enforce UTF-8 cleanliness
in sbuild, and tools processing the logs.

That said, we could certainly revert to ASCII for non-UTF-8 locales.  I
think your patch is too heavy-handed--it reverts to ASCII unconditionally.
However, if you make it conditional on "nl_langinfo(CODESET) != UTF8" this
will degrade gracefully for non-UTF-8 locales if you have a supplementary
non-Unicode set of formatting characters to substitute.  This should be
wrapped by POSIX.pm.  If you'd like to make this change, I'll be happy to
review and apply 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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768091: [buildd-tools-devel] Bug#768091: schroot: please support alternative compressions for file-based chroots

[Roger Leigh]

On Tue, Nov 04, 2014 at 10:51:12PM +0100, Aurelien Jarno wrote:
> schroot currently supports the gzip and bzip2 compressions for file-based
> chroots. It might be worth to support alternative compressions to let
> the user do a compromise between speed and space, depending for example
> if the chroot is used often or not.
> 
> The patch below adds support for xz, lzop and lz4 compression, which
> should cover most of the standard compression format available today.
> Could you please apply it in one of the next uploads? Thanks.

Thanks for the patch.  It looks fine except for the lz4 case, which
uses GNU tar-specific options and hardcodes the path to lz4 which is
nonportable, and it also lacks an update to the docs in
man/schroot.conf.5.man ("optionally compressed with...").

If you could fix it to use lz4 portably (I'd suggest piping) so it
works with BSD tar, and also fix up the docs, I'll be happy to apply
this.


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-dist-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-dist-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 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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#696632: initramfs-tools: Patches to clean up /run handling for jessie

[Roger Leigh]

On Sat, Sep 27, 2014 at 08:11:42PM +0100, Ben Hutchings wrote:
> On Wed, 11 Sep 2013 18:29:53 +0200 maximilian attems  wrote:
> > On Mon, 24 Dec 2012, Roger Leigh wrote:
> > 
> > > 1) Migration of /run to the rootfs is mandatory, i.e. /run is required to
> > >be present on the rootfs.  This will be the case for all jessie 
> > > installs
> > >and upgrades (unlike wheezy, which needed the special-case logic to
> > >manually migrate udev/mdadm state).
> 
> I'm not sure I understand this.  Are you saying all wheezy installations
> have /run on the root filesystem, so we can assume this in packages
> targetted at jessie and wheezy-backports?

Yes.  It was intended that /run be added in the etch->wheezy upgrade
and that packages which required it would use a conditional dependency
on initscripts.  For wheezy->jessie it's fully supported by all init
systems, and packages no longer need to have a dependency on initscripts
since it will be guaranteed to be present.  This is also in Debian
Policy now IIRC.

For both jessie and wheezy-backports, /run is guaranteed to be present.

> > While I agree on the patch himself, I don't see an urge for that.
> > There is no real cost in keeping that for now and axing once Jessie is
> > released. I like to keep one interval inbetween as it helps users..
> > (I know it is broken to often, but here there is no argument for the
> > rush).
> [...] 
> > As I said happy about that patch, but unlikely for now, so ok
> > for a downgrade to wishlist for the moment beeing?
> 

I assume this is directed to Max?  Not sure myself--all the necessary
stuff outside initramfs-tools has been present since wheezy TTBOMK.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761435: [buildd-tools-devel] Bug#761435: schroot: Nothing is mounted inside the chroot

[Roger Leigh]

On Sat, Sep 13, 2014 at 02:01:06PM -0700, Ben Longbons wrote:
> 
> I don't use schroot very often, and I recently noticed that when I use
> it, the inner system is missing all its mounts. In particular, there is
> nothing mounted on /proc or /dev/pts, but there is a private /tmp/ that
> is persistent even after schroot exits.
> 
> Upgrading to the version in experimental does NOT help.
> 
> I do use systemd, and I don't think I've successfully used schroot since
> I switched.

What do you mean by "inner system" here?

I would suggest running with the "-v" options to make schroot display all
the mount/umount operations as well as all the other setup and cleanup
work.  Do you see anything missing or failing?  All the setup/cleanup is
done via the setup scripts in /etc/schroot/setup.d, so it should be
possible to add additional diagnostics to the scripts to see what's
going wrong.

You can also run with "--debug=notice", which will give even more details
about the schroot internals, but I'm not sure in this case it will reveal
much of interest; I'd recommend "-v" though.

I have not tried schroot on systemd though I think other people have had
success since a few patches were submitted and applied for e.g. mount
namespaces.  In general these are to make schroot work around things
systemd has broken and/or arbitrarily changed which break us.  It's
entirely possible the systemd people broke even more basic system
functionality in the meantime.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#652459: initramfs-tools: [patch] Please support mounting of /usr in the initramfs

[Roger Leigh]

On Sun, Aug 31, 2014 at 12:13:29AM +0200, Michael Prokop wrote:
> Hi everyone,
> 
> (if you don't want to get Cc-ed any longer please let me know, just
> trying to involve everyone and get some traction)
> 
> * Michael Prokop [Thu Jul 31, 2014 at 05:30:53PM +0200]:
> > * Matthew Gabeler-Lee [Thu Jul 31, 2014 at 10:29:18AM -0400]:
> 
> > > Recent package upgrades have made it all but impossible for a Debian
> > > install supporting a graphical desktop environment not to use
> > > systemd. This quietly caused a system of mine to get switched from
> > > sysvinit to systemd, and thus no longer boot properly because of this
> > > issue (among others, but this isn't the place for that rant).
> 
> > > Can we _pretty please_ get versions of the affected packages at least
> > > uploaded to experimental?  I will add my voice to those volunteering
> > > to help test.
> 
> > I've rebased the patchset against current git master and a
> > preliminary and *untested*(!) package is available at:
> 
> >   https://people.debian.org/~mika/initramfs-tools/
> 
> > Feedback definitely welcome and required.
> 
> > maks, are you willing to accept the patchset once
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459#47 has been
> > addressed?
> 
> Maks, sadly still no reply from your side yet :(
> 
> > Is anyone else willing to help us in getting this issue resolved?
> 
> If we want to see this issue resolved for jessie we need to get this
> forward soonish. So is there anyone else who has tested my package
> and can confirm that the issue is resolved by it?
> 
> Michael Biebl, you also wrote:
> 
> | Agreed. The actual patch to mount /usr is rather small. The one for
> | mounting /etc complicates things quite a bit. Please let's not
> | entangle the two and just upload the bits for mounting /usr. If
> | there is later demand for the /etc-mount feature, it can be added
> | then.
> 
> This sounds good to me, is there any chance that either you, Roger
> Leigh or someone else would be willing to provide the according
> patchset (without the /etc-mount feature) rebased against our
> current git master and possibly while at it also take care of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459#89 ?
> If so please ping me (either by mail, IRC or at DebConf), any help
> is really appreciated.

I'm afraid I can't commit to any work at present.  But regarding
the mounting of /etc, that's just one or two commits at the end
of the patchset.  Just drop them to remove the feature.  But do
note that the feature is entirely harmless even if left in--it's
not used by default.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#759393: [buildd-tools-devel] Bug#759393: /etc/init.d/schroot: Switch Should-Start from lvm to lvm2

[Roger Leigh]

On Wed, Aug 27, 2014 at 01:00:00AM +0200, Laurent Bigonville wrote:
> /etc/init.d/schroot is currently declaring a "Should-Start" dependency
> against lvm. The initscript has been renamed to lvm2 for quite sometimes
> I guess (but still provides both lvm and lvm2)

OK.  In that case this isn't a bug, but a wishlist item.  If it's
providing "lvm" then there isn't really a problem here; it's
behaving backward-compatibly as designed.

> But a problem occurs with systemd, the lvm2 package is only adding the
> necessary symlink to mask the lvm2 LSB initscript. This makes think that
> the lvm unit/initscript is missing.

This is a bug in systemd which may affect many more packages since
alternate Provides are not exactly uncommon.  Is there a bug open
for this?

> The relation should probably be changed from lvm to lvm2

This is certainly true, and I'll look at doing this in due course.


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-dist-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-dist-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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#757083: [Pkg-sysvinit-devel] Bug#757083: initscripts: please treat /usr (if separate) the same as /

[Roger Leigh]

On Fri, Aug 08, 2014 at 01:30:05PM +0100, Simon McVittie wrote:
> On 08/08/14 12:53, Henrique de Moraes Holschuh wrote:
> > On Tue, 05 Aug 2014, Simon McVittie wrote:
> > /usr as a separate partition *and* no initramfs to mount it early is
> > [unfortunately] a really bad idea on jessie/sid, we don't have to add
> > support for that outside of the initramfs (but warning the user of the
> > problem is likely to be a good idea).
> 
> Indeed. With that in mind, I'm still not quite sure why initscripts
> would need to fsck /usr any earlier than it does now.

It needs to be treated as though it were the rootfs, which means
fscking it in checkroot and making it read-write at that point.
I'm afraid I've forgotten the specifics, IIRC there were some
fundamental reasons for it to handle various scenarios.

> Was that perhaps rleigh attempting to provide best-effort support for
> the deprecated cases MU-- and IU-- (separate /usr with either a
> monolithic kernel, or an initramfs where #652459 has not been fixed) by
> mounting /usr as soon as possible in ordinary userland, so that only the
> critical path from entry-to-userland to checkfs.sh needs to care about
> whether /usr is separate, allowing the rest of rcS to assume that /usr
> is mounted?

I don't think we specifically cater for separate /usr without an
initramfs, but neither do we intentionally break it.  Until we have
packages which require files from /usr in early boot, it should
continue to work with a big fat warning added.  We definitely
explicitly support booting w/o initramfs for Linux and non-Linux
kernels.  Some of the logic is likely for non-Linux.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751733: [buildd-tools-devel] Bug#751733: --location does not work with session names

[Roger Leigh]

On Mon, Jun 16, 2014 at 06:46:20AM +0200, Martin Pitt wrote:
> Package: schroot
> Version: 1.6.10-1
> 
> Hello,
> 
> I'm trying to find out the chroot directory of a particular session
> (for autopkgtest's schroot runner, FTR), but this doesn't work:
> 
> | $ schroot -b -c sid
> | sid-amd64-327bb347-fe31-4c6d-9e36-a90ae70c4fa2
> |
> | $ schroot --location -n sid-amd64-327bb347-fe31-4c6d-9e36-a90ae70c4fa2
> | E: --session-name is not permitted for the specified action
> | I: Run “schroot --help” to list usage example and all available options
> |
> | $ schroot --location -c sid-amd64-327bb347-fe31-4c6d-9e36-a90ae70c4fa2
> | E: sid-amd64-327bb347-fe31-4c6d-9e36-a90ae70c4fa2: Chroot not found

Might be a namespace issue.  Does adding a "session:" prefix help?
It might be defaulting to a "chroot:" prefix for this command, in
which case it can't find a session ID since it's not under that
prefix.

> As a workaround I'm using --all-sessions and grep for the line with
> the session ID, but that's a bit cumbersome:
> 
> | $ schroot --location --all-sessions
> | /var/lib/schroot/mount/sid-amd64-327bb347-fe31-4c6d-9e36-a90ae70c4fa2
> 
> This happens with both type=directory and an union-type, as well as
> with type=file.

I think we can improve this.  Historically, this option only
existed for compatibility with dchroot.  However, the existing
behaviour is suboptimal.  It only really makes sense for it to
work with one chroot at a time since the output makes little
sense otherwise.  And it only really makes sense for sessions
since there might not even be a location for some chroot
types (snapshots, block devices, loopback mounts etc.)

I'd suggest:
- making it work with a mandatory --chroot=$name parameter
- defaulting the prefix to session (for the -c arg above)
- maybe remove support for working with non-session
  prefixes entirely.  This doesn't work consistently with
  chroot/source prefixes, but it does work with sessions
  (both from chroots and source chroots).

Due to the behaviour break, I'm reluctant to change it for
1.6.x, but for 1.7.x it's a reasonable break for a new
major release.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#688325: [buildd-tools-devel] Bug#688325: Bug#688325: [schroot] I can't mount usb key with schroot

[Roger Leigh]

On Sun, Sep 23, 2012 at 09:47:44AM +0200, Guy Roussin wrote:
> >> I can not mount a USB key under /media because
> >> they belong to root.
> >>
> >> How can i achieve this ?
> > 
> > The same way as you would on the host system, especially since the
> > files under /dev/ are bind mounted from the host.  This is not, I
> > think, something that schroot itself should cater for.  Tools like
> > pmount and more recent tools used by common desktop environments
> > for mounting removable media should work inside the chroot as well;
> > particuarly when using the "desktop" profile.  If there's anything
> > we can add to that profile to make desktop removable media
> > support work better, then we can certainly look at adding that.
> > 
> > 
> > Regards,
> > Roger
> > 
> Thank you Roger,
> But this is what i get with pmount (i use the desktop profile) :
> 
> guy@pcplat53:~$ pmount /dev/sdb1
> guy@pcplat53:~$ pumount /dev/sdb1
> guy@pcplat53:~$ schroot -c precise
> (precise)guy@pcplat53:~$ pmount /dev/sdb1
> Error: could not open fstab-type file: No such file or directory
> (precise)guy@pcplat53:~$
> 
> This is ok with the host but not with the schroot

Sorry for the long delay.  Did you ever find a solution to this problem?

Which file can't be opened?  (strace as root inside the chroot might
help.)

I suspect pmount needs something extra bind mounting into the chroot
to work, but I'm not sure what that would be or where it lives.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#728096: [buildd-tools-devel] Bug#728096: schroot fails if shm tmpfs is mounted on /dev/shm

[Roger Leigh]

On Mon, Nov 25, 2013 at 04:49:45PM +0100, Laurent Bigonville wrote:
> Hi,
> 
> To be even more clear:
> 
> HOST:
> bigon@soldur:~$ ls -ld /dev/shm /run/shm
> ls: impossible d'accéder à /run/shm: Aucun fichier ou dossier de ce type
> drwxrwxrwt. 2 root root 300 nov 25 16:05 /dev/shm
> 
> CHROOT:
> (sid-amd64-sbuild)root@soldur:/# ls -ld /dev/shm /run/shm
> lrwxrwxrwx. 1 root root8 Nov 23  2012 /dev/shm -> /run/shm
> drwxr-xr-x. 2 root root 4096 Nov 23  2012 /run/shm
> 
> Creating /run/shm on the host is also fixing this.

Sorry for the delayed reply; RSI has been limiting my activity for some
time.

> Is it possible that schroot is actually trying to resolve the /dev/shm
> -> /run/shm symlink outside of the chroot?

It's possible, but unlikely.  The schroot-mount helper should ensure that
all mountpoints are inside the chroot and that it's not a symlink which
could redirect to a mountpoint outside.  That condition should be fatal.

Simply removing the /dev/shm link inside the chroot and making it a
directory should make things work.

Note that the "-v" option will make schroot log all mount operations
during session creation, and umount operations during cleanup.  I'd
recommend running with this to debug what's going on.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749960: [buildd-tools-devel] Bug#749960: schroot: please support a proot type of chroot

[Roger Leigh]

tags 749960 + moreinfo
thanks

On Sat, May 31, 2014 at 10:31:54AM +0800, Paul Wise wrote:
> Source: schroot
> Severity: wishlist
> 
> Please add support for proot in schroot, it uses ptrace to emulate
> chroots, which means that users who don't have any root access can
> create and enter chroots. As a result schroot wouldn't have to become
> root to create these chroots. Here is the package description:

This certainly looks very interesting.  However, we do need root
for a number of things in addition to what proot provides.
It could certainly work for the very simple case, but would not
be able to support any user switching, PAM auth, filesystem
mounting, union overlays, lvm snapshotting etc., so you'd lose
the greater part of all the features of schroot.

I'm afraid I won't have time to dedicate to this, but I'd certainly
be open to proposed patches or just general detail on how it might
be implemented.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749897: [buildd-tools-devel] Bug#749897: schroot: Can't end session after schroot automatically restored it during boot under systemd

[Roger Leigh]

tags 749897 + moreinfo

On Fri, May 30, 2014 at 10:07:24PM +0900, Mike Hommey wrote:
> So, I had three schroot sessions active and at some point, there was a reboot
> involved. I don't remember if it was a hard reboot or a soft reboot, because
> it was actually a while ago, but it doesn't matter anyways.
> 
> So, after a while, i figured that it made no sense to keep all those schroot
> mount points around, so I asked schroot to end the three sessions. Which it
> happily did, until it stopped on a EBUSY error while rmdir'ing the root
> mount point in /var/lib/schroot/mount/.
> 
> As far as I can tell, the reason why this happens is that the user session
> does the schroot -e runs in a mount namespace that is not the global mount
> namespace, thanks to systemd. And the schroot restore script at boot most
> likely runs in the global mount namespace. So, when schroot -e does its stuff,
> all it's doing is unmounting the bind mounts in the user namespace, but those
> bind mounts are still active in the global mount namespace. Then rmdir fails
> because of that.
> 
> Rebooting without systemd allowed schroot -e to do its job properly.

Great.  Another utterly simple thing that worked for a decade broken :(

Does it work if you run "schroot --recover-session -c $session" inside
a user session?  (with recovery at startup disabled).  Does it work if
logged in as root outside a user session?

Not being an expert, I'd be happy to hear any suggestions.  Sounds like
the ideal solution (if possible) would be to force all schroot mount/umount
etc. operations to be performed in the global namespace outside the user
session.  Is that possible?

We do need to support:
- transient sessions created for a single task e.g. build
- sessions which last for a whole "user session" e.g. for virtualising
  a piece of desktop software e.g. 32-bit chroot on 64-bit
- long lived sessions which persist over a long duration (across
  login sessions and reboots)

If that's not possible, maybe we just disable the initscript so that
session recovery doesn't occur under systemd?  Can we retain cleanup
of sessions on shutdown?  This idea won't be tenable if manual
recovery doesn't work.

Given that schroot is setuid, it looks like setuid programs are still
"inside" the user session (whatever that actually is concretely
defined as, since the documentation and "specification" (I use the
word in its loosest possible sense) are extremely poor and
incomplete).

I can't personally going to spend any time on this since I'm not using
systemd and don't plan to, but I would certainly appreciate any
suggestions or patches from anyone who understands exactly what systemd
broke and how it should be fixed, so long as it doesn't compromise
schroot's portability to other platforms.


Kind 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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#727712: [buildd-tools-devel] Bug#727712: Supplementary groups taken from the host system instead of the chroot

[Roger Leigh]

tags 727712 + wishlist
thanks

On Fri, Oct 25, 2013 at 06:22:55PM +0200, Gaudenz Steinlin wrote:
> Supplememntary groups are initilized with initgroups before switching to
> the chroot. This means that groups are initialize according to the group
> database on the host system instead of the chroot. But groups should be
> initialized according to the group database inside the chroot.

They probably should be, but they can't.  At least, they can't at
present, and unless a proper solution to the problem can be found,
they won't be for the forseeable future.

The rationale:
We can't do *any* system database lookups which use NSS after the
chroot() call.  It's not safe.  We can't risk
- using cached data
- triggering an NSS module load in the chroot

If we trigger a module load:
- it might be from an incompatible glibc version
- it might be from a different architecture (we support different
  architectures inside the chroot via qemu-user-static)
- the chroot might be from a completely different operating system
  (we support kernel personality switching) without any NSS support
- we may have dropped privs which allow lookups to work or disabled
  networking entirely which would break LDAP
- schroot works on several non-Linux non-glibc platforms; what would
  happen on these?

As a result, we took the decision to always do *all* NSS lookups
outside the chroot, and copy in the NSS databases to guarantee
consistency.  It's suboptimal, but it's safe under almost all
circumstances.  I'm certainly sympathetic to the fact that this
isn't ideal, and I'd be open to change the behaviour for 1.7.x, but
we do need a means of making this stuff work portably and reliably
without causing program crashes or security problems if NSS
screws up.

> The attached patch moves the group initialization after the chroot call.
> It is done against 1.6.5, but should also apply to 1.7.1 modulo the
> changed file location.

Thanks for taking the time to make the patch, but I can't apply it at
this time.

> But #685512 is a related but orthogonal problem. It might make sense to
> also move the pam initialization to after the chroot call to use the pam
> configuration inside the chroot. Otherwise setting groups with
> pam_groups won't because they get overwritten by initgroups (as it's the
> case right now as far as I understand the code). But setting groups with
> pam_groups seems like a corner case to me.

We have the same deal with PAM as well.  In fact, it's often worse
since these can invoke anything and trigger loading of all sorts of
additional libraries.  Given the architecture/personality mismatching,
this just can't work in a reliable manner.  This has caused some
complaints in the past for similar reasons to NSS, but the underlying
rationale is pretty much the same.

As for NSS, I'd be open to changing things if there was a clear
solution to the problems.


Kind 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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#718127: [buildd-tools-devel] Bug#718127: Bug#718127: Bug#718127: schroot: CHROOT_SESSION_PURGE and tar-based source chroots

[Roger Leigh]

On Tue, Jul 15, 2014 at 04:13:55PM +0200, Aurelien Jarno wrote:
> Hi,
> 
> On Mon, Jul 14, 2014 at 11:43:50PM +0100, Roger Leigh wrote:
> > tags 718127 + patch pending
> > thanks
> > 
> > On Sun, Jul 13, 2014 at 10:49:46PM +0100, Roger Leigh wrote:
> > > On Thu, Jul 10, 2014 at 10:36:28PM +0100, Roger Leigh wrote:
> > > > To implement this, we need session and source facets to have a
> > > > pointer to the parent chroot.  So we query a session chroot
> > > > and ask if its parent was a source chroot, and also link from
> > > > a source chroot to plain chroot for generality and
> > > > completeness.  Initial scoping for 1.7 (1.6 will be backported):
> > > > 
> > > > - chroot to inherit enable_shared_from_this and/or switch to
> > > >   using weak_ptr rather than bare pointers for the facet->chroot
> > > >   back reference
> > > > - session and source need "shared_ptr parent" fields
> > > > - session::create and source::create constructors to take a
> > > >   "shared_ptr parent" argument.  This will be passed by
> > > >   session_clonable::clone_session and source_clonable::clone_source,
> > > >   respectively
> > > > - session can check for the presence of a source facet in its
> > > >   parent and set SESSION_SOURCE if parent is not null and the
> > > >   facet is present.
> > > > - chroot will set CHROOT_SESSION_SOURCE=true if the SESSION_SOURCE
> > > >   flag is set, otherwise set to false.
> > > 
> > > Initial implementation here:
> > > 
> > > http://anonscm.debian.org/gitweb/?p=users/rleigh/schroot.git;a=shortlog;h=refs/heads/source-env
> > > 
> > > (last three commits).  Works as above.
> > > Now needs backporting to 1.6.
> > 
> > Now rewritten for 1.6.  I'd very much appreciate it if you could
> > try rebuilding 1.6.10 with these patches applied, and let me know
> > if it's doing what you want.  Run with -v to see the value of
> > CHROOT_SESSION_SOURCE for source and non-source chroots.
> > 
> > http://anonscm.debian.org/gitweb/?p=users/rleigh/schroot.git;a=shortlog;h=refs/heads/source-env-1.6
> 
> Thanks a lot for the quick patches. I have tried them on both 1.6.10 and
> 1.6.4 (with minor adjustement) as it's the version in wheezy currently 
> used on the buildds. I have tested them with directory-, tar- and
> lvm-based chroots, and they behave as expected. Thanks!

Many thanks for testing.  I'll make new 1.6 release soon; it needs a few
translation updates as well.  I'll put it in backports as well; can you
make use of these on the buildds?  If you use your own builds, feel free
to just use the patches as-is.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#718127: [buildd-tools-devel] Bug#718127: Bug#718127: Bug#718127: schroot: CHROOT_SESSION_PURGE and tar-based source chroots

[Roger Leigh]

tags 718127 + patch pending
thanks

On Sun, Jul 13, 2014 at 10:49:46PM +0100, Roger Leigh wrote:
> On Thu, Jul 10, 2014 at 10:36:28PM +0100, Roger Leigh wrote:
> > To implement this, we need session and source facets to have a
> > pointer to the parent chroot.  So we query a session chroot
> > and ask if its parent was a source chroot, and also link from
> > a source chroot to plain chroot for generality and
> > completeness.  Initial scoping for 1.7 (1.6 will be backported):
> > 
> > - chroot to inherit enable_shared_from_this and/or switch to
> >   using weak_ptr rather than bare pointers for the facet->chroot
> >   back reference
> > - session and source need "shared_ptr parent" fields
> > - session::create and source::create constructors to take a
> >   "shared_ptr parent" argument.  This will be passed by
> >   session_clonable::clone_session and source_clonable::clone_source,
> >   respectively
> > - session can check for the presence of a source facet in its
> >   parent and set SESSION_SOURCE if parent is not null and the
> >   facet is present.
> > - chroot will set CHROOT_SESSION_SOURCE=true if the SESSION_SOURCE
> >   flag is set, otherwise set to false.
> 
> Initial implementation here:
> 
> http://anonscm.debian.org/gitweb/?p=users/rleigh/schroot.git;a=shortlog;h=refs/heads/source-env
> 
> (last three commits).  Works as above.
> Now needs backporting to 1.6.

Now rewritten for 1.6.  I'd very much appreciate it if you could
try rebuilding 1.6.10 with these patches applied, and let me know
if it's doing what you want.  Run with -v to see the value of
CHROOT_SESSION_SOURCE for source and non-source chroots.

http://anonscm.debian.org/gitweb/?p=users/rleigh/schroot.git;a=shortlog;h=refs/heads/source-env-1.6

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 60175439a842d2bc96c56986409fbf1c2ad4acce Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Mon, 14 Jul 2014 21:17:37 +0100
Subject: [PATCH 1/3] sbuild::chroot::chroot: Inherit from
 enable_shared_from_this

---
 sbuild/sbuild-chroot.cc  | 2 ++
 sbuild/sbuild-chroot.h   | 2 +-
 sbuild/sbuild-tr1types.h | 2 ++
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/sbuild/sbuild-chroot.cc b/sbuild/sbuild-chroot.cc
index 6ec7088..e808551 100644
--- a/sbuild/sbuild-chroot.cc
+++ b/sbuild/sbuild-chroot.cc
@@ -105,6 +105,7 @@ error::error_strings
  init_errors + (sizeof(init_errors) / sizeof(init_errors[0])));
 
 sbuild::chroot::chroot ():
+  std::enable_shared_from_this(),
   name(),
   description(),
   users(),
@@ -132,6 +133,7 @@ sbuild::chroot::chroot ():
 }
 
 sbuild::chroot::chroot (const chroot& rhs):
+  std::enable_shared_from_this(),
   name(rhs.name),
   description(rhs.description),
   users(rhs.users),
diff --git a/sbuild/sbuild-chroot.h b/sbuild/sbuild-chroot.h
index e3f1cf7..98ed958 100644
--- a/sbuild/sbuild-chroot.h
+++ b/sbuild/sbuild-chroot.h
@@ -42,7 +42,7 @@ namespace sbuild
* configuration file, and may be initialised directly from an open
* keyfile.
*/
-  class chroot
+  class chroot : public std::enable_shared_from_this
   {
   public:
 /// Type of setup to perform.
diff --git a/sbuild/sbuild-tr1types.h b/sbuild/sbuild-tr1types.h
index 2739a50..a3b3191 100644
--- a/sbuild/sbuild-tr1types.h
+++ b/sbuild/sbuild-tr1types.h
@@ -39,6 +39,7 @@ namespace std {
 using std::tr1::static_pointer_cast;
 using std::tr1::const_pointer_cast;
 using std::tr1::dynamic_pointer_cast;
+using std::tr1::enable_shared_from_this;
 }
 # elif HAVE_BOOST_SHARED_PTR_HPP
 #  include 
@@ -48,6 +49,7 @@ namespace std {
 using boost::static_pointer_cast;
 using boost::const_pointer_cast;
 using boost::dynamic_pointer_cast;
+using boost::enable_shared_from_this;
 }
 # else
 #  error A shared_ptr implementation is not available
-- 
2.0.1

>From 7608267215790c1d7459c50773667f15785a942d Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Mon, 14 Jul 2014 22:22:28 +0100
Subject: [PATCH 2/3] sbuild::chroot: Add SESSION_SOURCE and
 CHROOT_SESSION_SOURCE

- add new SESSION_SOURCE session flag
- store session parent chroot in session facet when cloning
  a session
- set CHROOT_SESSION_SOURCE in setup environment if the
  session parent chroot had a source facet
---
 sbuild/sbuild-chroot-facet-session-clonable.cc |  2 +-
 sbuild/sbuild-chroot-facet-session.cc  | 28 -
 sbuild/sbuild-chroot-facet-session.h   | 29 --
 sbuild/sbuild-chroot.cc|  2 ++
 sbuild/sbuild-chroot.h |  3 ++-
 test/sbuild-

Bug#718127: [buildd-tools-devel] Bug#718127: Bug#718127: schroot: CHROOT_SESSION_PURGE and tar-based source chroots

[Roger Leigh]

On Thu, Jul 10, 2014 at 10:36:28PM +0100, Roger Leigh wrote:
> To implement this, we need session and source facets to have a
> pointer to the parent chroot.  So we query a session chroot
> and ask if its parent was a source chroot, and also link from
> a source chroot to plain chroot for generality and
> completeness.  Initial scoping for 1.7 (1.6 will be backported):
> 
> - chroot to inherit enable_shared_from_this and/or switch to
>   using weak_ptr rather than bare pointers for the facet->chroot
>   back reference
> - session and source need "shared_ptr parent" fields
> - session::create and source::create constructors to take a
>   "shared_ptr parent" argument.  This will be passed by
>   session_clonable::clone_session and source_clonable::clone_source,
>   respectively
> - session can check for the presence of a source facet in its
>   parent and set SESSION_SOURCE if parent is not null and the
>   facet is present.
> - chroot will set CHROOT_SESSION_SOURCE=true if the SESSION_SOURCE
>   flag is set, otherwise set to false.

Initial implementation here:

http://anonscm.debian.org/gitweb/?p=users/rleigh/schroot.git;a=shortlog;h=refs/heads/source-env

(last three commits).  Works as above.


Now needs backporting to 1.6.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#718127: [buildd-tools-devel] Bug#718127: schroot: CHROOT_SESSION_PURGE and tar-based source chroots

[Roger Leigh]

On Thu, Jul 10, 2014 at 11:03:38PM +0200, Aurelien Jarno wrote:
> On Thu, Jul 10, 2014 at 09:07:57PM +0100, Roger Leigh wrote:
> 
> > I think the correct solution will be to add a
> > 
> >   CHROOT_SESSION_SOURCE=true|false
> > 
> > setup environment variable, with corresponding
> > 
> >   SESSION_SOURCE  = 1 << 3  ///< The chroot is a source chroot.
> > 
> > setup flag to be set by the chroot facets.  The reason for this is that
> > SESSION_PURGE is indicating that the session will be purged, and
> > nothing more than that.  It does not make any implied statement about
> > whether or not it's a source chroot or not.  For most chroot types,
> > this is only set for non-source chroots since it uses a different
> > chroot type for the source chroot, but this isn't the case for file
> > chroots where both the source and non-source chroots are both
> > purged.  I'd rather not overload this flag with unwarranted meaning,
> > so I think adding an additional flag is the way to go here.
> > 
> 
> That's looks quite reasonable to me.

To implement this, we need session and source facets to have a
pointer to the parent chroot.  So we query a session chroot
and ask if its parent was a source chroot, and also link from
a source chroot to plain chroot for generality and
completeness.  Initial scoping for 1.7 (1.6 will be backported):

- chroot to inherit enable_shared_from_this and/or switch to
  using weak_ptr rather than bare pointers for the facet->chroot
  back reference
- session and source need "shared_ptr parent" fields
- session::create and source::create constructors to take a
  "shared_ptr parent" argument.  This will be passed by
  session_clonable::clone_session and source_clonable::clone_source,
  respectively
- session can check for the presence of a source facet in its
  parent and set SESSION_SOURCE if parent is not null and the
  facet is present.
- chroot will set CHROOT_SESSION_SOURCE=true if the SESSION_SOURCE
  flag is set, otherwise set to false.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#718127: schroot: CHROOT_SESSION_PURGE and tar-based source chroots

[Roger Leigh]

On Wed, Jul 09, 2014 at 10:15:19PM +0200, Aurelien Jarno wrote:
> On Sun, Jul 28, 2013 at 09:52:22AM +0100, Roger Leigh wrote:
> > Package: schroot
> > Version: 1.7.0-1
> > Severity: normal
> > 
> > Check if CHROOT_SESSION_PURGE is being set for file source chroots.
> > If it is, should this be changed?
> > 
> > We are purging the chroot.  But if we're repacking, then we are
> > preserving its state.
> > 
> > We should have an additional environment variable so that setup
> > scripts can determine if they are working with a source chroot.
> 
> Indeed this buildds are using this variable to determine if the current
> chroot is a source chroot or not. Since we switched to tar based chroots
> instead of lvm one, this variable is always defined. This has broken at
> least one security update on some buildds.

What was the reason for the breakage?  Is this an issue with schroot
itself, or the assumptions being made in the 99builddsourceslist
script?  Could you provide some more detail please?  I didn't fully
see how the details you provided related to this.

> I therefore think we should get this fixed asap, either by not setting
> this variable for source tar based chroots, or by providing a new
> variable. In the meantime, is there another (even complex) way to know
> if a chroot is a source one or not?

As a really hacky temporary workaround, check for "(source chroot)"
in CHROOT_DESCRIPTION.  This will not be changed for 1.6.x, but it's
obviously not something to rely on long term since it's purely a
text string.  And it's also localised so will vary depending on the
locale, so will only be reliable for the C locale.  And there's
nothing stopping this being in the initial description so it might
cause false positives.

I think the correct solution will be to add a

  CHROOT_SESSION_SOURCE=true|false

setup environment variable, with corresponding

  SESSION_SOURCE  = 1 << 3  ///< The chroot is a source chroot.

setup flag to be set by the chroot facets.  The reason for this is that
SESSION_PURGE is indicating that the session will be purged, and
nothing more than that.  It does not make any implied statement about
whether or not it's a source chroot or not.  For most chroot types,
this is only set for non-source chroots since it uses a different
chroot type for the source chroot, but this isn't the case for file
chroots where both the source and non-source chroots are both
purged.  I'd rather not overload this flag with unwarranted meaning,
so I think adding an additional flag is the way to go 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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751732: [buildd-tools-devel] Bug#751732: Bug#751732: sbuild-createchroot: No overlay configured by default

[Roger Leigh]

On Mon, Jun 16, 2014 at 09:02:10AM +0100, Wookey wrote:
> +++ Martin Pitt [2014-06-16 06:40 +0200]:
> > Package: sbuild
> > Version: 0.64.1-1
> > 
> > Hello,
> > 
> > When calling sbuild-createchroot like shown in the manpage example:
> > 
> >   sudo sbuild-createchroot jessie /tmp/jessie 
> > http://ftp.de.debian.org/debian/
> 
> > I. e. this uses type=directory without *any* overlay,
> > 
> > I'd say this is a fairly unexpected and even misleading default
> > configuration. IMHO it should set up a proper union-type, or if that's
> > somehow not appropriate (e. g. if not all Debian kernel support aufs),
> > rather default to type=tarball.
> 
> I don't think it's 'unexpected' for a chroot-creation tool to just
> make a plain chroot by default. That certainly what I always
> expected. However in the context of building packages, which is really
> sbuild's main purpose, a clean chroot for repeatable builds is such a
> good idea that I agree it should be the default. Or at the very least
> that the manpage example shows the tarball case (which is the one I
> always quote in docs).

Historically, we defaulted to plain directories for simplicity.
Today, making tar the default for sbuild is the simplest way
to get working throwaway sessions.  As before, more complex/
performant configuration will require manual action.  For
portability, tar is definitely preferable to overlays as the
default.

I'd be happy for sbuild-createchroot to switch to tar by default;
please feel free to commit and upload such a change.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741727: [buildd-tools-devel] Bug#741727: sbuild-createchroot: custom suffix in chroot names

[Roger Leigh]

On Wed, Jun 18, 2014 at 06:45:35PM +0200, Luca Falavigna wrote:
> Control: tags -1 + patch
> 
> 
> Attached patch implements this feature.

Looks fine, thanks.  Please feel free to commit and upload.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#710073: [buildd-tools-devel] Bug#710073: Bug#710073: Bug#710073: sbuild: add copy-on-write support

[Roger Leigh]

On Sat, May 10, 2014 at 02:00:05PM -0400, Samuel Bronson wrote:
> Roger Leigh  writes:
> 
> > On Fri, Jul 05, 2013 at 10:15:07AM -0700, Geoffrey Thomas wrote:
> 
> >> Hasn't overlayfs support been in schroot since 1.5.2-1 (May 2012)? I
> >> don't think any more support is needed on the sbuild side. Ubuntu
> >> seems to be making active use of overlayfs chroots -- mk-sbuild from
> >> ubuntu-dev-tools 0.136 (November 2011) onwards makes them, and they
> >> carry no patches to schroot and no relevant patches to sbuild.
> 
> Might be nice if the "type=" description in schroot.conf referenced the
> "filesystem union chroot" options section as applying to "directory"
> chroots?  They sound rather unappealing compared to the snapshot options
> there.

Just to be sure.  Are you referring to the examples in the template
schroot.conf that's installed by default?  This is a bit outdated
and doesn't cover everything; if you wish to provide an update for
it that would be 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-dist-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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745851: [buildd-tools-devel] Bug#745851: sbuild: should give a clear error message when chroot does not exist

[Roger Leigh]

On Fri, Apr 25, 2014 at 04:46:03PM -0300, Felipe Sateler wrote:
> I use sbuild with chroots. When the target distribution is UNRELEASED,
> sbuild cannot find a suitable chroot. I need to pass -d unstable to
> build. No complaints here.
> The bug is that sbuild gives no error indication that it could not find
> the chroot. It just says the build failed. Not even enabling debug
> output says anything useful:
> 
> Please print a big error message when the chroot cannot be set up, and
> if possible print out why.

This is certainly a good idea.

Just as a thought, if you add an UNRELEASED alias to your unstable
chroot configuration, it will then be possible to have it work.
This is not a proper fix for the reported problem, but it might be
useful as a workaround for 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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#669866: manpages: New manual page: hostname(5)

[Roger Leigh]

On Mon, Apr 21, 2014 at 03:39:20PM +0200, Michael Kerrisk (man-pages) wrote:
> On 04/21/2014 10:04 AM, Petter Reinholdtsen wrote:
> > [Roger Leigh]
> >> Sorry, I've not done anything on this lately--I'm not too active in
> >> Debian at present due to RSI and other reasons.  Petter, would you
> >> possibly be able to look into this on the sysvinit side?
> > 
> > As far as I can see from https://bugs.debian.org/669866 >, the
> > upstream manpages maintainer is waiting for copyright information for
> > the hostname.5 file.  This can only be provide by the authors, and
> > nothing I can do from the sysvinit side.
> 
> 
> Exactly. The page text says it was written by Lennart P and Roger. If 
> they're both agreeable, and have a license, then I'd take the page.

For my part, I'm happy for my contributions to this page to be licensed
under whatever DFSG-free licence you use for the manpages.


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#479397: [gutenprint] Moved Git repository away from collab-maint to printing

[Roger Leigh]

On Tue, Apr 15, 2014 at 01:27:00PM +0200, Didier 'OdyX' Raboud wrote:
> Hi Roger,
> 
> As discussed earlier [0] on the Debian Printing Team list [1], I have 
> now moved the gutenprint repository away from collab-maint to the new
> "printing" group on alioth [2].
> 
> If you had a local checkout of the repository, you need to hand it the 
> new repository URLs:
> 
>   git remote set-url origin 
> https://alioth.debian.org/anonscm/git/printing/gutenprint.git
>   git remote set-url origin --push 
> git+ssh://git.debian.org/git/printing/gutenprint.git
> 
> I will upload the package shortly including an update of the packaging
> and some fixes; I hope that's okay for you.

Yes, that's totally fine with me.  Thanks for doing 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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#669866: manpages: New manual page: hostname(5)

[Roger Leigh]

On Wed, Mar 26, 2014 at 08:28:00AM +0100, Michael Kerrisk (man-pages) wrote:
> @Roger, ping!

Sorry, I've not done anything on this lately--I'm not too active
in Debian at present due to RSI and other reasons.  Petter, would
you possibly be able to look into this on the sysvinit side?


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-dist-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  
ii  ucf  3.0027+nmu1

php5-json recommends no packages.

php5-json suggests no packages.

-- no debconf information


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

Bug#681884: [buildd-tools-devel] Bug#681884: Same problem with schroot 1.6.8-1

[Roger Leigh]

On Sat, Apr 05, 2014 at 09:25:33PM +1100, Erik de Castro Lopo wrote:
> Erik de Castro Lopo wrote:
> 
> > Can anyone figure out from what we know so far if this is an schroot
> > but or a systemd bug?
> > 
> > If someone can give me a gentle nudge in the right direction I'm willing
> > to invest some time on this because I really do need this bug fixed.
> 
> Now I can't even re-produce this bug.
> 
> I'm still using schroot 1.6.8-1 with systemd 204-8 but upgrading something
> else (no clue what) seems to have fixed.
> 
> I have schroot working properly again. I'm very happy. If no one else can
> re-produce this then the bug should be closed.

There's definitely a bug here, in fact two bugs:

- systemd shouldn't be breaking things by altering defaults that have
  worked for over a decade, thereby breaking every user of mount --bind.
  This is utterly wrong.  mount --bind is in widespread use and, like it
  or not, there are thousands of programs and scripts that, unwittingly
  or not, depend upon the existing kernel default.

- schroot should be able to cope with the default being changed; there's
  a patch to do this; it just needs updating to work on non-Linux systems
  and I'll apply it.  The bits of the existing patch just need wrapping in
  "if(Linux)" conditionals.

I'll fix this in schroot of course, as I have for many minor portability
issues over the years.  I do have some rather bad things to say about
systemd's attitudes here, but I'll refrain from it 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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#742701: [buildd-tools-devel] Bug#742701: Bug#742701: package built without _FORTIFY_SOURCE=2, debhelper or schroot issue?

[Roger Leigh]

On Wed, Mar 26, 2014 at 04:01:14PM +, Roger Leigh wrote:
> On Wed, Mar 26, 2014 at 03:01:37PM +0100, Matthias Klose wrote:
> > Package: debhelper,schroot
> > Severity: important
> > 
> > seen in unstable, according to
> > http://qa.debian.org/bls/packages/s/schroot.html
> > https://buildd.debian.org/status/fetch.php?pkg=schroot&arch=i386&ver=1.6.8-1&stamp=1388837978
> > 
> >  - schroot 1.6.8-1 sets debian/compat to 9
> >  - schroot sets DH_OPTIONS = --buildsystem=cmake
> > 
> > but CPPFLAGS are not appended to CFLAGS/CXXFLAGS as mentioned in
> > #668813. exporting DH_OPTIONS doesn't help either.
> > 
> > if you're not overwriting things like in korundum, appending the
> > CPPFLAGS seems to work. can't see what to fix in schroot.
> 
> Should simply be a matter of appending CPPFLAGS to CXXFLAGS?
> 
> From the description, #668813 sets CFLAGS, but doesn't mention
> CXXFLAGS--maybe it just needs updating to set both?

I checked the debhelper change, and it does set CXXFLAGS.  Looking at e.g.
https://buildd.debian.org/status/fetch.php?pkg=schroot&arch=powerpc&ver=1.6.8-1&stamp=1388838030:

  -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security

are being added.  So at least some options are being set automatically.
Is _FORTIFY_SOURCE passed using a different mechanism or a different variable?
Or do I need to take some additional measure to explicitly enable it?


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#742701: [buildd-tools-devel] Bug#742701: package built without _FORTIFY_SOURCE=2, debhelper or schroot issue?

[Roger Leigh]

On Wed, Mar 26, 2014 at 03:01:37PM +0100, Matthias Klose wrote:
> Package: debhelper,schroot
> Severity: important
> 
> seen in unstable, according to
> http://qa.debian.org/bls/packages/s/schroot.html
> https://buildd.debian.org/status/fetch.php?pkg=schroot&arch=i386&ver=1.6.8-1&stamp=1388837978
> 
>  - schroot 1.6.8-1 sets debian/compat to 9
>  - schroot sets DH_OPTIONS = --buildsystem=cmake
> 
> but CPPFLAGS are not appended to CFLAGS/CXXFLAGS as mentioned in
> #668813. exporting DH_OPTIONS doesn't help either.
> 
> if you're not overwriting things like in korundum, appending the
> CPPFLAGS seems to work. can't see what to fix in schroot.

Should simply be a matter of appending CPPFLAGS to CXXFLAGS?

>From the description, #668813 sets CFLAGS, but doesn't mention
CXXFLAGS--maybe it just needs updating to set both?


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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org