Bug#932909: Bug #932909: xchroot/2.7.5-1 [ITP] -- extended chroot with X11/Xorg forwarding

[Elmar Stellnberger]

Package: sponsorship-requests
Severity: wishlist

Xchroot 2.7.4 has also come with many new features. Dbus session 
creation and /dev/shm mounting satisfy the need even of exigent GUI 
programs like the Otter browser. It has a /media and subdirectory 
automounter which is especially useful for mirroring mounts of removable 
media. It is even possible to run a whole desktop session like KDE, 
Gnome or Xfce in an xchroot container. Desktop link creation for the GUI 
menu is included. The program has evolved much since Debian fellows have 
initially persuaded me to make the program open source. That time there 
was interest in the development of xchroot regarding Debian.

Bug#932909: Bug #932909: xchroot/2.7.5-1 [ITP] -- extended chroot with X11/Xorg forwarding

[Elmar Stellnberger]

Package: sponsorship-requests
Severity: wishlist

Dear Bart Martens,
Dear mentors,

  I have now applied the necessary changes for package "xchroot" to get 
sponsored:


  https://mentors.debian.net/package/xchroot

  dget -xu 
https://mentors.debian.net/debian/pool/main/x/xchroot/xchroot_2.7.5-1.dsc


  Changes since the last upload:

  The changelog now contains only one entry with reference to making 
the ITP bug #721447 closed. Version number is -1 as required.


  version 2.7.5 has a more robust xauth mechanism and fixes a fallacy 
when X-authorization is given on a per user or local basis rather than 
by a MIT-MAGIC-COOKIE-1: Now xchroot can generate the cookie on the fly 
if none is encountered:

https://www.elstel.org/ViewRSS.php?guid=7470#7470

Regards,
Elmar Stellnberger

Bug#932909: RFS: xchroot/2.7.4-7 [ITP] -- extended chroot with X11/Xorg forwarding

[Bastian Germann]

Control: tags -1 moreinfo

Please note that there is an automation in place that closes your RFSs when you 
delete your package from mentors.
Please just upload without deleting the old version (keep at least one of them).

Please read on how a changelog of a new Debian package has to look like.
Hint: It has to be only one version ending on -1 with exactly one entry that 
will auto_close the corresponding ITP.

When you have fixed the changelog untag morinfo from this bug.

sbuild chroot cleanup failed

[Tong Sun]

Hi,

I'm following
https://wiki.debian.org/sbuild#Apt_package_caching
to setup new schroot with eatmydata & ccache, but got "chroot cleanup
failed" afterwards.

Here is what I did:

sudo rm -r /srv/chroot/unstable-amd64-sbuild/
sudo rm /etc/schroot/chroot.d/unstable-amd64-sbuild-*
/etc/sbuild/chroot/unstable-amd64-sbuild

sudo sbuild-createchroot --include=eatmydata,ccache,gnupg unstable
/srv/chroot/unstable-amd64-sbuild
http://127.0.0.1:3142/deb.debian.org/debian

AOK so far, but when I tried to do
sudo sbuild-shell source:unstable-$arch-sbuild

then quit without doing anything, I'll get:

E: 10mount: E: Failed to open mount file â/proc/mountsâ: No such file
or directory
E: unstable-amd64-sbuild-d8cd8187-9a0a-47b0-ba1b-e0f0f5668e75: Chroot
setup failed: stage=setup-stop
Chroot cleanup failed


Tried twice (from a clean Debian sid environment), and twice got the
exact same error.

What is the problem and what should I do?

Thx!

Re: sbuild not working within docker: Chroot setup failed

[Tong Sun]

Please disregard the following message.

Found the answer from
https://stackoverflow.com/questions/33235395/run-chroot-within-docker

On Sun, Mar 17, 2019 at 10:37 AM Tong Sun
 wrote:
>
> Package: sbuild
> Version: 0.78.1-1
> Severity: normal
>
> Hi,
>
> Does sbuild works within docker?
>
> I'm getting "Chroot setup failed" error.
> Here are the steps to reproduce (within docker):
>
> gbp clone --all --pristine-tar
> g...@salsa.debian.org:go-team/packages/golang-github-ghodss-yaml.git
> cd golang-github-ghodss-yaml
> gbp buildpackage
>
> More details:
>
> ---
> $ gbp buildpackage
> gbp:info: Exporting 'HEAD' to
> '/.../yaml/build-area/golang-github-ghodss-yaml-tmp'
> gbp:info: Moving '/.../yaml/build-area/golang-github-ghodss-yaml-tmp'
> to '/.../yaml/build-area/golang-github-ghodss-yaml-1.0.0'
> gbp:info: Performing the build
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: applying fix-ftbfs-on-i386.patch
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building golang-github-ghodss-yaml using existing
> ./golang-github-ghodss-yaml_1.0.0.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: building golang-github-ghodss-yaml in
> golang-github-ghodss-yaml_1.0.0-2.debian.tar.xz
> dpkg-source: info: building golang-github-ghodss-yaml in
> golang-github-ghodss-yaml_1.0.0-2.dsc
> dpkg-source: info: unapplying fix-ftbfs-on-i386.patch
> sbuild (Debian sbuild) 0.78.1 (09 February 2019) on 98054b26de5d
>
> +==+
> | golang-github-ghodss-yaml 1.0.0-2 (amd64)Sun, 17 Mar 2019 14:07:48 
> + |
> +==+
>
> Package: golang-github-ghodss-yaml
> Version: 1.0.0-2
> Source Version: 1.0.0-2
> Distribution: UNRELEASED
> Machine Architecture: amd64
> Host Architecture: amd64
> Build Architecture: amd64
> Build Type: full
>
> E: 10mount: mount:
> /run/schroot/mount/unstable-amd64-sbuild-ef9e6c19-47f8-4938-9b8b-aea42c31a34e:
> permission denied.
> E: unstable-amd64-sbuild-ef9e6c19-47f8-4938-9b8b-aea42c31a34e: Chroot
> setup failed: stage=setup-start
> Chroot setup failed
> E: Error creating chroot session: skipping golang-github-ghodss-yaml
>
> +--+
> | Summary 
>  |
> +--+
>
> Build Architecture: amd64
> Build Type: full
> Build-Space: 0
> Build-Time: 0
> Distribution: UNRELEASED
> Fail-Stage: create-session
> Host Architecture: amd64
> Install-Time: 0
> Job: /sysvol/dg/yaml/build-area/golang-github-ghodss-yaml_1.0.0-2.dsc
> Machine Architecture: amd64
> Package: golang-github-ghodss-yaml
> Package-Time: 0
> Source-Version: 1.0.0-2
> Space: 0
> Status: failed
> Version: 1.0.0-2
> 
> Finished at 2019-03-17T14:07:48Z
> Build needed 00:00:00, 0k disk space
> E: Error creating chroot session: skipping golang-github-ghodss-yaml
> gbp:error: 'sbuild --source-only-changes -s -v -A --no-clean-source'
> failed: it exited with 1
> ---
>
> Note again,
>
> E: 10mount: mount:
> /run/schroot/mount/unstable-amd64-sbuild-ef9e6c19-47f8-4938-9b8b-aea42c31a34e:
> permission denied.
> E: unstable-amd64-sbuild-ef9e6c19-47f8-4938-9b8b-aea42c31a34e: Chroot
> setup failed: stage=setup-start
> Chroot setup failed
>
> I'm running all above as *root* within docker, so the "permission
> denied" has to be related to using sbuild within docker.
>
> please help.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.15.0-1012-azure (SMP w/2 CPU cores)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: unable to detect
>
> Versions of packages sbuild depends on:
> ii  adduser 3.118
> ii  libsbuild-perl  0.78.1-1
> ii  perl5.28.1-4
>
> Versions of packages sbuild recommends:
> pn  autopkgtest  
> ii  debootstrap  1.0.114
> ii  schroot  1.6.10-6+b1
>
> Versions of packages sbuild suggests:
> pn  deborphan  
> ii  e2fsprogs  1.44.5-1
> pn  kmod   
> ii  wget   1.20.1-1
>
> -- no debconf information

sbuild not working within docker: Chroot setup failed

[Tong Sun]

Package: sbuild
Version: 0.78.1-1
Severity: normal

Hi,

Does sbuild works within docker?

I'm getting "Chroot setup failed" error.
Here are the steps to reproduce (within docker):

gbp clone --all --pristine-tar
g...@salsa.debian.org:go-team/packages/golang-github-ghodss-yaml.git
cd golang-github-ghodss-yaml
gbp buildpackage

More details:

---
$ gbp buildpackage
gbp:info: Exporting 'HEAD' to
'/.../yaml/build-area/golang-github-ghodss-yaml-tmp'
gbp:info: Moving '/.../yaml/build-area/golang-github-ghodss-yaml-tmp'
to '/.../yaml/build-area/golang-github-ghodss-yaml-1.0.0'
gbp:info: Performing the build
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying fix-ftbfs-on-i386.patch
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building golang-github-ghodss-yaml using existing
./golang-github-ghodss-yaml_1.0.0.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building golang-github-ghodss-yaml in
golang-github-ghodss-yaml_1.0.0-2.debian.tar.xz
dpkg-source: info: building golang-github-ghodss-yaml in
golang-github-ghodss-yaml_1.0.0-2.dsc
dpkg-source: info: unapplying fix-ftbfs-on-i386.patch
sbuild (Debian sbuild) 0.78.1 (09 February 2019) on 98054b26de5d

+==+
| golang-github-ghodss-yaml 1.0.0-2 (amd64)Sun, 17 Mar 2019 14:07:48 + |
+==+

Package: golang-github-ghodss-yaml
Version: 1.0.0-2
Source Version: 1.0.0-2
Distribution: UNRELEASED
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

E: 10mount: mount:
/run/schroot/mount/unstable-amd64-sbuild-ef9e6c19-47f8-4938-9b8b-aea42c31a34e:
permission denied.
E: unstable-amd64-sbuild-ef9e6c19-47f8-4938-9b8b-aea42c31a34e: Chroot
setup failed: stage=setup-start
Chroot setup failed
E: Error creating chroot session: skipping golang-github-ghodss-yaml

+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 0
Build-Time: 0
Distribution: UNRELEASED
Fail-Stage: create-session
Host Architecture: amd64
Install-Time: 0
Job: /sysvol/dg/yaml/build-area/golang-github-ghodss-yaml_1.0.0-2.dsc
Machine Architecture: amd64
Package: golang-github-ghodss-yaml
Package-Time: 0
Source-Version: 1.0.0-2
Space: 0
Status: failed
Version: 1.0.0-2

Finished at 2019-03-17T14:07:48Z
Build needed 00:00:00, 0k disk space
E: Error creating chroot session: skipping golang-github-ghodss-yaml
gbp:error: 'sbuild --source-only-changes -s -v -A --no-clean-source'
failed: it exited with 1
---

Note again,

E: 10mount: mount:
/run/schroot/mount/unstable-amd64-sbuild-ef9e6c19-47f8-4938-9b8b-aea42c31a34e:
permission denied.
E: unstable-amd64-sbuild-ef9e6c19-47f8-4938-9b8b-aea42c31a34e: Chroot
setup failed: stage=setup-start
Chroot setup failed

I'm running all above as *root* within docker, so the "permission
denied" has to be related to using sbuild within docker.

please help.

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

