Bug#798697: Use CSS pre-wrap for message pages on lists.debian.org

[James Y Knight]

Package: lists.debian.org

For example, the mail:
  https://lists.debian.org/debian-sparc/2015/06/msg5.html
would be a lot easier to read in the archive, if the text soft-wrapped to
the browser width, instead of making a horizontal scrollbar.

Accomplishing this should be as trivial as adding a tiny bit of css to the
page, like:

pre {
 white-space: pre-wrap;
}

Bug#691371: Broken COPY relocation with UNIQUE symbols (upstream #12510)

[James Y Knight]

Package: libc6
Version: 2.13-35

I just rediscovered http://sourceware.org/bugzilla/show_bug.cgi?id=12510 in my 
application. Fixed by 
http://sourceware.org/git/?p=glibc.git;a=commit;h=028478fa40d85a73b19638dbe3f83b1acebf370c

Attached is the test-case I came up with before I found the commit that fixes 
it, and then the upstream bug.

This is a regression in wheezy vs squeeze; gcc in squeeze didn't generate 
UNIQUE symbols (at least for this case), AND the old dynamic linker seems to 
not have this bug.

The actual code part of that upstream patch applies cleanly to wheezy's libc 
and fixes the problem. ISTM that it'd be a good idea to backport, given that 
wheezy isn't going to upgrade to a new upstream release.

 test.h 
template
class Foo {
public:
static const char foo[];
};

 test1.cpp 
#include "test.h"

// Creates a UNIQUE symbol (and thus hits dynamic linker bug), used to
// create a WEAK symbol instead.
template
const char Foo::foo[] = "string";
template class Foo;

const char * getone() {
// Creates a R_X86_64_GLOB_DAT relocation
return Foo::foo;
}

 test2.cpp 
#include "test.h"
#include 
#include 

int main() {
// Reference creates a R_X86_64_COPY relocation
if (strcmp(Foo::foo, "string")) {
printf("'%s'\n", Foo::foo);
return 1;
}
return 0;
}


 test.sh 
g++ -fPIC -shared -o test.so test1.cpp
g++ -o test test2.cpp ./test.so
./test


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

Bug#678525: GCC bug

[James Y Knight]

It's not a bug in GCC. It's a bug in the code. The second call to
PyArg_ParseTuple passes an int* where a Py_ssize_t* should be passed. (The
&data_len argument).


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

Bug#681475: std::pair C++03/11 incompat

[James Y Knight]

Package: gcc-4.7
Version: 4.7.1-2

In the current version of GCC 4.7 in Debian, std::pair isn't
ABI-compatible when used as a return value between C++03 and C++11 modes.
This was recently fixed in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53657

It'd be really nice to get the fixed version of gcc accepted into wheezy,
so that users (or packages) compiling with -std=c++11 don't get mysterious
crashes from it. This particular incompatibility bites many boost::python
programs compiled in C++11 mode (against the c++03 debian
libboost-python), and surely there are other real cases where it shows up
as well.




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

Bug#610703: bug webpages should use white-space: pre-wrap

[James Y Knight]

On Jan 21, 2011, at 8:21 PM, Don Armstrong wrote:
> On Fri, 21 Jan 2011, James Y Knight wrote:
>> Also, changing the style to "pre-wrap" won't normally have any impact at all 
>> on hard-wrapped mail, since user's browser windows aren't generally < 80 
>> columns wide. So it seems to me like a no-lose change to make to the CSS.
> 
> It's perfectly legitimate to send very long lines which should not be 
> wrapped. We have quite a few examples where this is the case, which is why I 
> won't set that CSS element for all messages.

Essentially all other mail archive software now tells the browsers to soft-wrap 
long lines: pipermail (only as of mailman 2.1.13 or later), mhonarc used by 
lists.debian.org (forever, afaict), and gmane, at least. Works fine there...I 
can't see any advantage for having a horizontal scrollbar instead of letting 
the browser word-wrap. So, I'd say there is no circumstance when it is 
appropriate to have the lines run on past the edge of the browser window. 
Simply always tell it wrap to the window width, just like everyone else is 
doing.

