* Ian Jackson
| --divert
| In practice diversity in this option seems to cause more
| trouble than it's worse. Perhaps we should settle on
| `.diverted' or something ?
[...]
| Which leaves only the pathname :-).
While diverting libraries is something that should be done wi
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 497 (new: 27)
Total number of packages offered up for adoption: 109 (new: 2)
Total number of packages reques
Steve Langasek <[EMAIL PROTECTED]> writes:
> My understanding from reading this thread is that the signature of the
> function did *not* change, but that in previous versions of the library
> the macro definition in the header was simply broken, with the result
> that anything built using that def
On Thu, Jun 26, 2008 at 05:10:40PM -0700, Russ Allbery wrote:
> "Joe Smith" <[EMAIL PROTECTED]> writes:
> > If the change is a define in a header, where said define is *not* used
> > in the library itself, then the libraries binary will not change. Thus
> > physically it would have the same API an
"Joe Smith" <[EMAIL PROTECTED]> writes:
> If the change is a define in a header, where said define is *not* used
> in the library itself, then the libraries binary will not change. Thus
> physically it would have the same API and ABI.
If the new behavior of the header file is required for the new
Nikita Youshchenko <[EMAIL PROTECTED]> writes:
>> If the expr had a bug and old binaries didn't work with the old library
>> then I would say that requires and shlibs bump, possibly a versioned
>> conflicts against all rdepends and binNMUs.
> As far as I understand, as soon as source uses the aff
On Thu, Jun 26, 2008 at 11:31:44PM +0200, Norbert Preining wrote:
> On Do, 26 Jun 2008, Frans Pop wrote:
> > [1]http://lists.debian.org/debian-testing-security-announce/2008/06/msg00016.html
>
> And exactely that link is not present???
Actually, it is. Even if a typo were present, you could go t
On Do, 26 Jun 2008, Frans Pop wrote:
> [1]http://lists.debian.org/debian-testing-security-announce/2008/06/msg00016.html
And exactely that link is not present???
Best wishes
Norbert
---
Dr. Norbert Preining <[EMAIL PROT
Steve Langasek writes ("Re: RFC: Idea for improved diversions and alternatives
handling"):
> Declarative diversions are a much-needed enhancement to dpkg; there are
> cases one cannot deal with on upgrade without rm'ing one's own package files
> in the prerm in order to handle diversion changes, a
Christian Perrier writes ("Re: Non-related 'Recommends' dependencies - bug or
not?"):
> So, well, in such case, closing with "I think this is not a bug
> because synaptic is recommended by another package in the dependency
> chain" would have been better. Even better would have been to
> investiga
"Mathieu Malaterre" <[EMAIL PROTECTED]> wrote:
>
THANK YOU !
So far I only had FUDs about: 'no this is impossible, 'this is not the
right way'. Thanks for taking the time to answer in detail, this much
more supportive. I finally understood the previous aggressive answers,
I was simply looking at
"Bernhard R. Link" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
* Nikita Youshchenko <[EMAIL PROTECTED]> [080626 11:51]:
To fix #486693, I need to apply a patch that changes #define'd macro in
an
exported library header.
The pattern is:
extern int foo(char *param1, int param2
* Nikita Youshchenko <[EMAIL PROTECTED]> [080626 11:51]:
> To fix #486693, I need to apply a patch that changes #define'd macro in an
> exported library header.
>
> The pattern is:
>
> extern int foo(char *param1, int param2);
> #define bar(param) foo(param, expr(param))
>
> and changed thing is e
Package: wnpp
Severity: wishlist
Owner: Domenico Andreoli <[EMAIL PROTECTED]>
* Package name: libv4l
Version : 0.1
Upstream Author : Hans de Goede <[EMAIL PROTECTED]>
* URL : http://people.atrpms.net/~hdegoede/
* License : LGPL
Programming Lang: C
Descriptio
> If the expr had a bug and old binaries didn't work with the old
> library then I would say that requires and shlibs bump, possibly a
> versioned conflicts against all rdepends and binNMUs.
As far as I understand, as soon as source uses the affected macro, binary is
broken if compiled against un
* Nikita Youshchenko [Thu, 26 Jun 2008 13:22:19 +0400]:
> Hello.
> To fix #486693, I need to apply a patch that changes #define'd macro in an
> exported library header.
> The pattern is:
> extern int foo(char *param1, int param2);
> #define bar(param) foo(param, expr(param))
> and changed thi
* Neil Williams [Thu, 26 Jun 2008 12:33:33 +0100]:
> SONAME bump would seem appropriate
W. T. F. (Hint: no, it is not appropriate.)
[snipped completely irrelevant stuff to the case at hand]
--
Adeodato Simó dato at net.com.org.es
Debian Developer
Package: wnpp
Severity: wishlist
Owner: Vincent Bernat <[EMAIL PROTECTED]>
* Package name: openlldp
Version : cvs snapshot
Upstream Author : OpenLLDP team
* URL : http://openlldp.sourceforge.net/
* License : GPL
Programming Lang: C
Description : implemen
Nikita Youshchenko <[EMAIL PROTECTED]> writes:
> Hello.
>
> To fix #486693, I need to apply a patch that changes #define'd macro in an
> exported library header.
>
> The pattern is:
>
> extern int foo(char *param1, int param2);
> #define bar(param) foo(param, expr(param))
>
> and changed thing is
On Thu, 2008-06-26 at 12:33 +0100, Neil Williams wrote:
> > Any comments on how to handle this change in packaging properly?
>
> Maybe upstream could implement a "deprecated" support scheme that allows
> the old routine to be available, puts the new routine under a new name
> and moves the old ro
On Thu, 2008-06-26 at 13:22 +0400, Nikita Youshchenko wrote:
> Hello.
>
> To fix #486693, I need to apply a patch that changes #define'd macro in an
> exported library header.
>
> The pattern is:
>
> extern int foo(char *param1, int param2);
> #define bar(param) foo(param, expr(param))
>
> and
On Thu, Jun 26, 2008 at 10:52:43AM +0200, Per Olofsson wrote:
> Hi,
>
> Don Armstrong wrote:
> > I have no idea if it's trivially possible, but it would be ideal if
> > whatever spell checker we switched to had some sort of compatibility
> > layer for ispell to reduce the number of applications th
* Luca Bruno ([EMAIL PROTECTED]) [080626 09:57]:
> Rebuilt from incoming for i386, it seems to work here too:
good. thanks!
> I've also seen that -4 doesn't really force ipv4 resolution and connection:
great that you thought of testing that, too. It is entirely
possible that there are more cases
Hello.
To fix #486693, I need to apply a patch that changes #define'd macro in an
exported library header.
The pattern is:
extern int foo(char *param1, int param2);
#define bar(param) foo(param, expr(param))
and changed thing is expr(param)
Looks like binary interface of the shared library do
Hi,
Don Armstrong wrote:
> I have no idea if it's trivially possible, but it would be ideal if
> whatever spell checker we switched to had some sort of compatibility
> layer for ispell to reduce the number of applications that are
> affected by such a migration.
Both hunspell and aspell have such
Yves-Alexis Perez scrisse:
> On jeu, 2008-06-26 at 08:41 +0200, Yves-Alexis Perez wrote:
> > Here it seems to work fine even with curl 7.18.2-1:
>
> Hmhm well. Ok. With curl 7.8.12-1e1 and libcares:
> So it seems to work.
Rebuilt from incoming for i386, it seems to work here too:
[EMAIL PROTECT
On jeu, 2008-06-26 at 08:41 +0200, Yves-Alexis Perez wrote:
> Here it seems to work fine even with curl 7.18.2-1:
Hmhm well. Ok. With curl 7.8.12-1e1 and libcares:
[EMAIL PROTECTED]: curl -v -o /dev/null
http://public.teleport-iabg.de/test100m.dat
* About to connect() to public.teleport-iabg.de
* Yves-Alexis Perez ([EMAIL PROTECTED]) [080626 08:42]:
> On jeu, 2008-06-26 at 00:28 +0200, Andreas Schuldei wrote:
> > Hi!
> >
> > As a solution for "#481189 curl: cannot connect to IPv6 hosts
> > anymore" I added a patch to hook curl to c-ares even for ipv6
> > lookups. Upstream is very interes
28 matches
Mail list logo
