(Commands like reopen need to go to cont...@bugs.debian.org to work and
the bug number needs to be given. See http://www.debian.org/Bugs - but
I'm not re-opening the bug as this is not a bug in Debian AFAICT.)
On Sat, 29 Oct 2011 18:13:09 +0300
anatoly techtonik wrote:
> > I'm fairly sure it's not actually a bug in the source code of the Perl
> > scripts themselves, so that approach won't get far. I see no reason to
> > think this is a problem within svn-buildpackage itself, it is something
> > to do with your VM configuration.
>
> That's not helpful. Perl executes ok. Other perl scripts also execute
> ok. So the problem in the way Perk executed this particular script.
The problem *appears* as a result of using this package, that's the best
that can be demonstrated so far. No evidence that the package is the
cause of the bug. (You are trying to pin the effect on the wrong cause.)
The output below shows that there are low level memory and/or
library linkage problems on this VM. Chances are high that if you
installed a wider range of software on this VM you would find other
packages demonstrating the same problem. It sounds like something in
your low level setup is causing programs to end up accessing memory
outside of the normal behaviour. Which programs will show the effect is
entirely unpredictable - this time it's svn-buildpackage but there is
nothing about svn-bp which is actually causing the memory corruption,
it is simply the only package you've run so far which has revealed the
underlying fault in your VM.
> Maybe in the way Perl imports external modules. Think about it - you
> should know. Perhaps the problem is in some binary extension or svn
> bindings. I don't have experience with that.
No evidence of that and the only evidence is solely under your control.
There's nothing I can do about that.
My advice? Ditch the current VM and recreate it from scratch. Something
is definitely wrong in the low level config of this VM. Trash it.
(That's why people use VM in the first place, after all.)
> >> > Also try creating a Wheezy chroot and testing in that.
> >>
> >> Oh no. That's too hardcore. I don't want to pollute this VM more than
> >> necessary.
> >
> > debootstrap wheezy dir/
> > chroot dir/
>
> I am running Squeeze, not Wheezy. Is it ok?
debootstrap carries scripts to cope with the release after the stable
release, so yes, debootstrap in stable can always generate a bootstrap
based on the testing release which follows it.
> > It's not hard. Something had to call that to create the VM in the
> > first place. It's how Debian Installer creates the installation.
>
> The machine was created with Xen.
No, xen just provided the top level interface. Something installed the
actual Debian packages and that is probably debootstrap because
debootstrap is explicitly designed to be able to create Debian systems
on most POSIX systems. Xen then provides another layer on top of the
"chroot /dir" command to operate the VM.
> Will it create other dirs like
> pbuilder does somewhere in /var (or /usr)? I'd really like to keep
> this machine clean of any extra stuff.
This "machine" is demonstrating low level memory corruption issues.
That is no basis for retaining it of trying to keep it clean.
debootstrap will put the system under the current working directory so
that you can just clean it up afterwards. HOWEVER, there seems little
point doing that on this system because the VM itself is bust and a
different chroot will still suffer memory corruption. It might show up
with different packages but it will still be there.
Create a debootstrap chroot on another machine and test svn-buildpackage
there, maybe in a completely fresh VM but if that shows problems as
well then on a completely different physical machine.
You can create a Squeeze or Wheezy Debian system on another machine,
build your package in that and copy the package to the VM. There is
absolutely no need to build the package in the VM itself, especially
if you want to keep the VM "clean".
> > (yet you're expecting to use svn-buildpackage to build Debian packages
> > to use on presumably other Debian machines?)
>
> I need to a stable version 0.6 of Bitten (which is trac-bitten) that
> was not released yet in Debian. I can't build it on other machine,
> because latest Python policy (not new version of package) requires
> versions of packages like buildhelper that are absent on previous
> versions.
You are trying to backport a package which has never been packaged
properly for Debian. svn-buildpackage is not the solution there. You'd
have to learn Debian packaging properly and ask advice from
http://mentors.debian.net
I cannot help you with that task but there are others in Debian who
can. mentors is the place for that assistance.
> > I think you are blaming the wrong package - just because one package
> > shows the error does not mean that the bug actually lies in that
> > package. I suspect a problem in the VM itself and it's the kind o
