12:09 p.m.
We noticed that "bc -l" will always segfault. Richard Maw tracked this down,
and noticed that there's an upstream "alpha" release, 1.06.95, from 2006,
which fixes this (and some other) problems. Debian is using that release.
I propose we upgrade bc in Baserock to 1.06.95. This is slightly tricky
since Lorry doesn't support multiple versions for tarball releases at
this time.
I have tested this as follows:
* create a new system branch
* morph edit in that system branch
* build and deploy the devel-system-x86_64-generic system
* in the deployed system, run this and watch it segfault:
echo 1/2 | bc -l
* in the system branch's bc, replace the old sources with the alpha
release (commands copy-pasted from my shell history):
- rm -rf *
- wget http://alpha.gnu.org/gnu/bc/bc-1.06.95.tar.bz2
- tar xf bc-1.06.95.tar.bz2
- mv bc-1.06.95/* .
- rmdir bc-1.06.95
- rm bc-1.06.95.tar.bz2
- git add .
- git rm acconfig.h mkinstalldirs stamp-h.in
- git commit
* build and deploy the devel system again
* in the deployed system, run this and watch it NOT segfault:
echo 1/2 | bc -l
The delta between the two releases is quite large, and it's all
upstream changes: Baserock does not carry a delta for bc.
Would everyone be OK if I merge my branch with the new upstream
release into bc-tarball's baserock/morph? +1 or -1 for this merge?
--
http://www.codethink.co.uk/ http://wiki.baserock.org/ http://www.baserock.com/
12:12 p.m.
On Wed, Sep 18, 2013 at 18:09:02 +0100, Lars Wirzenius wrote:
Would everyone be OK if I merge my branch with the new upstream
release into bc-tarball's baserock/morph? +1 or -1 for this merge?
If you update the lorry, will it not import the new tarball for us?
D.
--
Daniel Silverstone http://www.codethink.co.uk/
Principal Managing Engineer GPG 4096/R Key Id: 3CCE BABE 206C 3B69
4:48 a.m.
On Wed, Sep 18, 2013 at 06:12:37PM +0100, Daniel Silverstone wrote:
On Wed, Sep 18, 2013 at 18:09:02 +0100, Lars Wirzenius wrote:
> Would everyone be OK if I merge my branch with the new upstream
> release into bc-tarball's baserock/morph? +1 or -1 for this merge?
If you update the lorry, will it not import the new tarball for us?
I am under the impression it doesn't, and I didn't want to experiment and
possibly break things on a live Trove.
--
http://www.codethink.co.uk/ http://wiki.baserock.org/ http://www.baserock.com/
4:57 a.m.
On 19/09/13 10:48, Lars Wirzenius wrote:
On Wed, Sep 18, 2013 at 06:12:37PM +0100, Daniel Silverstone wrote:
> On Wed, Sep 18, 2013 at 18:09:02 +0100, Lars Wirzenius wrote:
>> Would everyone be OK if I merge my branch with the new upstream
>> release into bc-tarball's baserock/morph? +1 or -1 for this merge?
> If you update the lorry, will it not import the new tarball for us?
I am under the impression it doesn't, and I didn't want to experiment and
possibly break things on a live Trove.
I think it will, but it will create a new commit id and the previous
commit will be lost. Which I think it will break previous baserock
releases.
Tiago
5:06 a.m.
On Thu, Sep 19, 2013 at 10:57:18AM +0100, Tiago Gomes wrote:
On 19/09/13 10:48, Lars Wirzenius wrote:
>On Wed, Sep 18, 2013 at 06:12:37PM +0100, Daniel Silverstone wrote:
>>On Wed, Sep 18, 2013 at 18:09:02 +0100, Lars Wirzenius wrote:
>>>Would everyone be OK if I merge my branch with the new upstream
>>>release into bc-tarball's baserock/morph? +1 or -1 for this merge?
>>If you update the lorry, will it not import the new tarball for us?
>I am under the impression it doesn't, and I didn't want to experiment and
>possibly break things on a live Trove.
>
I think it will, but it will create a new commit id and the previous
commit will be lost. Which I think it will break previous baserock
releases.
It *shouldn't* break a release: we shouldn't be referring to the master
branch, but a baserock/something branch, and releases should be petrified,
so the ref is a sha1 anyway.
However, I don't want to lose history in any case.
--
http://www.codethink.co.uk/ http://wiki.baserock.org/ http://www.baserock.com/
5:17 a.m.
On Thu, Sep 19, 2013 at 11:06:58 +0100, Lars Wirzenius wrote:
[snip]
For reference, Lorry's tarball import is actually clever enough to deal with
this, although the change was not widely publicised.
It does the right thing if you change the tarball URL :-)
D.
--
Daniel Silverstone http://www.codethink.co.uk/
Principal Managing Engineer GPG 4096/R Key Id: 3CCE BABE 206C 3B69
12:13 p.m.
On Wed, Sep 18, 2013 at 06:09:02PM +0100, Lars Wirzenius wrote:
Would everyone be OK if I merge my branch with the new upstream
release into bc-tarball's baserock/morph? +1 or -1 for this merge?
For this change, yes, though I think we should also apply any of debian's
patches that apply, since there's likely to be more than just debian
integration patches there.
12:29 p.m.
On Wed, Sep 18, 2013 at 06:13:58PM +0100, Richard Maw wrote:
On Wed, Sep 18, 2013 at 06:09:02PM +0100, Lars Wirzenius wrote:
> Would everyone be OK if I merge my branch with the new upstream
> release into bc-tarball's baserock/morph? +1 or -1 for this merge?
For this change, yes, though I think we should also apply any of debian's
patches that apply, since there's likely to be more than just debian
integration patches there.
I looked at them. This seems the only one relevant to us, though I
admit I don't know what it does:
--- bc-1.06.95.orig/bc/main.c
+++ bc-1.06.95/bc/main.c
@@ -358,6 +358,9 @@
errno = save;
#else
write (1, "\n(interrupt) Exiting bc.\n", 26);
+#ifdef READLINE
+ rl_initialize (); /* Clear readline buffer */
+#endif
#if defined(LIBEDIT)
if (edit != NULL)
el_end(edit);
The rest is Debian packaging, or documentation tweaks, which I don't
care about.
--
http://www.codethink.co.uk/ http://wiki.baserock.org/ http://www.baserock.com/
4:42 a.m.
On Wed, Sep 18, 2013 at 06:29:50PM +0100, Lars Wirzenius wrote:
On Wed, Sep 18, 2013 at 06:13:58PM +0100, Richard Maw wrote:
> On Wed, Sep 18, 2013 at 06:09:02PM +0100, Lars Wirzenius wrote:
> > Would everyone be OK if I merge my branch with the new upstream
> > release into bc-tarball's baserock/morph? +1 or -1 for this merge?
>
> For this change, yes, though I think we should also apply any of debian's
> patches that apply, since there's likely to be more than just debian
> integration patches there.
I looked at them. This seems the only one relevant to us, though I
admit I don't know what it does:
--- bc-1.06.95.orig/bc/main.c
+++ bc-1.06.95/bc/main.c
@@ -358,6 +358,9 @@
errno = save;
#else
write (1, "\n(interrupt) Exiting bc.\n", 26);
+#ifdef READLINE
+ rl_initialize (); /* Clear readline buffer */
+#endif
#if defined(LIBEDIT)
if (edit != NULL)
el_end(edit);
The rest is Debian packaging, or documentation tweaks, which I don't
care about.
Some research into the Debian changelog reveals this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287210
Summary: without this change, this will happen:
1
(interrupt) use quit to exit.
2+3
15
The input buffer (which contains "1") is not cleared when the user
types control-C. So the whole expression is "12+3", which is rather
surprising.
A minor bug, but we might as well fix it, I think. I'll add the patch,
and rebuild the system.
--
http://www.codethink.co.uk/ http://wiki.baserock.org/ http://www.baserock.com/
6:08 a.m.
On Thu, Sep 19, 2013 at 10:42:58AM +0100, Lars Wirzenius wrote:
A minor bug, but we might as well fix it, I think. I'll add the
patch,
and rebuild the system.
I applied the patch to the branch, and built + deployed the system again.
Works fine, though of course we don't actually use readline at the moment.
--
http://www.codethink.co.uk/ http://wiki.baserock.org/ http://www.baserock.com/
7:46 a.m.
On Wed, Sep 18, 2013 at 06:09:02PM +0100, Lars Wirzenius wrote:
* in the system branch's bc, replace the old sources with the
alpha
release (commands copy-pasted from my shell history):
- rm -rf *
- wget http://alpha.gnu.org/gnu/bc/bc-1.06.95.tar.bz2
- tar xf bc-1.06.95.tar.bz2
- mv bc-1.06.95/* .
- rmdir bc-1.06.95
- rm bc-1.06.95.tar.bz2
- git add .
- git rm acconfig.h mkinstalldirs stamp-h.in
- git commit
I have tried to build a baserock-10 system with those changes and have
encountered build failures. I am now attempting to build from master,
but that will take a long time as I am currently rebuilding everything
upwards of stage1-gcc.
I will withold a verdict until I know whether those changes work against
master.
3473
days inactive
3474
days old
10 comments
5 participants
participants (5)
-
Daniel Silverstone -
Jonathan Maw -
Lars Wirzenius -
Richard Maw -
Tiago Gomes