Kernel: Linux 4.15.0-1012-azure (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages sbuild depends on:
ii  adduser 3.118
ii  libsbuild-perl  0.78.1-1
ii  perl5.28.1-4

Versions of packages sbuild recommends:
pn  autopkgtest  
ii  debootstrap  1.0.114
ii  schroot  1.6.10-6+b1

Versions of packages sbuild suggests:
pn  deborphan  
ii  e2fsprogs  1.44.5-1
pn  kmod   
ii  wget   1.20.1-1

-- no debconf information

Re: Bowtie segfaults in pbuilder chroot at build time (Was: Issue with new version of Bowtie)

[Steffen Möller]

Hi Andreas,

On 25.09.17 11:41, Andreas Tille wrote:
> Hi Phil,
>
> On Thu, Sep 21, 2017 at 11:47:40PM +0100, Phil Wyett wrote:
>> At this current time on a pbuilder sid created using:
>>
>> sudo pbuilder create --distribution sid --debootstrapopts --variant=buildd
>>
>> I cannot reproduce seg faults at all. I have tracked back through the med 
>> list
>> and done all commands tested, one example:
>>
>> root@ks-yoda:/tmp/buildd/bowtie-1.2.1.1+dfsg# ./bowtie --version
>> bowtie-align version 1.2.1.1
>> 64-bit
>> Built on Debian-reproducible
>> Mon, 04 Sep 2017 14:13:56 +0200
>> Compiler: gcc version 7.2.0
>> Options: -O3  -Wl,--hash-style=both -DWITH_TBB -Wdate-time 
>> -D_FORTIFY_SOURCE=2
>> -g -O2 -fdebug-prefix-map=.=. -fstack-protector-strong -Wformat 
>> -Werror=format-
>> security  -g -O2 -fdebug-prefix-map=.=. -fstack-protector-strong -Wformat
>> -Werror=format-security -std=c++03 -Wl,-z,relro -Wl,-z,now
>> Sizeof {int, long, long long, void*, size_t, off_t}: {4, 8, 8, 8, 8, 8}
>> root@ks-yoda:/tmp/buildd/bowtie-1.2.1.1+dfsg#
> Thanks for the attempt to reproduce.  I tried to ignore the test results
> at build time and installed the resulting package on my local machine.
> Now the segfaults are not happening any more.  That's really strange.  I
> do not think that the issue is caused due to a broken chroot (I'm
> actually using cowbuilder not pbuilder) since I can reproduce the
> problem on three different machines.
>
> Besides the build problem I need to ask the bioinformaticans on the
> Debian Med list about changes in the output of bowtie.  If I run the
> test suite with the freshly installed package I get things like:
>
>
> Error testing example
> --- tests/example1.out  2017-09-04 14:11:54.115569050 +0200
> +++ example1.out2017-09-23 07:41:11.214221005 +0200
> @@ -1,5 +0,0 @@
> --  gi|110640213|ref|NC_008253.1|   148810  10:A>G,13:C>G
> --  gi|110640213|ref|NC_008253.1|   2852852 8:T>A
> --  gi|110640213|ref|NC_008253.1|   4930433 4:G>T,6:C>G
> --  gi|110640213|ref|NC_008253.1|   905664  6:A>G,7:G>T
> -+  gi|110640213|ref|NC_008253.1|   1093035 2:T>G,15:A>T
>
>
> I wonder whether some bioinformatican could at least reproduce this and
> could comment on the test suite.
>
> For general Debian Mentors I'll leave the question for more ideas why
> the program segfaults inside pbuilder (at that time including debugging
> symbols) but runs when installing the package on a real machine and
> what I could do to track this down.


This is exactly what I get. I think this needs to be discussed with
upstream.

Cheers,

Steffen

Re: Bowtie segfaults in pbuilder chroot at build time (Was: Issue with new version of Bowtie)

[Andreas Tille]

Hi Phil,

On Thu, Sep 21, 2017 at 11:47:40PM +0100, Phil Wyett wrote:
> At this current time on a pbuilder sid created using:
> 
> sudo pbuilder create --distribution sid --debootstrapopts --variant=buildd
> 
> I cannot reproduce seg faults at all. I have tracked back through the med list
> and done all commands tested, one example:
> 
> root@ks-yoda:/tmp/buildd/bowtie-1.2.1.1+dfsg# ./bowtie --version
> bowtie-align version 1.2.1.1
> 64-bit
> Built on Debian-reproducible
> Mon, 04 Sep 2017 14:13:56 +0200
> Compiler: gcc version 7.2.0
> Options: -O3  -Wl,--hash-style=both -DWITH_TBB -Wdate-time -D_FORTIFY_SOURCE=2
> -g -O2 -fdebug-prefix-map=.=. -fstack-protector-strong -Wformat 
> -Werror=format-
> security  -g -O2 -fdebug-prefix-map=.=. -fstack-protector-strong -Wformat
> -Werror=format-security -std=c++03 -Wl,-z,relro -Wl,-z,now
> Sizeof {int, long, long long, void*, size_t, off_t}: {4, 8, 8, 8, 8, 8}
> root@ks-yoda:/tmp/buildd/bowtie-1.2.1.1+dfsg#

Thanks for the attempt to reproduce.  I tried to ignore the test results
at build time and installed the resulting package on my local machine.
Now the segfaults are not happening any more.  That's really strange.  I
do not think that the issue is caused due to a broken chroot (I'm
actually using cowbuilder not pbuilder) since I can reproduce the
problem on three different machines.

Besides the build problem I need to ask the bioinformaticans on the
Debian Med list about changes in the output of bowtie.  If I run the
test suite with the freshly installed package I get things like:


Error testing example
--- tests/example1.out  2017-09-04 14:11:54.115569050 +0200
+++ example1.out2017-09-23 07:41:11.214221005 +0200
@@ -1,5 +0,0 @@
--  gi|110640213|ref|NC_008253.1|   148810  10:A>G,13:C>G
--  gi|110640213|ref|NC_008253.1|   2852852 8:T>A
--  gi|110640213|ref|NC_008253.1|   4930433 4:G>T,6:C>G
--  gi|110640213|ref|NC_008253.1|   905664  6:A>G,7:G>T
-+  gi|110640213|ref|NC_008253.1|   1093035 2:T>G,15:A>T


I wonder whether some bioinformatican could at least reproduce this and
could comment on the test suite.

For general Debian Mentors I'll leave the question for more ideas why
the program segfaults inside pbuilder (at that time including debugging
symbols) but runs when installing the package on a real machine and
what I could do to track this down.

Kind regards

Andreas.


-- 
http://fam-tille.de

Re: Bowtie segfaults in pbuilder chroot at build time (Was: Issue with new version of Bowtie)

[Phil Wyett]

On Thu, 2017-09-21 at 22:42 +0200, Andreas Tille wrote:
> On Thu, Sep 21, 2017 at 07:00:27PM +0200, Steffen Möller wrote:
> > > That looks pretty similar and no visible missing. 
> > 
> > You have cowdancer - but you are right. Hm. Just because it works for me
> > without pbuilder - I know the build process takes a while but would you
> > mind much to confirm the crash when executed in your regular environment?
> 
> If I use debuild on a machine running *testing* bowtie builds fine and
> doese not segfault.
>  
> So either the difference is in testing <-> unstable or build on local
> machine <-> pbuilder chroot.
> 
> Kind regards
> 
>   Andreas.
> 

Hi,

At this current time on a pbuilder sid created using:

sudo pbuilder create --distribution sid --debootstrapopts --variant=buildd

I cannot reproduce seg faults at all. I have tracked back through the med list
and done all commands tested, one example:

root@ks-yoda:/tmp/buildd/bowtie-1.2.1.1+dfsg# ./bowtie --version
bowtie-align version 1.2.1.1
64-bit
Built on Debian-reproducible
Mon, 04 Sep 2017 14:13:56 +0200
Compiler: gcc version 7.2.0
Options: -O3  -Wl,--hash-style=both -DWITH_TBB -Wdate-time -D_FORTIFY_SOURCE=2
-g -O2 -fdebug-prefix-map=.=. -fstack-protector-strong -Wformat -Werror=format-
security  -g -O2 -fdebug-prefix-map=.=. -fstack-protector-strong -Wformat
-Werror=format-security -std=c++03 -Wl,-z,relro -Wl,-z,now
Sizeof {int, long, long long, void*, size_t, off_t}: {4, 8, 8, 8, 8, 8}
root@ks-yoda:/tmp/buildd/bowtie-1.2.1.1+dfsg#

Regards

Phil

-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

GitLab: https://gitlab.com/kathenas

Twitter: kathenasorg

Instagram: kathenasorg

GPG: 1B97 6556 913F 73F3 9C9B 25C4 2961 D9B6 2017 A57A

signature.asc
Description: This is a digitally signed message part

Re: Bowtie segfaults in pbuilder chroot at build time (Was: Issue with new version of Bowtie)

[Andreas Tille]

On Thu, Sep 21, 2017 at 07:00:27PM +0200, Steffen Möller wrote:
> > That looks pretty similar and no visible missing. 
> 
> You have cowdancer - but you are right. Hm. Just because it works for me
> without pbuilder - I know the build process takes a while but would you
> mind much to confirm the crash when executed in your regular environment?

If I use debuild on a machine running *testing* bowtie builds fine and
doese not segfault.
 
So either the difference is in testing <-> unstable or build on local
machine <-> pbuilder chroot.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Bowtie segfaults in pbuilder chroot at build time (Was: Issue with new version of Bowtie)

[Phil Wyett]

On Thu, 2017-09-21 at 15:12 +0200, Andreas Tille wrote:
> Hi Phil,
> 
> thanks for your attempt to help.
> 
> On Thu, Sep 21, 2017 at 12:15:50PM +0100, Phil Wyett wrote:
> > 1. Parallel build.
> > 
> > // Diff starts  on line below.
> > diff --git a/debian/rules b/debian/rules
> > index 7919361..b536ce7 100755
> > --- a/debian/rules
> > +++ b/debian/rules
> > @@ -11,7 +11,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> >  pkg := $(shell dpkg-parsechangelog | sed -n 's/^Source: //p')
> >  
> >  %:
> > -   dh $@
> > +   dh $@ --parallel
> >  
> >  override_dh_auto_build:
> > $(MAKE) allall
> > // Diff ends on line above.
> 
> That's redundant since debian/compat=10 is used.
>  
> > 2. At error the unit tests should dump a diff to std error.
> > 
> > The script is very old style and has errors.
> 
> Well, its old style but you replaced `` by $() which has the same
> result und adding "" around variables is probably better style but
> not solving any problem here.  Or am I missing something?
> 
> > // Diff starts  on line below.
> > diff --git a/debian/tests/run-unit-test b/debian/tests/run-unit-test
> > index dfcb0e5..1335a4b 100644
> > --- a/debian/tests/run-unit-test
> > +++ b/debian/tests/run-unit-test
> > @@ -5,19 +5,19 @@ if [ "$1" = "test_at_build_time" ] ; then
> >  else
> >  pkg=bowtie
> >  if [ "$ADTTMP" = "" ] ; then
> > -  ADTTMP=`mktemp -d /tmp/${pkg}-test.XX`
> > +  ADTTMP=$(mktemp -d /tmp/${pkg}-test.XX)
> >  fi
> > -mkdir -p $ADTTMP/tests
> > -cp -a debian/tests/example* $ADTTMP/tests
> > -cd $ADTTMP
> > -cp -a /usr/share/doc/bowtie/examples/indexes $ADTTMP
> > +mkdir -p "$ADTTMP"/tests
> > +cp -a debian/tests/example* "$ADTTMP"/tests
> > +cd "$ADTTMP"
> > +cp -a /usr/share/doc/bowtie/examples/indexes "$ADTTMP"
> >  fi
> >  
> >  check_result () {
> > -EDIFF=`diff -u tests/$1.out $1.out`
> > +EDIFF=$(diff -u tests/"$1".out "$1".out)
> >  if ! $EDIFF ; then
> >  echo "Error testing example"
> > -echo $EDIFF
> > +echo "$EDIFF"
> >  exit 1
> >  else
> >  echo "$1 OK"
> > // Diff ends on line above.
> > 
> > A diff is now outputted at example6.
> 
> That's no change at all.  The point is that *after* outputting the
> diff (which is the very same as without your changes) the segfault
> happens again.  The *very* strange thing is that the test suite
> works until example5 bit if I force an error before running the
> script and run it manually inside the chroot
> 
> 
> root@wr-linux01:/# cd build/bowtie-1.2.1.1+dfsg/
> root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ./bowtie
> Segmentation fault
> root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# sh debian/tests/run-unit-test
> test_at_build_time
> Segmentation fault
> debian/tests/run-unit-test: 18: debian/tests/run-unit-test: ---: not found
> Error testing example
> --- tests/example1.out  2017-09-21 12:55:02.0 +
> +++ example1.out2017-09-21 13:07:54.755536757 +
> @@ -1,5 +0,0 @@
> --  gi|110640213|ref|NC_008253.1|   148810  10:A>G,13:C>G
> --  gi|110640213|ref|NC_008253.1|   2852852 8:T>A
> --  gi|110640213|ref|NC_008253.1|   4930433 4:G>T,6:C>G
> --  gi|110640213|ref|NC_008253.1|   905664  6:A>G,7:G>T
> -+  gi|110640213|ref|NC_008253.1|   1093035 2:T>G,15:A>T
> root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# bash debian/tests/run-unit-test
> test_at_build_time
> debian/tests/run-unit-test: line 27: 24652 Segmentation fault  bowtie -a
> -v 2 e_coli --suppress 1,5,6,7 -c ATGCATCATGCGCCAT > example1.out
> debian/tests/run-unit-test: line 18: ---: command not found
> Error testing example
> --- tests/example1.out  2017-09-21 12:55:02.0 +
> +++ example1.out2017-09-21 13:08:04.855722853 +
> @@ -1,5 +0,0 @@
> --  gi|110640213|ref|NC_008253.1|   148810  10:A>G,13:C>G
> --  gi|110640213|ref|NC_008253.1|   2852852 8:T>A
> --  gi|110640213|ref|NC_008253.1|   4930433 4:G>T,6:C>G
> --  gi|110640213|ref|NC_008253.1|   905664  6:A>G,7:G>T
> -+  gi|110640213|ref|NC_008253.1|   1093035 2:T>G,15:A>T
> 
> 
> 
> The problem happens even for example1.  So I keep on thinking that
> running inside the chroot is evident to reproduce the problem and
> the script itself

Re: Bowtie segfaults in pbuilder chroot at build time (Was: Issue with new version of Bowtie)

[Andreas Tille]

Hi Phil,

thanks for your attempt to help.

On Thu, Sep 21, 2017 at 12:15:50PM +0100, Phil Wyett wrote:
> 1. Parallel build.
> 
> // Diff starts  on line below.
> diff --git a/debian/rules b/debian/rules
> index 7919361..b536ce7 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -11,7 +11,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
>  pkg := $(shell dpkg-parsechangelog | sed -n 's/^Source: //p')
>  
>  %:
> -   dh $@
> +   dh $@ --parallel
>  
>  override_dh_auto_build:
> $(MAKE) allall
> // Diff ends on line above.

That's redundant since debian/compat=10 is used.
 
> 2. At error the unit tests should dump a diff to std error.
> 
> The script is very old style and has errors.

Well, its old style but you replaced `` by $() which has the same
result und adding "" around variables is probably better style but
not solving any problem here.  Or am I missing something?

> // Diff starts  on line below.
> diff --git a/debian/tests/run-unit-test b/debian/tests/run-unit-test
> index dfcb0e5..1335a4b 100644
> --- a/debian/tests/run-unit-test
> +++ b/debian/tests/run-unit-test
> @@ -5,19 +5,19 @@ if [ "$1" = "test_at_build_time" ] ; then
>  else
>  pkg=bowtie
>  if [ "$ADTTMP" = "" ] ; then
> -  ADTTMP=`mktemp -d /tmp/${pkg}-test.XX`
> +  ADTTMP=$(mktemp -d /tmp/${pkg}-test.XX)
>  fi
> -mkdir -p $ADTTMP/tests
> -cp -a debian/tests/example* $ADTTMP/tests
> -cd $ADTTMP
> -cp -a /usr/share/doc/bowtie/examples/indexes $ADTTMP
> +mkdir -p "$ADTTMP"/tests
> +cp -a debian/tests/example* "$ADTTMP"/tests
> +cd "$ADTTMP"
> +cp -a /usr/share/doc/bowtie/examples/indexes "$ADTTMP"
>  fi
>  
>  check_result () {
> -EDIFF=`diff -u tests/$1.out $1.out`
> +EDIFF=$(diff -u tests/"$1".out "$1".out)
>  if ! $EDIFF ; then
>  echo "Error testing example"
> -echo $EDIFF
> +echo "$EDIFF"
>  exit 1
>  else
>  echo "$1 OK"
> // Diff ends on line above.
> 
> A diff is now outputted at example6.

That's no change at all.  The point is that *after* outputting the
diff (which is the very same as without your changes) the segfault
happens again.  The *very* strange thing is that the test suite
works until example5 bit if I force an error before running the
script and run it manually inside the chroot


root@wr-linux01:/# cd build/bowtie-1.2.1.1+dfsg/
root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ./bowtie
Segmentation fault
root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# sh debian/tests/run-unit-test 
test_at_build_time
Segmentation fault
debian/tests/run-unit-test: 18: debian/tests/run-unit-test: ---: not found
Error testing example
--- tests/example1.out  2017-09-21 12:55:02.0 +
+++ example1.out2017-09-21 13:07:54.755536757 +
@@ -1,5 +0,0 @@
--  gi|110640213|ref|NC_008253.1|   148810  10:A>G,13:C>G
--  gi|110640213|ref|NC_008253.1|   2852852 8:T>A
--  gi|110640213|ref|NC_008253.1|   4930433 4:G>T,6:C>G
--  gi|110640213|ref|NC_008253.1|   905664  6:A>G,7:G>T
-+  gi|110640213|ref|NC_008253.1|   1093035 2:T>G,15:A>T
root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# bash debian/tests/run-unit-test 
test_at_build_time
debian/tests/run-unit-test: line 27: 24652 Segmentation fault  bowtie -a -v 
2 e_coli --suppress 1,5,6,7 -c ATGCATCATGCGCCAT > example1.out
debian/tests/run-unit-test: line 18: ---: command not found
Error testing example
--- tests/example1.out  2017-09-21 12:55:02.0 +
+++ example1.out2017-09-21 13:08:04.855722853 +
@@ -1,5 +0,0 @@
--  gi|110640213|ref|NC_008253.1|   148810  10:A>G,13:C>G
--  gi|110640213|ref|NC_008253.1|   2852852 8:T>A
--  gi|110640213|ref|NC_008253.1|   4930433 4:G>T,6:C>G
--  gi|110640213|ref|NC_008253.1|   905664  6:A>G,7:G>T
-+  gi|110640213|ref|NC_008253.1|   1093035 2:T>G,15:A>T



The problem happens even for example1.  So I keep on thinking that
running inside the chroot is evident to reproduce the problem and
the script itself is not the problem even if it produces strange
effects.  I would love to hear further opinions to the gdb output
I provided in my first mail to this thread on debian-mentors.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Bowtie segfaults in pbuilder chroot at build time (Was: Issue with new version of Bowtie)

[Phil Wyett]

On Thu, 2017-09-21 at 12:15 +0100, Phil Wyett wrote:
> On Thu, 2017-09-21 at 08:27 +0200, Andreas Tille wrote:
> > Hi Steffen,
> > 
> > On Wed, Sep 20, 2017 at 10:52:55PM +0200, Steffen Möller wrote:
> > > > ...
> > > > Error testing example
> > > > --- tests/example6.out 2017-09-20 13:07:01.0 + +++
> > > > example6.out 2017-09-20 13:13:53.186064608 + @@ -1 +1,5 @@ -
> > > > gi|110640213|ref|NC_008253.1| 2852852 8:T>A +-
> > > > gi|110640213|ref|NC_008253.1| 148810 10:A>G,13:C>G ++
> > > > gi|110640213|ref|NC_008253.1| 1093035 2:T>G,15:A>T +-
> > > > gi|110640213|ref|NC_008253.1| 905664 6:A>G,7:G>T +-
> > > > gi|110640213|ref|NC_008253.1| 4930433 4:G>T,6:C>G
> > > > debian/rules:46: recipe for target 'override_dh_auto_test' failed
> > > > make[1]: *** [override_dh_auto_test] Error 1
> > > > make[1]: Leaving directory '/build/bowtie-1.2.1.1+dfsg'
> > > > debian/rules:14: recipe for target 'build' failed
> > > > make: *** [build] Error 2
> > > > dpkg-buildpackage: error: debian/rules build gave error exit status 2
> > > > I: copying local configuration
> > > > E: Failed autobuilding of package
> > > > I: user script
> > > > /var/cache/pbuilder/build/cow.8814/tmp/hooks/C99_failed_build starting
> > > > root@wr-linux01:/# cd build/bowtie-1.2.1.1+dfsg/
> > > > root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ./bowtie
> > > > Segmentation fault
> > > > root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ./bowtie --version
> > > > Segmentation fault
> > > > 
> > > > 
> > > > You need to setup a pbuilder hook to be able to stop the build and
> > > > end up inside the pbuilder chroot.
> > > 
> > > Hm. I feel like building that outside the chroot ;)
> > > 
> > > > root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# apt-get install gdb
> > > > Reading package lists... Done
> > > > Building dependency tree   
> > > > Reading state information... Done
> > > > The following additional packages will be installed:
> > > >   libbabeltrace-ctf1 libbabeltrace1 libdw1 libelf1 libmpdec2 libpopt0
> > > > libpython3.5 libpython3.5-minimal libpython3.5-stdlib
> > > > ...
> > > > root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# gdb --args bowtie-align-s --
> > > > wrapper basic-0
> > > > GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> > > > ...
> > > > Type "apropos word" to search for commands related to "word"...
> > > > Reading symbols from bowtie-align-s...done.
> > > > (gdb) run
> > > > Starting program: /build/bowtie-1.2.1.1+dfsg/bowtie-align-s --wrapper
> > > > basic-0
> > > > [Thread debugging using libthread_db enabled]
> > > > Using host libthread_db library "/lib/x86_64-linux-
> > > > gnu/libthread_db.so.1".
> > > > 
> > > > Program received signal SIGSEGV, Segmentation fault.
> > > > 0x7652003e in dlsym () from /lib/x86_64-linux-gnu/libdl.so.2
> > > > (gdb)
> > > >  
> > > > 
> > > > Same happens when testing bowtie-align-l.
> > > > 
> > > > 
> > > > Does this ring a bell somehow?
> > > 
> > > Sounds like a missing dynamic library?
> > > 
> > > ldd bowtie-align-l gives me
> > > 
> > >     linux-vdso.so.1 (0x7ffcb73f3000)
> > >     libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7faf4d456000)
> > >     libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > > (0x7faf4d239000)
> > >     libtbb.so.2 => /usr/lib/x86_64-linux-gnu/libtbb.so.2
> > > (0x7faf4cffb000)
> > >     libtbbmalloc_proxy.so.2 =>
> > > /usr/lib/x86_64-linux-gnu/libtbbmalloc_proxy.so.2 (0x7faf4cdf7000)
> > >     libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> > > (0x7faf4ca78000)
> > >     libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7faf4c774000)
> > >     libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> > > (0x7faf4c55d000)
> > >     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7faf4c1c)
> > >     /lib64/ld-linux-x86-64.so.2 (0x7faf4d94c000)
> > >     libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> > > (0x7faf4bfbc000)
> 

Re: Bowtie segfaults in pbuilder chroot at build time (Was: Issue with new version of Bowtie)

[Phil Wyett]

