Package: xsane
Version: 0.999-11ubuntu1
Followup-For: Bug #1013933
Thanks for keeping XSane alive in Debian.
I am a long-time user myself, out of necessity: I have tried several times
to use simple-scan (the only alternative I can find), and it just doesn’t
offer the functionality of XSane. XSane
Upstream Enchant maintainer (and DM) here! I'm delighted to see the
transition is happening; if there are any problems with Enchant 2, I'm very
happy to help. I am not sure which Debian notifications I get about
Enchant, so if I seem to overlook something that could use my attention,
feel free to p
On Wed, 27 Mar 2024 at 20:25, Santiago Vila wrote:
>
> When I had already a bunch of them, I realized there is a macro
> STDC_HEADERS which is not properly detected.
Ah, I suspect the configure code is too old. Regenerating configure etc.
(autoreconf) might help.
-#if STDC_HEADERS
> +#if STDC_
On Mon, 15 Jul 2024 at 07:39, Sven Joachim wrote:
> Santiago, can you please investigate why the rpl_malloc symbol is gone?
Upstream maintainer here.
This symbol is an internal gnulib symbol (from gnulib's free.c), I don't
understand why anything else should be using it. It's certainly not
(in
Package: ppp
Version: 2.4.3-20050321+1
Followup-For: Bug #306261
The CPU problem seems to be associated for me
with getting a lot of errors like this:
May 3 17:51:42 localhost pppoa[2744]: Packet not from driver (mac:
00:60:4C:71:8C:D2)
Not sure what's causing it, but restarting the PPP conne
Package: ppp
Version: 2.4.3-20050321+1
Followup-For: Bug #306261
I'm having similar near-100% CPU consumption with ppp run by eagle-usb
utils. It's using pppoa, so I don't think the problem is specifically
with the rp-pppoe plugin (unless my CPU problem is different). In
fact, I'm not even sure th
Package: plptools
Followup-For: Bug #384146
I've added the patches from this (merged) bug to CVS for upcoming
plptools 0.16 (i.e. the FTBFS on amd64, and the FTBFS with gcc >=
4.1).
Thanks for the patches, and do contact me if I shouldn't just be
taking them as they are.
-- System Information:
De
Package: jirc
Version: 0.5-1
Severity: grave
Justification: renders package unusable
When I run jirc I get the following error:
$ jirc
Can't locate POE/Preprocessor.pm in @INC (@INC contains:
/home/rrt/local/share/perl5 /etc/perl /usr/local/lib/perl/5.8.8
/usr/local/share/perl/5.8.8 /usr/lib/pe
On Mon, 23 Jul 2007, Kees Cook wrote:
Hi! Thanks for reporting this.
It looks like this is actually a problem in libpoe-component-jabber-perl
(see bug #404125). I suspect I can work around it with some Perl
tricks, but in the meantime I will raise the priority of the other bug.
Thanks. Sorr
Package: pcregrep
Followup-For: Bug #436277
Reporter, did you install libpcre3 7.2 on your system? pcregrep
depends only on libpcre3 >= 6.0, but maybe it uses flags that are not
in libpcre3 until a later version, and hence the dependency needs to
be bumped.
If I install pcregrep 7.3-2 and libpcre
Package: libpcre3
Followup-For: Bug #436277
I see that the shlibdeps were bumped recently in response to #441435.
Does that also fix this bug?
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (700, 'testing'), (600, 'experimental'), (600, 'unstable')
Architectu
On Sat, 2 Jun 2007, Robert Millan wrote:
Package: zile
Version: 2.2.31-1
Severity: grave
If you edit the attached ca.po (obtained from totem svn) on an x86_64 system,
and try to search something (in my test, ""), zile will crash.
Could I have a gdb backtrace (and a valgrind trace if that
On Tue, 5 Jun 2007, Robert Millan wrote:
On Mon, Jun 04, 2007 at 10:54:52AM +0200, Reuben Thomas wrote:
Could I have a gdb backtrace (and a valgrind trace if that works on
x86_64)?
gdb backtrace:
#0 0x00411aa2 in search_forward (startp=0x55e9a0, starto=0,
s=0x55d7e1 "a"
On Fri, 8 Jun 2007, Robert Millan wrote:
On Fri, Jun 08, 2007 at 08:35:10PM +0200, Reuben Thomas wrote:
If you single-step in gdb from the call to search_forward you should be
able to see where bogosity sets in. (But don't worry about that too much; a
correct backtrace is the main thi
Package: mt-daapd
Version: 0.2.4+r1376-1.1+etch1
Followup-For: Bug #483337
I use mt-daapd, and I'm rather aghast to see it disappear from lenny.
I'd be happy to test any fix if that would help it get into lenny.
Please let me know.
-- System Information:
Debian Release: lenny/sid
APT prefers t
On Mon, 6 Apr 2009, Tim wrote:
This bug has been in zile a *long* time, but I have never managed to
either write a detailed enough bug report or get anyone to care.
My dear sir, I'm not sure whether I've ever had a bug report from you, but I
certainly *do* care, and have made several attempts
On Mon, 6 Apr 2009, Tim wrote:
Oh, please take no offense, as none was intended. I'm not even sure
what bug reports I might have submitted on the issue in the past, and
if I did, it probably didn't have enough detail. It's just one of
those bugs that only pops up right in the middle of somethi
Package: copher
Severity: grave
Justification: renders package unusable
Please update to 0.2.0, which actually works, unlike the currently
packaged version, owing to changes at SourceForge.
-- System Information:
Debian Release: 5.0.2
APT prefers stable
APT policy: (500, 'stable')
Architectur
Package: inform
Version: 6.30-2
Followup-For: Bug #289739
Since this bug's fix is small (and only applies to inform-docs, not
inform) and the reporter seems to be a DD, I was wondering whether he
could NMU it; otherwise inform will not be in etch, which seems a bit
silly for the sake of such a sim
In particular, I presume cooperation with upstream would expedite it? I
for one am keen to see vlc in etch. I've written a note to upstream
pointing out the problem a) in case they're not aware and b) to show
that there are users who care.
If there's a question of doing some digging through so
Package: plptools
Version: 0.15-1
Severity: serious
Justification: unknown
As the upstream maintainer it might seem bad form to report bugs to
Debian, but my C++ (minimal as it is) is not up to this:
rfsvfactory.cc:40: error: specialization of 'Enum::sdata::sdata() [with E =
rfsvfactory::errs]'
Rationale: this is a bug in all current versions of unison. It applies
to a specific use case, one in which one of the media is likely to
disappear during backup. By all means add a big fat warning until the
bug is fixed, but please don't prevent us getting the up-to-date
version of unison.
T
Package: psiconv
Version: 0.9.8-4.1
Severity: grave
Tags: patch
Justification: renders package unusable
Recent versions of GraphicsMagick require the InitializeMagick API to be called:
1.3.8 (January 21, 2010)
[…]
Behavior Changes:
* InitializeMagick() MUST be invoked
On 11 January 2011 13:55, Jakub Wilk wrote:
> retitle 609535 psiconv: magick/semaphore.c:526: LockSemaphoreInfo: Assertion
> `semaphore_info->signature == 0xabacadabUL' failed.
> tags 609535 - patch
> thanks
>
> Thanks for your bugreport! (I'm not maintainer of this package, but I'll
> comment any
On 11 January 2011 16:16, Jakub Wilk wrote:
> * Reuben Thomas , 2011-01-11, 15:15:
>>
>> GetMagickFileList is only called in the loop initializer, and the loop is
>> only run once.
>
> You are right, thanks for correction. Still, it's quite a surprising place
>
On 5 November 2011 12:08, peter green wrote:
> abiword's migration to testing is blocked by a dependency on psiconv
> psiconv's migration to testing is blocked by the following bug
> http://bugs.debian.org/609535 psiconv: magick/semaphore.c:526:
> LockSemaphoreInfo: Assertion `semaphore_info->sign
I was just wondering why you can't do the following in the short term:
1. Fix autoconf (all five versions in Debian) to default to using bash
and only fall back to sh if there is no bash and sh seems to be OK.
2. Regenerate the affected packages and rebuild, adding bash as a build-dep
?
--
htt
On 31 July 2010 20:50, Raphael Geissert wrote:
> On Saturday 31 July 2010 15:43:12 Reuben Thomas wrote:
>> I was just wondering why you can't do the following in the short term:
>>
>> 1. Fix autoconf (all five versions in Debian) to default to using bash
>> and onl
On 1 August 2010 19:40, Julien Cristau wrote:
> On Sat, Jul 31, 2010 at 20:43:12 +0100, Reuben Thomas wrote:
>
>> I was just wondering why you can't do the following in the short term:
>>
>> 1. Fix autoconf (all five versions in Debian) to default to using bash
&
On 18 January 2011 12:15, Jakub Wilk wrote:
> * Julien Cristau , 2011-01-18, 12:50:
>>>
>>> This doesn't look good. GetMagickFileList is called in a loop and
>>> InitializeMagick is supposed to be run only once.
>>>
>> That sounds like broken API for a library. How is a library using
>> graphicsm
On 25 January 2011 20:43, Adam D. Barratt wrote:
> user release.debian@packages.debian.org
> usertag 609535 + squeeze-will-remove
> thanks
Please see bug #611260: the major part of this is in fact a bug in
graphicsmagick, not in psiconv.
With my patch, and a fixed graphicsmagick, psiconv wor
On 31 January 2011 11:47, Julien Cristau wrote:
> On Mon, Jan 31, 2011 at 11:34:57 +0000, Reuben Thomas wrote:
>> 1. Remove psiconv just for squeeze.
>>
> We've done 1 for now, the rest is not up to the release team.
In that case, would you be kind enough to build a ba
On Mon, 11 Nov 2024 at 09:55, Andreas Tille wrote:
> Am Thu, Nov 07, 2024 at 08:17:44PM +0100 schrieb Andreas Tille:
> > Am Thu, Nov 07, 2024 at 08:34:47AM +0100 schrieb Petter Reinholdtsen:
> > > I suspect this fix to psnup caused the build problem in
> > > https://bugs.debian.org/1086290 >. Do
33 matches
Mail list logo
