Debian Bug report logs - #581337
sm: SIGSEGV on armel

Package: screen-message; Maintainer for screen-message is Joachim Breitner <nomeata@debian.org>;

Reported by: Paul Wise <pabs@debian.org>

Date: Wed, 12 May 2010 09:15:01 UTC

Severity: serious

Found in version 0.18-1

Fixed in version screen-message/0.19-1

Done: Joachim Breitner <nomeata@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to debian-bugs-dist@lists.debian.org, Dirk Eddelbuettel <edd@debian.org>:
Bug#581337; Package sm. (Wed, 12 May 2010 09:15:04 GMT) (full text, mbox, link).

Acknowledgement sent to Paul Wise <pabs@debian.org>:
New Bug report received and forwarded. Copy sent to Dirk Eddelbuettel <edd@debian.org>. (Wed, 12 May 2010 09:15:04 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Package: sm
Version: 0.18-1
Severity: serious

While testing if Khmer rendering is now working (it is), I found that sm
now segfaults on armel. The workaround is to comment out sm.c line 285:

        g_object_set(draw,"can-focus",1);

Alternatively if this is actually needed, this seems to work too:

	g_object_set(G_OBJECT(draw),"can-focus",1);

That gives this warning at runtime though:

(sm:6012): GLib-GObject-WARNING **: IA__g_object_set_valist: object class `GtkDrawingArea' has no property named `\u0002'

Here is the backtrace from my OpenMoko Freerunner running Debian sid:

root@booph:~/tmp/screen-message-0.18# gdb sm
rGNU gdb (GDB) 7.1-debian
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/root/tmp/screen-message-0.18/sm...done.
(gdb) r
Starting program: /home/root/tmp/screen-message-0.18/sm 
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x40998470 in strchr () from /lib/libc.so.6
(gdb) bt
#0  0x40998470 in strchr () from /lib/libc.so.6
#1  0x407d8450 in g_param_spec_pool_lookup () from /usr/lib/libgobject-2.0.so.0
#2  0x407d31f8 in g_object_set_valist () from /usr/lib/libgobject-2.0.so.0
#3  0x407d3978 in g_object_set () from /usr/lib/libgobject-2.0.so.0
#4  0x0000aa68 in main (argc=0, argv=0x0) at sm.c:285
(gdb) thread apply all bt full

Thread 1 (Thread 0x40d9f9d0 (LWP 6183)):
#0  0x40998470 in strchr () from /lib/libc.so.6
No symbol table info available.
#1  0x407d8450 in g_param_spec_pool_lookup () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#2  0x407d31f8 in g_object_set_valist () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#3  0x407d3978 in g_object_set () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#4  0x0000aa68 in main (argc=0, argv=0x0) at sm.c:285
        input = <value optimized out>
        c = <value optimized out>
        input_provided = <value optimized out>
        screen = 0x340c8
        colormap = 0x36400
        white = {pixel = 9716, red = 65535, green = 65535, blue = 65535}
        black = {pixel = 39453, red = 0, green = 0, blue = 0}
        color = {pixel = 45, red = 15840, green = 16386, blue = 38088}
        start = {dummy1 = 0x409e5198, dummy2 = 0x4001fb00, dummy3 = 64, dummy4 = 0, dummy5 = 1073872056, dummy6 = 1073889280, dummy7 = 1083402354, dummy8 = -1, dummy9 = 0x0, 
          dummy10 = 0x40ceeae8, dummy11 = 64, dummy12 = 19, dummy13 = 1083349696, dummy14 = 0x0}
        end = {dummy1 = 0x40024814, dummy2 = 0x0, dummy3 = 1088024608, dummy4 = 1, dummy5 = 0, dummy6 = 1, dummy7 = 1073780592, dummy8 = -1098374208, dummy9 = 0x40024814, 
          dummy10 = 0x0, dummy11 = 1088026416, dummy12 = 1, dummy13 = 0, dummy14 = 0x1}
        vbox_button = <value optimized out>
        hbox = <value optimized out>
        vbox = <value optimized out>
        accel = <value optimized out>
        key = <value optimized out>
        mod = <value optimized out>
(gdb) quit
A debugging session is active.

	Inferior 1 [process 6183] will be killed.

Quit anyway? (y or n) y

-- 
bye,
pabs

http://wiki.debian.org/PaulWise

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#581337; Package sm. (Thu, 13 May 2010 02:21:03 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. (Thu, 13 May 2010 02:21:03 GMT) (full text, mbox, link).

Message #10 received at 581337@bugs.debian.org (full text, mbox, reply):

reassign 581337 screen-message
thanks

'sm' is the source for r-cran-sm which is not the screen-message source
giving you the sm binary.

Dirk

On 12 May 2010 at 17:13, Paul Wise wrote:
| Package: sm
| Version: 0.18-1
| Severity: serious
| 
| While testing if Khmer rendering is now working (it is), I found that sm
| now segfaults on armel. The workaround is to comment out sm.c line 285:
| 
|         g_object_set(draw,"can-focus",1);
| 
| Alternatively if this is actually needed, this seems to work too:
| 
| 	g_object_set(G_OBJECT(draw),"can-focus",1);
| 
| That gives this warning at runtime though:
| 
| (sm:6012): GLib-GObject-WARNING **: IA__g_object_set_valist: object class `GtkDrawingArea' has no property named `\u0002'
| 
| Here is the backtrace from my OpenMoko Freerunner running Debian sid:
| 
| root@booph:~/tmp/screen-message-0.18# gdb sm
| rGNU gdb (GDB) 7.1-debian
| Copyright (C) 2010 Free Software Foundation, Inc.
| License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
| This is free software: you are free to change and redistribute it.
| There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
| and "show warranty" for details.
| This GDB was configured as "arm-linux-gnueabi".
| For bug reporting instructions, please see:
| <http://www.gnu.org/software/gdb/bugs/>...
| Reading symbols from /home/root/tmp/screen-message-0.18/sm...done.
| (gdb) r
| Starting program: /home/root/tmp/screen-message-0.18/sm 
| [Thread debugging using libthread_db enabled]
| 
| Program received signal SIGSEGV, Segmentation fault.
| 0x40998470 in strchr () from /lib/libc.so.6
| (gdb) bt
| #0  0x40998470 in strchr () from /lib/libc.so.6
| #1  0x407d8450 in g_param_spec_pool_lookup () from /usr/lib/libgobject-2.0.so.0
| #2  0x407d31f8 in g_object_set_valist () from /usr/lib/libgobject-2.0.so.0
| #3  0x407d3978 in g_object_set () from /usr/lib/libgobject-2.0.so.0
| #4  0x0000aa68 in main (argc=0, argv=0x0) at sm.c:285
| (gdb) thread apply all bt full
| 
| Thread 1 (Thread 0x40d9f9d0 (LWP 6183)):
| #0  0x40998470 in strchr () from /lib/libc.so.6
| No symbol table info available.
| #1  0x407d8450 in g_param_spec_pool_lookup () from /usr/lib/libgobject-2.0.so.0
| No symbol table info available.
| #2  0x407d31f8 in g_object_set_valist () from /usr/lib/libgobject-2.0.so.0
| No symbol table info available.
| #3  0x407d3978 in g_object_set () from /usr/lib/libgobject-2.0.so.0
| No symbol table info available.
| #4  0x0000aa68 in main (argc=0, argv=0x0) at sm.c:285
|         input = <value optimized out>
|         c = <value optimized out>
|         input_provided = <value optimized out>
|         screen = 0x340c8
|         colormap = 0x36400
|         white = {pixel = 9716, red = 65535, green = 65535, blue = 65535}
|         black = {pixel = 39453, red = 0, green = 0, blue = 0}
|         color = {pixel = 45, red = 15840, green = 16386, blue = 38088}
|         start = {dummy1 = 0x409e5198, dummy2 = 0x4001fb00, dummy3 = 64, dummy4 = 0, dummy5 = 1073872056, dummy6 = 1073889280, dummy7 = 1083402354, dummy8 = -1, dummy9 = 0x0, 
|           dummy10 = 0x40ceeae8, dummy11 = 64, dummy12 = 19, dummy13 = 1083349696, dummy14 = 0x0}
|         end = {dummy1 = 0x40024814, dummy2 = 0x0, dummy3 = 1088024608, dummy4 = 1, dummy5 = 0, dummy6 = 1, dummy7 = 1073780592, dummy8 = -1098374208, dummy9 = 0x40024814, 
|           dummy10 = 0x0, dummy11 = 1088026416, dummy12 = 1, dummy13 = 0, dummy14 = 0x1}
|         vbox_button = <value optimized out>
|         hbox = <value optimized out>
|         vbox = <value optimized out>
|         accel = <value optimized out>
|         key = <value optimized out>
|         mod = <value optimized out>
| (gdb) quit
| A debugging session is active.
| 
| 	Inferior 1 [process 6183] will be killed.
| 
| Quit anyway? (y or n) y
| 
| -- 
| bye,
| pabs
| 
| http://wiki.debian.org/PaulWise
| xapplication/pgp-signature [Click mouse-2 to save to a file]

-- 
  Regards, Dirk

Bug reassigned from package 'sm' to 'screen-message'. Request was from Dirk Eddelbuettel <edd@debian.org> to control@bugs.debian.org. (Thu, 13 May 2010 02:21:05 GMT) (full text, mbox, link).

Bug No longer marked as found in versions screen-message/0.18-1. Request was from Dirk Eddelbuettel <edd@debian.org> to control@bugs.debian.org. (Thu, 13 May 2010 02:21:06 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Joachim Breitner <nomeata@debian.org>:
Bug#581337; Package screen-message. (Thu, 13 May 2010 02:27:05 GMT) (full text, mbox, link).

Acknowledgement sent to Paul Wise <pabs@debian.org>:
Extra info received and forwarded to list. Copy sent to Joachim Breitner <nomeata@debian.org>. (Thu, 13 May 2010 02:27:06 GMT) (full text, mbox, link).

Message #19 received at 581337@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Wed, 2010-05-12 at 21:18 -0500, Dirk Eddelbuettel wrote:

> 'sm' is the source for r-cran-sm which is not the screen-message source
> giving you the sm binary.

I filed the bug against the sm binary package, not the sm source
package. I was under the impression that the BTS could now handle this
properly. owner@bugs.d.o, is that not the case?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Joachim Breitner <nomeata@debian.org>. (Thu, 13 May 2010 02:36:04 GMT) (full text, mbox, link).

Message #24 received at 581337@bugs.debian.org (full text, mbox, reply):

On 13 May 2010 at 10:25, Paul Wise wrote:
| On Wed, 2010-05-12 at 21:18 -0500, Dirk Eddelbuettel wrote:
| 
| > 'sm' is the source for r-cran-sm which is not the screen-message source
| > giving you the sm binary.
| 
| I filed the bug against the sm binary package, not the sm source
| package. I was under the impression that the BTS could now handle this
| properly. owner@bugs.d.o, is that not the case?

I don't think so. I get about one or so a year for this package. 

One day I'll rename my several dozen r-cran-* packages such that all their
source are also called r-cran-* but the renaming and stay in NEW is such a
hazzle that I've shied away from it so far...

-- 
  Regards, Dirk

Acknowledgement sent to owner@bugs.debian.org:
Extra info received and forwarded to list. Copy sent to Joachim Breitner <nomeata@debian.org>. (Thu, 13 May 2010 05:45:09 GMT) (full text, mbox, link).

Message #29 received at 581337@bugs.debian.org (full text, mbox, reply):

On Thu, 13 May 2010, Paul Wise wrote:
> On Wed, 2010-05-12 at 21:18 -0500, Dirk Eddelbuettel wrote:
> > 'sm' is the source for r-cran-sm which is not the screen-message source
> > giving you the sm binary.
> 
> I filed the bug against the sm binary package, not the sm source
> package. I was under the impression that the BTS could now handle this
> properly. owner@bugs.d.o, is that not the case?

This is the case, or at least, it should be.

However, the whole idea of having source package which do not produce
at least a binary of the same name is fundamentally broken, and I have
spoken repeatedly against doing it.


Don Armstrong

-- 
The beauty of the DRUNKENNESS subprogram was that you could move your
intoxication level up and down at will, instead of being caught on a
relentless down escalator to bargain basement philosophy and the
parking garage.
 -- Rudy von Bitter _Software_ p124

http://www.donarmstrong.com              http://rzlab.ucr.edu

Information forwarded to debian-bugs-dist@lists.debian.org, Joachim Breitner <nomeata@debian.org>:
Bug#581337; Package screen-message. (Thu, 13 May 2010 11:27:02 GMT) (full text, mbox, link).

Message #34 received at 581337@bugs.debian.org (full text, mbox, reply):

On 12 May 2010 at 22:40, Don Armstrong wrote:
| On Thu, 13 May 2010, Paul Wise wrote:
| > On Wed, 2010-05-12 at 21:18 -0500, Dirk Eddelbuettel wrote:
| > > 'sm' is the source for r-cran-sm which is not the screen-message source
| > > giving you the sm binary.
| > 
| > I filed the bug against the sm binary package, not the sm source
| > package. I was under the impression that the BTS could now handle this
| > properly. owner@bugs.d.o, is that not the case?
| 
| This is the case, or at least, it should be.
| 
| However, the whole idea of having source package which do not produce
| at least a binary of the same name is fundamentally broken, and I have
| spoken repeatedly against doing it.

Well narrowly spoken I then still do the right thing as my 'source pkg: sm'
with 'binary pkg: r-cran-sm' does provide the 'command'

     library(sm)			

inside R. 

There can't be another 'binary command' for the R language, but every R users
refers to this as 'sm'.

But I know what you really imply. I do get the 'letter' but not the 'spirit'
of this suggestion. 

-- 
  Regards, Dirk

Message #37 received at 581337@bugs.debian.org (full text, mbox, reply):

On Thu, 13 May 2010, Dirk Eddelbuettel wrote:
> On 12 May 2010 at 22:40, Don Armstrong wrote:
> | However, the whole idea of having source package which do not
> | produce at least a binary of the same name is fundamentally
> | broken, and I have spoken repeatedly against doing it.
> 
> Well narrowly spoken I then still do the right thing as my 'source
> pkg: sm' with 'binary pkg: r-cran-sm' does provide the 'command'
> 
>      library(sm)			
> 
> inside R. 

Right, the logic behind choosing sm as a source package name for
r-cran-sm is clear. My main problem with it is just the ramifications
of doing that in Debian.

If I was paying more attention when R packages started coming into the
archive, I would have lobbied harder for them to follow the lib*-perl
model, where the source package and the binary package have the same
name... so the binary package r-cran-sm would be built by the
r-cran-sm source package, and if you wanted the R library sm, you'd
just look for r-*-sm. [Since users don't generally see the source
package name, it tends not to matter what it's called.]

> There can't be another 'binary command' for the R language, but
> every R users refers to this as 'sm'.

Well, there could be, but hopefully people wouldn't at least conflict
with the CRAN repository.

> But I know what you really imply. I do get the 'letter' but not the
> 'spirit' of this suggestion.

The spirit here is really just to avoid confusion where you have a
binary and source package which share the same name, but are built
from different source packages. I've made changes to the BTS to handle
this issue, so that the BTS deals with it properly, but (as evidenced
by this bug) it's confusing for the maintainers and users who haven't
been exposed to this problem and its solution.

For the record, if you mean the source package sm, you need to file
bugs against:

Source: sm

or reassign them using

reassign nnn src:sm

Source packages will always have 'src:' prefixed, which works ok,
because ';' isn't a valid character for a package name. As a nod to
backwards compatibility, bugs filed against a package 'foo' which
isn't a binary package, but is a source package, will behave as if
they were assigned to 'src:foo'. Otherwise, it's assumed that you mean
the binary package, not the source package.

At least, that's how it's supposed to work. [If it didn't, or doesn't
in the future, please let me know.]

Don Armstrong

-- 
When I was a kid I used to pray every night for a new bicycle. Then I 
realized that the Lord doesn't work that way so I stole one and asked
Him to forgive me.
 -- Emo Philips.

http://www.donarmstrong.com              http://rzlab.ucr.edu

Message #42 received at 581337@bugs.debian.org (full text, mbox, reply):

On 13 May 2010 at 10:01, Don Armstrong wrote:
| On Thu, 13 May 2010, Dirk Eddelbuettel wrote:
| > On 12 May 2010 at 22:40, Don Armstrong wrote:
| > | However, the whole idea of having source package which do not
| > | produce at least a binary of the same name is fundamentally
| > | broken, and I have spoken repeatedly against doing it.
| > 
| > Well narrowly spoken I then still do the right thing as my 'source
| > pkg: sm' with 'binary pkg: r-cran-sm' does provide the 'command'
| > 
| >      library(sm)			
| > 
| > inside R. 
| 
| Right, the logic behind choosing sm as a source package name for
| r-cran-sm is clear. My main problem with it is just the ramifications
| of doing that in Debian.
| 
| If I was paying more attention when R packages started coming into the
| archive, I would have lobbied harder for them to follow the lib*-perl

If memory serves, I started with RODBC and tseries. Thanks to the
corresponding debian/changelog entries, that can be pinned to March 2003.
Seven years ago. AFAICR we had no consistent Perl Policy (TM) at the time.

On 30 Dec 2003 I posted (to debian-devel and r-devel) a proposed 'Debian R
Policy' but never followed in a formal manner.  

*Informally* we now have this consensus: new r-cran-$FOO packages of CRAN
sources $FOO comes with source and binary named r-cran-$FOO.

So the question now is whether we need to clean up the several dozen packages
that do not correspond.

| model, where the source package and the binary package have the same
| name... so the binary package r-cran-sm would be built by the
| r-cran-sm source package, and if you wanted the R library sm, you'd
| just look for r-*-sm. [Since users don't generally see the source
| package name, it tends not to matter what it's called.]

Yes. That is what we do.

We even once had r-bioc-* for a BioC package (that was later withdrawn, the
BioC people changed their packaging layoyt) and we have
r-other-$AUTHOR-$PACKAGE for things that comes from neither CRAN nor BioC.
 
| > There can't be another 'binary command' for the R language, but
| > every R users refers to this as 'sm'.
| 
| Well, there could be, but hopefully people wouldn't at least conflict
| with the CRAN repository.
| 
| > But I know what you really imply. I do get the 'letter' but not the
| > 'spirit' of this suggestion.
| 
| The spirit here is really just to avoid confusion where you have a
| binary and source package which share the same name, but are built
| from different source packages. I've made changes to the BTS to handle
| this issue, so that the BTS deals with it properly, but (as evidenced
| by this bug) it's confusing for the maintainers and users who haven't
| been exposed to this problem and its solution.
| 
| For the record, if you mean the source package sm, you need to file
| bugs against:
| 
| Source: sm
| 
| or reassign them using
| 
| reassign nnn src:sm

Ack.
 
| Source packages will always have 'src:' prefixed, which works ok,
| because ';' isn't a valid character for a package name. As a nod to
| backwards compatibility, bugs filed against a package 'foo' which
| isn't a binary package, but is a source package, will behave as if
| they were assigned to 'src:foo'. Otherwise, it's assumed that you mean
| the binary package, not the source package.
| 
| At least, that's how it's supposed to work. [If it didn't, or doesn't
| in the future, please let me know.]

:)

Dirk

| 
| 
| Don Armstrong
| 
| -- 
| When I was a kid I used to pray every night for a new bicycle. Then I 
| realized that the Lord doesn't work that way so I stole one and asked
| Him to forgive me.
|  -- Emo Philips.
| 
| http://www.donarmstrong.com              http://rzlab.ucr.edu

-- 
  Regards, Dirk

Acknowledgement sent to owner@bugs.debian.org:
Extra info received and forwarded to list. Copy sent to Joachim Breitner <nomeata@debian.org>. (Thu, 13 May 2010 19:03:03 GMT) (full text, mbox, link).

Message #47 received at 581337@bugs.debian.org (full text, mbox, reply):

On Thu, 13 May 2010, Dirk Eddelbuettel wrote:
> On 13 May 2010 at 10:01, Don Armstrong wrote:
> | If I was paying more attention when R packages started coming into
> | the archive, I would have lobbied harder for them to follow the
> | lib*-perl
> 
> If memory serves, I started with RODBC and tseries. Thanks to the
> corresponding debian/changelog entries, that can be pinned to March
> 2003. Seven years ago. AFAICR we had no consistent Perl Policy (TM)
> at the time.
> 
> On 30 Dec 2003 I posted (to debian-devel and r-devel) a proposed 'Debian R
> Policy' but never followed in a formal manner.  

Yeah, it's mainly my fault that I didn't notice or respond properly.
[I was even using R then, though I wasn't working on the BTS.]

> *Informally* we now have this consensus: new r-cran-$FOO packages of
> CRAN sources $FOO comes with source and binary named r-cran-$FOO.

Awesome; that's really what I wanted to make sure was happening.

> So the question now is whether we need to clean up the several dozen
> packages that do not correspond.

It's not worth it, IMO. The pain of renaming source packages is worse
than the minor issue of bugs ocassionally getting into the wrong
place. So long as we try to avoid the problem for new packages, it's
good enough as far as I'm concerned.


Don Armstrong

-- 
Nothing is as inevitable as a mistake whose time has come.
 -- Tussman's Law

http://www.donarmstrong.com              http://rzlab.ucr.edu

Information forwarded to debian-bugs-dist@lists.debian.org, Joachim Breitner <nomeata@debian.org>:
Bug#581337; Package screen-message. (Thu, 13 May 2010 20:30:06 GMT) (full text, mbox, link).

Message #52 received at 581337@bugs.debian.org (full text, mbox, reply):

On 13 May 2010 at 12:00, Don Armstrong wrote:
| On Thu, 13 May 2010, Dirk Eddelbuettel wrote:
| > On 13 May 2010 at 10:01, Don Armstrong wrote:
| > | If I was paying more attention when R packages started coming into
| > | the archive, I would have lobbied harder for them to follow the
| > | lib*-perl
| > 
| > If memory serves, I started with RODBC and tseries. Thanks to the
| > corresponding debian/changelog entries, that can be pinned to March
| > 2003. Seven years ago. AFAICR we had no consistent Perl Policy (TM)
| > at the time.
| > 
| > On 30 Dec 2003 I posted (to debian-devel and r-devel) a proposed 'Debian R
| > Policy' but never followed in a formal manner.  
| 
| Yeah, it's mainly my fault that I didn't notice or respond properly.
| [I was even using R then, though I wasn't working on the BTS.]
| 
| > *Informally* we now have this consensus: new r-cran-$FOO packages of
| > CRAN sources $FOO comes with source and binary named r-cran-$FOO.
| 
| Awesome; that's really what I wanted to make sure was happening.
| 
| > So the question now is whether we need to clean up the several dozen
| > packages that do not correspond.
| 
| It's not worth it, IMO. The pain of renaming source packages is worse
| than the minor issue of bugs ocassionally getting into the wrong
| place. So long as we try to avoid the problem for new packages, it's
| good enough as far as I'm concerned.

Bingo. I fully agree.

And I personally don't care that much about the r-cran-* packages in Debian
(besides of course religiously maintaining my own ones). I care more about,
and look after, the result of the 'cran2deb' GSoC I mentored and which lives
at

  http://debian.cran.r-project.org

It has i386 and amd64 repos of all of CRAN as r-cran-* --- as of today 2243
packages.  If you run testing, or can run testing binaries, it is quite
useful.  Now, for those on other arches .... tough bananas I am afraid.

-- 
  Regards, Dirk

Reply sent to Joachim Breitner <nomeata@debian.org>:
You have taken responsibility. (Mon, 17 May 2010 16:37:17 GMT) (full text, mbox, link).

Notification sent to Paul Wise <pabs@debian.org>:
Bug acknowledged by developer. (Mon, 17 May 2010 16:37:17 GMT) (full text, mbox, link).

Message #57 received at 581337-close@bugs.debian.org (full text, mbox, reply):

Source: screen-message
Source-Version: 0.19-1

We believe that the bug you reported is fixed in the latest version of
screen-message, which is due to be installed in the Debian FTP archive:

screen-message_0.19-1.debian.tar.gz
  to main/s/screen-message/screen-message_0.19-1.debian.tar.gz
screen-message_0.19-1.dsc
  to main/s/screen-message/screen-message_0.19-1.dsc
screen-message_0.19.orig.tar.gz
  to main/s/screen-message/screen-message_0.19.orig.tar.gz
sm_0.19-1_amd64.deb
  to main/s/screen-message/sm_0.19-1_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 581337@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Joachim Breitner <nomeata@debian.org> (supplier of updated screen-message package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 17 May 2010 18:13:34 +0200
Source: screen-message
Binary: sm
Architecture: source amd64
Version: 0.19-1
Distribution: unstable
Urgency: low
Maintainer: Joachim Breitner <nomeata@debian.org>
Changed-By: Joachim Breitner <nomeata@debian.org>
Description: 
 sm         - Displays a short text fullscreen
Closes: 581337
Changes: 
 screen-message (0.19-1) unstable; urgency=low
 .
   * New upstream release
     + Fixes SIGSEGV by not using g_object_set (Closes: #581337)
   * Switch to 3.0 (quilt) source format
   * Bump standards version, no change.
Checksums-Sha1: 
 a2a22d42464be1d3f0e2d358f178bc9f4d6e399b 1210 screen-message_0.19-1.dsc
 ebfe432bd95d1d5d2cacb1d0c317414ec5ffad21 89838 screen-message_0.19.orig.tar.gz
 c621bb743b05d5fa2c45d5cd8a32fc098de5a1d3 3002 screen-message_0.19-1.debian.tar.gz
 d3230a416bccd22bfbe05327514add2f90571bd1 16646 sm_0.19-1_amd64.deb
Checksums-Sha256: 
 18bbc9ee570ebfe98a3587a8663d24497ac4e2cb7b1f09f70ff49aa5f171b4ad 1210 screen-message_0.19-1.dsc
 496741e63a0ee87c645ca0e2d5f5608c2cacf81127a1af083f2dc61721994bf9 89838 screen-message_0.19.orig.tar.gz
 05ce934099806527e202c19b08113388e8f6d365cd473d515ef3a2b577ca6cc4 3002 screen-message_0.19-1.debian.tar.gz
 dccdaa069d4dd363dfded6ecabb74d181399be4511fb4ca70def4ed9b5912653 16646 sm_0.19-1_amd64.deb
Files: 
 c993dc39bb7606a242a657031cca5d9e 1210 games optional screen-message_0.19-1.dsc
 8fdc923b4de3fb84a2438aaabd34eb3b 89838 games optional screen-message_0.19.orig.tar.gz
 661fd5f8fa5ba8464f38782f25040ef6 3002 games optional screen-message_0.19-1.debian.tar.gz
 3a7ec99e7a4c295ba1867c08b6c63fb1 16646 games optional sm_0.19-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkvxazwACgkQ9ijrk0dDIGzHjgCgqQPY2K7gmmTzyu/5etmjhR91
1GEAoIubL0N+t+9OQYQDYjaM3k9pEVUC
=PeT6
-----END PGP SIGNATURE-----

Bug Marked as found in versions 0.18-1. Request was from Gerfried Fuchs <rhonda@debian.at> to control@bugs.debian.org. (Thu, 22 Jul 2010 19:33:02 GMT) (full text, mbox, link).

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 20 Aug 2010 07:33:50 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Tue Jan 9 19:34:30 2018; Machine Name: beach

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Debian Bug report logs - #581337 sm: SIGSEGV on armel

Debian Bug report logs - #581337
sm: SIGSEGV on armel