On Thu, 2017-09-21 at 08:27 +0200, Andreas Tille wrote:
> Hi Steffen,
> 
> On Wed, Sep 20, 2017 at 10:52:55PM +0200, Steffen Möller wrote:
> > > ...
> > > Error testing example
> > > --- tests/example6.out 2017-09-20 13:07:01.0 + +++
> > > example6.out 2017-09-20 13:13:53.186064608 + @@ -1 +1,5 @@ -
> > > gi|110640213|ref|NC_008253.1| 2852852 8:T>A +-
> > > gi|110640213|ref|NC_008253.1| 148810 10:A>G,13:C>G ++
> > > gi|110640213|ref|NC_008253.1| 1093035 2:T>G,15:A>T +-
> > > gi|110640213|ref|NC_008253.1| 905664 6:A>G,7:G>T +-
> > > gi|110640213|ref|NC_008253.1| 4930433 4:G>T,6:C>G
> > > debian/rules:46: recipe for target 'override_dh_auto_test' failed
> > > make[1]: *** [override_dh_auto_test] Error 1
> > > make[1]: Leaving directory '/build/bowtie-1.2.1.1+dfsg'
> > > debian/rules:14: recipe for target 'build' failed
> > > make: *** [build] Error 2
> > > dpkg-buildpackage: error: debian/rules build gave error exit status 2
> > > I: copying local configuration
> > > E: Failed autobuilding of package
> > > I: user script
> > > /var/cache/pbuilder/build/cow.8814/tmp/hooks/C99_failed_build starting
> > > root@wr-linux01:/# cd build/bowtie-1.2.1.1+dfsg/
> > > root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ./bowtie
> > > Segmentation fault
> > > root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ./bowtie --version
> > > Segmentation fault
> > > 
> > > 
> > > You need to setup a pbuilder hook to be able to stop the build and
> > > end up inside the pbuilder chroot.
> > 
> > Hm. I feel like building that outside the chroot ;)
> > 
> > > root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# apt-get install gdb
> > > Reading package lists... Done
> > > Building dependency tree   
> > > Reading state information... Done
> > > The following additional packages will be installed:
> > >   libbabeltrace-ctf1 libbabeltrace1 libdw1 libelf1 libmpdec2 libpopt0
> > > libpython3.5 libpython3.5-minimal libpython3.5-stdlib
> > > ...
> > > root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# gdb --args bowtie-align-s --
> > > wrapper basic-0
> > > GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> > > ...
> > > Type "apropos word" to search for commands related to "word"...
> > > Reading symbols from bowtie-align-s...done.
> > > (gdb) run
> > > Starting program: /build/bowtie-1.2.1.1+dfsg/bowtie-align-s --wrapper
> > > basic-0
> > > [Thread debugging using libthread_db enabled]
> > > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x7652003e in dlsym () from /lib/x86_64-linux-gnu/libdl.so.2
> > > (gdb)
> > >  
> > > 
> > > Same happens when testing bowtie-align-l.
> > > 
> > > 
> > > Does this ring a bell somehow?
> > 
> > Sounds like a missing dynamic library?
> > 
> > ldd bowtie-align-l gives me
> > 
> >     linux-vdso.so.1 (0x7ffcb73f3000)
> >     libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7faf4d456000)
> >     libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > (0x7faf4d239000)
> >     libtbb.so.2 => /usr/lib/x86_64-linux-gnu/libtbb.so.2
> > (0x7faf4cffb000)
> >     libtbbmalloc_proxy.so.2 =>
> > /usr/lib/x86_64-linux-gnu/libtbbmalloc_proxy.so.2 (0x7faf4cdf7000)
> >     libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> > (0x7faf4ca78000)
> >     libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7faf4c774000)
> >     libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> > (0x7faf4c55d000)
> >     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7faf4c1c)
> >     /lib64/ld-linux-x86-64.so.2 (0x7faf4d94c000)
> >     libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7faf4bfbc000)
> >     librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7faf4bdb4000)
> >     libatomic.so.1 => /usr/lib/x86_64-linux-gnu/libatomic.so.1
> > (0x7faf4bbac000)
> >     libtbbmalloc.so.2 => /usr/lib/x86_64-linux-gnu/libtbbmalloc.so.2
> > (0x7faf4b96e000)
> > 
> > anything reported missing by ldd in your pbuilder environment?
> 
> Inside pbuilder chroot:
> 
> root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ldd bowtie-align-

Re: Bowtie segfaults in pbuilder chroot at build time (Was: Issue with new version of Bowtie)

[Andreas Tille]

Hi Steffen,

On Wed, Sep 20, 2017 at 10:52:55PM +0200, Steffen Möller wrote:
> > ...
> > Error testing example
> > --- tests/example6.out 2017-09-20 13:07:01.0 + +++ example6.out 
> > 2017-09-20 13:13:53.186064608 + @@ -1 +1,5 @@ - 
> > gi|110640213|ref|NC_008253.1| 2852852 8:T>A +- 
> > gi|110640213|ref|NC_008253.1| 148810 10:A>G,13:C>G ++ 
> > gi|110640213|ref|NC_008253.1| 1093035 2:T>G,15:A>T +- 
> > gi|110640213|ref|NC_008253.1| 905664 6:A>G,7:G>T +- 
> > gi|110640213|ref|NC_008253.1| 4930433 4:G>T,6:C>G
> > debian/rules:46: recipe for target 'override_dh_auto_test' failed
> > make[1]: *** [override_dh_auto_test] Error 1
> > make[1]: Leaving directory '/build/bowtie-1.2.1.1+dfsg'
> > debian/rules:14: recipe for target 'build' failed
> > make: *** [build] Error 2
> > dpkg-buildpackage: error: debian/rules build gave error exit status 2
> > I: copying local configuration
> > E: Failed autobuilding of package
> > I: user script 
> > /var/cache/pbuilder/build/cow.8814/tmp/hooks/C99_failed_build starting
> > root@wr-linux01:/# cd build/bowtie-1.2.1.1+dfsg/
> > root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ./bowtie
> > Segmentation fault
> > root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ./bowtie --version
> > Segmentation fault
> >
> >
> > You need to setup a pbuilder hook to be able to stop the build and
> > end up inside the pbuilder chroot.
> 
> Hm. I feel like building that outside the chroot ;)
> 
> > root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# apt-get install gdb
> > Reading package lists... Done
> > Building dependency tree   
> > Reading state information... Done
> > The following additional packages will be installed:
> >   libbabeltrace-ctf1 libbabeltrace1 libdw1 libelf1 libmpdec2 libpopt0 
> > libpython3.5 libpython3.5-minimal libpython3.5-stdlib
> > ...
> > root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# gdb --args bowtie-align-s 
> > --wrapper basic-0
> > GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> > ...
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from bowtie-align-s...done.
> > (gdb) run
> > Starting program: /build/bowtie-1.2.1.1+dfsg/bowtie-align-s --wrapper 
> > basic-0
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x7652003e in dlsym () from /lib/x86_64-linux-gnu/libdl.so.2
> > (gdb)
> >  
> >
> > Same happens when testing bowtie-align-l.
> >
> >
> > Does this ring a bell somehow?
> 
> Sounds like a missing dynamic library?
> 
> ldd bowtie-align-l gives me
> 
>     linux-vdso.so.1 (0x7ffcb73f3000)
>     libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7faf4d456000)
>     libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7faf4d239000)
>     libtbb.so.2 => /usr/lib/x86_64-linux-gnu/libtbb.so.2
> (0x7faf4cffb000)
>     libtbbmalloc_proxy.so.2 =>
> /usr/lib/x86_64-linux-gnu/libtbbmalloc_proxy.so.2 (0x7faf4cdf7000)
>     libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x7faf4ca78000)
>     libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7faf4c774000)
>     libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x7faf4c55d000)
>     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7faf4c1c)
>     /lib64/ld-linux-x86-64.so.2 (0x7faf4d94c000)
>     libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7faf4bfbc000)
>     librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7faf4bdb4000)
>     libatomic.so.1 => /usr/lib/x86_64-linux-gnu/libatomic.so.1
> (0x7faf4bbac000)
>     libtbbmalloc.so.2 => /usr/lib/x86_64-linux-gnu/libtbbmalloc.so.2
> (0x7faf4b96e000)
> 
> anything reported missing by ldd in your pbuilder environment?

Inside pbuilder chroot:

root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ldd bowtie-align-l  
linux-vdso.so.1 (0x7ffe9511a000)
/usr/lib/cowdancer/libcowdancer.so (0x7f56d5209000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f56d4feb000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f56d4dce000)
libtbb.so.2 => /lib/x86_64-linux-gnu/libtbb.so.2 (0x7f56d4b9)
libtbbmalloc_proxy.so.2 => 
/lib/x86_64-linux-gnu/libtbbmalloc_proxy.so.2 (0x7f56d498c000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libs

Re: Bowtie segfaults in pbuilder chroot at build time (Was: Issue with new version of Bowtie)

[Steffen Möller]

On 20.09.17 15:44, Andreas Tille wrote:
> [switching back to list discussion also involving debian-mentors.
>  Please see the gdb output below I get when installing gdb inside the
>  pbuilder chroot.]
>
> Hi Steffen,
>
> On Wed, Sep 20, 2017 at 02:26:20PM +0200, Steffen Möller wrote:
>>>> /build/bowtie-1.2.1.1+dfsg# ./bowtie -a -v 2 e_coli --suppress 1,5,6,7 -c 
>>>> ATGCATCATGCGCCAT
>>>> Segmentation fault
>>>>
>>>>
>>>> I intended to open an issue on Github but when doing so I wanted to leave
>>>> a proof that we are using the latest upstream version:
>>>>
>>>>
>>>> /build/bowtie-1.2.1.1+dfsg# ./bowtie -v
>>>> Segmentation fault
>>>>
>>>>
>>>> Hups, I think something is wrong at our side and the build has a problem.
>>>>
>>>> Has anybody some spare cylces to track this down?
>>> Any volunteer?
>>
>> Not really, except that on my virtual machine "bowtie -v" shows the
>> expected (long) usage information.
> I guess you try to test the *existing* bowtie package.  Please note
> that I was talking about the new version in Git which I try to build
> and the segfault happens in the pbuilder chroot (I just learned that
> you are rarely using pbuilder - see subsequent fast5 uploads :-P ).

I was using it (for -2  and later versions at least), but for some weird
reason that issue did not surface in pbulder (if you allow me to point to
your  -5 upload) or was only spotted during my building of a reverse
dependency.


> So please try to build latest Git (git.debian.org seems to be offline
> currently). 
It is back.
>  I get:
>
> ...
> Error testing example
> --- tests/example6.out 2017-09-20 13:07:01.0 + +++ example6.out 
> 2017-09-20 13:13:53.186064608 + @@ -1 +1,5 @@ - 
> gi|110640213|ref|NC_008253.1| 2852852 8:T>A +- gi|110640213|ref|NC_008253.1| 
> 148810 10:A>G,13:C>G ++ gi|110640213|ref|NC_008253.1| 1093035 2:T>G,15:A>T +- 
> gi|110640213|ref|NC_008253.1| 905664 6:A>G,7:G>T +- 
> gi|110640213|ref|NC_008253.1| 4930433 4:G>T,6:C>G
> debian/rules:46: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 1
> make[1]: Leaving directory '/build/bowtie-1.2.1.1+dfsg'
> debian/rules:14: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> I: copying local configuration
> E: Failed autobuilding of package
> I: user script /var/cache/pbuilder/build/cow.8814/tmp/hooks/C99_failed_build 
> starting
> root@wr-linux01:/# cd build/bowtie-1.2.1.1+dfsg/
> root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ./bowtie
> Segmentation fault
> root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ./bowtie --version
> Segmentation fault
>
>
> You need to setup a pbuilder hook to be able to stop the build and
> end up inside the pbuilder chroot.

Hm. I feel like building that outside the chroot ;)

>
>> So, I cannot immediately reproduce
>> the behaviour you observe. What does "bowtie --version" do for you? 
> See above - but we are most probably talking about different things.

Hm.

So, I get this:

example5 OK
# reads processed: 5
# reads with at least one reported alignment: 5 (100.00%)
# reads that failed to align: 0 (0.00%)
Reported 5 alignments to 1 output stream(s)
debian/tests/run-unit-test: 18: debian/tests/run-unit-test: ---: not found
Error testing example
--- tests/example6.out 2017-09-20 22:18:16.708036897 +0200 +++
example6.out 2017-09-20 22:25:50.634724676 +0200 @@ -1 +1,5 @@ -
gi|110640213|ref|NC_008253.1| 2852852 8:T>A +-
gi|110640213|ref|NC_008253.1| 148810 10:A>G,13:C>G ++
gi|110640213|ref|NC_008253.1| 1093035 2:T>G,15:A>T +-
gi|110640213|ref|NC_008253.1| 905664 6:A>G,7:G>T +-
gi|110640213|ref|NC_008253.1| 4930433 4:G>T,6:C>G
debian/rules:46: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/home/moeller/git/debian-med/bowtie'
debian/rules:14: recipe for target 'binary' failed
make: *** [binary] Error 2


I interpret this like the first 5 examples being fine, just the 6th
failing. When executign directly, I get


$ ./bowtie -a --best --strata -v 2 --suppress 1,5,6,7 e_coli -c
ATGCATCATGCGCCAT
-   gi|110640213|ref|NC_008253.1|   2852852 8:T>A
-   gi|110640213|ref|NC_008253.1|   148810  10:A>G,13:C>G
+   gi|110640213|ref|NC_008253.1|   1093035 2:T>G,15:A>T
-   gi|110640213|ref|NC_008253.1|   905664  6:A>G,7:G>T
-   gi|110640213|ref|NC_008253.1|   4930433 4:G>T,6:C>G
# reads processed: 5
# reads with at least one reported alignment: 5 (100.00%)
# reads 

Bowtie segfaults in pbuilder chroot at build time (Was: Issue with new version of Bowtie)

[Andreas Tille]

[switching back to list discussion also involving debian-mentors.
 Please see the gdb output below I get when installing gdb inside the
 pbuilder chroot.]

Hi Steffen,

On Wed, Sep 20, 2017 at 02:26:20PM +0200, Steffen Möller wrote:
> >> /build/bowtie-1.2.1.1+dfsg# ./bowtie -a -v 2 e_coli --suppress 1,5,6,7 -c 
> >> ATGCATCATGCGCCAT
> >> Segmentation fault
> >>
> >>
> >> I intended to open an issue on Github but when doing so I wanted to leave
> >> a proof that we are using the latest upstream version:
> >>
> >>
> >> /build/bowtie-1.2.1.1+dfsg# ./bowtie -v
> >> Segmentation fault
> >>
> >>
> >> Hups, I think something is wrong at our side and the build has a problem.
> >>
> >> Has anybody some spare cylces to track this down?
> > Any volunteer?
> 
> 
> Not really, except that on my virtual machine "bowtie -v" shows the
> expected (long) usage information.

I guess you try to test the *existing* bowtie package.  Please note
that I was talking about the new version in Git which I try to build
and the segfault happens in the pbuilder chroot (I just learned that
you are rarely using pbuilder - see subsequent fast5 uploads :-P ).
So please try to build latest Git (git.debian.org seems to be offline
currently).  I get:

...
Error testing example
--- tests/example6.out 2017-09-20 13:07:01.0 + +++ example6.out 
2017-09-20 13:13:53.186064608 + @@ -1 +1,5 @@ - 
gi|110640213|ref|NC_008253.1| 2852852 8:T>A +- gi|110640213|ref|NC_008253.1| 
148810 10:A>G,13:C>G ++ gi|110640213|ref|NC_008253.1| 1093035 2:T>G,15:A>T +- 
gi|110640213|ref|NC_008253.1| 905664 6:A>G,7:G>T +- 
gi|110640213|ref|NC_008253.1| 4930433 4:G>T,6:C>G
debian/rules:46: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/build/bowtie-1.2.1.1+dfsg'
debian/rules:14: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
I: copying local configuration
E: Failed autobuilding of package
I: user script /var/cache/pbuilder/build/cow.8814/tmp/hooks/C99_failed_build 
starting
root@wr-linux01:/# cd build/bowtie-1.2.1.1+dfsg/
root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ./bowtie
Segmentation fault
root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# ./bowtie --version
Segmentation fault


You need to setup a pbuilder hook to be able to stop the build and
end up inside the pbuilder chroot.

> So, I cannot immediately reproduce
> the behaviour you observe. What does "bowtie --version" do for you? 

See above - but we are most probably talking about different things.

> Should we add "bowtie -v" as an autotest, just testing that it does not
> crash but that it exits with a bad code ( == 1) ?

I assume this test will not be necessary since it is not really
`bowtie -v` which breaks but *any* call of bowtie segfaults inside
the pbuilder environment.

> Another question to me is why we do not have a bowtie-dbgsym package.
> Where is it?

No idea but hey, I installed gdb into the pbuilder environment and did:

root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# apt-get install gdb
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  libbabeltrace-ctf1 libbabeltrace1 libdw1 libelf1 libmpdec2 libpopt0 
libpython3.5 libpython3.5-minimal libpython3.5-stdlib
...
root@wr-linux01:/build/bowtie-1.2.1.1+dfsg# gdb --args bowtie-align-s --wrapper 
basic-0
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
...
Type "apropos word" to search for commands related to "word"...
Reading symbols from bowtie-align-s...done.
(gdb) run
Starting program: /build/bowtie-1.2.1.1+dfsg/bowtie-align-s --wrapper basic-0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x7652003e in dlsym () from /lib/x86_64-linux-gnu/libdl.so.2
(gdb)
 

Same happens when testing bowtie-align-l.


Does this ring a bell somehow?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Piuparts fails when attempting to create chroot

[Ben Finney]

Howdy all,

When Piuparts runs in an Sbuild session, it fails with a traceback:

=
0m0.7s DEBUG: Command ok: ['dpkg', '--info', 
'/home/bignose/Projects/debian/python-coverage/build-area/python3-coverage_4.4.1+dfsg.1-1_amd64.deb']
0m0.7s DEBUG: Created temporary directory /tmp/tmphwGgjf
0m0.7s DEBUG: Copying /srv/chroot/unstable-amd64-sbuild/ into /tmp/tmphwGgjf
0m0.7s DEBUG: Starting command: ['mount', '-t', 'proc', 'proc', 
'/tmp/tmphwGgjf/proc']
0m0.7s DEBUG: Command ok: ['mount', '-t', 'proc', 'proc', '/tmp/tmphwGgjf/proc']