Furthermore, every mail client I know of also word wraps at the window width 
(but surely you can find some example of one that doesn't). 

However, it's not worth it to me to argue further. I've already had it solved 
for myself for over a year by adding this to my browsers' user-CSS file, (added 
to workaround the issue with older mailman installations, but works for debbugs 
too):
html>body>pre { white-space: pre-wrap !important; }

> If there's no way (besides checking out X-mailer) to determine whether we 
> should be wrapping at some width, or just letting the lines run on, then 
> people will just have to use less crappy mailers.


That's a good one. I'm sure everyone is going to use a different mailer so that 
the web archives of debian bug reports will be pretty.

James


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

Bug#610703: bug webpages should use white-space: pre-wrap

[James Y Knight]

Don Armstrong wrote:
> The solution is to actually change styles for messages which use
> format=flowed, not change it for messages which properly insert
> linebreaks.

I'm afraid you've misunderstood the issue. There is no problem in debbugs
related to format=flowed. The whole point of format=flowed mail is that it
*does* insert linebreaks. So as long as the reader doesn't decode the
format=flowed encoding (which debbugs does not), it looks almost like
80char-wrapped-text.

However, Apple mail no longer uses format=flowed. Now (since OSX 10.6.2),
it simply sends long lines (encoded with quoted-printable if necessary to
ensure the lines don't exceed the line limit in the SMTP transaction).

Also, changing the style to "pre-wrap" won't normally have any impact at
all on hard-wrapped mail, since user's browser windows aren't generally <
80 columns wide. So it seems to me like a no-lose change to make to the
CSS.




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

Bug#610703: bug webpages should use white-space: pre-wrap

[James Y Knight]

Package: bugs.debian.org

Bugs submitted via email from mailers like Apple Mail (starting in OSX 10.6.2+) 
show up as one long line in the bug archives, with a horizontal scrollbar. This 
is unfortunate.

This started happening because they now just use long lines, and 
quoted-printable to wrap them into the mail payload when they're too long for 
SMTP, instead of format=flowed like they did before. And the bug archive 
software decodes quoted-printable, but didn't decode format=flowed.

Here's an example of a rather unfortunate page:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560781

The solution is to add:
pre {
 white-space: pre-wrap;
}
to /css/bugs.css

James


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

Bug#531529: Ping re: pdftk refuses to work with DRM'd PDFs

[James Y Knight]

Just wondering if this bug got lost...Can this patch be applied?

There's really no point in checking that the password entered was the "owner" 
password when the "user" password is entirely equivalent...

James


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

Bug#569203: Already packaged in Ubuntu

[James Y Knight]

Presumably that package can just be imported into Debian. It's been  
there since Apr 2009 apparently.

http://packages.ubuntu.com/source/lucid/parti-all



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

Bug#579494: socat is GPLv2-only, links against GPLv3 libreadline6

[James Y Knight]

Package: socat
Version: 1.7.1.2-1
Severity: serious

Socat is licensed under the GPLv2, according to the "README" file, not  
GPLv2 or later. The debian package is built against libreadline6,  
which is under GPLv3 or later. Since GPLv2 and GPLv3 are incompatible,  
this is a license violation.


I'd suggest making socat Build-Depend on libreadline5-dev again to  
solve this problem. (Which thus unfixes bug 553853; that should be  
marked wontfix, since fixing it necessarily involves a license  
violation.)


James



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

Bug#553741: libreadline 6 is GPLv3+: clisp can't use it

[James Y Knight]

CLISP is under GPLv2 only, while libreadline version 6 is licensed  
under GPLv3.


Therefore, it is not be legal for clisp to use libreadline version 6;  
I recommend this be closed wontfix.


James



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

Bug#568813: SASL auth broken (patch available upstream)

[James Y Knight]

Package: autofs5-ldap
Version: 5.0.3-3

(still broken in 5.0.4-3.1).

SASL auth is broken against some ldap servers (like windows server  
2008), because autofs5 tries to authenticate twice on a single  
connection, and the server won't accept a second authentication.


It's already fixed upstream, with this patch:
http://www.kernel.org/pub/linux/daemons/autofs/v5/autofs-5.0.5-refactor-ldap-sasl-bind.patch

That patch applies cleanly to the existing debian package version  
5.0.4-3.1, and auth works. It'd be nice if this patch could be  
integrated into the debian package.


James



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

Bug#151820: Good news upstream

[James Y Knight]

On Feb 2, 2010, at 5:27 AM, Olaf van der Spek wrote:

Nice!
If that's not possible, maybe adding the new syntax to the existing  
Ubuntu patch (I assume it's send host-name "gethostname()";)  
shouldn't be hard.


My understanding from the man pages is that it would be:
  send host-name = gethostname();
although I've not attempted to verify that my understanding is correct.

If you look in the "dhcp-options" and "dhcp-eval" manpages, you can  
see the syntax for such expressions. I don't see any mention of them  
working in a "send" line, but I *think* all the infrastructure for  
parsing and evaluating such expressions is already present, it's just  
the new function gethostbyname() expression that was added (thus  
expr_gethostname). So the patch will be completely different and  
should be much less hacky than Ubuntu's patch.


James



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

Bug#151820: Good news upstream

[James Y Knight]

I just ran into this issue recently for a group of hosts I'm managing,  
and solved it, for now, by importing the patch "debian/patches/dynamic- 
hostname.dpatch" from Ubuntu's DHCP3 package, and adding:

  send host-name "";
to the default config file. Just to get things going for myself.

However, while investigating things, I ran into good news from  
upstream; it looks like it will be (finally!) fixed in dhclient 4.2,  
woo!


From http://oldwww.isc.org/sw/dhcp/dhcp4_2.php?noframes=1

"
Added a configuration function, 'gethostname()', which calls the  
system function of the same name and presents the results as a data  
expression. This function can be used to incorporate the system level  
hostname of the system the DHCP software is operating on in responses  
or queries (such as including a failover partner's hostname in a dhcp  
message or binding scope, or having a DHCP client send any system  
hostname in the host-name or FQDN options by default).

"

But, since 4.2 alpha was just released in December, and Debian doesn't  
even have 4.1 yet, it looks like this probably won't make it in time  
for squeeze...and it'd be really nice if it worked right out of the  
box in Squeeze if at all possible.


So, perhaps now that upstream's preferred solution is known, it'd be  
okay to backport that change to the DHCP version currently in Debian,  
so that squeeze can have the fix? I suspect it *WOULD* be completely  
trivial to backport, if ISC's CVS repository wasn't behind a $200 pay- 
wall (Seriously!). But, even without being able to just merge  
the single commit, I think just grepping for expr_gethostname and  
copying everything about that is likely to be all that's needed.


If you're amenable to releasing a dhcp3-client with such a backport, I  
can take a shot at extracting out such a patch...(although, perhaps  
you have access to upstream's source repo and it'd be easier for you?)


James



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

Bug#560781: (require :package) no longer works for CLC-managed packages

[James Y Knight]

On Jan 14, 2010, at 12:41 AM, Peter Van Eynde wrote:


My current plan was to:

- - make the inclusion of the CLC directory configurable
- - add clbuild support to the package:
  * clbuild would get downloaded and updated on the client machine
  * we would have a new command clc-clbuild which would download and
compile the package as a 'cl-build' user. The resulting files
are world-readable, but not writable. (also updates should work)



Only root would be able to use clc-clbuild, right?

I don't really have any opinion on the specifics of the implementation  
or whether this would work well or not, but I'm very much in favor of  
a change that *allows* fasls to be created for use by all users,  
instead of compiled separately for each user.


I understand it can't do that always by default, because then it  
blocks apt-get for unreasonable amounts of time recompiling every  
installed lisp package for every updated implementation, like CLC did  
at one point in the past.


IMO it'd be best, from a theoretical standpoint, if the buildds  
generated actual binary debs for each lisp impl, but I suppose that's  
also infeasible for various reasons.


--

I guess my ideal debian lisp integration would be:

$ apt-get install sbcl cl-cffi
-> I have actual FASL files on disk that sbcl can use, so that
(require :cffi) just has to load them: no compilation necessary.

But since that seems infeasible, second best would be:

Works like today, where it gets compiled separately for every user,  
unless admin first runs a shell command like:


$ clc-precompile sbcl cl-cffi

At which point, the fasls are compiled for sbcl and usable by all  
users. An upgrade of cl-cffi would have to make sure to delete that  
cache, so that the per-user cache can be populated for the new version.


But anyways, this is all incremental improvements. What's most  
important to me is that, by default, without additional configuration,  
installing sbcl and the cl-cffi packages actually makes cffi usable,  
in the normal way (require :cffi), on the system sbcl.


James



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

Bug#560781: (require :package) no longer works for CLC-managed packages

[James Y Knight]

On Jan 12, 2010, at 11:10 AM, Peter Van Eynde wrote:


Hello James,

Just FYI I've started working on CLC v7 where this will be a system- 
wide

setting overrideable with a user-specific configuration file.


Thanks for the info.

I'd still like to hear if you have any more specifics about the  
problem with CLBuild, though.


And if the CLC v7 work isn't going to be complete in time for the next  
Debian release, I'd like to make a humble suggestion that the change  
in 6.19 be reverted, and system-wide packages be put back in the  
default ASDF paths.


(Especially if the change was done due to rumors of a problem with  
CLBuild, rather than an actual problem. Some people seem to think CLC  
still has a daemon for compiling stuff like it did in 2003...)


James



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

Bug#560781: (require :package) no longer works for CLC-managed packages

[James Y Knight]

This change was done so that using for example clbuild in Debian  
becomes

possible again. Otherwise the packaged systems will interfere with the
clbuild or locally generated systems.


I still don't understand. The new behavior, even though now  
documented, breaks all user expectations for how to use lisp packages,  
and makes everything debian specific. That just doesn't seem like a  
good idea.


I've never had a problem with using locally built systems that I put  
in ~/.sbcl/systems: they come before /usr/share/common-lisp/systems/  
in the asdf:*central-registry* by default and it works just fine.


And what's the issue with CLBuild? I just tried using it (for the  
first time) to see what the deal was, and it really doesn't look  
broken. (Note: I reverted the change in CLC, so this is with CLC fully- 
active). It seems to work fine. Note that CLBuild overrode  
asdf:*central-registry* to only contain its packages, so it shouldn't  
even matter what CLC did to asdf:*central-registry*...


If you can describe the bug, maybe some other solution than  
having .deb-provided lisp packages disabled by default might come to  
mind.


./clbuild install cffi
[[[...downloads a bunch of stuff using darcs...]]]

./clbuild lisp
This is SBCL 1.0.31.0.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.

* asdf:*central-registry*

(#P"/tmp/clbuild/systems/")

* (require 'cffi)
[[[...lots of spam, compiling and loading everything...]]]

* (cffi:defcfun ("abs" c-abs) :int (n :int))

C-ABS
* (c-abs -5)

5

James

BTW: I didn't get your previous email to the bug, only the close  
notice...Seems kind of bogus behavior for a bugtracker.




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

Bug#560963: cl-cffi: Loading cffi fails

[James Y Knight]

This is probably related to bug 560781.



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

Bug#560859: prefix-args accumulate indefinitely

[James Y Knight]

Package: rlwrap
Version: 0.28-2

If I press "M-5" and then "f", "f" gets correctly repeated 5 times. However, 
then the count doesn't get reset, so all letters from then on out all get 
repeated 5 times! The prefix-arg should be reset after every command. But here 
there doesn't seem to be any way to reset the prefix argument at all! Even 
pressing M-1 after that just appends the 1 to the 5, causing everything to be 
repeated 51 times, even worse!

This is quite irritating, as when that happens there's no way to recover except 
quitting the program, so far as I can tell.

I'm not sure who this bug belongs to. I think it's in rlwrap since I've never 
seen it happen in other readline-using programs (for example: python), but, 
just in case it's not, I have libreadline5 5.2-3.1.

I also tried upgrading rlwrap 0.33 from unstable, which uses libreadline6, and 
that didn't change the behavior.


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

Bug#560781: (require :package) no longer works for CLC-managed packages

[James Y Knight]

Package: common-lisp-controller
Version: 6.19

When I upgraded CLC from 6.17 to 6.20, neither
(require 'cffi)
nor
(asdf:oos 'asdf:compile-op :cffi)
work anymore, even though the cl-cffi package is installed. 

Looking at the changelog, it seems like this was an intentional change in 6.19,
"Make clc only active in clc calls. This should increase the compatibility with 
clbuild and friends"

But I don't really understand what the intended usage is now? So it's 
compatible with clbuild...by not working by itself anymore? I don't get it. Am 
I expected to have to explicitly call clc:clc-require now?

I kinda feel like I must be missing something obvious, since nobody else has 
reported this bug yet.

If this was intentional, and it is required that I call clc:clc-require, it is 
really quite unfortunate, as it means the debian packaged lisp software no 
longer works normally like custom-installed asdf packages do...and I'm not 
about to change all my locally-installed packages to call clc-require...so this 
makes the debian CL-* packages seem basically useless and broken.

At the very least, the documentation needs updating if things are going to stay 
this way, since it still says:
> - a user wants to use a system-wide library.
>   (asdf:oos 'asdf:compile-op :)
>   will load the system at
>   /usr/share/common-lisp/systems/.asd
>   that will use the source at 
>   /usr/share/common-lisp/source/
>   fasls will be placed in 
>   /var/cache/common-lisp-controller

And that's not the case




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

Bug#543730: SIP 4.8 has a new (non-free?) license

[James Y Knight]

Source: sip4-qt3
Version: 4.8.1-1
Severity: serious

The copyright file in the package contains the license for SIP 4.0 not  
SIP 4.8. (That's a bug in itself...)


The *actual* SIP 4.8 license (contained in the file named "LICENSE")  
is substantially different. In particular, it now contains a new clause:

4. Licensee may not use SIP 4.8.1 to generate Python bindings for any
C or C++ library for which bindings are already provided by Riverbank.



As I understand things, this makes the license non-free due to DFSG6  
"No Discrimination Against Fields of Endeavor", and furthermore, not  
GPL-compatible.





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

Bug#499801: sprof doesn't work at all in lenny

[James Y Knight]

Also described in this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=458861

sprof in lenny (libc 2.7-18) is currently completely non-functional  
due to that bug.


I tried applying that patch to debian's glibc, and while it applies  
cleanly, and solves the immediate issue, I then get:


Inconsistency detected by ld.so: dl-open.c: 652: _dl_open: Assertion  
`_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!


And unfortunately, that bug is also still present in debian glibc  
2.9-21. So sprof in unstable is also completely non-functional. :(


It might be solved by the patch in:
http://sourceware.org/ml/libc-alpha/2008-08/msg00016.html

But I haven't tried rebuilding again with that patch to see if those  
*two* patches are all that's needed.

The thread suggests that it might not be...

James



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

Bug#531529: pdftk refuses to work with DRM'd PDFs

[James Y Knight]

Package: pdftk
Version: 1.41-3

With a PDF which is encrypted and has an owner password set, but no  
user password (so I can view it in any other tool), it refuses to do  
anything unless you provide the owner password. There's no reason for  
it to do so, it just arbitrarily decides not to work.


This patch fixes it for me:

diff -ur pdftk-1.41/pdftk/pdftk.cc pdftk-1.41-2/pdftk/pdftk.cc
--- pdftk-1.41/pdftk/pdftk.cc   2006-11-28 17:51:36.0 -0500
+++ pdftk-1.41-2/pdftk/pdftk.cc 2009-06-01 23:43:24.0 -0400
@@ -191,7 +191,7 @@
// store in this java object so the gc can trace it
g_dont_collect_p->addElement( reader );

-   input_pdf_p->m_authorized_b= ( !reader->encrypted ||  
reader->passwordIsOwner );

+   input_pdf_p->m_authorized_b= true;
if( !input_pdf_p->m_authorized_b ) {
open_success_b= false;
}




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

Bug#487316: Libunwind 0.99 released

[James Y Knight]

libunwind 0.99 was released on 08-May-2009. It'd be great if this new  
release could be uploaded to debian, with support for x86, amd64, arm,  
mips, and powerpc archs.


But I have a bad feeling this package might be effectively orphaned in  
Debian, considering it's the only package "owned" by Matthieu, and has  
seen no update nor comment in a great many years.


See also, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465876  
where u++, co-maintained by Matthieu, was orphaned by another DD in  
Feb 2008. Perhaps this package should be also be placed into orphaned  
status?






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

Bug#522849: Execshield kernel patch partially to blame

[James Y Knight]

So I attempted to reproduce my issue with a debian 2.6.26 kernel, and  
was unable to. The debian kernel always put mmap areas either at the  
top of the address space or in the middle, depending on whether the  
stack size ulimit is finite or not.


After  further investigation, it seems that the behavior of smushing  
all the shared-library mappings down at the bottom, conflicting with  
the heap, is not in the upstream kernel, but is due to the execshield  
patch that Fedora adds. Looking at the patch here:


http://cvs.fedora.redhat.com/viewvc/devel/kernel/linux-2.6-execshield.patch?revision=1.90&view=markup

I see it makes mmap use "arch_get_unmapped_exec_area" (added in the  
patch) to get a free memory area if you call mmap with PROT_EXEC and  
(via arch_pick_mmap_layout) "if (!(current->personality &  
READ_IMPLIES_EXEC))".


And, arch_get_unmapped_exec_area starts filling from the bottom up.  
Also, despite it having a comment saying "Must not let a PROT_EXEC  
mapping get into the brk area", it appears that does sometimes happen,  
as well. And when it happens, it causes the heap to have no room to  
grow, thus breaking bash. Argh!


Although I'm not using the debian kernel or the debian execshield  
patch, I suspect this behavior is also present in the Debian  
execshield kernel patch but haven't verified.


This behavior was changed in Fedora CVS revision 1.103, with comment  
"Fix from H.J. Lu, we were doing 32-bit randomization on 64-bit  
vaddr". So the condition under which it will call  
arch_pick_mmap_layout now includes "mmap_is_ia32()". Thus it appears  
that on x86_64, the normal top-down stack layout will now be used for  
PROT_EXEC mappings as well, therefore leaving the heap plenty of room.


Given that I found that the behavior was a kernel bug not expected  
kernel behavior, that it wasn't ever in a "normal" kernel, and that  
it's apparently been fixed, I wouldn't be too upset to see this bug  
report result in no change to bash.


But I still think that the brain-damaged malloc included with bash  
would probably be better off disabled. Every other app can use mmap to  
get memory when sbrk runs out; bash was the only thing which sometimes  
failed.


James



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

Bug#522849: Bash xrealloc randomly fails

[James Y Knight]

Package: bash
Version: 3.2-4

I'm on an x86_64 machine.

I believe this bug is due to Bash's builtin malloc implementation only  
supporting sbrk() and not mmap() to get memory.


I'd like to suggest that the correct resolution of this bug is to  
disable bash's builtin malloc and simply use glibc's. I'm not sure  
whether or not this should be considered a kernel bug as well.


More details:

bash fails with a message like:
xrealloc: ../bash/general.c:888: cannot reallocate 262144 bytes (0  
bytes allocated)
(not always that exact line in the source, but that particular failure  
line is pretty common, I expect because it's allocating a lot of  
memory).


This started happening after an upgrade from kernel 2.6.22 to kernel  
2.6.26 (non-debian kernels). I've tracked it down to this new feature:

<<<
1.9. BRK and PIE executable randomization

Exec-shield is a Red Hat that was started in 2003 by Red Hat to
implement several security protections and is mainly used in Red Hat and
Fedora. Many features have already been merged lot of time ago, but not
all of them. In 2.6.25 two of them are being merged: brk() randomization
and PIE executable randomization. Those two features should make the
address space randomization on i386 and x86_64 complete.

http://kernelnewbies.org/Linux_2_6_25#head-fc71477174376b69ac7c3cd153ed513d25bf2cae
<<<

The randomized brk placement is disableable via "echo 1 > /proc/sys/ 
kernel/randomize_va_space". When that value is set to 1, the failures  
stop happening. When it's set to 2 (default value for my kernel), bash  
randomly fails with the above error.


It seems that what is happening is that the randomized heap placement  
is sometimes causing there to be shared libraries mapped close enough  
after the heap such that there's not enough room for expansion. And  
since bash's malloc can only use sbrk memory, it simply fails at that  
point.


I'll also note that the placement of libraries in low memory around  
the heap only happens if you've set a stack size ulimit, e.g. "ulimit - 
S -s 10240".


Here's /proc//maps of a process shortly before it fails:

0011-0012b000 r-xp  08:04  
41272590   /lib/ld-2.7.so
0032a000-0032c000 rw-p 0001a000 08:04  
41272590   /lib/ld-2.7.so
0040-004ba000 r-xp  08:04  
41271303   /bin/bash
006b9000-006c3000 rw-p 000b9000 08:04  
41271303   /bin/bash

006c3000-006c8000 rw-p 006c3000 00:00 0
006c8000-00702000 r-xp  08:04  
41272640   /lib/libncurses.so.5.6
00702000-00902000 ---p 0003a000 08:04  
41272640   /lib/libncurses.so.5.6
00902000-00907000 rw-p 0003a000 08:04  
41272640   /lib/libncurses.so.5.6
00907000-00909000 r-xp  08:04  
41272625   /lib/libdl-2.7.so
00909000-00b09000 ---p 2000 08:04  
41272625   /lib/libdl-2.7.so
00b09000-00b0b000 rw-p 2000 08:04  
41272625   /lib/libdl-2.7.so
00b0b000-00c49000 r-xp  08:04  
41272608   /lib/libc-2.7.so
00c49000-00e49000 ---p 0013e000 08:04  
41272608   /lib/libc-2.7.so
00e49000-00e4c000 r--p 0013e000 08:04  
41272608   /lib/libc-2.7.so
00e4c000-00e4e000 rw-p 00141000 08:04  
41272608   /lib/libc-2.7.so

00e4e000-00e53000 rw-p 00e4e000 00:00 0
00e53000-00e5a000 r-xp  08:04  
41272645   /lib/libnss_compat-2.7.so
00e5a000-01059000 ---p 7000 08:04  
41272645   /lib/libnss_compat-2.7.so
01059000-0105b000 rw-p 6000 08:04  
41272645   /lib/libnss_compat-2.7.so
0105b000-01064000 r-xp  08:04  
41272653   /lib/libnss_nis-2.7.so
01064000-01264000 ---p 9000 08:04  
41272653   /lib/libnss_nis-2.7.so
01264000-01266000 rw-p 9000 08:04  
41272653   /lib/libnss_nis-2.7.so
01266000-0127 r-xp  08:04  
41272649   /lib/libnss_files-2.7.so
0127-0146f000 ---p a000 08:04  
41272649   /lib/libnss_files-2.7.so
0146f000-01471000 rw-p 9000 08:04  
41272649   /lib/libnss_files-2.7.so
01471000-01473000 r-xp  08:04  
41320632   /usr/lib/gconv/ISO8859-1.so
01473000-01672000 ---p 2000 08:04  
41320632   /usr/lib/gconv/ISO8859-1.so
01672000-01674000 rw-p 1000 08:04  
41320632   /usr/lib/gconv/ISO8859-1.so
01e9d000-01ead000 rw-p 01e9d000 00:00  
0  [heap]
01f24000-01f38000 r-xp  08:04  
41272643   /lib/libnsl-2.7.so
01f38000-02137000 ---p 00014000 08:04  
41272643   /lib/libnsl-2.7.so
02137000-02139000 rw-p 0001300

Bug#499880: segfault in psycopg2

[James Y Knight]

Version 2.0.8 of psycopg2 has been released, and it would be good to  
get it packaged. One important thing it fixes is a double free in  
one of the error handling, which quickly leads to segfaults.
+1. Just ran into this segfault. I'll probably have to fix it locally  
sometime soon, but it would be really nice if a fix for it was  
released in debian.


If 2.0.8 can't be pulled into testing at this point in the release  
cycle, it seems at least fixing that segfault would be good.


This commit:
http://bazaar.launchpad.net/~psycopg/psycopg/2.0.x/revision/346.1.5

might be enough to fix that, but I don't know for sure.

From the NEWS file:

What's new in psycopg 2.0.8
---

* The connection object now has a get_backend_pid() method that
  returns the current PostgreSQL connection backend process PID.

* The PostgreSQL large object API has been exposed through the
  Cursor.lobject() method.

* Some fixes to ZPsycopgDA have been merged from the Debian package.

* A memory leak was fixed in Cursor.executemany().

* A double free was fixed in pq_complete_error(), that caused crashes
  under some error conditions.




James



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

Bug#487374: FTBFS: Cannnot calculate stack trace

[James Y Knight]

I built this package successfully on amd64 by adding:
DEB_CONFIGURE_EXTRA_FLAGS := --enable-frame-pointers

to debian/rules. I expect that should be conditional upon the arch  
being amd64 but I don't know how to do that.


Unfortunately, the build failures on powerpc and ia64 look to be  
completely different problems.


James



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

Bug#485955: gdb: completely fails to detect frames

[James Y Knight]

Could this be the same bug as:
https://bugzilla.novell.com/show_bug.cgi?id=390722
and
https://bugs.launchpad.net/ubuntu/hardy/+source/gdb/+bug/111869
?
(with patch available)

James



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

Bug#487316: Please package newer libunwind

[James Y Knight]

Package: libunwind
Severity: wishlist

Parts of google-perftools only work on x86-64 if libunwind is  
installed. However, it requires at least the libunwind-snap-070410  
version (at least according to its "INSTALL" file). Since libunwind  
upstream doesn't appear to be much into making releases, it might be  
appropriate to simply grab their latest git tree? The rate of change  
does not seem particularly high, so it seems that it might be a fairly  
safe thing to do.


That version should at least additionally work on x86 and x86-64, and  
appears to have at least some support in the code for arm, hppa,  
ppc32/64, and mips.


I notice that Fedora has packaged a snapshot from 070224 and  
apparently builds it for ia64, x86_64, i386, and ppc64.


Thanks,
James



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

Bug#425147: google-perftools new upstream version

[James Y Knight]

Just another vote for a newer version: I wanted to use this library in  
my code, but 0.8 is quite old. It sure would be nice if a newer  
version was packaged. They're now up to 0.97 upstream, fwiw.


Thanks,
James



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

Bug#422625: libc6 2.5-5 breaks binutils 2.17-3

[James Y Knight]

Package: libc6
Version: 2.5-5

On x86_64, mostly debian etch. After upgrading libc6 to unstable, I  
can no longer compile anything.


echo "int main() {return 0;}" > test.c
gcc test.c

/lib/libc.so.6: file not recognized: File format not recognized
collect2: ld returned 1 exit status

Upgrading binutils from 2.17-3 to 2.17cvs20070426-4 fixes the  
problem. Perhaps libc6 should have a versioned conflict with binutils?


James


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

Bug#422452: bzr-svn missing dependancy on python-pysqlite2

[James Y Knight]

Package: bzr-svn
Version: 0.3.2-1
Severity: serious
Justification: Policy 3.5

*** Please type your report below this line ***
Running 'bzr branch' emits:
Needs at least Python2.5 or Python2.4 with the pysqlite2 module
Unable to load plugin 'svn' from '/usr/lib/python2.4/site-packages/ 
bzrlib/plugins'


And indeed, bzr-svn is unusable.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (700, 'stable'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1.1381_FC3smp
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages bzr-svn depends on:
ii  bzr 0.15-1   bazaar-ng, the next- 
generation dis
ii  python  2.4.4-2  An interactive high- 
level object-o
ii  python-central  0.5.12   register and build  
utility for Pyt
ii  python-subversion   1.4.2dfsg1-2 Python bindings for  
Subversion
ii  python2.4   2.4.4-3  An interactive high- 
level object-o


bzr-svn recommends no packages.



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

debian-bugs-dist@lists.debian.org

[James Y Knight]

On Apr 20, 2005, at 5:14 AM, [EMAIL PROTECTED] wrote:
Maybe this bug can be closed. %% is as efficient a shortcut as was % .
It looks like the issue was a communication problem . One side 
believing there
 where no way to call the current job and the other filing at explaing 
how it was still
available (by keeping most of the topic on the rationale behind the 
old syntax removal).
I disagree that it's okay: removing those shortcuts was pointless, 
changing it back would likely be trivial, and it basically only leads 
to irritate people. However, it is possible to workaround without 
patching bash: "alias %=fg" seems to fix it perfectly, for the fg case. 
It doesn't make %& work, but I never used that one..

James

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