Bug#732643: I just discovered this is a duplicate of bug 675512
Feel free to mark this as a duplicate of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675512 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732643: Please add snapshot session sharing feature
Package: schroot Version: 1.6.5 Severity: wishlist I have a user who would like to create an lvm snapshot session and then share it with another user. Currently only the root user can access other user's sessions. It would be helpful if a non-root user could run a command to grant a second non-root user to access their session with the same privileges they have. This should only be allowed if that second user also has the necessary privileges to create their own identical snapshot sessions from the same source chroot. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711277: [buildd-tools-devel] Bug#711277: contents of 1.7.0 tarball has changed
> Thanks for the diff. I'm not sure where the different tarballs > have originated from--maybe one was a prerelease test tarball? Thanks Roger. Do you have any ideas on the proper way to resolve the unit test failures I'm seeing with the official tarball? -Zach -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#656239: compile errors with gcc 4.7
Package: schroot
Version: 1.4.23
The gcc compiler in the Fedora distribution has recently been updated to
gcc 4.7, at which point schroot failed to build.
Official build results can be seen here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3668529
Specifically, the compile errors are here:
http://koji.fedoraproject.org/koji/getfile?taskID=3688962&name=build.log
A fedora contributer (Ralf Corsepius), has developed a patch (attached)
which results in a successful build.
diff -Naur schroot-1.4.23.orig/sbuild/sbuild-custom-error.h
schroot-1.4.23/sbuild/sbuild-custom-error.h
--- schroot-1.4.23.orig/sbuild/sbuild-custom-error.h2011-06-11
17:54:38.186135440 +0200
+++ schroot-1.4.23/sbuild/sbuild-custom-error.h 2012-01-17 16:25:31.343780636
+0100
@@ -41,8 +41,8 @@
* @param error the error code.
*/
custom_error (error_type error):
- sbuild::error(format_error(null(), null(), null(), error, null(),
null(), null()),
- format_reason(null(), null(), null(), error, null(),
null(), null()))
+ sbuild::error(this->format_error(null(), null(), null(), error,
null(), null(), null()),
+ this->format_reason(null(), null(), null(), error,
null(), null(), null()))
{
}
@@ -55,8 +55,8 @@
template
custom_error (C const& context,
error_type error):
- sbuild::error(format_error(context, null(), null(), error, null(),
null(), null()),
- format_reason(context, null(), null(), error, null(),
null(), null()))
+ sbuild::error(this->format_error(context, null(), null(), error,
null(), null(), null()),
+ this->format_reason(context, null(), null(), error,
null(), null(), null()))
{
}
@@ -69,8 +69,8 @@
template
custom_error (error_type error,
D const& detail):
- sbuild::error(format_error(null(), null(), null(), error, detail,
null(), null()),
- format_reason(null(), null(), null(), error, detail,
null(), null()))
+ sbuild::error(this->format_error(null(), null(), null(), error,
detail, null(), null()),
+ this->format_reason(null(), null(), null(), error,
detail, null(), null()))
{
}
@@ -85,8 +85,8 @@
custom_error (error_type error,
D const& detail,
E const& detail2):
- sbuild::error(format_error(null(), null(), null(), error, detail,
detail2, null()),
- format_reason(null(), null(), null(), error, detail,
detail2, null()))
+ sbuild::error(this->format_error(null(), null(), null(), error,
detail, detail2, null()),
+ this->format_reason(null(), null(), null(), error,
detail, detail2, null()))
{
}
@@ -103,8 +103,8 @@
D const& detail,
E const& detail2,
F const& detail3):
- sbuild::error(format_error(null(), null(), null(), error, detail,
detail2, detail3),
- format_reason(null(), null(), null(), error, detail,
detail2, detail3))
+ sbuild::error(this->format_error(null(), null(), null(), error,
detail, detail2, detail3),
+ this->format_reason(null(), null(), null(), error,
detail, detail2, detail3))
{
}
@@ -119,8 +119,8 @@
custom_error (C const& context,
error_type error,
D const& detail):
- sbuild::error(format_error(context, null(), null(), error, detail,
null(), null()),
- format_reason(context, null(), null(), error, detail,
null(), null()))
+ sbuild::error(this->format_error(context, null(), null(), error,
detail, null(), null()),
+ this->format_reason(context, null(), null(), error,
detail, null(), null()))
{
}
@@ -155,8 +155,8 @@
D const& context2,
error_type error,
E const& detail):
- sbuild::error(format_error(context1, context2, null(), error, detail,
null(), null()),
- format_reason(context1, context2, null(), error, detail,
null(), null()))
+ sbuild::error(this->format_error(context1, context2, null(), error,
detail, null(), null()),
+ this->format_reason(context1, context2, null(), error,
detail, null(), null()))
{
}
diff -Naur schroot-1.4.23.orig/sbuild/sbuild-nostream.h
schroot-1.4.23/sbuild/sbuild-nostream.h
--- schroot-1.4.23.orig/sbuild/sbuild-nostream.h2011-05-27
18:01:47.134846621 +0200
+++ schroot-1.4.23/sbuild/sbuild-nostream.h 2012-01-17 15:56:54.369906387
+0100
@@ -58,7 +58,7 @@
std::basic_ios(&nbuf),
std::basic_ostream(&nbuf)
{
- init(&nbuf);
+ this->init(&nbuf);
}
private:
diff -Naur schroot-1.4.23.orig/sbuild/sbuild-parse-error.h
schroot-1.4.23/sbuild/sbuild-parse-error.h
--- s
Bug#612510: [buildd-tools-devel] Bug#612510: Bug#612510: build issue with boost 1.46
On Thursday, February 10, 2011 05:10:06 am Roger Leigh wrote: > OK, it proved not to require a configure check, just a conditional to > check the provided filesystem version. Could you try the attached > patch and see if it builds correctly for you? Verified, it applies and builds fine with boost 1.44 and 1.46 thanks! -Zach -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#612510: [buildd-tools-devel] Bug#612510: build issue with boost 1.46
On Tuesday, February 08, 2011 02:49:01 pm Roger Leigh wrote: > > sbuild-chroot-config.cc: In member function 'void > > sbuild::chroot_config::add_config_directory(const string&, const > > string&)': sbuild-chroot-config.cc:170:49: error: no matching function > > for call to > > 'std::basic_string::basic_string(boost::filesystem3::path)' > > OK, they must have removed the explicit cast to string. A little > annoying, since a filename is just a string. > > I'll add a configure check. > > Would you be OK to test a prerelease tarball once I've done that, since > I can't test it myself yet? It'll probably be the weekend at the > earliest, given that I'm supported to be writing my PhD thesis, and > not coding ;-) Sure, just let me know where to get it when it's ready. I'm in no hurry, as we already have a good Fedora build with my current patch. btw, I think boost 1.46 is still beta, not released yet. So, if this is an issue you think they might want to fix in boost, we can try to pursue that. It looks like it was scheduled to release yesterday, though, so they might push back pretty hard. thanks! -Zach -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#612510: [buildd-tools-devel] Bug#612510: build issue with boost 1.46
On Tuesday, February 08, 2011 02:17:12 pm Roger Leigh wrote: > The provided patch doesn't build with Boost 1.42, and I'd like to > have backward compatibility if possible. The final .string() is > not required to build with 1.42, and this might also be the case > with 1.64. Please could you let me know if the attached modified > patch also builds OK with 1.64? If not we'll need to check what's > supported in configure and conditionally compile the correct > version (which we already do for some Boost incompatibilities). Unfortunately, in boost 1.46 taking out the call to string() results in this failure: sbuild-chroot-config.cc: In member function 'void sbuild::chroot_config::add_config_directory(const string&, const string&)': sbuild-chroot-config.cc:170:49: error: no matching function for call to 'std::basic_string::basic_string(boost::filesystem3::path)' -Zach -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#612510: build issue with boost 1.46
Package: schroot
Version: 1.4.19
When I build schroot with boost 1.46, I get this error:
sbuild-chroot-config.cc: In member function 'void
sbuild::chroot_config::add_config_directory(const string&, const string&)':
sbuild-chroot-config.cc:170:32: error: 'class
boost::filesystem3::directory_entry' has no member named 'leaf
As was suggested on the Fedora development list, substituting
path().filename().string() for leaf() seems to fix the problem. I'm attaching
a
patch which does this.
-Zach
--- sbuild/sbuild-chroot-config.cc.orig 2011-02-07 09:22:04.0 -0800
+++ sbuild/sbuild-chroot-config.cc 2011-02-07 09:22:13.0 -0800
@@ -167,7 +167,7 @@
dirent != end_iter;
++dirent)
{
- std::string name(dirent->leaf());
+ std::string name(dirent->path().filename().string());
// Skip common directories.
if (name == "." || name == "..")
--- sbuild/sbuild-run-parts.cc.orig 2011-02-07 10:35:10.0 -0800
+++ sbuild/sbuild-run-parts.cc 2011-02-07 10:35:20.0 -0800
@@ -81,7 +81,7 @@
dirent != end_iter;
++dirent)
{
- std::string name(dirent->leaf());
+ std::string name(dirent->path().filename().string());
// Skip common directories.
if (name == "." || name == "..")
Bug#605939: [buildd-tools-devel] Bug#605939: Bug#605939: Bug#605939: Bug#605939: Regression: Chroots with periods in the name no longer work.
On Sunday 05 December 2010 13:25:57 Roger Leigh wrote: > Can anyone see any downside from being this permissive, or any > security implication I've not seen? (I'm only looking at pathname- > based security exploits here--is there anything else we need to > worry about?) Like lvm, it might be wise to check that btrfs supports the various allowed characters. I saw one reference to an old btrfs man page that disallows both types of slashes, however the current man page does not mention the restriction. I don't have time at the moment, but I can try to test some scenarios some time later this week. -Zach -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593256: Uses deprecated "priority" key by default
Package: schroot Version: 1.4.8 When I create a persistent schroot session, and I do not specify the priority, the default priority is set to 0. Later on when I access the session, I get multiple warnings about using a deprecated key. Example, a simple chroot, with no priority defined: [catalan] type=directory directory=/usr/share/chroots/catalan users=root personality=linux32 $ schroot -b -c catalan catalan-8cfd7498-f27b-405a-b548-b288a16df8b3 $ grep priority /var/lib/schroot/session/catalan-8cfd7498-f27b-405a-b548-b288a16df8b3 priority=0 $ schroot -r -c catalan-8cfd7498-f27b-405a-b548-b288a16df8b3 -- uname -a W: line 13 [zcarter-catalan-build-raqpcczeft-22354]: Deprecated key ‘priority’ used I: This option will be removed in the future; please update your configuration W: line 13 [zcarter-catalan-build-voymvdo87r-23549]: Deprecated key ‘priority’ used I: This option will be removed in the future; please update your configuration W: line 13 [catalan-8cfd7498-f27b-405a-b548-b288a16df8b3]: Deprecated key ‘priority’ used I: This option will be removed in the future; please update your configuration W: line 13 [zcarter-catalan-build-4wkg75bp65-28331]: Deprecated key ‘priority’ used I: This option will be removed in the future; please update your configuration W: line 13 [zcarter-catalan-build-l8ade2oead-21142]: Deprecated key ‘priority’ used I: This option will be removed in the future; please update your configuration W: line 13 [zcarter-catalan-build-s1161vn4ko-24734]: Deprecated key ‘priority’ used I: This option will be removed in the future; please update your configuration Linux nudj 2.6.33.6-147.2.4.fc13.x86_64 #1 SMP Fri Jul 23 17:14:44 UTC 2010 i686 i686 i386 GNU/Linux It seems that the default behavior should not use a deprecated key. In fact, with a persistent session I don't see a way *not* to use it. BTW, thanks for putting out 1.4.8 ! -Zach -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589889: [buildd-tools-devel] Bug#589889: Bug#589889: schroot: session names being inconsistently restricted
On Saturday 07 August 2010 02:43:13 Roger Leigh wrote: > I just need to work out how to disable boost::regex::collate; is there > an inverse of that option? Since it's enabled by default for > extended regexes, I'm not sure how to turn this off. indeed, from the faq: "[Note - when regex_constants::nocollate in effect, the library behaves "as if" the LC_COLLATE locale category were always "C", regardless of what its actually set to - end note]." -Zach
Bug#589889: [buildd-tools-devel] Bug#589889: Bug#589889: schroot: session names being inconsistently restricted
On Saturday 07 August 2010 02:43:13 Roger Leigh wrote: > > Just some additional background info. When I was troubleshooting this > > issue I noticed some inconsistent behavior in the boost regex > > logic. Some of my session names were allowed, and some were not, and I > > was banging my head against the wall trying to figure out what was > > different. A friend of my suggested it may have to do with how the > > ranges are handled, such as "a-z". Testing confirmed that hypothesis, at > > least in my environment. Apparently, those ranges are not very reliable > > with regard to your locale setting. > > Could you possible let me know what the locale and name was so I can > reproduce this? I can reproduce it with grep on my machine: $ LC_COLLATE="en_US.UTF-8" $ echo WbwvSLZqAf | egrep '^[a-z0-9][a-z0-9-]' <-- match! WbwvSLZqAf $ export LC_COLLATE=C $ echo WbwvSLZqAf | egrep '^[a-z0-9][a-z0-9-]' <-- no match $ Note, the first character is an uppercase W, which shouldn't match. The regex is taken from the is_valid_filename() function in the schroot code. On my fedora machine, if I unset LC_COLLATE (which is the default), I get the same behavior as if it were set to "en_US.UTF-8". thanks, -Zach -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589889: [buildd-tools-devel] Bug#589889: schroot: session names being inconsistently restricted
On Thursday 22 July 2010 02:04:52 Roger Leigh wrote: > Agreed on all counts and the patch looks great. I'll review it in > more detail when I have time at the weekend and make a new release > then. Cool! thanks. Just some additional background info. When I was troubleshooting this issue I noticed some inconsistent behavior in the boost regex logic. Some of my session names were allowed, and some were not, and I was banging my head against the wall trying to figure out what was different. A friend of my suggested it may have to do with how the ranges are handled, such as "a-z". Testing confirmed that hypothesis, at least in my environment. Apparently, those ranges are not very reliable with regard to your locale setting. From http://www.cs.brown.edu/~jwicks/boost/libs/regex/doc/faq.html: "Q. Why don't character ranges work properly (POSIX mode only)? A. The POSIX standard specifies that character range expressions are locale sensitive - so for example the expression [A-Z] will match any collating element that collates between 'A' and 'Z'. That means that for most locales other than "C" or "POSIX", [A-Z] would match the single character 't' for example, which is not what most people expect - or at least not what most people have come to expect from regular expression engines. For this reason, the default behaviour of boost.regex (perl mode) is to turn locale sensitive collation off by not setting the regex_constants::collate compile time flag. However if you set a non-default compile time flag - for example regex_constants::extended or regex_constants::basic, then locale dependent collation will be enabled, this also applies to the POSIX API functions which use either regex_constants::extended or regex_constants::basic internally. [Note - when regex_constants::nocollate in effect, the library behaves "as if" the LC_COLLATE locale category were always "C", regardless of what its actually set to - end note]." So, it might be advisable to change the regexes used in sbuild-util.cc to use the more reliable character classes, such as [:lower:] and [:digit:], documented here: http://www.boost.org/doc/libs/1_43_0/libs/regex/doc/html/boost_regex/syntax/character_classes/std_char_clases.html Or, set some compile-time flags to force the locale sensitivity off. -Zach -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589889: schroot: session names being inconsistently restricted
Package: schroot
Version: 1.4.7
Severity: important
schroot allows me to create a persistent session with a particular name, such
as "zcarter-catalan-build-cb67j4yZoS-16646".
However, when I attempt to access it later on, it fails like this:
$ /usr/bin/schroot -p -v -r -c zcarter-catalan-build-cb67j4yZoS-16646 -- uname
-a
E: zcarter-catalan-build-cb67j4yZoS-16646: Chroot not found
I traced it down to the is_valid_filename() function defined in sbuild-util.cc
When schroot scans all the files in the session directory, it is skipping those
that don't match certain regex restrictions, even though they are valid
filenames, and were created by the same version of
schroot.
This is a regression from behaviour not present in the 1.2 series.
I see two solutions, either:
- enforce the same restrictions when the chroot session is first created.
- loosen the restrictions, since the run-parts() restrictions do not seem
appropriate to restrict session names.
My vote would be for the latter solution.
I'm attaching a patch that works for me.
thanks!
-Zach
--- ./sbuild/sbuild-util.cc.orig 2010-07-21 15:11:30.0 -0700
+++ ./sbuild/sbuild-util.cc 2010-07-21 15:18:12.0 -0700
@@ -170,6 +170,20 @@
}
bool
+sbuild::is_valid_sessionname (std::string const& name)
+{
+ bool match = false;
+
+ static regex file_namespace("^[a-zA-Z0-9][a-zA-Z0-9_-]*$");
+
+ if (regex_search(name, file_namespace)) {
+match = true;
+ }
+
+ return match;
+}
+
+bool
sbuild::is_valid_filename (std::string const& name,
bool lsb_mode)
{
--- ./sbuild/sbuild-util.h.orig 2010-07-21 15:20:33.0 -0700
+++ ./sbuild/sbuild-util.h 2010-07-21 15:17:38.0 -0700
@@ -79,6 +79,17 @@
/**
* Check if a filename matches the allowed pattern(s). This will
* not match dotfiles, backup files, dpkg configuration backup
+ * files, etc.
+ *
+ * @param name the filename to check.
+ * @returns true if it matches, false if not.
+ */
+ bool
+ is_valid_sessionname (std::string const& name);
+
+ /**
+ * Check if a filename matches the allowed pattern(s). This will
+ * not match dotfiles, backup files, dpkg configuration backup
* files, etc. This uses the same rules as run-parts(8).
*
* @param name the filename to check.
--- ./sbuild/sbuild-chroot-config.cc.orig 2010-07-21 15:19:21.0 -0700
+++ ./sbuild/sbuild-chroot-config.cc 2010-07-21 15:19:34.0 -0700
@@ -139,7 +139,7 @@
continue;
// Skip backup files and dpkg configuration backup files.
- if (!is_valid_filename(name))
+ if (!is_valid_sessionname(name))
continue;
std::string filename = dir + "/" + name;
Bug#589658: schroot: configure.ac boost function header issue
Package: schroot
Version: 1.4.2
In the fedora build system, the ./configure process fails with this error:
configure: error: libboost_program_options (Boost C++ Libraries) is not
installed, but is required by schroot
It doesn't seem to fail on my local build machine, but it does in the fedora
build system. I'm not sure what the difference could be, as the toolchain
should be exactly the same.
The config.log shows this:
"...
| include
| int
| main ()
| {
| boost::program_options::variables_map::variables_map dummy()
| ;
| return 0;
| }
configure:18263: g++ -o conftest -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -
fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
conftest.cpp -lboost_program_options -lboost_system -lboost_regex -
lboost_program_options-mt >&5
conftest.cpp: In function 'int main()':
conftest.cpp:58:1: error:
'boost::program_options::variables_map::variables_map' names the constructor,
not the type
conftest.cpp:58:54: error: expected ';' before 'dummy'
conftest.cpp:59:3: error: statement cannot resolve address of overloaded
function
configure:18263: $? = 1
configure: failed program was:
...
"
At the suggestion of some other fedora developers, I made this change and now
it works:
diff --git a/configure.ac b/configure.ac
index 47d1b80..779a837 100644
--- a/configure.ac
+++ b/configure.ac
@@ -565,7 +565,7 @@ AC_MSG_CHECKING([for boost::program_options::variables_map
in -lboost_program_op
saved_LIBS="${LIBS}"
LIBS="${saved_LIBS} -lboost_program_options"
define([testprog], [AC_LANG_PROGRAM([#include ],
-
[boost::program_options::variables_map::variables_map dummy()])])
+ [boost::program_options::variables_map
dummy()])])
AC_LINK_IFELSE(testprog,
[AC_MSG_RESULT([yes])
BOOST_LIBS="${BOOST_LIBS} -lboost_program_options"],
Bug#584961: schroot: lvm-snapshot device lock permission failure
Package: schroot Version: 1.2.3 Severity: normal When a non-root user is accessing an lvm snapshot chroot, the call to lockdev is made with insufficient permissions, resulting in this error: E: test-f13-401b1c48-570f-48bb-8389-4b6d44f18577: Failed to lock chroot: /dev/fastvg/f13lv: Failed to lock device: Failed to lock device This issue can also be reproduced in schroot 1.4.2 Additional details are available in Fedora bug 600638 here: https://bugzilla.redhat.com/show_bug.cgi?id=600636 The patch proposed there consists of moving the setuid call to an earlier point before the call to lockdev is made. -Zach -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583504: schroot: non-uuid formatted chroot names do not work with lvm snapshots
Package: schroot Version: 1.4.2 Severity: normal When compiled without uuid support, schroot creates chroot names that include colon characters in them. When creating a snapshot based on those names, the lvcreate command fails like this: E: 05lvm: Logical volume name "f12-2010-05-27T20:35:13Z-12237" is invalid Recommendation: when uuid support is not available, convert the colon characters to some other allowable character, such as underscore '_'. Alternatively, another suggestion would be to modify the autotools to require uuid support. -Zach -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#491358: additional info
I am using these packages: # gcc 3 gcc-3.4.6-9 libgcc-3.4.6-9 gcc-c++-3.4.6-9 # also tried gcc 4 gcc4-4.1.2-14.EL4 gcc4-c++-4.1.2-14.EL4 make-3.80-6.EL4 pam-devel-0.77-66.23 boost-devel-1.32.0-6.rhel4 lockdev-devel-1.0.1-6.2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#491358: schroot: error when using schroot -p option (E: Empty expression)
Package: schroot
Version: 1.1.6
Severity: normal
When using the -p option, schroot exits with this error: E: Empty expression
[EMAIL PROTECTED] ~]$ schroot -c bering -- uname -a
I: [bering-2008-07-19T04:58:47Z-13217 chroot] Running command: “uname -a”
Linux nerf 2.4.21-47.0.1.EL #1 Thu Oct 19 11:42:25 EDT 2006 i686 i686 i386
GNU/Linux
[EMAIL PROTECTED] ~]$ schroot -p -c bering -- uname -a
E: Empty expression
[EMAIL PROTECTED] ~]$
This only occurs on CentOS 4.x. I've done some debugging in the code, but I
cannot find exactly where the exception is coming from. It occurring somewhere
inside this function in sbuild-auth.cc:
void
auth::set_environment (environment const& environment)
{
this->user_environment = environment; <---exception is thrown during this
operation
}
I realize this is not Debian, but I would really appreciate any pointers or
workarounds to get this working in CentOS 4.x. I am trying to build and
support schroot in a diverse development environment.
Fedora, Ubuntu, Debian, Gentoo, CentOS 5.x all work fine, but CentOS 4.x is
having this one issue.
-Zach