Piuparts caught exception, exiting...

Traceback (most recent call last):
  File "/usr/sbin/piuparts", line 3461, in 
main()
  File "/usr/sbin/piuparts", line 3446, in main
process_packages(package_list)
  File "/usr/sbin/piuparts", line 3345, in process_packages
chroot.create()
  File "/usr/sbin/piuparts", line 786, in create
self.mount_proc()
  File "/usr/sbin/piuparts", line 1689, in mount_proc
os.symlink("../proc/mounts", etcmtab)
OSError: [Errno 2] No such file or directory

0m1.0s DEBUG: Starting command: ['umount', '/tmp/tmphwGgjf/proc']
0m1.0s DEBUG: Command ok: ['umount', '/tmp/tmphwGgjf/proc']
0m1.0s DEBUG: Starting command: ['rm', '-rf', '--one-file-system', 
'/tmp/tmphwGgjf']
0m1.0s DEBUG: Command ok: ['rm', '-rf', '--one-file-system', '/tmp/tmphwGgjf']
0m1.0s DEBUG: Removed directory tree at /tmp/tmphwGgjf
0m1.0s ERROR: piuparts run ends.

E: Piuparts run failed.
=

What can I do to correct this and allow Piuparts to proceed?

-- 
 \ “I know you believe you understood what you think I said, but I |
  `\ am not sure you realize that what you heard is not what I |
_o__) meant.” —Robert J. McCloskey |
Ben Finney

Re: Ups, pbuilder chroot broken - here comes the real build error (Was: New version of phyml: Can't exec "gcc": No such file or directory)

[James Cowgill]

Hi,

On 17/08/16 14:36, Andreas Tille wrote:
> On Wed, Aug 17, 2016 at 01:55:23PM +0100, James Cowgill wrote:
>>
>> I think there might be something up with your pbuilder chroot.s
> 
> After updating this the strange error vanished - sorry for the noise.
> 
>> At least
>> the initial stages of the build work fine for me with sbuild (gcc errors
>> out later though).
> 
> So lets come to the real build errors of [1]: I just fixed the first issue
> in a new patch (please git pull) but I do not understand this one:
> 
> ...
> gcc  -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -Wall -O2 -msse 
> -fomit-frame-pointer -funroll-loops -Wempty-body -Wuninitialized  
> -I/usr/include/libhmsbeagle-1 -lhmsbeagle -ldl  -c -o lk.o lk.c
> lk.c: In function 'Update_PMat_At_Given_Edge':
> lk.c:2449:31: error: invalid initializer
>int p_matrices[1] = b_fcus->Pij_rr_idx;
>^~
> lk.c:2450:31: error: invalid initializer
>double branch_lens[1] = len;

You can't initialize an array with a scalar value (double[] != double).
Also, using an array of fixed size 1 is a code smell (why use an array
at all?)

The quick fix here is probably to wrap the values in curly braces to
form a correct array initializer.

James



signature.asc
Description: OpenPGP digital signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Johannes Schauer]

Hi Paul,

Quoting Paul Elliott (2016-08-05 21:28:25)
> OK this time I deleted the recommended files as before, but I noted there
> were no other chroots in use. So I purged both sbuild and schroot with
> apt-get and reinstalled.

note that purging sbuild and schroot will not remove the chroots. But it will
get you a clean initual configuration.

> I then recreated th chroot using steps 1-6 of "Create the chroot" from the
> wiki page.

Which sbuild version are you using? Since fixing of bug #801798 (so since
sbuild version 0.67.0) steps 2 and 3 from that wiki page are not useful
anymore, unless you want to build packages for Debian squeeze.

Also, step 4 has only to be done once after you installed sbuild and not every
time you create a new chroot.

> I get the same error!
> 
> Setup apt archive
> -
> 
> Merged Build-Depends: build-essential, fakeroot
> Filtered Build-Depends: build-essential, fakeroot
> dpkg-deb: building package 'sbuild-build-depends-core-dummy' in
> '/<>/resolver-aIr7Ri/apt_archive/sbuild-build-depends-core-dummy.deb'.
> dpkg-deb: error: failed to make temporary file (control member): No such
> file or directory
> Dummy package creation failed
> E: Setting up apt archive failed
> +--+
> | Cleanup
> 
> 
> Some how some bad data is being stored in some unknown place.
> 
> Is there any way to figure out what directory does not exist? (control
> member)

Please file a bug report against sbuild. Even if the problem is on your side,
the above error message is very cryptic and not helpful at all. In your bug
report, please include the following:

 - which sbuild version are you using?
 - which Debian release are you using?
 - list precisely which commands you are executing

Thanks!

cheers, josch


signature.asc
Description: signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Adam Borowski]

On Fri, Aug 05, 2016 at 10:07:23PM +0200, Jakub Wilk wrote:
> * Wookey , 2016-08-05, 20:56:
> >I think there is a way to stop it putting i the <>
> >substitutions, but I can't find that now.
> 
> In /etc/sbuild/sbuild.conf set:
> $log_filter = 0;
> 
> (It's beyond me why this is enabled by default.)

It makes build logs significantly more readble, and in the rare case you
actually need that information, it's right there near the start.

-- 
An imaginary friend squared is a real enemy.

Re: How do you delete a sbuild an sbuild chroot and start over?

[Jakub Wilk]

* Jakub Wilk , 2016-08-05, 22:07:

* Wookey , 2016-08-05, 20:56:
I think there is a way to stop it putting i the <> 
substitutions, but I can't find that now.


In /etc/sbuild/sbuild.conf set:
$log_filter = 0;


You can also use this tool to (hopefully) reverse filtering:
https://github.com/jwilk/deb-toolbox/blob/master/unfudge-build-log

--
Jakub Wilk

Re: How do you delete a sbuild an sbuild chroot and start over?

[Jakub Wilk]

* Wookey , 2016-08-05, 20:56:
I think there is a way to stop it putting i the <> 
substitutions, but I can't find that now.


In /etc/sbuild/sbuild.conf set:
$log_filter = 0;


(It's beyond me why this is enabled by default.)

--
Jakub Wilk

Re: How do you delete a sbuild an sbuild chroot and start over?

[Wookey]

On 2016-08-05 14:28 -0500, Paul Elliott wrote:

> dpkg-deb: building package 'sbuild-build-depends-core-dummy' in 
> '/<>/
> resolver-aIr7Ri/apt_archive/sbuild-build-depends-core-dummy.deb'.
> dpkg-deb: error: failed to make temporary file (control member): No such file
> or directory

> Is there any way to figure out what directory does not exist? (control member)

<> tells you what it is at the top of the log: 
e.g.
I: NOTICE: Log filtering will replace 'build/most-Ru6goH/most-5.0.0a' with 
'«PKGBUILDDIR»'
I: NOTICE: Log filtering will replace 'build/most-Ru6goH' with '«BUILDDIR»'
I: NOTICE: Log filtering will replace 
'var/lib/schroot/mount/sid-arm64-sbuild-9ba727aa-c9d7-4d64-9d2a-679b6ad14a8e' 
with '«CHROOT»'

So you can find out what directory it is trying to use. I guess maybe
you have a permissions problem?
 

You may also find that --log-external-command-output and 
--log-external-command-error
will help. 

--debug will give you buckloads of output, which again may help clarify the 
issue.

I think there is a way to stop it putting i the <>
substitutions, but I can't find that now.



Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Paul Elliott]

OK this time I deleted the recommended files as before, but I noted there
were no other chroots in use. So I purged both sbuild and schroot with
apt-get and reinstalled.

I then recreated th chroot using steps 1-6 of "Create the chroot" from the
wiki page.

I get the same error!

Setup apt archive
-

Merged Build-Depends: build-essential, fakeroot
Filtered Build-Depends: build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-core-dummy' in
'/<>/resolver-aIr7Ri/apt_archive/sbuild-build-depends-core-dummy.deb'.
dpkg-deb: error: failed to make temporary file (control member): No such
file or directory
Dummy package creation failed
E: Setting up apt archive failed
+--+
| Cleanup


Some how some bad data is being stored in some unknown place.

Is there any way to figure out what directory does not exist? (control
member)

Thank You


On Fri, Aug 5, 2016 at 2:42 AM, Paul Elliott <pelli...@blackpatchpanel.com>
wrote:

> Ok, I deleted my old sbuild chroot for debian testing.
>
> I then created two sbuild chroot according to the wiki instructions.
>
> For testing, and for unstable.
>
> I have then tried to build 2 different packages, on the different chroots.
>
>
> I always get the following error:
> Setup apt archive
> -
>
> Merged Build-Depends: build-essential, fakeroot
> Filtered Build-Depends: build-essential, fakeroot
> dpkg-deb: building package 'sbuild-build-depends-core-dummy' in
> '/<>/resolver-mAdLP4/apt_archive/sbuild-
> build-depends-core-dummy.deb'.
> dpkg-deb: error: failed to make temporary file (control member): No such
> file or directory
> Dummy package creation failed
> E: Setting up apt archive failed
> +---
> -------+
> | Cleanup
>
> I am not sure if this error is because of the way I deleted the old
> chroot. Before I was getting a different error complaining
> that debfoster does not exist under "testing". BTW why does debfoster fail
> to exist under testing?
>
> Any ideas what the problem is with the above error? As far as I can figure
> out sbuild-build-depends-core-dummy does not even exist.
>
>
> Thank You
> --
> Paul Elliott   1(512)837-1096
> pelli...@blackpatchpanel.com   3300 Plaza Drive, apt 1
> http://www.free.blackpatchpanel.com/pme/   New Albany, IN 47150
>
>
> On Tue, Aug 2, 2016 at 11:06 PM, Paul Elliott <
> pelli...@blackpatchpanel.com> wrote:
>
>>
>>
>> Sometimes a user gets a sbuild chroot so screwed up that it does not
>> work anymore, and the user has no idea how to fix it, because he does not
>> know what he did wrong.
>>
>> He wants to start over from scratch.
>>
>> The problem is, it is not documented the correct way to delete
>> the chroot and tar ball. The users want to put sbuild back to
>> the way it was just after sbuild was installed.
>>
>>
>> What is the proper way to do that?
>>
>> Thank You for your answers.
>>
>>
>> --
>> Paul Elliott   1(512)837-1096
>> pelli...@blackpatchpanel.com   3300 Plaza Drive, apt 1
>> http://www.free.blackpatchpanel.com/pme/   New Albany, IN 47150
>>
>
>

Re: How do you delete a sbuild an sbuild chroot and start over?

[Johannes Schauer]

Hi,

Quoting Andrey Rahmatullin (2016-08-05 09:49:11)
> On Fri, Aug 05, 2016 at 02:42:27AM -0500, Paul Elliott wrote:
> > Before I was getting a different error complaining
> > that debfoster does not exist under "testing". BTW why does debfoster fail
> > to exist under testing?
> Because it was removed from testing and the new version hasn't entered
> testing yet.

note, that version 0.70.0 of sbuild in unstable (also didn't migrate to testing
yet) doesn't add debfoster to the chroot by default anymore.

So your problem shouldn't exist anymore with the most recent sbuild release.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Andrey Rahmatullin]

On Fri, Aug 05, 2016 at 02:42:27AM -0500, Paul Elliott wrote:
> Before I was getting a different error complaining
> that debfoster does not exist under "testing". BTW why does debfoster fail
> to exist under testing?
Because it was removed from testing and the new version hasn't entered
testing yet.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Paul Elliott]

Ok, I deleted my old sbuild chroot for debian testing.

I then created two sbuild chroot according to the wiki instructions.

For testing, and for unstable.

I have then tried to build 2 different packages, on the different chroots.


I always get the following error:
Setup apt archive
-

Merged Build-Depends: build-essential, fakeroot
Filtered Build-Depends: build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-core-dummy' in
'/<>/resolver-mAdLP4/apt_archive/sbuild-build-depends-core-dummy.deb'.
dpkg-deb: error: failed to make temporary file (control member): No such
file or directory
Dummy package creation failed
E: Setting up apt archive failed
+--+
| Cleanup

I am not sure if this error is because of the way I deleted the old chroot.
Before I was getting a different error complaining
that debfoster does not exist under "testing". BTW why does debfoster fail
to exist under testing?

Any ideas what the problem is with the above error? As far as I can figure
out sbuild-build-depends-core-dummy does not even exist.


Thank You
--
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   3300 Plaza Drive, apt 1
http://www.free.blackpatchpanel.com/pme/   New Albany, IN 47150


On Tue, Aug 2, 2016 at 11:06 PM, Paul Elliott <pelli...@blackpatchpanel.com>
wrote:

>
>
> Sometimes a user gets a sbuild chroot so screwed up that it does not
> work anymore, and the user has no idea how to fix it, because he does not
> know what he did wrong.
>
> He wants to start over from scratch.
>
> The problem is, it is not documented the correct way to delete
> the chroot and tar ball. The users want to put sbuild back to
> the way it was just after sbuild was installed.
>
>
> What is the proper way to do that?
>
> Thank You for your answers.
>
>
> --
> Paul Elliott   1(512)837-1096
> pelli...@blackpatchpanel.com   3300 Plaza Drive, apt 1
> http://www.free.blackpatchpanel.com/pme/   New Albany, IN 47150
>

Re: How do you delete a sbuild an sbuild chroot and start over?

[Sean Whitton]

Hello,

On Wed, Aug 03, 2016 at 10:21:46AM +0200, Jonas Meurer wrote:
> Please note that this will delete *all* chroots and their configuration.
> I woud prefer something like:

That's what he said he wanted to do :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Wookey]

On 2016-08-03 13:12 +0200, Johannes Schauer wrote:
> Hi,
> 
> Quoting Paul Wise (2016-08-03 12:41:28)
> > > As far as I know, schroot still doesn't
> > > document how to delete a chroot.
> > 
> > Seems to me like sbuild should have an sbuild-deletechroot command
> > that should call the relevant tool for the chroot in question and
> > schroot should have a corresponding command that would DTRT.
> 
> it is unlikely, that there will be a schroot command that does the right thing
> because schroot also leaves it up to the user to create the chroot in the 
> first
> place. This is also why sbuild-createchroot is doing everything manually
> including assembling the right schroot configuration file.

schroot does have the info it needs though - to lok up where the chroot is 
stored and remove it, so it could...
 
> My last attempt at implementing a command that does this was stopped early on
> by the question how this tool should best be called:
> 
>  - sbuild-deletechroot
>  - sbuild-removechroot
>  - sbuild-destroychroot
> 
> Maybe a native English speaker could tell me the most natural choice for a 
> tool
> that does the opposite of what sbuild-createchroot does.

'destroy' is closest to the opposite of 'create'. But 'remove' sounds
a bit less cataclysmic :-) Either will do fine.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Johannes Schauer]

Hi,

Quoting Paul Wise (2016-08-03 12:41:28)
> On Wed, Aug 3, 2016 at 1:06 PM, Johannes Schauer wrote:
> 
> > The main issue here is, that it is not clear *where* the bug should be 
> > filed.
> > Sbuild supports multiple backends. The probably most used one is the schroot
> > backend because that is used by sbuild-createchroot and the default of the
> > CHROOT_MODE configuration variable.
> >
> > Indeed I do remember having had a similar question when I started using 
> > sbuild
> > but never got around filing a bug. As far as I know, schroot still doesn't
> > document how to delete a chroot.
> 
> Seems to me like sbuild should have an sbuild-deletechroot command
> that should call the relevant tool for the chroot in question and
> schroot should have a corresponding command that would DTRT.

it is unlikely, that there will be a schroot command that does the right thing
because schroot also leaves it up to the user to create the chroot in the first
place. This is also why sbuild-createchroot is doing everything manually
including assembling the right schroot configuration file.

My last attempt at implementing a command that does this was stopped early on
by the question how this tool should best be called:

 - sbuild-deletechroot
 - sbuild-removechroot
 - sbuild-destroychroot

Maybe a native English speaker could tell me the most natural choice for a tool
that does the opposite of what sbuild-createchroot does.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Paul Wise]

On Wed, Aug 3, 2016 at 1:06 PM, Johannes Schauer wrote:

> The main issue here is, that it is not clear *where* the bug should be filed.
> Sbuild supports multiple backends. The probably most used one is the schroot
> backend because that is used by sbuild-createchroot and the default of the
> CHROOT_MODE configuration variable.
>
> Indeed I do remember having had a similar question when I started using sbuild
> but never got around filing a bug. As far as I know, schroot still doesn't
> document how to delete a chroot.

Seems to me like sbuild should have an sbuild-deletechroot command
that should call the relevant tool for the chroot in question and
schroot should have a corresponding command that would DTRT.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: How do you delete a sbuild an sbuild chroot and start over?

[Jonas Meurer]

Am 03.08.2016 um 06:20 schrieb Sean Whitton:
> On Tue, Aug 02, 2016 at 11:06:31PM -0500, Paul Elliott wrote:
>> Sometimes a user gets a sbuild chroot so screwed up that it does not
>> work anymore, and the user has no idea how to fix it, because he does not
>> know what he did wrong.
>>
>> He wants to start over from scratch.
>>
>> The problem is, it is not documented the correct way to delete
>> the chroot and tar ball. The users want to put sbuild back to
>> the way it was just after sbuild was installed.
>>
>>
>> What is the proper way to do that?
> 
> Asking for a friend? ;)
> 
> Assuming you used the suggestions for making the chroot on the sbuild
> wiki page, this should do it:
> 
> # rm -rf /srv/chroot/* /etc/sbuild/chroot/*-sbuild 
> /etc/schroot/chroot.d/*-sbuild

Please note that this will delete *all* chroots and their configuration.
I woud prefer something like:

SCHROOT=unstable-amd64-sbuild
SCHROOT_DIR=$(readlink -e /etc/sbuild/${SCHROOT})
rm -r ${SCHROOT_DIR} /etc/sbuild/${SCHROOT} \
/etc/schroot/chroot.d/$[SCHROOT}-*

Afterwards you can start over by creating a fresh version of the schroot
with sbuild-createchroot as documented on the wiki page[1].

Cheers,
 jonas

[1] https://wiki.debian.org/sbuild

> If you didn't use the suggestions on the wiki page, just start nuking
> stuff in those three directories.
> 




signature.asc
Description: OpenPGP digital signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Johannes Schauer]

Hi Paul,

Quoting Sean Whitton (2016-08-03 06:20:26)
> On Tue, Aug 02, 2016 at 11:06:31PM -0500, Paul Elliott wrote:
> > Sometimes a user gets a sbuild chroot so screwed up that it does not
> > work anymore, and the user has no idea how to fix it, because he does not
> > know what he did wrong.
> > 
> > He wants to start over from scratch.
> > 
> > The problem is, it is not documented the correct way to delete
> > the chroot and tar ball. The users want to put sbuild back to
> > the way it was just after sbuild was installed.

if it's not documented, you should file a bug about that. ;)

The main issue here is, that it is not clear *where* the bug should be filed.
Sbuild supports multiple backends. The probably most used one is the schroot
backend because that is used by sbuild-createchroot and the default of the
CHROOT_MODE configuration variable.

Indeed I do remember having had a similar question when I started using sbuild
but never got around filing a bug. As far as I know, schroot still doesn't
document how to delete a chroot.

> > What is the proper way to do that?
> 
> Asking for a friend? ;)
> 
> Assuming you used the suggestions for making the chroot on the sbuild
> wiki page, this should do it:
> 
> # rm -rf /srv/chroot/* /etc/sbuild/chroot/*-sbuild 
> /etc/schroot/chroot.d/*-sbuild
> 
> If you didn't use the suggestions on the wiki page, just start nuking
> stuff in those three directories.

Paul was talking about "a chroot" (singular). The above advice kills all
chroots including those that are not related to sbuild. Assuming that you are
using the schroot backend, you can do the following:

 1. figure out which schroot you were using with sbuild. If you used an
unstable chroot on amd64, then look out for a file that is called like
/etc/schroot/chroot.d/unstable-amd64-sbuild-XX where XX is a random
ASCII string
 2. look inside that file to figure out where the chroot data lives in your
file system by looking at the directory= or the file= options
 3. if you want to delete the schroot, just delete the configuration file under
/etc/schroot/chroot.d/unstable-amd64-sbuild-XX together with the actual
chroot the configuration file pointed to

I never heard about /etc/sbuild/chroot/ but it seems it's used for the sudo
backend. I don't even know where the code is that creates this. But if you
don't care, then you can leave that directory alone.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: How do you delete a sbuild an sbuild chroot and start over?

[Sean Whitton]

On Tue, Aug 02, 2016 at 11:06:31PM -0500, Paul Elliott wrote:
> Sometimes a user gets a sbuild chroot so screwed up that it does not
> work anymore, and the user has no idea how to fix it, because he does not
> know what he did wrong.
> 
> He wants to start over from scratch.
> 
> The problem is, it is not documented the correct way to delete
> the chroot and tar ball. The users want to put sbuild back to
> the way it was just after sbuild was installed.
> 
> 
> What is the proper way to do that?

Asking for a friend? ;)

Assuming you used the suggestions for making the chroot on the sbuild
wiki page, this should do it:

# rm -rf /srv/chroot/* /etc/sbuild/chroot/*-sbuild 
/etc/schroot/chroot.d/*-sbuild

If you didn't use the suggestions on the wiki page, just start nuking
stuff in those three directories.

-- 
Sean Whitton


signature.asc
Description: PGP signature

How do you delete a sbuild an sbuild chroot and start over?

[Paul Elliott]

Sometimes a user gets a sbuild chroot so screwed up that it does not
work anymore, and the user has no idea how to fix it, because he does not
know what he did wrong.

He wants to start over from scratch.

The problem is, it is not documented the correct way to delete
the chroot and tar ball. The users want to put sbuild back to
the way it was just after sbuild was installed.


What is the proper way to do that?

Thank You for your answers.


-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   3300 Plaza Drive, apt 1
http://www.free.blackpatchpanel.com/pme/   New Albany, IN 47150


signature.asc
Description: PGP signature

Automated build process for special purpose chroot-ed packages

[Peter Viskup]

Hi all,
I am beginner in Debian packaging and would like to ask you for an opinion
regarding use of debhelper to create chroot-ed packages.
Somebody of you already worked on some similar solution probably.

Background:
 - requirement to have more instances of same service in chroot-ed
environment
 - simplify the maintenance of chroot environments
 - being able to upgrade chroot-ed services separately
 - build packages for all instances automagically
 - maintain some instance specific configuration file templates

I would like to be able to create those packages at once (one
dpkg-buildpackage execution) and using template within the 'debian'
directory. This should simplify the process of creating package for new
chroot.

Environment:
 - packages created as package-chroot-instance and installed in base
system
 - chroot directory /chroot/instance (package-chroot-instance will
place it's files directly to this location)
 - use of some jailing tool calls in preinst/postinst maintainer scripts

Could somebody comment on this approach whether it's reasonable or better
would be to have separate copies of sources for every package? Some more
detailed proposals from your side how to accomplish this (e.g. debian/rules
for every package)?

Thank you all in advance.

-- 
Peter Viskup

Re: Automated build process for special purpose chroot-ed packages

[Jordan Metzmeier]

On Tue, Nov 11, 2014 at 6:51 AM, Peter Viskup skupko...@gmail.com wrote:
 Could somebody comment on this approach whether it's reasonable or better
 would be to have separate copies of sources for every package? Some more
 detailed proposals from your side how to accomplish this (e.g. debian/rules
 for every package)?


Are these packages you intend to upload to Debian? It sounds like
docker containers may serve your needs better.

https://www.docker.com/

Regards,
Jordan Metzmeier


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAD758RixX8r1AM+P=xUrwXiXg+gnimwrR64MMF+=za30oye...@mail.gmail.com

Re: Re: Automated build process for special purpose chroot-ed packages

[Peter Viskup]

That seems to be quite a big overhead and does not meet our security
requirements. We cannot change the design at the moment (e.g. migrate to
LXC,...).
We need to run those services (rsyslog in our case) in chroot for security
purposes.
Any proposals to build those packages from one source are appreciated.

-- 
Peter Viskup

PS: I'm not subscribed, please, leave my email in cc. ;-)

Bug#728716: marked as done (RFS: xchroot/2.3.3-5 [ITP] -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots)

[Debian Bug Tracking System]

Your message dated Tue, 08 Apr 2014 04:25:23 +
with message-id e1wxnb9-0008sv...@quantz.debian.org
and subject line closing RFS: xchroot/2.3.3-5 [ITP] -- extended chroot with 
X11/Xorg forwarding and aufs/unionfs support for read only roots
has caused the Debian Bug report #728716,
regarding RFS: xchroot/2.3.3-5 [ITP] -- extended chroot with X11/Xorg 
forwarding and aufs/unionfs support for read only roots
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


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

Package: sponsorship-requests
Subject: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for my package xchroot:

 * Package name: xchroot
   Version : 2.3.2-9
   Upstream Author : Elmar Stellnberger estel...@elstel.org
 * URL : https://www.elstel.org/xchroot
 * License : S-FSL v1.3.1
   Section : x11

  It is a little convenience bash script with man page wrapped into a package:

xchroot - extended chroot with X11/Xorg forwarding and aufs/unionfs support 
for read only roots

  I am sure you will like it; also good for packaging with multiple OS versions.


  To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/xchroot


  Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/x/xchroot/xchroot_2.3.2-9.dsc

  More information about xchroot can be obtained from 
https://www.elstel.org/xchroot.

  Changes since the last upload:

Today I have fixed a lot of warnings shown by the pacakge evaluation of 
mentors

  Note:

The xchroot S-FSL v1.3.1 license would need some legal review. It was 
especially designed for
distributions available free of charge like Debian. The license has been 
revised thouroughly
and should not pose any restrictions concerning re-distribution by Debian 
or any other free
distro. The author plans to publish more software under this or a reworked 
version of the
S-FSL license.

  Kind Regards,
  Elmar Stellnberger


---End Message---
---BeginMessage---
Package xchroot has been removed from mentors.---End Message---

Re: Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]

[Wookey]

+++ Ross Gammon [2014-03-01 23:37 +0100]:
 Now you have all helped me to realise that I can spam with 'debian/rules
 build' to test if it fixes a FTBFS, or 'fakeroot debian/rules binary' to
 go all the way to a 'deb' which I can try installing.

(And very usefully, just retry the packaging step without doing the
whole build again (can save a lot of time)).

 But if I don't want to install all the build dependencies on the machine
 I am using, how can I pass these commands to pbuilder? Or can I override
 gbp buildpackage (with pbuilder as an option) in some way so that it
 ignores the fact that there are altered files?

Just do the builds in a chroot. One of the coolest things about schroot
is that by default your home dir is mounted inside the chroot so you get
the exact same veiw inside and outside.

So you issue the dpkg-buldpackage, or fakeroot debian/rules binary or
whatever build commands inside the chroot. Thereby testing the build in
a stable (fairly) clean environment, and not filling your main machine
with build-deps.

Meanwhile you do do other stuff on the codebase from outside the chroot using 
all
your favourite tools too. Just avoid operations that are suite-specific.

 Hoping someone can solve a regular frustration of mine.

The above is how I do it.

 Regards,
 
 Ross
 
 
 -- 
 To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/53126122.1060...@the-gammons.net
 
Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140302111636.gf18...@stoneboat.aleph1.co.uk

Re: Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]

[gregor herrmann]

On Sun, 02 Mar 2014 08:38:06 +0100, Ross Gammon wrote:

  'gbp
  buildpackage' fails because it detects altered files in the source code.

  Ah, here it is in the manpage:
  --git-export=treeish

 Thanks Gregor, but I was already aware of --git-export=WC 
 --git-ignore-new. I have used this when I wanted to test changes to e.g.
 d/rules before committing the fix.

Ok.

 What I was probably not clear about, was that I meant changes made
 outside the debian directory.

Ah, indeed, I had not realized this; and I hadn't thought about this
issue because ...

 dpkg-source: info: building gramps using existing
 ./gramps_4.0.3+dfsg.orig.tar.gz
 dpkg-source: info: local changes detected, the modified files are:
  gramps-4.0.3+dfsg/setup.py
 dpkg-source: error: aborting due to unexpected upstream changes, see
 /tmp/gramps_4.0.3+dfsg-3.diff.8Ha2F5
 dpkg-source: info: you can integrate the local changes with dpkg-source
 --commit
 dpkg-buildpackage: error: dpkg-source -b gramps-4.0.3+dfsg gave error
 exit status 2

... it's dpkg-source here failing, and not gbp :)
(Well, indirectly and later gbp can't go on as well.)

 But anyway, studying this error a bit harder with a clear head in the
 morning, and then studying the man page for dpkg-source, I solved it.
 Adding the option -i.* to gbp successfully got passed to dpkg-source,
 and it built.

I usually create a quick quilt patch (manually or by following the
advive from the error: you can integrate the local changes with
dpkg-source --commit) in this case.

Or I just try the changes in the chroot (with running debian/rules
$target manually there; cf. also Wookey's ideas). Works with
cowbuilder as well with the C10shell hook (which can also be
triggered by a exit 1 in debian/rules in the desired override_*).

Note that this local changes detected error only happens with
source format 3.0 quilt, and is generally considered an advantage (to
avoid unintentional changes in the upstream code). But yes, during
experimenting it can be a bit annoying.
 

Cheers,
gregor


-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   NP: Joan Baez: Ghetto


signature.asc
Description: Digital signature

Re: Is there a way to preserve pbuilder chroot environment?

[Mikhail Morfikov]

 Can you elaborate a bit on what you mean by having to build a package
 multiple times before it builds successfully? With pbuilder, your
 package should be able to be built with a single invocation of
 pbuilder (given a .dsc) or pdebuild (when unpacked). Anything more
 than that and the ftpmasters will probably consider your package to
 FTBFSIASW (fail to build from source in a sane way).

I mean that I'm new to it, and I'm making lots of mistakes, and
rebuilding the chroot environment each time doesn't help much. I'll
check the cowbuilder tool and maybe it will prove to be useful.


signature.asc
Description: PGP signature

Re: Is there a way to preserve pbuilder chroot environment?

[Mikhail Morfikov]

 Pbuilder also supports that using hooks, e.g.:
 
 # ln -s /usr/share/doc/pbuilder/examples/C10shell
 /var/cache/pbuilder/hooks/C10shell
 
 ...and the next time your build fails, pbuilder will dump you in the
 chroot with a shell.

I checked this solution, but I'm wondering how to resume pbuilder after
it dumps me in the chroot? Let's say I fixed everything that should be
fixed, and what next?


signature.asc
Description: PGP signature

Re: Is there a way to preserve pbuilder chroot environment?

[Rebecca N. Palmer]

sbuild also has lots of nifty extra features.  One I use a lot is the ability
to locally build a stack of related packages against each other[1].
You can do that in pbuilder (https://wiki.debian.org/PbuilderTricks ; 
also allows testing locally-built packages in a pbuilder --login 
session), but be aware that this method leaves the locally-built 
packages available until explicitly removed, so if you decide not to 
upload the new version of the library, don't forget to remove it before 
building anything that uses it.



--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53119ef7.4010...@bham.ac.uk

Re: Is there a way to preserve pbuilder chroot environment?

[Wookey]

+++ Barry Warsaw [2014-02-28 16:42 -0500]:
 On Feb 28, 2014, at 10:52 AM, Mikhail Morfikov wrote:
 
 I'm new to building packages by using pbuilder tool, and I have to build
 a package multiple times before it builds successfully, or in the way
 I prefer.
 
 This is one of the reasons why I prefer to use sbuild for most of my local
 builds. 

I swapped from pbuilder to sbuild some years ago. sbuild integrates with
schroot in a really nice way. You can schroot in to the same chroots
that sbuild will use and stay in for multiple builds. I use tarball
chroots for clean builds which always revert to the initial state and
plain chroots for other general testing. This is how I normally deal
with mikhail's issue - develop in a plain chroot until I think things
are working then test with clean builds in a tarball or lvm chroot.

sbuild supports cross-building too which I find handy.

I must admit I'm surprised so many people still use pbuilder, although I
do agree that the syntax is a bit simpler for a 'standard upload' build.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140301092020.gv18...@stoneboat.aleph1.co.uk

Re: Is there a way to preserve pbuilder chroot environment?

[Paul Wise]

On Sat, Mar 1, 2014 at 5:20 PM, Wookey wrote:

 I must admit I'm surprised so many people still use pbuilder, although I
 do agree that the syntax is a bit simpler for a 'standard upload' build.

I still use cowbuilder because schroot doesn't support cowdancer for
copy-on-write chroots and I found tarball mode in pbuilder to be way
too slow. The one time I used sbuild, interrupting the build gave me a
completely broken chroot that I had to reinstall. I don't think that
failure mode should be the default, hope it isn't any more.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6EyJ6J4fTtDqo-oNBHF-WFTK0zm1KC7=r0q0usn+yl...@mail.gmail.com

Re: Is there a way to preserve pbuilder chroot environment?

[Mattia Rizzolo]

On Sat, Mar 1, 2014 at 4:17 AM, Paul Wise p...@debian.org wrote:
 If you can convince the pbuilder and sbuild maintainers to work
 together to merge all the missing parts of
 pbuilder/cowbuilder/qemubuilder into sbuild,

That would be a great adventure!


-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahkymevzugact_9yfc_pcu687-36zv43ruwejy0mmjszmee...@mail.gmail.com

Re: Is there a way to preserve pbuilder chroot environment?

[Ferenc Wagner]

Paul Wise p...@debian.org writes:

 On Sat, Mar 1, 2014 at 5:20 PM, Wookey wrote:

 I must admit I'm surprised so many people still use pbuilder, although I
 do agree that the syntax is a bit simpler for a 'standard upload' build.

 I still use cowbuilder because schroot doesn't support cowdancer for
 copy-on-write chroots and I found tarball mode in pbuilder to be way
 too slow.

I use sbuild (actually, schroot under the hood) with btrfs-snapshot
chroots.  Creating a new build environment really is a snap.

 The one time I used sbuild, interrupting the build gave me a
 completely broken chroot that I had to reinstall.

By default, the snapshot is destroyed when sbuild finishes in any way.
No chance to damage the origin chroot this way.
-- 
Regards,
Feri.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fvn2100w@lant.ki.iif.hu

RE: Is there a way to preserve pbuilder chroot environment?

[Bas van den Dikkenberg]

I use a hook withs give me root access to build env when a build is failed

Added this line to .pbuilderrc
HOOKDIR=/var/cache/pbuilder/hook.d

And placed the file C10shell in there with this content:

#!/bin/sh
# invoke shell if build fails.

apt-get install -y --force-yes vim less bash nano
cd /tmp/buildd/*/debian/..
/bin/bash  /dev/tty  /dev/tty 2 /dev/tty


With this give you access to build enverement

If you want to copy stuff out of the env you can the do by accessing your build 
directory  and copy the stuff y



--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/8c48efc8d3fd4db3b7f14d1cfb895441@srv04.dikkenberg.local

Re: Is there a way to preserve pbuilder chroot environment?

[Paul Wise]

On Sat, Mar 1, 2014 at 10:11 PM, Ferenc Wagner wrote:

 I use sbuild (actually, schroot under the hood) with btrfs-snapshot
 chroots.  Creating a new build environment really is a snap.

Personally I wouldn't feel comfortable using btrfs on my main system
yet and I don't have a separate system just for builds.

 By default, the snapshot is destroyed when sbuild finishes in any way.
 No chance to damage the origin chroot this way.

If you aren't using any of the snapshot-capable mechanisms it will.
For many people none are suitable so that could be common.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6fseiqm+admufjvvzycxj7wtpsmybyytkeuo-u1ib6...@mail.gmail.com

Re: Is there a way to preserve pbuilder chroot environment?

[Wookey]

+++ Ferenc Wagner [2014-03-01 15:11 +0100]:
 Paul Wise p...@debian.org writes:
 
  On Sat, Mar 1, 2014 at 5:20 PM, Wookey wrote:
 
  I must admit I'm surprised so many people still use pbuilder, although I
  do agree that the syntax is a bit simpler for a 'standard upload' build.
 
  I still use cowbuilder because schroot doesn't support cowdancer for
  copy-on-write chroots and I found tarball mode in pbuilder to be way
  too slow.
 
 I use sbuild (actually, schroot under the hood) with btrfs-snapshot
 chroots.  Creating a new build environment really is a snap.

btrfs (and LVM) snapshots are great, but they only help if you have a
btrfs or LVM volume to hand to work on.

cowbuilder has the significant advantage that it works on any filesystem.

In my experience the sbuild maintainer is very open to improvements and
is happy for people to integrate new features on git branches then ask
for a merge. (I had to learn git to do this for the cross-support - it
was painful!)

I would also make the comment that sbuild is very well written and
designed. So fixes usually only have to be done in one place. It's nice
to work with.

I have no idea how easy general cow support would be to add to
sbuild/schroot.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140301152819.ga18...@stoneboat.aleph1.co.uk

Re: Is there a way to preserve pbuilder chroot environment?

[Wookey]

+++ Paul Wise [2014-03-01 23:17 +0800]:
 On Sat, Mar 1, 2014 at 10:11 PM, Ferenc Wagner wrote:
 
  By default, the snapshot is destroyed when sbuild finishes in any way.
  No chance to damage the origin chroot this way.
 
 If you aren't using any of the snapshot-capable mechanisms it will.
 For many people none are suitable so that could be common.

I have done an astonishing number of builds (and crossbuilds) in sbuild.
I have killed many of them in mid-build for many reasons. It has a nice
cleanup-mechanism which spots such interruptions and tidies up. I have
never managed to currupt my chroot doing this, so I think you were very
unlucky. It _is_ quite easy to get a lot of schroot mounts left lying
about if you often kill terms or screen/tmux sessions or X sessions or
machines running them.

A nice feature of schroot is that you can resume such chroots and carry
on from whatever state it was in (at the filesystem level). Again, I've
never seen corruption doing this.

You can also run commands on multiple chroots in parallel (whcih is a
bit scary, but it works :-). Handy for doing builds for several suites
at once.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140301153354.gb18...@stoneboat.aleph1.co.uk

Re: Is there a way to preserve pbuilder chroot environment?

[Jakub Wilk]

* Wookey woo...@wookware.org, 2014-03-01, 15:28:
I still use cowbuilder because schroot doesn't support cowdancer for 
copy-on-write chroots and I found tarball mode in pbuilder to be way 
too slow.
I use sbuild (actually, schroot under the hood) with btrfs-snapshot 
chroots.  Creating a new build environment really is a snap.


btrfs (and LVM) snapshots are great, but they only help if you have a 
btrfs or LVM volume to hand to work on.


sbuild supports also aufs chroots, which don't require any specific 
underlying fs, and are reasonably fast.


The only problem is that aufs is semi-unsupported in Debian. But I still 
trust it more than cowdancer…


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140301162734.ga5...@jwilk.net

Re: Is there a way to preserve pbuilder chroot environment?

[Vincent Cheng]

On Sat, Mar 1, 2014 at 12:18 AM, Mikhail Morfikov mmorfi...@gmail.com wrote:
 Pbuilder also supports that using hooks, e.g.:

 # ln -s /usr/share/doc/pbuilder/examples/C10shell
 /var/cache/pbuilder/hooks/C10shell

 ...and the next time your build fails, pbuilder will dump you in the
 chroot with a shell.

 I checked this solution, but I'm wondering how to resume pbuilder after
 it dumps me in the chroot? Let's say I fixed everything that should be
 fixed, and what next?

If you want to continue fixing issues as you go along, just keep
spamming 'fakeroot debian/rules binary' in your shell (assuming your
end goal is to produce binary .deb packages). You can of course try
running other targets in d/rules to narrow down and solve specific
issues that you want to fix.

Regards,
Vincent


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caczd_td2ycxtqlxgduph12txhmu3qetct2pzj6gpvao67on...@mail.gmail.com

Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]

[Ross Gammon]

On 03/01/2014 10:46 PM, Vincent Cheng wrote:
 On Sat, Mar 1, 2014 at 12:18 AM, Mikhail Morfikov mmorfi...@gmail.com wrote:
 Pbuilder also supports that using hooks, e.g.:

 # ln -s /usr/share/doc/pbuilder/examples/C10shell
 /var/cache/pbuilder/hooks/C10shell

 ...and the next time your build fails, pbuilder will dump you in the
 chroot with a shell.

 I checked this solution, but I'm wondering how to resume pbuilder after
 it dumps me in the chroot? Let's say I fixed everything that should be
 fixed, and what next?
 
 If you want to continue fixing issues as you go along, just keep
 spamming 'fakeroot debian/rules binary' in your shell (assuming your
 end goal is to produce binary .deb packages). You can of course try
 running other targets in d/rules to narrow down and solve specific
 issues that you want to fix.
 
 Regards,
 Vincent
 
Thank you all, this has been a useful thread for me. But it hasn't yet
given me the exact answer I needed (but some clues!). And maybe my
question will also be useful to others.

Many times I have used 'gbp pq import' to create a patch queue and try
out some crazy patches to the source code there. I have used the
options to tell gbp where the debian  upstream branches are, but 'gbp
buildpackage' fails because it detects altered files in the source code.
I have tried several times to find solution in the man pages for gbp,
pbuilder and dpkg-buildpackage etc.

Now you have all helped me to realise that I can spam with 'debian/rules
build' to test if it fixes a FTBFS, or 'fakeroot debian/rules binary' to
go all the way to a 'deb' which I can try installing.

But if I don't want to install all the build dependencies on the machine
I am using, how can I pass these commands to pbuilder? Or can I override
gbp buildpackage (with pbuilder as an option) in some way so that it
ignores the fact that there are altered files?

Hoping someone can solve a regular frustration of mine.

Regards,

Ross


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53126122.1060...@the-gammons.net

Re: Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]

[gregor herrmann]

On Sat, 01 Mar 2014 23:37:22 +0100, Ross Gammon wrote:

 'gbp
 buildpackage' fails because it detects altered files in the source code.

 Or can I override
 gbp buildpackage (with pbuilder as an option) in some way so that it
 ignores the fact that there are altered files?

Yes, you can:

== excerpt from ~/.gbp.conf ==

[buildpackage]
...
export = WC


Ah, here it is in the manpage:

--git-export=treeish
  Instead  of  exporting the current branch head, export the
  treeish object treeish. The special name INDEX exports the
  current index whereas the special name WC exports the
  current working copy as is.


Cheers,
gregor


-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   NP: Don McLean: The Carnival Is Ended


signature.asc
Description: Digital signature

Re: Test builds in gbp patch-queue branch [was: Re: Is there a way to preserve pbuilder chroot environment?]

[Ross Gammon]

On 03/02/2014 12:38 AM, gregor herrmann wrote:
 On Sat, 01 Mar 2014 23:37:22 +0100, Ross Gammon wrote:
 
 'gbp
 buildpackage' fails because it detects altered files in the source code.
 
 Or can I override
 gbp buildpackage (with pbuilder as an option) in some way so that it
 ignores the fact that there are altered files?
 
 Yes, you can:
 
 == excerpt from ~/.gbp.conf ==
 
 [buildpackage]
 ...
 export = WC
 
 
 Ah, here it is in the manpage:
 
 --git-export=treeish
   Instead  of  exporting the current branch head, export the
   treeish object treeish. The special name INDEX exports the
   current index whereas the special name WC exports the
   current working copy as is.
 
 
 Cheers,
 gregor
 
Thanks Gregor, but I was already aware of --git-export=WC 
--git-ignore-new. I have used this when I wanted to test changes to e.g.
d/rules before committing the fix.
What I was probably not clear about, was that I meant changes made
outside the debian directory.
For example, make a simple change to a working package by adding #Ross
is a berk to setup.py.
gbp buildpackage with the pbuilder option and --git-export 
--git-ignore-new still fails:

dpkg-source: info: building gramps using existing
./gramps_4.0.3+dfsg.orig.tar.gz
dpkg-source: info: local changes detected, the modified files are:
 gramps-4.0.3+dfsg/setup.py
dpkg-source: error: aborting due to unexpected upstream changes, see
/tmp/gramps_4.0.3+dfsg-3.diff.8Ha2F5
dpkg-source: info: you can integrate the local changes with dpkg-source
--commit
dpkg-buildpackage: error: dpkg-source -b gramps-4.0.3+dfsg gave error
exit status 2
gbp:error: Couldn't run 'git-pbuilder': git-pbuilder returned 2

But anyway, studying this error a bit harder with a clear head in the
morning, and then studying the man page for dpkg-source, I solved it.

Adding the option -i.* to gbp successfully got passed to dpkg-source,
and it built.

Cheers,

Ross
PS: now I had better remove that change before I forget ;-)


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5312dfde.3060...@the-gammons.net

Is there a way to preserve pbuilder chroot environment?

[Mikhail Morfikov]

I'm new to building packages by using pbuilder tool, and I have to build
a package multiple times before it builds successfully, or in the way
I prefer. The most annoying part ot this is installation of
dependencies -- each time I build a package, it has to install
the same dependencies over and over.

I checked some of pbuilder options:
--save-after-login
--save-after-exec

But the first one only works with --login parameter, and the second one
doesn't work with --build at all. I could log into the chroot
environment and install all the dependencies the package requires, but
I suppose there's a better way to do it, or am I wrong?


signature.asc
Description: PGP signature

Re: Is there a way to preserve pbuilder chroot environment?

[Vincent Cheng]

On Fri, Feb 28, 2014 at 1:52 AM, Mikhail Morfikov mmorfi...@gmail.com wrote:
 I'm new to building packages by using pbuilder tool, and I have to build
 a package multiple times before it builds successfully, or in the way
 I prefer. The most annoying part ot this is installation of
 dependencies -- each time I build a package, it has to install
 the same dependencies over and over.

Can you elaborate a bit on what you mean by having to build a package
multiple times before it builds successfully? With pbuilder, your
package should be able to be built with a single invocation of
pbuilder (given a .dsc) or pdebuild (when unpacked). Anything more
than that and the ftpmasters will probably consider your package to
FTBFSIASW (fail to build from source in a sane way).

About the annoying part of having to wait for pbuilder to install all
build-deps at each run, you can:
- get pbuilder to set up the chroot in a tmpfs (e.g. I actually have
/var/cache/pbuilder/build/ symlinked to /tmp, which is mounted as a
tmpfs; setting up a pbuilder chroot is blazing fast)
- use cowbuilder
- go buy and use a SSD

Any of the above options should make it far less annoying to build
your package in a clean chroot each time.

Regards,
Vincent


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACZd_tAOScKkiB_pY=ppgs+34usttjd0+rk-or7rxfxhlev...@mail.gmail.com

Re: Is there a way to preserve pbuilder chroot environment?

[Mattia Rizzolo]

On Feb 28, 2014 10:52 AM, Mikhail Morfikov mmorfi...@gmail.com wrote:

 I'm new to building packages by using pbuilder tool, and I have to build
 a package multiple times before it builds successfully, or in the way
 I prefer. The most annoying part ot this is installation of
 dependencies -- each time I build a package, it has to install
 the same dependencies over and over.

You shouldn't try to preserve the environment, every time you build stuff
you should have a clean installation.

I developed a set of scripts to easy have and manage multiple chroots and
speed up building.

See
https://gitlab.com/mapreri/settings/blob/master/pbuilder/scripts/pbuilder-common(rename
the file like pbuilder-sid-amd64 (or symlink,as you prefer) that
works in combo with this .pbuilderrc (
https://gitlab.com/mapreri/settings/blob/master/pbuilderrc) install on the
host ccache and eatmydata, all the stuff will live in ~/pbuilder.

Maybe you can catch some hints on how to resolve your issue

(That repo is there to let me deploy a new system and keep track of some
settings of some tools I use.)

Re: Is there a way to preserve pbuilder chroot environment?

[Vincent Cheng]

On Fri, Feb 28, 2014 at 2:11 AM, Mattia Rizzolo mapr...@ubuntu.com wrote:
 On Feb 28, 2014 10:52 AM, Mikhail Morfikov mmorfi...@gmail.com wrote:

 I'm new to building packages by using pbuilder tool, and I have to build
 a package multiple times before it builds successfully, or in the way
 I prefer. The most annoying part ot this is installation of
 dependencies -- each time I build a package, it has to install
 the same dependencies over and over.

 You shouldn't try to preserve the environment, every time you build stuff
 you should have a clean installation.

 I developed a set of scripts to easy have and manage multiple chroots and
 speed up building.

 See
 https://gitlab.com/mapreri/settings/blob/master/pbuilder/scripts/pbuilder-common
 (rename the file like pbuilder-sid-amd64 (or symlink,as you prefer) that
 works in combo with this .pbuilderrc (
 https://gitlab.com/mapreri/settings/blob/master/pbuilderrc) install on the
 host ccache and eatmydata, all the stuff will live in ~/pbuilder.

Hmmm, out of curiousity, how is this different from pbuilder-dist (in
ubuntu-dev-tools)?

Also, s/squeezy/squeeze/.

Regards,
Vincent


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACZd_tCNSPMBoU76vnovgsqxOyjm5cKDuNahq_ZWbmf0X=+q...@mail.gmail.com

Re: Is there a way to preserve pbuilder chroot environment?

[Bartosz Feński]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

W dniu 28.02.2014 10:52, Mikhail Morfikov pisze:
 I'm new to building packages by using pbuilder tool, and I have to build
 a package multiple times before it builds successfully, or in the way
 I prefer. The most annoying part ot this is installation of
 dependencies -- each time I build a package, it has to install
 the same dependencies over and over.

 I checked some of pbuilder options:
 --save-after-login
 --save-after-exec

 But the first one only works with --login parameter, and the second one
 doesn't work with --build at all. I could log into the chroot
 environment and install all the dependencies the package requires, but
 I suppose there's a better way to do it, or am I wrong?

You're right. The better way is to use cowbuilder instead of pbuilder.
The first is a wrapper around the latter.

regards
fEnIo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMQXkAACgkQhQui3hP+/ECE6ACfYgGChV5Xpd8wWfLCkMc4v1b0
DOQAoKPm8w5/ryZBGPYR+jR4HN3fzTZq
=TjSV
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53105e44.9050...@fenski.pl

Re: Is there a way to preserve pbuilder chroot environment?

[Mattia Rizzolo]

On Feb 28, 2014 11:17 AM, Vincent Cheng vch...@debian.org wrote:
 Hmmm, out of curiousity, how is this different from pbuilder-dist (in
 ubuntu-dev-tools)?

The concept is the same, but it is quite different:
* integrate support for ccache and apt caching for separate dists (every
dists uses a different directory, while pbuilder-dist uses a single
/var/cache/pbuilder/apt that causes me some issues, iirc)
* it does a lot more checks (e.g., it checks if the correct qemu package is
installed if needed)
* correct support for non x86 arches (for now only arm64, it uses
qemu-debootstrap for it)
* with the pbuilderrc I set up like eatmydata witch speed up all the steps,
the apt depends resolver to gdebi, witch is quite faster than the default
(I don't remember the default now), ccahe
* other thing I don't remember now.
Out of that script there is also some pbuilder hooks, for example.

In short, it's write around my needs :)

Yes, the concept is the same, but since it doesn't satisfied me I wrote my
own pbuilder-dist-like script+pbuilderrc.
Since I keep all my configurations in git and that script is quite good
looking I though other can benefit of it.
Maybe when it's better write, better support of all the cases I'll
encounter I'll  ask the maintainer of ubuntu-dev-tools (or devscripts,
maybe) to include it or part of it.

Re: Is there a way to preserve pbuilder chroot environment?

[Mikhail Morfikov]

 You're right. The better way is to use cowbuilder instead of pbuilder.
 The first is a wrapper around the latter.

Thanks for the hint.



signature.asc
Description: PGP signature

Re: Is there a way to preserve pbuilder chroot environment?

[Mikhail Morfikov]

 You shouldn't try to preserve the environment, every time you build
 stuff you should have a clean installation.

I know, but when I work with the same package, I think there's no point
in installing the same dependencies over and over. I could save the
chroot, and when I finish playing with the package, I would test it in a
clear environment.

Thanks for the links, I'll check them later. 


signature.asc
Description: PGP signature

Re: Is there a way to preserve pbuilder chroot environment?

[Barry Warsaw]

On Feb 28, 2014, at 10:52 AM, Mikhail Morfikov wrote:

I'm new to building packages by using pbuilder tool, and I have to build
a package multiple times before it builds successfully, or in the way
I prefer.

This is one of the reasons why I prefer to use sbuild for most of my local
builds.  You can tell it to preserve the chroot when the build fails, and it's
easy to go in, inspect the build environment, and tweak your package into
building.  Occasionally, it's even useful to preserve the chroot when the
package build succeeds, just to poke around.

For Debian packages, I usually do all my update testing with sbuild and
schroot, and then do one final pbuilder build -- with a test of the resulting
.debs just to be sure -- for the binary package upload.

sbuild also has lots of nifty extra features.  One I use a lot is the ability
to locally build a stack of related packages against each other[1].  The
Ubuntu wiki has a nice page on getting started with sbuild[2].

Cheers,
-Barry

[1]
http://www.wefearchange.org/2011/09/sbuild-with-local-newer-dependencies.html
[2] https://wiki.ubuntu.com/SimpleSbuild


signature.asc
Description: PGP signature

Re: Is there a way to preserve pbuilder chroot environment?

[Vincent Cheng]

On Fri, Feb 28, 2014 at 1:42 PM, Barry Warsaw ba...@python.org wrote:
 On Feb 28, 2014, at 10:52 AM, Mikhail Morfikov wrote:

I'm new to building packages by using pbuilder tool, and I have to build
a package multiple times before it builds successfully, or in the way
I prefer.

 This is one of the reasons why I prefer to use sbuild for most of my local
 builds.  You can tell it to preserve the chroot when the build fails, and it's
 easy to go in, inspect the build environment, and tweak your package into
 building.  Occasionally, it's even useful to preserve the chroot when the
 package build succeeds, just to poke around.

Pbuilder also supports that using hooks, e.g.:

# ln -s /usr/share/doc/pbuilder/examples/C10shell
/var/cache/pbuilder/hooks/C10shell

...and the next time your build fails, pbuilder will dump you in the
chroot with a shell.

Regards,
Vincent


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caczd_tbhnngnv4azwcytbtit1n4uitplm_epwmqngjmw2_a...@mail.gmail.com

Re: Is there a way to preserve pbuilder chroot environment?

[Mattia Rizzolo]

On Fri, Feb 28, 2014 at 10:42 PM, Barry Warsaw ba...@python.org wrote:
 This is one of the reasons why I prefer to use sbuild for most of my local
 builds.  You can tell it to preserve the chroot when the build fails, and it's
 easy to go in, inspect the build environment, and tweak your package into
 building.  Occasionally, it's even useful to preserve the chroot when the
 package build succeeds, just to poke around.

Just to point out that you can do the same with pbuilder (using
hooks). At this time there is no so much differences between sbuild
and pbuilder.

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAHKYmevanxkkh0ZWqhOKP=e4xsVQpoM_ui2dN=7s_cdmybk...@mail.gmail.com

Re: Is there a way to preserve pbuilder chroot environment?

[Paul Wise]

On Sat, Mar 1, 2014 at 6:31 AM, Mattia Rizzolo wrote:

 At this time there is no so much differences between sbuild and pbuilder.

If you can convince the pbuilder and sbuild maintainers to work
together to merge all the missing parts of
pbuilder/cowbuilder/qemubuilder into sbuild, I will buy you and the
pbuilder/sbuild maintainers a beverage of your choice at DebConf.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6fwbfz62f7japtt2ygwwmcu8bd6uvnczre+b+tquo1...@mail.gmail.com

Bug#735550: marked as done (RFS: proot/3.2.2-1 -- emulate chroot, bind mount and binfmt_misc for non-root users)

[Debian Bug Tracking System]

Your message dated Wed, 29 Jan 2014 16:28:50 +
with message-id e1w8y0q-0001kb...@quantz.debian.org
and subject line closing RFS: proot/3.2.2-1 -- emulate chroot, bind mount and 
binfmt_misc for non-root users
has caused the Debian Bug report #735550,
regarding RFS: proot/3.2.2-1 -- emulate chroot, bind mount and binfmt_misc for 
non-root users
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


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

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package proot

* Package name: proot
  Version : 3.2.2-1
  Upstream Author : Cédric Vincent cedric.vinc...@st.com
* URL : http://proot.me
* License : GPL
  Section : utils

It builds those binary packages:

  proot - emulate chroot, bind mount and binfmt_misc for non-root users

To access further information about this package, please visit the 
following URL:


http://mentors.debian.net/package/proot


Alternatively, one can download the package with dget using this 
command:


  dget -x 
http://mentors.debian.net/debian/pool/main/p/proot/proot_3.2.2-1.dsc


More information about proot can be obtained from http://proot.me.

Changes since the last upload:

 * Only build for supported architectures (closes: #733247)
 * Upgrade to latest PRoot version (Closes: #730363)
 * Fix copyright holders
 * Build with hardening
 * Print the full command line while building
 * Add a watch file


Regards,

--
Rémi Duraffort
http://ivoire.dinauz.org/blog
---End Message---
---BeginMessage---
Package proot version 3.2.2-1 is in unstable now.
http://packages.qa.debian.org/proot---End Message---

Re: Bug#728716: RFS: xchroot/2.3.3-3 [ITP] -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots

[Gergely Nagy]

Elmar Stellnberger estel...@gmail.com writes:

 Am 12.11.2013 10:24, schrieb Andrew Shadura:
 Hello,

 On 12 November 2013 10:22, Elmar Stellnberger estel...@gmail.com wrote:
 O.K. That is actually what is to be done next.
 There are some people whom I know and who I am going to consult.
 It will at last be necessary in my very own interest to assert that the
 license will work in practice as intended.
 I hope you are going to accept the results if and only if I consult
 someone who is a lawyer.
 Again, thanks for your contribution to the license. It was actually
 necessary to make it fit for practical usage.
 Unfortunately, it's still unfit for use.

 Could you tell me in a short why you do think so.

A good number of people already told you, on multiple mailing lists and
on other media, repeatedly. Go read them.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gccp9wo.fsf@algernon.balabit

Bug#728716: RFS: xchroot/2.3.3-3 [ITP] -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots

[Elmar Stellnberger]

O.K. That is actually what is to be done next.
There are some people whom I know and who I am going to consult.
It will at last be necessary in my very own interest to assert that the
license will work in practice as intended.
I hope you are going to accept the results if and only if I consult
someone who is a lawyer.
Again, thanks for your contribution to the license. It was actually
necessary to make it fit for practical usage.

Yours Sincerely,
Elmar Stellnberger

P.S. I hope my postings to the OSI license-discuss mailing list
from last week will get posted soon.

Am 12.11.2013 07:41, schrieb Bart Martens:

Hi Elmar,

It's OK that you write your own non-free license, but this license in
particular has, in my opinion, too many serious flaws to allow it in section
non-free.  I suggest to get professional legal advice or to use an existing
well-known license.

Regards,

Bart Martens



--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5281f348.1050...@gmail.com

Bug#728716: RFS: xchroot/2.3.3-3 [ITP] -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots

[Andrew Shadura]

Hello,

On 12 November 2013 10:22, Elmar Stellnberger estel...@gmail.com wrote:
 O.K. That is actually what is to be done next.
 There are some people whom I know and who I am going to consult.
 It will at last be necessary in my very own interest to assert that the
 license will work in practice as intended.
 I hope you are going to accept the results if and only if I consult
 someone who is a lawyer.
 Again, thanks for your contribution to the license. It was actually
 necessary to make it fit for practical usage.

Unfortunately, it's still unfit for use.

-- 
WBR, Andrew


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cacujmdo+piacm0zn4co8mt2bonfrgjqwlm3u3+6ec3oujqt...@mail.gmail.com

Bug#728716: RFS: xchroot/2.3.3-3 [ITP] -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots

[Elmar Stellnberger]

Am 12.11.2013 10:24, schrieb Andrew Shadura:

Hello,

On 12 November 2013 10:22, Elmar Stellnberger estel...@gmail.com wrote:

O.K. That is actually what is to be done next.
There are some people whom I know and who I am going to consult.
It will at last be necessary in my very own interest to assert that the
license will work in practice as intended.
I hope you are going to accept the results if and only if I consult
someone who is a lawyer.
Again, thanks for your contribution to the license. It was actually
necessary to make it fit for practical usage.

Unfortunately, it's still unfit for use.


Could you tell me in a short why you do think so.


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52821cfa.9020...@gmail.com

Bug#728716: RFS: xchroot/2.3.3-3 [ITP] -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots

[Bart Martens]

Hi Elmar,

It's OK that you write your own non-free license, but this license in
particular has, in my opinion, too many serious flaws to allow it in section
non-free.  I suggest to get professional legal advice or to use an existing
well-known license.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131112074119.ga13...@master.debian.org

Re: How to startx inside a pbuilder-managed chroot?

[Jaromil]

hi Francesco,

On Sat, 10 Sep 2011, Francesco Poli wrote:

 What I am trying to do (and failing miserably at) is to start an X
 session inside a throw-away sid chroot environment.

maybe worth mentioning also this approach: I'm using Xepyr to do this,
with some small drawbacks, having also implemented it as common
development flow inside the dyne:III SDK

here an excerpt of the relevant steps:

after a mount -o bind of the usual /sys /proc and /dev i'll start
Xephyr from the host system:

Xephyr -screen $resolution :1 !

then chroot inside the guest system and give these commands:

export DISPLAY=localhost:1

and

gnome-session (or another window manager)

will start the gnome desktop inside a nested X window.

the drawback is that daemons listening on sockets will overlap and
stuff like gnome-settings will keep spitting back connections errors,
maybe someone has even a solution here so solve that.

FYI the dyneSDK I'm writing to absolve this and other tasks on top of
debian's live-build is here

https://github.com/dyne/dynebolic/blob/master/dyneIII/dynesdk

ciao


-- 
jaromil,  dyne.org developer,  http://jaromil.dyne.org
GPG: B2D9 9376 BFB2 60B7 601F 5B62 F6D3 FBD9 C2B6 8E39





signature.asc
Description: Digital signature

Re: How to startx inside a pbuilder-managed chroot?

[Osamu Aoki]

Hi,

On Sun, Sep 18, 2011 at 12:15:17AM +0200, Francesco Poli wrote:
 On Sun, 18 Sep 2011 02:42:54 +0900 Osamu Aoki wrote:
...
 I thought I could use a virtual machine, like, say, kvm, but there's a
 problem, it seems.
 
 If I understand correctly, with kvm, the guest system runs on a virtual
 machine with virtual hardware that is not identical to the actual
 hardware the host system runs on.

Correct :-)  That is usually good enough environment if you were looking
for evaluationg unstable/experimental gnome packages.  But it seems you
want more.

 The most important tests I have to perform involve the
 xserver-xorg-video-intel package: I need to run Intel video drivers
 on an Intel integrated graphics chip, with DRI 3D acceleration
 activated. If kvm makes the guest system see an emulated video card,
 the guest system won't run Intel video drivers, and I won't be able
 to reproduce the bugs...

If this is the case, then do not bother any fancy ways.  You do not want
to waste your time debugging virtual environment systems.  Just create a
dual (or multi) boot environment.  One. your main development platform.
The other small partition as your evaluation environment.  I would even
suggest you to keep disk image of system testing environment so you can
always reset it.

 Did I misunderstand something?
 May I run Intel video drivers on my actual hardware from inside a kvm
 virtual machine?

Maybe but why make things too complicated.  If you need to ask (also I
need to ask), it means this is not good baseline configuration we want
to base your work.  Creating dual boot is quite simple with grub as long
as you have extra disk space.  If you have time, you may look into
debian live CD/USB.  Then you can always create a toss-away system to
evaluate your driver.

Good luck.

Osamu


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110918122414.ga6...@goofy.lan

Re: How to startx inside a pbuilder-managed chroot?

[Francesco Poli]

On Sun, 18 Sep 2011 03:22:24 +0300 Georgios M. Zarkadas wrote:

 Hi,

Hi everyone!

First of all: thanks to Georgios and to Osamu for their kind replies.

I have good news: I managed to start X inside my pbuilder-managed
chroot environment!   :-)
It was tricky and dirty, but it worked.
Moreover, the X session was not fully functional (xterm was not able to
start, as getpty returned an error: I had to start GVim and type in
commands through its :! shell...).
Anyway, I was able to perform the tests I had in mind.

If someone is interested in what was missing in my previous attempts,
I had to do the following (before  su - niceguy ):

  # mount -t sysfs sysfs /sys
  # vim /etc/init.d/udev
  (turn the first if statement in mount_tmpfs() into a comment, so that
   the script does not attempt to remount /dev after incorrectly
   assuming it is already mounted)
  # /etc/init.d/udev start

For this to succeed, I also had to stop udev *outside* the chroot
environment:

  # /etc/init.d/udev stop
  # umount /dev

All in all, it was very unpractical and dirty.
I would *not* recommend this procedure to anyone...

 
 From the answers of the other participants of this thread so far, I
 think that the simpler solution for your case is to: 
 
 i) Make a minimal sid installation in a usb hard disk with only the
 packages contained in the chroot plus the ones you want to test.
 
 ii) Boot the real hardware (the box with the graphics card) from the usb
 disk, start X the usual way and perform the tests.
[...]
 This does not answer your original question of course (I don't have a
 good answer to that either) but it will allow you to do the job, with a
 different type of throw-away test environment.

I agree with Georgios' suggestion: next time I need something like
this, I'll look into live-build and try to create a custom Debian Live
with the packages I need.
Once this customized Debian Live image is written to a USB stick, I
will be able to boot the real hardware from the USB mass storage device
and perform all the tests I want.


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpfy55iYqSAH.pgp
Description: PGP signature

Re: How to startx inside a pbuilder-managed chroot?

[Osamu Aoki]

Hi,

On Sat, Sep 10, 2011 at 10:07:21PM +0200, Francesco Poli wrote:
 Hello,
 I am not sure which list I should direct this question to: it's a
 problem I am facing because I need to try and reproduce some bugs
 inside a throw-away test environment (without risking to crash my real
 boxes).
 If there's a better Debian list where I can ask this question, please
 suggest: I apologize in advance, if this is the case.
 
 What I am trying to do (and failing miserably at) is to start an X
 session inside a throw-away sid chroot environment.

I used to do this long time ago (4-5 years ago, I had methods in

Since X requires many devices to be shared, virtual environment seems to
be realistic and simple for this.

Use kvm, qemu, virtualbox-ose, etc.  These are much safer through away
environment with less complication.

Then you can have multiple desktops :-)

Osamu


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110917174254.gc12...@goofy.lan

Re: How to startx inside a pbuilder-managed chroot?

[Francesco Poli]

On Sun, 18 Sep 2011 02:42:54 +0900 Osamu Aoki wrote:

 Hi,

Hi Osamu, thanks a lot for your kind reply!

 
 On Sat, Sep 10, 2011 at 10:07:21PM +0200, Francesco Poli wrote:
[...]
  What I am trying to do (and failing miserably at) is to start an X
  session inside a throw-away sid chroot environment.
 
 I used to do this long time ago (4-5 years ago, I had methods in
 
 Since X requires many devices to be shared, virtual environment seems to
 be realistic and simple for this.
 
 Use kvm, qemu, virtualbox-ose, etc.  These are much safer through away
 environment with less complication.

I thought I could use a virtual machine, like, say, kvm, but there's a
problem, it seems.

If I understand correctly, with kvm, the guest system runs on a virtual
machine with virtual hardware that is not identical to the actual
hardware the host system runs on.
The most important tests I have to perform involve the
xserver-xorg-video-intel package: I need to run Intel video drivers
on an Intel integrated graphics chip, with DRI 3D acceleration
activated. If kvm makes the guest system see an emulated video card,
the guest system won't run Intel video drivers, and I won't be able
to reproduce the bugs...

Did I misunderstand something?
May I run Intel video drivers on my actual hardware from inside a kvm
virtual machine?

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpoPW6WotNa1.pgp
Description: PGP signature

Re: How to startx inside a pbuilder-managed chroot?

[Paul Wise]

On Sun, Sep 18, 2011 at 6:15 AM, Francesco Poli wrote:

 May I run Intel video drivers on my actual hardware from inside a kvm
 virtual machine?

It looks like kvm is supposed to support PCI pass-through, but not for
graphics cards:

http://phoronix.com/forums/showthread.php?33506-QEMU-0.14-Improves-Linux-Virtualization

Apparently Xen does support that for GPUs though.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6GxtWEfn950kce2rxy_K+EkSx0T5jPxsQQs4dOXdYu=r...@mail.gmail.com

Re: How to startx inside a pbuilder-managed chroot?

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 18.09.2011 00:24, Paul Wise wrote:
 Apparently Xen does support that for GPUs though.

yes it does, but don't expect too much from it. Passing through video
cards is a complicated, error-prone operation. For some video cards
(notably Nvidia's) this is known not to work at all in some cases. If I
didn't scare you off yet, have a look to [1] and [2].

Finally please note, passing through a PCI devices implies to hide it
from your host system. This means, you have /no/ video card output at
all from your host system, unless you have a spare video card. This
turns your testing system into a headless one.

[1] http://wiki.xensource.com/xenwiki/XenPCIpassthrough
[2] http://wiki.xen.org/xenwiki/XenVGAPassthrough
- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOdR9+AAoJEMcrUe6dgPNt1CEP/jCUdA+7wztL28QlxdjQ4bxN
RjNF7bpYQk2aLQNSys66Juj2HRn3YWrekIMVypzs3tI/Nt9+kXbT7pkcx/P75R/q
0FqEnhlC93ZHQVUiEBkueiuMLWuAXH1kDnr9hfUgB2qrS3XcVTP/e9Mo/YWvGBEV
Ocs5Kr7+nbIQui1/LhCxHax8+bwhgIn0Hb0bFlLKCleIDHCoUk4ermKUB5/mrGgh
qtS2XoopI0F10CuOXO54qqiHF0AGg0DERww4SXTqmnJu1ytHPIgCG+1qJybjXIOw
GmpFFPMm7x03tGIHCHKaPXbgRN/+s4Cv0wlHZVWb8NQErZd0QchvjBTZTJmdCxfX
3EzgC3gL7GNQDcQKHRYQNlkxvao4L32LAkW4lW5X0wHzdJZJ1WLo+OC03iQkZ2ev
06CgiyR8d8/iPLydFzDiRS4bcLYNOGhG4hpQcu1dRA1wf+F01T9eJ6Gdi+UDm9gi
OH4QvvdCGPAvWEQ6U1KrSorGp3r6s0ZU6ePljSj4YC0EWjYd9xYlMItmjoCeH9oY
ylOu1xyD4EZbf2wBPNVyVKDAI5KhRrncyae0Ct9OO345ZJrsDBowYMe6dlk2e7ms
ysm0sClVXjRG9MT+SMnHOkOlcxz+BZrxGnTutO3XOBWpS4/hdtt3WRJ+YjHUknsr
dtbqCHa6ukbZhDnHvjQ5
=3vvz
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e751f7f.6050...@toell.net

Re: How to startx inside a pbuilder-managed chroot?

[Georgios M. Zarkadas]

Hi,

From the answers of the other participants of this thread so far, I
think that the simpler solution for your case is to: 

i) Make a minimal sid installation in a usb hard disk with only the
packages contained in the chroot plus the ones you want to test.

ii) Boot the real hardware (the box with the graphics card) from the usb
disk, start X the usual way and perform the tests.

If you want complete security of your normal system's data, unplug the
internal hard disk of the test box whenever you intend to boot from the
usb disk (or make a complete backup beforehand).

This does not answer your original question of course (I don't have a
good answer to that either) but it will allow you to do the job, with a
different type of throw-away test environment.

regards
George Zarkadas


signature.asc
Description: This is a digitally signed message part

How to startx inside a pbuilder-managed chroot?

[Francesco Poli]

Hello,
I am not sure which list I should direct this question to: it's a
problem I am facing because I need to try and reproduce some bugs
inside a throw-away test environment (without risking to crash my real
boxes).
If there's a better Debian list where I can ask this question, please
suggest: I apologize in advance, if this is the case.

What I am trying to do (and failing miserably at) is to start an X
session inside a throw-away sid chroot environment.

The chroot environment has already been set up long ago and I keep it
updated.
A description of how I set up the sid chroot environment (by using
pbuilder) may be found at
http://www.inventati.org/frx/doc/nanodocs/testing_workstation_programming.html#setting-up-chroots-for-building-debian-packages

Here's what I tried. I closed my real X session, and logged in on my
first virtual console. From there, I logged into my sid chroot (in a
throw-away manner):

  $ sudo pbuilder login --configfile ~/.pbuilder/sid.conf

Then, inside the chroot, I installed the needed packages, among which:

  # aptitude install xorg
  # aptitude install fluxbox

I created a temporary regular user:

  # adduser --disabled-login niceguy
  # adduser niceguy video
  # adduser niceguy adm
  # passwd niceguy

and prepared a simple ~/.xsession file:

  # cat ~niceguy/.xsession
  fluxbox  MANAGERPID=$!
  xset r rate 400 40
  xset b off
  wait $MANAGERPID
  savelog -p -c 4 ~/.xsession-errors

I changed allowed_users=console into allowed_users=anybody
in /etc/X11/Xwrapper.config and then became the regular user
(but please note that I got the same errors as root!):

  # su - niceguy
  $ startx

I got an error that told me that X could not open tty0.
Indeed there's no /dev/tty0 in my sid chroot: it seems that
only /dev/tty is present.
Please note that I don't have external directories bind-mounted in the
chroot environment, since the pbuilder documentation seems to say that
it is considered harmful for the throw-away mode:
http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#chroot

I tried to manually create the device file:

  # mknod /dev/tty0 c 4 0
  # chown niceguy:tty /dev/tty0

After that, X refused to start with a different error message: cannot
open virtual console 7...


Please, someone more knowledgeable than me, tell me where I went
wrong!
I searched the web about running X inside chroot environments, but I
failed to find useful hints about my issue.
Thanks for any help you may provide!


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpTQAhrx2zbH.pgp
Description: PGP signature

Re: How to startx inside a pbuilder-managed chroot?

[Francesco Poli]

On Sat, 10 Sep 2011 22:07:21 +0200 Francesco Poli wrote:

 Hello,
[...]

I forgot to add that I am not subscribed to the list, hence please Cc:
me on replies.
Thanks!

-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp2BOsi2rq8U.pgp
Description: PGP signature

chroot

[Jaromír Mikeš]

Hello mentors,

trying set up chroot sid environment here.

After processing

#cdebootstrap sid /path/to/chroot

process stay on line

P: Configuring helper cdebootstrap-helper-apt

Just want to know if it is normal and I should continue set up chroot.
Or there is something wrong.

I am using this how-to:
http://viral.media.mit.edu/wiki/tiki-index.php?page=Debian+chroot+environment

regards

mira
 


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

Re: chroot

[Jaromír Mikeš]

 Od: Jaromír Mikeš mira.mi...@seznam.cz

 process stay on line

 P: Configuring helper cdebootstrap-helper-apt

Sorry for this question ... it is quite known issue

Is there other way how to test .change file with lintian in sid e.g. pbuilder?

regards

mira


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

Re: chroot

[Alexander Reichle-Schmehl]

Hi!

Jaromír Mikeš schrieb:
 Od: Jaromír Mikeš mira.mi...@seznam.cz
 
 process stay on line

 P: Configuring helper cdebootstrap-helper-apt
 Sorry for this question ... it is quite known issue
 
 Is there other way how to test .change file with lintian in sid e.g. pbuilder?

Yould either use pbuilder --login to log into your pbuilder chroot or
install the lintian backport from www.backports.org.


Best regards,
  Alexander



signature.asc
Description: OpenPGP digital signature

Re: chroot

[Jaromír Mikeš]

 Od: Alexander Reichle-Schmehl alexan...@schmehl.info

  process stay on line
 
  P: Configuring helper cdebootstrap-helper-apt
  Sorry for this question ... it is quite known issue
  
  Is there other way how to test .change file with lintian in sid e.g.
 pbuilder?
 
 Yould either use pbuilder --login to log into your pbuilder chroot or
 install the lintian backport from www.backports.org.

Thank you for tip 
btw. just cdebootstrap has a problem probably only on ubuntu based distros ... 
debootstrap is fine

regards

mira  


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

Re: pbuilder/chroot problems

[Sven Joachim]

On 2008-11-09 01:06 +0100, Boyd Stephen Smith Jr. wrote:

 I'm trying to set up a pbuilder environment on my laptop, and it's failing 
 with this error:
 W: Failure trying to run: chroot /home/bss/debootstrap-test 
 dpkg --force-depends --install var/cache/apt/archives/libc6_2.7-16_amd64.deb

 I tried etch instead of sid, thinking it might be some unstable breakage, and 
 got an error that only differed in the version of libc6.

 The error looked to be coming for debootstrap, so I tried debootstrapping 
 manually (variant=buildd) and got the same error.

 Then, I attempted to to the chroot command directly, and got a bit more 
 verbose output ending in:
 Setting up libc6 (2.7-16) ...
 sh: /dev/null: Permission denied
 sh: /dev/null: Permission denied

My crystal ball tells me that /home is mounted with the `nodev' option.
Correct?

