Package: libtool
Version: 2.4.6-2
Severity: normal
Dear Maintainer,
After upgrading to stretch from jessie I see new warnings when
building Subversion from source. These take the form
ar: `u' modifier ignored since `D' is the default (see `U')
when linking static libraries.
A reduced test c
"Laszlo Boszormenyi (GCS)" writes:
>> The current stable is
>> 3.7.3-1 and doesn't have this bug. The current testing is 3.7.13-1 and
>> it does have the bug. The next stable would be better with a patched
>> 3.7.13 or 3.7.16.
> I can ask Release Managers. Freeze is in effect for a while and s
> sqlite3_3.7.16-1_amd64.deb
> 25b67faae81f48afe0d08645a86f1462 1107998 debug extra
> libsqlite3-0-dbg_3.7.16-1_amd64.deb
> b08943eabee0befbfbb1f37880e9a905 467418 libs standard
> libsqlite3-0_3.7.16-1_amd64.deb
> 9335c9f90422c7c1a0152b9cfa02af8b 595222 libdevel optional
> libsql
Package: libsqlite3-0
Version: 3.7.13-1
Severity: normal
Tags: upstream patch
Dear Maintainer,
SQLite added a feature (in 3.7.11 I think) to ensure that journal/wal
files have the same permissions as the database file:
http://www.sqlite.org/src/info/84b324606a
The implementation sets umask to 0
8194)
+++ ../../rapidsvn-trunk/AUTHORS(revision 8195)
@@ -76,4 +76,4 @@
csola48 - translation
Alexey Reztsov- translation
Viet NQ - source code
-
+ Philip Martin - source code
Index: ../../rapidsvn-trunk/src/svncpp/context.cpp
Package: mdetect
Version: 0.5.2.1
Severity: normal
Tags: patch
I have a serial mouse connected to /dev/ttyS0. Running mdetect -vvv
causes a SEGV. The following patch fixes the problem
--- mice.c.orig 2005-10-28 14:02:36.0 +0100
+++ mice.c 2009-09-01 11:34:27.0 +0100
@@ -26,
"brian m. carlson" writes:
> I'm aware of that. My opinion remains the same: GCC should generate
> POSIX-conformant code without warnings with -O2 -Wall. That can be
> achieved by disabling -fstrict-aliasing at -O2, by patching glibc to
> allow aliasing of the relevant types, by special-casing
"brian m. carlson" writes:
> I expect that when used on a POSIX system (at least in strict POSIX mode
> or when invoked as "c99"), gcc-4.4 neither warns nor generates code
> contrary to POSIX with -O2 -Wall.
You can add -fno-strict-aliasing which will disable the optimisation
and thus prevent th
"brian m. carlson" writes:
> This is a standard and idiomatic usage of Berkeley sockets. AFAIK,
> there is no other way to work with the sockets interface, and even if
> there were, this method is extremely common, not to mention sanctioned
> by POSIX.
It may be idiomatic but it's not strictly
Kurt Roeckx writes:
> I assume you did something like "aptitude install libtool/experimental",
> and expected libtool-doc to also be upgraded?
aptitude install -t experimental libtool
which I think is the same thing.
> libtool-doc is only a Suggests. Maybe a Recommends would have
> different
Kurt Roeckx writes:
> I'm guessing you're saying that libtool-doc should still conflict
> with libtool1.4-doc? I don't agree. libtool1.4-doc is only
> part of oldstable. You should not be using it anymore in stable.
No. I had libtool and libtool-doc 1.5 installed when I upgraded
libtool to 2
Package: libtool
Version: 2.2.6a-1
Severity: normal
The 1.5 series libtool packages conflict with the 1.4 series doc
packages. The 2.2 libtool (in experimental) should conflict with both
the 1.4 and 1.5 series doc packages but only the 1.4 conflict is
present. This means that an upgrade from
not too long, section 6.7.8/15 of the ISO C
standard states:
"Successive characters of the character literal (including the
terminating null character if there is room or if the array is of
unknown size) initialize the elements of the array"
So string3 is correctly initiali
Philip Martin <[EMAIL PROTECTED]> writes:
> Port some of the atomic code from 1.2.x to 0.9.x, in particular make
> mutex operations that fail cause an abort and make the generic C
> implementation of apr_atomic_cas work on 64 bit platforms.
A less radical change to the code is sim
+if (prev == cmp) {
+ *mem = with;
}
-return *(void **)mem;
+CHECK(apr_thread_mutex_unlock(lock));
#else
prev = *(void **)mem;
if (prev == cmp) {
*mem = with;
}
-return prev;
#endif /* APR_HAS_THREADS */
+return prev;
}
#endif /*!defined(apr_atomic_c
k));
prev = *mem;
if (prev == cmp) {
*mem = with;
}
CHECK(apr_thread_mutex_unlock(lock));
#else
prev = *mem;
if (prev == cmp) {
*mem = with;
}
#endif /* APR_HAS_THREADS */
return prev;
}
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
to find it because there are only 15 slots and all but one should
be zero, e.g.
(gdb) p bdb_cache[0].array[1]
$9 = (apr_hash_entry_t *) 0x0
(gdb) p bdb_cache[0].array[3]
$10 = (apr_hash_entry_t *) 0x8072d30
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ng without optimisation on ia64?
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
If so then it's
upstream issue 2551 and the fix will be in 1.3.2.
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Philip Martin]
>> Is there a Subversion packaging problem ahead? If libsvn0 starts to
>> use libapr1 this will change the ABI of libsvn0 and any package built
>> against the existing libsvn0 ABI may not work correc
the problem for non-Debian binaries. I suspect the libsvn0 name
will have to change, much like a C++ ABI transition.
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Philip Martin]
>> Install the db4.2-util package and replace
>>
>>svnadmin recover path/to/repo
>>
>> with
>>
>>db4.2_recover -h path/to/repo/db
>
> That's what I've bee
Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Philip Martin]
>> The Subversion FAQ has an item that was written when Brane's Windows
>> build was upgraded from 4.2 to 4.3.
>>
>> http://subversion.tigris.org/faq.html#bdb43-upgrade
>
> Yes, well, that
was written when Brane's Windows
build was upgraded from 4.2 to 4.3.
http://subversion.tigris.org/faq.html#bdb43-upgrade
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
t include an rpath to the install directory, the
directory path gets stored in the .la file, so when libtool links
another library or application the path is available.
> PS: This might actually be the wrong bug in which we're
> discussing this.
Or perhaps the bugs should be merged?
--
oes straight through
to the linker, and it appears that the command line option overrides
RPATH in the library. Is it a linker bug for the command line option
to have priority? I don't know.
Perhaps libtool should not be passing that --rpath during the link?
Perhaps libtool should be passi
org/cgi-bin/bugreport.cgi?bug=291641
Subversion 1.2 has a Build-Conflicts with Subversion 1.1 to avoid
this problem.
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Devin Carraway <[EMAIL PROTECTED]> writes:
> One other note -- I tried manually removing the deleted file's tag from the
> .svn/entries XML file in the client copy, and the crash went away. Here was
This problem is fixed upstream on the 1.2.x branch, see r15579.
--
Phili
directory had not been updated. Any
such items get removed when the parent directory is updated.
The fix is r15516 in the Subversion repository.
--
Philip Martin
Package: xemacs21
Version: 21.4.17-1
Severity: normal
XEmacs/gnus is displaying encoded rfc2047 headers, which makes them
unreadable. A typical Subject line is
Subject: =?UTF-8?B?W0lzc3VlIDkwOF0gIFN0b3JlIHRleHQtYmFzZSBjb21wcmVzc2Vk?=
which should be decoded to
Subject: [Issue 908] Store t
from
::operator+ to ns::operator+ would be an ABI change.
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ke
namespace ns {
class A;
};
ns::A operator+(const ns::A& x, const ns::A& y);
class ns::A {
public:
A(int j) { i = j; };
private: int i;
friend A (::operator+)(const A& x, const A& y);
};
using namespace ns;
A operator+(const A& x, const A& y
Scott James Remnant <[EMAIL PROTECTED]> writes:
> On Sat, 2005-01-22 at 01:01 +0000, Philip Martin wrote:
>
>> I find the libtool inter-library documentation confusing, but I think this
>> is a Debian bug simply because Debian's libtool fails and GNU's libtool
c should
> honour the RPATH of that shared library.
I'm not a compiler expert, but does gcc ever see that information? I
think gcc, via collect2, invokes the ld linker to do the link and so
gcc never sees any of the NEEDED or RPATH data. The ld linker is part
of the binutils package,
Scott James Remnant <[EMAIL PROTECTED]> writes:
> On Sat, 2005-01-22 at 01:01 +0000, Philip Martin wrote:
>
>> A recent change to the Subversion source (revision 12801) introduced
>> new functions into the three dependent libraries, and made
>> libsvn_ra-1.so
Package: libtool
Version: 1.5.6-3
Severity: normal
*** Please type your report below this line ***
Sorry this is so long, a quick summary: Debian's libtool appears to resolve
inter-library dependencies to the install tree rather than the build tree,
this is different from the upstream GNU behaviou
recode string
That's probably caused by a filename that cannot be converted to
UTF-8. The Subversion repository uses UTF-8 internally and the client
converts between your current locale and UTF-8. It looks like one of
the files in the working copy has a name that is not valid byte
seq
37 matches
Mail list logo
