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
Laszlo Boszormenyi (GCS) g...@debian.hu 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
b08943eabee0befbfbb1f37880e9a905 467418 libs standard
libsqlite3-0_3.7.16-1_amd64.deb
9335c9f90422c7c1a0152b9cfa02af8b 595222 libdevel optional
libsqlite3-dev_3.7.16-1_amd64.deb
2ed88790f788be0335c53644bc8a31ac 117150 interpreters optional
libsqlite3-tcl_3.7.16-1_amd64.deb
--
From: Philip Martin phi
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
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
@@
brian m. carlson sand...@crustytoothpaste.ath.cx 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
brian m. carlson sand...@crustytoothpaste.ath.cx 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
brian m. carlson sand...@crustytoothpaste.ath.cx 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
Kurt Roeckx k...@roeckx.be 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
Kurt Roeckx k...@roeckx.be 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
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
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 initialized with the two bytes '1' and '2' and
the terminating null is discarded.
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
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 simply to truncate
(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]
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]
= *(void **)mem;
if (prev == cmp) {
*mem = with;
}
-return prev;
#endif /* APR_HAS_THREADS */
+return prev;
}
#endif /*!defined(apr_atomic_cas) !defined(APR_OVERRIDE_ATOMIC_CAS) */
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
optimisation on ia64?
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 correctly with the new
libsvn0.
Way ahead
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]
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 procedure assumes you still have a /usr/bin/svnadmin
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 been leaning toward, but I am still trying to read
enough source and docs to be reasonably
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]
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?
--
Philip Martin
--
To UNSUBSCRIBE, email
that --rpath during the link?
Perhaps libtool should be passing the build dir instead? (That might
mean that libtool has to relink the executable at install time to get
the correct final rpath.) Does that make it a libtool bug?
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
/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.
--
Philip Martin
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
; };
private: int i;
friend A ns::operator+(const A x, const A y);
};
using namespace ns;
A ns::operator+(const A x, const A y) {
return A(x.i + y.i);
}
However if this is code within a library then switching from
::operator+ to ns::operator+ would be an ABI change.
--
Philip Martin
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) {
return A(x.i + y.i);
}
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Scott James Remnant [EMAIL PROTECTED] writes:
On Sat, 2005-01-22 at 01:01 +, 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
appears to work. Is there some reason
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, not gcc.
--
Philip Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
Scott James Remnant [EMAIL PROTECTED] writes:
On Sat, 2005-01-22 at 01:01 +, 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 reference those new functions.
Does only
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
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
sequence in your current locale.
--
Philip Martin
--
To UNSUBSCRIBE, email
37 matches
Mail list logo