Sven


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: pbuilder/chroot problems

[Boyd Stephen Smith Jr.]

On Sunday 09 November 2008 03:05, Sven Joachim wrote:
 On 2008-11-09 01:06 +0100, Boyd Stephen Smith Jr. wrote:
  I attempted to to the chroot command directly, and got a bit more
  verbose output ending in:
  Setting up libc6 (2.7-16) ...
  sh: /dev/null: Permission denied
  sh: /dev/null: Permission denied

 My crystal ball tells me that /home is mounted with the `nodev' option.
 Correct?

Brilliant!

Yeah, that's my problem. I guess I was expecting 'nodev' to cause some other 
error, perhaps on device creation.  I was initially creating my pbuilder 
chroots on in /var/cache and that's also mounted 'nodev'.

I know chroots will need special attention but, are there any guidelines as to 
what filesystems are generally safe to mount 'nodev' (and 'nosuid')?
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
[EMAIL PROTECTED]                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     


pgphWdHWkG8dU.pgp
Description: PGP signature

pbuilder/chroot problems

[Boyd Stephen Smith Jr.]

I'm trying to set up a pbuilder environment on my laptop, and it's failing 
with this error:
W: Failure trying to run: chroot /home/bss/debootstrap-test 
dpkg --force-depends --install var/cache/apt/archives/libc6_2.7-16_amd64.deb

I tried etch instead of sid, thinking it might be some unstable breakage, and 
got an error that only differed in the version of libc6.

The error looked to be coming for debootstrap, so I tried debootstrapping 
manually (variant=buildd) and got the same error.

Then, I attempted to to the chroot command directly, and got a bit more 
verbose output ending in:
Setting up libc6 (2.7-16) ...
sh: /dev/null: Permission denied
sh: /dev/null: Permission denied
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
75.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (Can't locate Term/ReadLine.pm in @INC (@INC 
contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 
/usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 
/usr/local/lib/site_perl .) 
at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.)
debconf: falling back to frontend: Teletype
sh: /dev/null: Permission denied
sh: /dev/null: Permission denied
/var/lib/dpkg/info/libc6.postinst: line 29: /dev/null: Permission denied
dpkg: error processing libc6 (--install):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 libc6

I checked the permissions of /dev/null inside the chroot and they are 
identical to the permissions outside the chroot:
crw-rw-rw- 1 root root 1, 3 2007-05-21 10:31 debootstrap-test/dev/null
crw-rw-rw- 1 root root 1, 3 2008-11-08 03:35 /dev/null

Outside the chroot, I can write to either device as any user.  Once I've 
chrooted, writing fails:
sh-3.2# id
uid=0(root) gid=0(root) groups=0(root)
sh-3.2# echo foo  /dev/null
sh: /dev/null: Permission denied

I can only assume that the issue is introduced by the chroot command.  The 
chroot I'm using comes from coreutils-5.97-5.3.  However, my VPS has the same 
version of coreutils, and it does not show similar behavior:
[EMAIL PROTECTED]:~$ sudo cowbuilder --login --basepath 
/var/cache/pbuilder/sid.cow
Password:
 - Copying COW directory
 - Invoking pbuilder
 - Running in no-targz mode
 - copying local configuration
 - mounting /proc filesystem
 - mounting /dev/pts filesystem
 - policy-rc.d already exists
Obtaining the cached apt archive contents
 - entering the shell
[EMAIL PROTECTED]:/# echo foo  /dev/null
[EMAIL PROTECTED]:/# echo $?
0

(I use cowbuilder there, but error occurs with both cowbuilder and pbuilder.)

Since the chroot command delegates most of the heavy lifting to the chroot 
system call, I thought that this change in behavior might be due to differing 
kernel versions.  The VPS (working) is 2.6.24-19-xen (uname -r).  The 
laptop (broken) is 2.6.24-etchnhalf.1-amd64.

Moving back to 2.6.18-[456] on this laptop would be a little annoying -- it 
has Intel 3945 wireless built-in, and I prefer the iwl3945 module in 2.6.24 
over the ipw3945 module in 2.6.18 -- among other things, it suspends better.

I don't see a bug about this, perhaps I should file one?
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
[EMAIL PROTECTED]                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     


pgpqok98fbZbR.pgp
Description: PGP signature

Re: sid chroot

[Jeremiah C. Foster]

 Thank you Ricardo,
 
 That did the trick.
 
 However, now i wander whether would be appropriate to bring up this 
 inconsistency between the two tools. For instance the Debian Reference 
 document section 8.6.35.1 states:
 
 A chroot Debian environment can easily be created by the debootstrap 
 command in Sarge. For post-Sarge distributions, you may use cdebootstrap 
 command instead with appropriate option. For example, to create a Sid 
 chroot on /sid-root while having fast Internet access:
 
 However, on Etch cdebootstrap seems to fail while debootstrap works fine.

I think it is known that debootstrap is better than cdebootstrap. For
example, here is a quote from a recent email on debian-live:[0]

in general, you should always prefere debootstrap over cdebootstrap:
debootstrap turned out to be better maintained, and it is the official
tool of debian, also used by debian-installer, and it is slightly
faster (although it's written in shell and cdebootstrap is C).

second, debootstrap got updated in the first etch point release
4.0r1) and is thus recent enough to build a lenny or sid live system.

0. http://lists.debian.org/debian-live/2008/08/msg00249.html


Personally I have used debootstrap without a problem a couple of
times so I feel confident in its quality. I have never used
cdebootstrap. 
 
 if you think that this is important enough to be brought up then whom 
 shall i address?

You may want to file a bug against cdebootstrap.

Regards,
  Jeremiah


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

sid chroot

[Dionysis Kalofonos]

Hello,

i am trying to create a chroot environment for sid using the command

cdebootstrap  -v  --flavour=minimal  sid  /sid  http://ftp.debian.org/deb

under etch.

however i get the following error message:

O: The following NEW packages will be installed:
O:   apt-utils lzma
O: 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
O: Need to get 243kB of archives.
O: After this operation, 504kB of additional disk space will be used.
O: WARNING: The following packages cannot be authenticated!
O:   lzma apt-utils
O: Failed to fetch bootstrap:/pool/main/l/lzma/lzma_4.43-14_i386.deb 
Hash Sum mismatch
O: Failed to fetch 
bootstrap:/pool/main/a/apt/apt-utils_0.7.14+b1_i386.deb  Hash Sum mismatch

O: Authentication warning overridden.
O: E: Unable to fetch some archives, maybe run apt-get update or try 
with --fix-missing?

E: Couldn't install system due to errors!

this happens only on the above specific packages and not the numerous 
packages that where downloaded and installed by cdebootstrap up to that 
point. what is the meaning of the error, and how can i overcome it?


many thanks, regards
--
-- Dionysis Kalofonos


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: sid chroot

[Ricardo Ichizo]

Hello Dionysis,

On Thu, Aug 28, 2008 at 11:18:30AM +0200, Dionysis Kalofonos wrote:
 Hello,

 i am trying to create a chroot environment for sid using the command

 cdebootstrap  -v  --flavour=minimal  sid  /sid  http://ftp.debian.org/deb

 under etch.


Try it with debootstrap.

debootstrap sid /sid-root http://ftp.debian.org/debian/

Best regards,
-- 
  _(~)_
   )(  [[ n1ghtcr4wler ]]
  (@_@)   xmpp:[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: sid chroot

[Sebastian Harl]

Hi,

On Thu, Aug 28, 2008 at 11:18:30AM +0200, Dionysis Kalofonos wrote:
 i am trying to create a chroot environment for sid using the command
 
 cdebootstrap  -v  --flavour=minimal  sid  /sid  http://ftp.debian.org/deb
 
 under etch.

In general, *debootstraping Sid under Etch is not supported - use
cdebootstrap-static from Sid for that purpose.

HTH,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Re: sid chroot

[Dionysis Kalofonos]

Thank you Ricardo,

That did the trick.

However, now i wander whether would be appropriate to bring up this 
inconsistency between the two tools. For instance the Debian Reference 
document section 8.6.35.1 states:


A chroot Debian environment can easily be created by the debootstrap 
command in Sarge. For post-Sarge distributions, you may use cdebootstrap 
command instead with appropriate option. For example, to create a Sid 
chroot on /sid-root while having fast Internet access:


However, on Etch cdebootstrap seems to fail while debootstrap works fine.

if you think that this is important enough to be brought up then whom 
shall i address?


-- Dionysis Kalofonos


Ricardo Ichizo wrote:

Hello Dionysis,

On Thu, Aug 28, 2008 at 11:18:30AM +0200, Dionysis Kalofonos wrote:

Hello,

i am trying to create a chroot environment for sid using the command

cdebootstrap  -v  --flavour=minimal  sid  /sid  http://ftp.debian.org/deb

under etch.



Try it with debootstrap.

debootstrap sid /sid-root http://ftp.debian.org/debian/

Best regards,



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: sid chroot

[Dionysis Kalofonos]

Hi Sebastian, thank you for your reply.

I was also advised to use debootstrap instead, and that tool worked 
fine. However, having read your message now i get the impression that 
something fishy has happened.


regards
-- Dionysis Kalofonos


Sebastian Harl wrote:

Hi,

On Thu, Aug 28, 2008 at 11:18:30AM +0200, Dionysis Kalofonos wrote:

i am trying to create a chroot environment for sid using the command

cdebootstrap  -v  --flavour=minimal  sid  /sid  http://ftp.debian.org/deb

under etch.


In general, *debootstraping Sid under Etch is not supported - use
cdebootstrap-static from Sid for that purpose.

HTH,
Sebastian




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: RFC/RFS: aptjail: Powerful chroot() generator for Debian systems

[Francois-Denis Gonthier]

Hello,

The description of your project has somehow piqued my curiosity.  But, as Neil 
Williams said, I think you need to explain to us how is it different from 
(c)deboostrap.

What can you program do that I couldn't do with a trivial shell script? What 
have you solved that would go beyond triviality?  What have YOU used this 
script for?

BTW, I can't sponsor since I'm not a DD, but maybe I can find an use for it at 
work.

On August 12, 2007 01:05:37 am Kyle Moffett wrote:
 -snip-
 The relevant files are all found at http://moffetthome.net:1/
 ~kyle/aptjail/  I've got all the outputs of dpkg-buildpackage, as

At 7:55 EAT, this site was not working:

An error occurred while loading http://moffetthome.net:1/~kyle/aptjail:
Unknown host hephaestus.moffett.home

 well as the original source tarball I made (aptjail-0.01.tar.bz2)
 and an extracted copy in the aptjail subdirectory.





pgp2CVRe39LLu.pgp
Description: PGP signature