I am happy to remove the icons etc per your request.
However let me ask you two question.
First, I'm not a KDE person. Could I get you to identify with
specificity all directories or files currently in libdjvulibre15 which
should be removed? This would ensure that I don't miss any.
Second, I s
Package: ipv6calc
Version: 0.46-2
There is some CVS debris doesn't belong.
$ dpkg --listfiles ipv6calc | egrep CVS
/usr/share/doc/ipv6calc/examples/CVS
/usr/share/doc/ipv6calc/examples/CVS/Entries
/usr/share/doc/ipv6calc/examples/CVS/Repository
/usr/share/doc/ipv6calc/examples/CVS/Root
/usr/shar
Package: hddtemp
Version: 0.3-beta13-9
Severity: wishlist
It would help unclutter and shorten log files if hddtemp would skip
generating its syslog() entries when the temperature is unchanged
since the most recent logged temperature. For even more convenience
some hysteresis could be added, so en
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yes; I think it would be okay to remove oaklisp at this point.
(If I ever get around to making the upstream changes it needs to bring
it into the 2000s I'll just upload the result as a new package.)
--Barak.
==
Yes, it probably has to do with that.
Will look into a transitional package. But although it might solve
the multiple libdjvulibre1 vs multiple libdjvulibre15 problem, it
probably won't solve this libqt* issue.
--Barak.
--
To UNSUBSCRIBE, email to [EMAI
Sure, but there is an automated system that does the
unstable-to-testing migration. Don't know why it failed here.
--Barak.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
This isn't djview's fault, is it?
I'll wait, and close this bug once libqt3-mt migrates into testing.
--
Barak A. Pearlmutter <[EMAIL PROTECTED]>
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www-bcl.cs.nuim.ie/~barak/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTE
Hi, I'm a Motorola V220 user and a Debian developer. Was considering
packaging moto4lin myself, and noticed your ITP. Please let me know
if you are still planning to package moto4lin, or if there are any
difficulties I might be able to help with.
--Barak.
You should simply upgrade djview instead of allowing apt-get to remove it.
The evince package is outside my control, but should be recompiled
against this new version library in due course.
Will see about making the next version of the shared library package
coexist with the older .so version.
--
In reaction to the issue you raised, the man page cjb2(1) has been
changed in CVS by the upstream developers to reflect the fact that
there is a possibility of unacceptable character substitutions at a
losslevel above 100, but not at 100.
I am including the diff below, and would appreciate any sug
According to upstream there is a qualitative change in coding strategy
when -lossiness is increased above 100, rather than just a
quantitative one. So I don't think the problem you're worrying about
will actually occur. But you might want to consider using a lower
level of compression, like -loss
So you're saying that this is a theoretical bug, in that if the
document were scanned at an even higher resolution it is possible that
this problem would occur even at the default losslevel of 100?
The documentation has already been updated (in CVS) to discuss this.
But basically it seems like an
It would appear that if you use a losslevel of 100 (the recommended
value, and the value used by -lossy) the problem disappears. The
resulting file size increase is under 3%.
Unless you object (perhaps by suggesting a patch to the place in the
documentation that led you to use 200 there) I would
I've verified the problem, and will forward the issue to the upstream
developers.
--
Barak A. Pearlmutter <[EMAIL PROTECTED]>
Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland
http://www-bcl.cs.nuim.ie/~barak/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe".
Um, that patches the script "configure" without a corresponding patch
to "configure.ac". But the first is built periodically from the
second. I'd rather have a more permanent solution to the problem...
--Barak.
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
PS But on second thought, please go ahead and NMU with that patch. It
should clear the issue for now, and shouldn't do any harm. Later I'll
fix it "right" and upload that. And your NMU will allow me to take my
time finding the "right" fix. Which I suppose involves writing an
autoconf script to
The upload is no problem, I have things fixed already in CVS, and they
are mostly trivial anyway. In fact the X library stuff fixed itself.
The only thing hold me up is the m68k issue. I have not taken the
time to dive in the build system far enough to figure out how to
either change -O3 to -O2 o
Yes, all true.
I will upload a rev which generates libdjvulibre15. When that comes
down the pike, please recompile evince against it.
--Barak.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECT
Problem is what does "fix djvulibre" mean here?
Fix it to generate the old soname, thus losing soname compatibility
with upstream?
Fix it to generate a different library name, perhaps libdjvulibre15?
Fix it by asking upstream to stop changing the soname for no reason?
Fix it by convincing anyon
Sebastien,
Could I trouble you to recompile and dupload evince against
libdjvulibre1 (>= 3.5.14-6) to deal with soname change? Evince is the
only package that uses the lib, so that will clear the issue.
I'm not sure if the API has changed in a fashion that justifies a
chance in soname. Upstream
Regarding this:
> c) changing default to --rsyncable is not an option (IMHO) because
> it would generate different archives than a stock, self-compiled and
> other-distro's gzip, which is obviously not a good idea.
Does that really matter? I'd think generating something that is
gunzipable by sto
I think the latest upload, version 3.5.14-6, addresses this issue.
But because the report contained insufficient information to
replicate, I cannot be sure.
I attempted to directly contact the filer, at
Cristiano De Michele <[EMAIL PROTECTED]>
but this address is no longer valid.
If anyone el
Just to confirm: this is a GCC 4.0 issue, which I have replicated.
I will mention it to upstream; I'm sure they will want to be GCC 4.0 clean.
--
Barak A. Pearlmutter <[EMAIL PROTECTED]>
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www-bcl.cs.nuim.ie/~barak/
--
Thanks. Fixed in sources, will close when next version uploads.
--
Barak A. Pearlmutter
Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland
http://www-bcl.cs.nuim.ie/~barak/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
thanks. fixed in sources, will close when next version uploads.
--
Barak A. Pearlmutter
Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland
http://www-bcl.cs.nuim.ie/~barak/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I'd also appreciate having IPv6 support in MTR. If upstream is not
responsive in integrating this IPv6 patch, I'd urge you (the Debian
maintainer) to integrate it into the Debian version anyway. Debian in
general has excellent IPv6 support, and there's no reason for MTR to
lag behind.
--
Barak A.
As far as I can tell, the issue here has to do with MS Windows and not
Debian. With that in mind, I am inclined to close this bug.
If there are any objections please raise them now.
Even with the bug closed, I will certainly welcome any patches that
would address the documentation deficiency tha
I'm in the process of adding the patch above to the man pages.
When this uploads, it will close this bug report.
If you want to keep the "feature request" part of this alive, please
refile it separately. You might be better off filing it upstream
though; it is much more likely to get attention th
This seems to not be a problem with mozilla, which is really the
plugin target. I think it would make sense to transfer this issue to
galeon, and if they find that there is a fault in the djvu plugin
then it can be reassigned back and forwarded upstream. But given that
other browsers do not exhib
Could I get you to file this upstream, as a feature request at
djview.souceforge.org ? I have not used the bookmark-enabled russian
version you mention, so I wouldn't be in a position to tell them about
it ...
--Barak.
--
To UNSUBSCRIBE, email to [EMAIL
> As for the modified i2o-dev.h, yeah I've confirmed that it will work
> using dpatch and a patch that puts the modified linux/i2o-dev.h in the
> include directory in the source. So I have a working package.
Could you send me the patch please, so I can avoid reinventing the
wheel? Thanks,
31 matches
Mail list logo
