Bug#745720: polarssl: FTBFS on mips, powerpc, s390x and sparc
Hi,
I'm one of the upstream developers.
We believe we fixed this in our development branch for the next release, which
should be out in a few days. In case you want to test the fix right now, the
patch is attached.
We plan to add a big-endian machine to our buildbot installation in the next
future, in order to catch this kind of problem before the code is released.
Thanks for your report,
Manuel.
diff --git a/library/bignum.c b/library/bignum.c
index 012e9e3..af04883 100644
--- a/library/bignum.c
+++ b/library/bignum.c
@@ -1773,16 +1773,27 @@ cleanup:
return( ret );
}
+/*
+ * Fill X with size bytes of random.
+ *
+ * Use a temporary bytes representation to make sure the result is the same
+ * regardless of the platform endianness (usefull when f_rng is actually
+ * deterministic, eg for tests).
+ */
int mpi_fill_random( mpi *X, size_t size,
int (*f_rng)(void *, unsigned char *, size_t),
void *p_rng )
{
int ret;
+unsigned char *buf;
-MPI_CHK( mpi_grow( X, CHARS_TO_LIMBS( size ) ) );
-MPI_CHK( mpi_lset( X, 0 ) );
+if( ( buf = polarssl_malloc( size ) ) == NULL )
+return( POLARSSL_ERR_MPI_MALLOC_FAILED );
+
+MPI_CHK( f_rng( p_rng, buf, size ) );
+MPI_CHK( mpi_read_binary( X, buf, size ) );
-MPI_CHK( f_rng( p_rng, (unsigned char *) X-p, size ) );
+polarssl_free( buf );
cleanup:
return( ret );
Bug#683817: [texdoc] problem with texdoc and finding manuals on Debian
Hi Norbert, hi all,
On 05/08/2012 21:30, Norbert Preining wrote:
Here on Debian a strange thing happens, namely that texdoc does
not find the pgfmanual. But first some explanations:
Ok.
On Debian:
* most of TeX Live is installed into /usr/share/texlive/{texmf-dist,texmf}
(ie TEXLIVEROOT is /u/s/texlive)
* some packages that are packaged separately in Debian install into
another tree /usr/share/texmf which is called TEXMFDEBIAN and
added to the TEXMF var
TEXMF =
{$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,$TEXMFSYSCONFIG,!!$TEXMFSYSVAR,!!$TEXMFDEBIAN,!!$TEXMFMAIN,!!$TEXMFLOCAL,!!$TEXMFDIST}
* one example is pgf, which is packaged separately, and ships pgfmanual.pdf
as
/usr/share/texmf/doc/pgf/pgfmanual.pdf.gz
This appears to be unrelated: creating a file named foobar.pdf.gz in
TEXMFHOME/doc and invoking texdoc foobar fails too.
(note the compression!)
* texdoc is configured to search/use compressed docs, too
Here is the problem, in texdoc.cnf:
zipext_list = gz bz2 xz
should be:
zipext_list = gz, bz2, xz
Every _list configuration item is a coma-separated list. I'll change the
comments in texdoc.cnf to make that clearer.
The above change should fix the probem (at least it does for me). Please let me
now if any problem remains.
Manuel.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683817: [texdoc] problem with texdoc and finding manuals on Debian
Hi, On 06/08/2012 09:41, Norbert Preining wrote: Unfortunately, then we fall into the pain of the disappearing file, (tmp file disappears). I have set the viewer to (xdg-open %s) But this is what is recommended in the documentation. Do you have an idea about that, too? Which actual viewer is selected by xdg-open on your system? Is it blocking? From the comments in texdoc.cnf: # WARNING: for zip support your viewer needs to be blocking, i.e. it must not # return immediately: otherwise the temporary file will be deleted too early The actual command used (showed using the -v switch) is: (xdg-open /tmp/texdoc.xc1YEN/pgfmanual.pdf; rm -f /tmp/texdoc.xc1YEN/pgfmanual.pdf; rmdir /tmp/texdoc.xc1YEN) If you have a better idea, suggestions are most welcome. Otherwise, the only way is to make sure you use a blocking viewer (I usually use xpdf, evince seem to be fine too). Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683817: [texdoc] problem with texdoc and finding manuals on Debian
On 06/08/2012 10:02, Norbert Preining wrote: On Mo, 06 Aug 2012, Manuel Pégourié-Gonnard wrote: Which actual viewer is selected by xdg-open on your system? Is it blocking? From Uggg ... right ... xdg-open is NOT blocking... argg, I guess I have to go back to see otherwise it will not work. Yes, more precisely it is not *always* blocking, depending on the selected viewer (on my box, it selects evince and everything works fine). My humble opinion is te people who develop viewer should always make them blocking, since it is trivial to turn a blocking viewer into a non-blocking one using a wrapper script, but the converse is much harder. But of course an opinion doesn't help. That is unfortunately not an option on Debian, if someone is using KDE or any other environment. evince might not be installed, nor okular, etc. xdg-open tries to work around that that people can set their own plus system defaults etc etc, so that is the reason I switched to xdg-open some time ago. And since all of the texlive docs are not compressed, there is no problem. Yep. I will have to think about it, but don't see a good solution for now but trying to get an update to pgf and latex-beamer into the archive that ships uncompressed pdfs, and for latex-beamer also adds a link. I think that may be the best short-term solution. Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674185: [texdoc] texdoc and cweb manual
Hi Norbert, On 24/05/2012 00:48, Norbert Preining wrote: texdoc cannot find cweb manual: $ texdoc -l cweb 1 /home/norbert/tl/2012/texmf-dist/doc/latex/cweb-latex/cweb-user.pdf = User manual 2 /home/norbert/tl/2012/texmf-dist/doc/latex/cweb-latex/cweb-conf.pdf = Internal interfaces 3 /home/norbert/tl/2012/texmf-dist/doc/plain/cweb/cwebman.dvi Hum, really? ;-) But we would ike to get cwebman.dvi as an option (maybe first?), too. Is this possible? Of course it is. I just made it the first result. Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607351: texlive-binaries: texdoc aliasing sometimes doesn't work
Hi Frank,
Le 06/06/2011 21:08, Frank Küster a écrit :
tags 607351 fixed-upstream
thanks
Manuel Pégourié-Gonnard m...@elzevir.fr wrote:
I went ahead and implemented that in texdoc 0.81, just uploaded to TeX Live.
Now
texdoc finds its configuration files in $TEXMF/texdoc in the order
prescribed by
the regular precedence between texmf trees.
Which means the default configuration file should be installed in TEXMFDIST
if
TEXMFMAIN happens to have higher precedence than TEXMFLOCAL (as in the case
in
upstream TeX Live).
I hope it fixes the problem.
yes, I think so. I'm marking this as fixed upstream, however, we need
to make sure when TL 2011 is packaged that it actually works with our
configuration. Maybe we've already mis-patched the file locations.
It just so happens, I got two reports in two days about the config file not
being found in Debian testing and current Ubuntu. I wonder if it would be
possible for you to fix this in a 2009-XX version of texlive-base without
waiting for TL 2011 packages to be ready.
I can see three options:
1. Install a symlink from /usr/share/texmf/texdoc/texdoc.cnf (where texdoc 0.61
expects the file) to /etc/texmf/texdoc/texdoc.cnf (its actual location).
2. Update texdoc to 0.81. This would require to update LUAINPUTS as mentioned in
my recent message to debian-tex-maint (which would anyway be a good idea imo).
Other than that, I just tested it and it works like a charm.
3. Alternatively, attached is a patch you can apply (with -p2 in
/usr/share/texmf-texlive/scripts/texdoc) to backport the feature from 0.81 to a
new 0.61a version. I tested it and found no problem with it.
Thanks,
Manuel.
diff --git a/script/config.tlu b/script/config.tlu
index dac13ef..4d12db1 100644
--- a/script/config.tlu
+++ b/script/config.tlu
@@ -281,21 +281,30 @@ function confline_to_config(line, file, pos)
return false
end
-
--- return a table with config file and if they exist
+-- return the list of configuration files
function get_config_files ()
+-- get names
local platform = string.match (kpse.var_value ('SELFAUTOLOC'), '.*/(.*)$')
-local TEXMFHOME = kpse.var_value ('TEXMFHOME')
-local TEXMFLOCAL = kpse.var_value ('TEXMFLOCAL')
-local TEXMFMAIN = kpse.var_value ('TEXMFMAIN')
-return {
-TEXMFHOME .. '/texdoc/texdoc-'..platform..'.cnf',
-TEXMFHOME .. '/texdoc/texdoc.cnf',
-TEXMFHOME .. '/texdoc/texdoc-dist.cnf',
-TEXMFLOCAL .. '/texdoc/texdoc-'..platform..'.cnf',
-TEXMFLOCAL .. '/texdoc/texdoc.cnf',
-TEXMFMAIN .. '/texdoc/texdoc.cnf'
+local names = {
+'texdoc-'..platform..'.cnf',
+'texdoc.cnf',
+'texdoc-dist.cnf',
}
+-- get dirs
+local sep = (os.type == 'windows') and ';' or ':'
+local texmf_texdoc = kpse.expand_path('$TEXMF/texdoc')
+local dirs = texmf_texdoc:explode(sep)
+-- merge them
+local ret = {}
+for _, dir in ipairs(dirs) do
+for _, name in ipairs(names) do
+local pathname = dir .. '/' .. name
+if lfs.isfile(pathname) then
+table.insert(ret, pathname)
+end
+end
+end
+return ret
end
-- the config_files table is shared by the next two functions
@@ -304,31 +313,30 @@ local config_files = {}
-- set config/aliases from all config files
function setup_config_from_files ()
-for i, file in ipairs (get_config_files ()) do
-local found = lfs.isfile(file)
+local file_list = get_config_files()
+for i, file in ipairs (file_list) do
+local status = config.lastfile_switch and 'disabled' or 'active'
config_files[i] = {
path = file,
-status = found and (config.lastfile_switch
-and 'disabled' or 'active') or 'absent',
+status = status,
}
-if config_files[i].status == 'active' then
+if status == 'active' then
read_config_file (file)
end
end
end
-- now a special information function (see -f,--file option)
-function show_config_files (print_fun, prefix)
+function show_config_files (print_fun, verbose)
+local pref = verbose and '' or ''
print_fun(Configuration files are:)
for i, file in ipairs (config_files) do
-local home = prefix and
-((i==2) and (*) or ) -- home conffile is the 2nd
-or ''
-print_fun (home..file.status..'\t'..win32_hook(file.path))
+print_fun(pref..file.status..'\t'..win32_hook(file.path))
end
-if prefix then
-print((*) This is the recommended configuration file
-.. for your personal preferences.)
+if verbose then
+local texmfhome = kpse.var_value('TEXMFHOME')
+print_fun('Recommended file for personal settings:')
+print_fun(pref..texmfhome..'/texdoc/texdoc.cnf')
end
end
diff --git a/script/constants.tlu b/script/constants.tlu
index 2cbc995..649f4cf 100644
--- a/script
Bug#606171: reportbug crashing on non-ascii characters
Hi, Le 26/08/2011 20:13, Sandro Tosi a écrit : Are you still able to replicate this problem? Nope, the problem is gone. (Tested on the same machine, now running Debian stable.) Thanks, Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635382: [tex-live] latex-unicode source and licensing
Le 26/07/2011 12:36, Lionel Elie Mamane a écrit : (Please keep 635...@bugs.debian.org in the CC list when replying). In the texlive SVN, in the directory Master/texmf-dist/tex/latex/ucs, there are a bunch of files that start with: 1) I don't find ucs.dtx; do you have it or know where to find it? I don't, and indeed it sounds like a problem. 2) I don't find the LICENSE file to know what the some modifications are. Do you have it or know where to find it? Yep, it's in TL in texmf-dist/doc/latex/ucs, or on CTAN at: http://mirror.ctan.org/macros/latex/contrib/unicode/ The modifications do not add any restriction to the LPPL, at first glance, so they are not a problem at all. 3) More generally, http://www.unruh.de/DniQ/latex/unicode/ redirects to http://wolfgang.jeltsch.info/software/latex-unicode/, which is a 404. Do you have another upstream (maintainer) for latex-unicode? I presume he/she would have the above. I found that http://www.unruh.de/DniQ/ redirects to http://www.cs.ut.ee/~unruh/ which has contact information about Dominique Unruh, ucs.sty's author. The page looks fairly up-to-date so I assume the contact info is valid. Would you like to contact him about the missing ucs.dtx? If you do, please keep us informed. Thanks, Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635491: [tex-live] [BUG] ucshyper does
Hi,
We (the TeX Live team) do not maintain ucshyper.sty, we merely take what is on
CTAN and distribute it in (hopefully) usable form.
Your suggestion looks fine but should be addressed to the author (see the other
thread for possible contact info).
Thanks,
Manuel.
Le 26/07/2011 13:00, Lionel Elie Mamane a écrit :
Hi,
(Please keep 635...@bugs.debian.org in the CC list when replying).
ucshyper.sty tries (buggily) to disable itself when (la)tex is not run
in PDF output mode. But ucshyper works like a charm when producing a
DVI meant for post-processing with dvipdfm (and hyperref loaded with
hdvipdfm driver). I have only tested it with pdf(la)tex running in DVI
output mode, but I expect plain (la)tex would work just as well.
Patch attached. Assumes e-tex (uses \ifdefined). I assume this is OK.
I disabled the loading of hyperref, so that the user can choose hir
hyperref driver freely; instead a call to \hypersetup{unicode=true},
and hence a requirement that ucshyper be loaded *after* hyperref.
What would be your thoughts about upgrading the warnings (or maybe one
of them) to errors?
ucshyper.sty is in directory Master/texmf-dist/tex/latex/ucs
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607351: texlive-binaries: texdoc aliasing sometimes doesn't work
Le 06/06/2011 21:08, Frank Küster a écrit : tags 607351 fixed-upstream thanks Manuel Pégourié-Gonnard m...@elzevir.fr wrote: I hope it fixes the problem. yes, I think so. I'm marking this as fixed upstream, however, we need to make sure when TL 2011 is packaged that it actually works with our configuration. Maybe we've already mis-patched the file locations. Let me know if you'd like me to check this when you package TL2011. Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607351: texlive-binaries: texdoc aliasing sometimes doesn't work
Le 04/06/2011 01:59, Manuel Pégourié-Gonnard a écrit : Actually, I think I don't even need a new kpathsea search PATH, I can directly consult the value of $TEXMF and then just append texdoc/texdoc.cnf. This would be compatible with the current locations and would also find configuration files in TEXMFDIST or TEXMFSYSCONFIG for example, which, IIUC, would solve your problem. I went ahead and implemented that in texdoc 0.81, just uploaded to TeX Live. Now texdoc finds its configuration files in $TEXMF/texdoc in the order prescribed by the regular precedence between texmf trees. Which means the default configuration file should be installed in TEXMFDIST if TEXMFMAIN happens to have higher precedence than TEXMFLOCAL (as in the case in upstream TeX Live). I hope it fixes the problem. Thanks for your suggestion, Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607351: texlive-binaries: texdoc aliasing sometimes doesn't work
Hi Frank, Le 20/05/2011 15:19, Frank Küster a écrit : Manuel, why does texdoc look for texdoc.cnf in particular directories? Why doesn't it just do a kpathsea lookup for texdoc.cnf, thus looking in all TEXMF trees defined on the site for the user running texdoc? Besides the reason you mention, there are two more: - I like to be able to display a list of possible configuration files with texdoc -f to avoid lengthy explanations about where to put/search the config files. - currently there are special configuration files like texdoc-linux.cnf on linux, etc. However, I'm not sure if anyone is using them at all and it would probably be better to suppress them. So there is actually only one reason. Hm, one explanation might be that there doesn't seem to be a way to get kpathsea find texdoc.cnf at the places where it currently is. But that could be fixed. I think the problem might become more general, and maybe kpathsea should be changed to look for config files for script at a particular place. TEXMF/config or TEXMF/scripts/config comes to mind. In order to find the right file below that directory, a script would declare its name as the engine and the configuration files could be sorted as the scripts are now. Actually, I think I don't even need a new kpathsea search PATH, I can directly consult the value of $TEXMF and then just append texdoc/texdoc.cnf. This would be compatible with the current locations and would also find configuration files in TEXMFDIST or TEXMFSYSCONFIG for example, which, IIUC, would solve your problem. I'll probably be able to modify the -f option so that it is still helpful to a clueless (regarding texmf trees and kpsewhich) user. The only point is, in TeX Live the order of the trees is: TEXMFMAIN TEXMFLOCAL TEXMFDIST so TEXMFMAIN and TEXMFLOCAL would be reversed comparing to the current situation. Maybe I should ship the default configuration file in TEXMFDIST then. What do you think? In general, sounds like a good idea, but I need to think about it a bit more. Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611275: [manpages-dev] *_module.2 Co should not be removed
Package: manpages-dev Version: 3.27-1 Severity: normal --- Please enter the report below this line. --- Hi, According to README.Debian: Some pages present in the upstream version were removed because a better version exists in other package. These pages are: [...] manpages-dev: modules.2, get_kernel_syms.2, create_module.2, init_module.2, delete_module.2 According to changelog.Debian.gz, those better pages were provided by modutils. However, modutils was removed a while ago, since it is superseded by module-init-tools which do not provide those manpages. So, I suggest that the above manpages be reintroduced in manpages-dev. Thanks, Manuel. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.37+6+ Debian Release: 6.0 990 testing mirror.home-dn.net 980 testing security.debian.org 980 testing ftp2.fr.debian.org 910 testing dl.google.com 910 testing deb.opera.com 890 stable mirror.home-dn.net 880 stable security.debian.org 880 stable ftp.fr.debian.org 810 stable dl.google.com 690 unstablemirror.home-dn.net 680 unstableftp.fr.debian.org 580 experimentalftp.fr.debian.org 505 grml-testingdeb.grml.org --- Package information. --- Depends (Version) | Installed ===-+-=== manpages| 3.27-1 Package's Recommends field is empty. Suggests (Version) | Installed ==-+-=== man-browser| -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606171: reportbug crashing on non-ascii characters
Hi Sandro,
Le 02/01/2011 16:37, Sandro Tosi a écrit :
Well, I'm not exactly sure why this is happening (it should have not)
but could you try to apply the attached patch to /usr/bin/reportbug
and try to replicate the problem?
I tried with the patch applied, and unfortunately it doesn't prevent the crash.
The final error message now ends with:
File /usr/bin/reportbug, line 1733, in user_interface
conftext = conftext + u'%s %s\n' % (f, confinfo[f].encode('utf-8'))
AttributeError: 'exceptions.IOError' object has no attribute 'encode'
Which actually helped me understand the problem a bit better: the origin of the
offending 0xc3 byte is actually the error string Permission non accordée
(access denied message with LANG=fr_FR.utf8) that occurs since the user runing
reportbug doesn't have access to one of munin-node configuration files.
Attached is a patch that works for me. I don't know Python, so I hope it's
correct. The way the charset is guessed is copied from line 504 of
/usr/bin/reportbug.
hth,
Manuel.
PS: the patch is against a file from python-reportbug, so maybe the bug should
be moved to this package. Up to you.
--- utils.py.ori 2011-01-06 01:25:15.0 +0100
+++ utils.py 2011-01-06 01:29:07.0 +0100
@@ -42,6 +42,7 @@
import rfc822
import socket
import subprocess
+import locale
from string import ascii_letters, digits
@@ -646,7 +647,10 @@
try:
fp = file(filename)
except IOError, msg:
-confinfo[filename] = msg
+charset = locale.nl_langinfo(locale.CODESET)
+if charset.lower() == 'ansi_x3.4-1968':
+charset = 'us-ascii'
+confinfo[filename] = unicode(str(msg), encoding=charset)
continue
filemd5 = commands.getoutput('md5sum ' + commands.mkarg(filename)).split()[0]
Bug#606171: reportbug crashing on non-ascii characters
Le 06/01/2011 01:37, Manuel Pégourié-Gonnard a écrit : PS: the patch is against a file from python-reportbug, so maybe the bug should be moved to this package. Up to you. PPS: I realised just after sending my message that I didn't keep enough directory components in the file names when creating the patch, so it may not be obvious that the file in question is /usr/share/pyshared/reportbug/utils.py Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606171: reportbug crashing on non-ascii characters
Hi Sandro, Le 26/12/2010 22:40, Sandro Tosi a écrit : do you really have this char $ python -c print u'\xc3' Ã in a config file, or a path to a conffile? :) Not in a path :-) But, recursively grepping for non-ascii chars in /etc/munin, I found that /etc/munin/plugins/interrupts (or more precisely, the files this link points to) contains the following line: Idea and base from Ragnar Wisløff. The character ø is actually the two bytes 0xc3 0xb8 (the file seems to be encoded in UTF-8). No, the crash happens where the code is enlisting the config files (path + conffile name), so it should be one of the munin-node conffile: can you confirm? I think the above confirms. Please let me know if you need more information. Thanks, Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607351: texlive-binaries: texdoc aliasing sometimes doesn't work
Hi Frank, Le 17/12/2010 10:00, Frank Küster a écrit : Package: texlive-binaries Btw, I tried installing this on a squeeze box, and it doesn't seem to provide texdoc. I found it in texlive-base. $ grep amsthm /usr/share/texmf-texlive/texdoc/texdoc.cnf alias amsthm = amsthdoc $ texdoc -s amsthm 1 /usr/share/texmf-texlive/doc/generic/tex-virtual-academy-pl/latex2e/macro/amsthm.html Please enter the number of the file to view, anything else to skip: $ texdoc --version texdoc 0.61 $ texdoc -s amsthdoc 1 /usr/share/texmf-texlive/doc/latex/amscls/amsthdoc.pdf 2 /usr/share/texmf-texlive/doc/latex/amsthdoc-it/amsthdoc_it.pdf 3 /usr/share/texmf-texlive/doc/latex/amsthdoc-it/README So, although the alias is present, it is not used. Manuel, do you have an idea? This is the current Debian testing version. $ texdoc -f texdoc 0.61 Configuration files are: absent /home/mpg/texmf/texdoc/texdoc-bin.cnf (*) active /home/mpg/texmf/texdoc/texdoc.cnf absent /home/mpg/texmf/texdoc/texdoc-dist.cnf absent /usr/local/share/texmf/texdoc/texdoc-bin.cnf absent /usr/local/share/texmf/texdoc/texdoc.cnf absent /usr/share/texmf/texdoc/texdoc.cnf (*) This is the recommended configuration file for your personal preferences. Texdoc doesn't look for the configuration file where it actually is (or conversly, the config file isn't were texdoc expects it). So, the two obvious (and mutually exclusive) solutions are: 1. symlink texdoc.cnf under TEXMFMAIN rather than TEXMFDIST 2. 'patch' config.tlu with sed -i s/TEXMFMAIN/TEXMFDIST/g (I just checked, it doesn't have any side effects). I guess 1 is the easiest, but I'm not sure how you handle TEXMFMAIN vs TEXMFDIST in Debian, so... Let me know if problems remain or if you have more questions. Thanks, Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606171: reportbug crashing on non-ascii characters
Package: reportbug Version: 4.12.6 Hi, I was trying to report a bug against munin-node, when: m...@thue:~% reportbug -q --template -T none -s none -S normal -b --list-cc none -q munin-node *** Welcome to reportbug. Use ? for help at prompts. *** Detected character set: UTF-8 Please change your locale if this is incorrect. Using 'Manuel Pegourie-Gonnard m...@elzevir.fr' as your from address. Getting status for munin-node... Verifying package integrity... Will send report to Debian (per lsb_release). Maintainer for munin-node is 'Munin Debian Maintainers munin-deb-ma...@linpro.no'. Looking up dependencies of munin-node... Getting changed configuration files... Traceback (most recent call last): File /usr/bin/reportbug, line 2098, in module main() File /usr/bin/reportbug, line 1045, in main return iface.user_interface() File /usr/bin/reportbug, line 1733, in user_interface conftext = conftext + u'%s %s\n' % (f, confinfo[f]) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 32: ordinal not in range(128) I'm using testing (squeeze), kernel 2.6.32-5-686, python 2.6.6-3+squeeze1 and python-reportbug 4.12.6. My default locale is fr_FR.utf8. I first thought the problem was due to non-ascii character in my user name, so I tried to remove the accented characters from my name in ~/.reportbugrc, but to no avail. Thanks in advance, Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571679: [tex-live] moving ucs back to -recommended
Hi,
Norbert Preining a écrit :
From a Debian bug report:
- Forwarded message from Decklin Foster deck...@red-bean.com -
Somewhere between Lenny and now, ucs.sty was moved from -recommended
to -extra. As UTF-8 support is (I believe) a release goal, I would
- End forwarded message -
I somehow agree that making inputting utf8 with -recommended would be
a nice thing. I don't want to dig through the dependencies now, but
are there any specific reasons why we moved ucs package to latexextra?
Well, ucs isn't required for utf8 input, \usepackage[utf8]{inputenc} is enough.
Maybe ucs has a better coverage, I'm not sure, but I don't see a problem with it
being in -extra, since there is already something for utf8 input in
-recommended.
Manuel.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564089: [tex-live] \...@colonspace is no longer defined in frenchb v2.3d (v2.4a is OK)
Hi,
Norbert Preining a écrit :
- Forwarded message from Vincent Lefevre vinc...@vinc17.net -
I've used
\makeatletter
\renewcommand{\...@colonspace}{\fdp@thinspace}
\makeatother
I beg your pardon, but why the hell are your trying to fiddle with frenchb's
internals rather than using the provided interface?
The most correct way to achieve this effect with frenchb 2.x is
\frenchbsetup{ThinColonSpace=true}
Previously, the official interface (which still works with 2.x) was:
\renewcommand\Fcolonspace{\thinspace}
(note you don't need \makeatletter). This interface was introduced in frenchb
1.5f. I can't find the release date, but I checked that the version in TL 2005
was already 1.6g. So this interface has been stable for at least 5 years.
Now since that breaks completely backward compatibility, also in
our upstream TeX Live, any suggestion what we should do here?
Well, my opinion is that is does not break compatibility since users are
supposed to use the interface, not the @-macros. And the interface is stable and
not broken.
To tell the truth, there is however a problem with the fact that \...@colonspace
is undefined in the preamble in frenchb 2.3d (as a matter of fact, it is defined
\AtBeginDocument): it break with tex4ht. For example, the HTML French version of
the TeX Live guide doesn't compile with frenchb 2.3d. As discussed with Daniel,
this was arguably a bug with the way tex4ht is trying to guess the version of
frenchb, however he preferred fixing this on his side, since the maintenance
status of tex4ht was rather unclear at that time.
So, I don't know if it's worth an update, but I just wanted to get the facts
clear: there is no compatibility breakage for documents using the advertised
interface. The only breakage is for documents using tex4ht.
Manuel.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564089: [tex-live] \...@colonspace is no longer defined in frenchb v2.3d (v2.4a is OK)
Oops, I didn't see Daniel's reply before posting... and my message is
essentially a copy of his reply...
Manuel Pégourié-Gonnard a écrit :
Hi,
Norbert Preining a écrit :
- Forwarded message from Vincent Lefevre vinc...@vinc17.net -
I've used
\makeatletter
\renewcommand{\...@colonspace}{\fdp@thinspace}
\makeatother
I beg your pardon, but why the hell are your trying to fiddle with frenchb's
internals rather than using the provided interface?
The most correct way to achieve this effect with frenchb 2.x is
\frenchbsetup{ThinColonSpace=true}
Previously, the official interface (which still works with 2.x) was:
\renewcommand\Fcolonspace{\thinspace}
(note you don't need \makeatletter). This interface was introduced in frenchb
1.5f. I can't find the release date, but I checked that the version in TL 2005
was already 1.6g. So this interface has been stable for at least 5 years.
Now since that breaks completely backward compatibility, also in
our upstream TeX Live, any suggestion what we should do here?
Well, my opinion is that is does not break compatibility since users are
supposed to use the interface, not the @-macros. And the interface is stable
and
not broken.
To tell the truth, there is however a problem with the fact that
\...@colonspace
is undefined in the preamble in frenchb 2.3d (as a matter of fact, it is
defined
\AtBeginDocument): it break with tex4ht. For example, the HTML French version
of
the TeX Live guide doesn't compile with frenchb 2.3d. As discussed with
Daniel,
this was arguably a bug with the way tex4ht is trying to guess the version of
frenchb, however he preferred fixing this on his side, since the maintenance
status of tex4ht was rather unclear at that time.
So, I don't know if it's worth an update, but I just wanted to get the facts
clear: there is no compatibility breakage for documents using the advertised
interface. The only breakage is for documents using tex4ht.
Manuel.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557861: [texdoc] texdoc and support_zipped
On 08/01/2010 21:49, Frank Küster wrote: (and similar for TEXMFSYSCONFIG). But that implies that user-changed files there (even files that would be created by texconfig, but have not yet been) will be respected. And I know from discussions with Thomas that the tree was always intended as *the* place for personal or side-wide configuration changes, respectively. That's why the tree comes before anything else. So, maybe I should change the search path to add TEXMF(SYS)CONFIG indeed. Manuel, wouldn't it be easier to simply search texdoc.cnf (and texdoc-bin.cnf or whatever) with kpse.find_file? I haven't looked into the code recently, but generally I think if a file looks into texmf trees, it should use kpathsea in any case, wherever possible. I want to read all teh configuration files, and the kpse Lua library doesn't provide a way to find all results like kpsewhich's --all option. (I wanted to request it and even began preparing a patch at some point, then it went out of my mind.) Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557861: texdoc and support_zipped
On 05/01/2010 16:54, Norbert Preining wrote: Indeed it does, but you need to change the viewers. The automatically selected ones (gnome-open in my case) return immediately, thus the temp file will be removed and all gone. You're right. I forgot to mention that. It confirms my feeling that support_zipped should not be enabled by default. It asks for too much control over too many things. I would suggest to: - turn it into a normal option - document it in texdoc.cnf cleanly - mention that the automatically selected viewers will most probably not work (gnome-open immediately returns, and I assume the same for kde-open etc) - *but* leave it disabled under normal circumstances I'll probably do that. That does not change much (but the making the option a real one, which in fact is already prepared, becasue there are parts where you check for C.support_zipped!!), No, options are in the config table. C is for constants. (Identifiers in constants.tlu that look global are accessed (read-only) via the C table outside. This is a pretty standard Lua trick, but I should probably document the fact.) Norbert, please don't hesitate to ask me if you think something should be changed in texdoc (or its documentation). Well, there is no documentation of it, at least none that I grasped that it has to be directly in constants.tlu ;-) See my suggestion from above. Documenting undocumented facts counts as changing documentation :-) Yup, if not another RC bug had to be fixed we probably would already be there. BTW: The telxive packages currently in unstable already have the above changes ;-) Nice. -- One more thing: I was a bit puzzled that texdoc does not look into TEXMFSYSCONFIG or TEXMFCONFIG /texdoc/texdoc.cnf In upstream texlive that would be .../2009/texmf-config (TEXMFSYSCONFIG) ~/.texlive2009/texmf-config (TEXMFCONFIG) on Debian it would be /etc/texmf (TEXMFSYSCONFIG) ~/.texlive/texmf-config (TEXMFCONFIG) Hum, that's probably because I always forget they exist :-) Do you see any practical use case for configuration files here? I'm slightly reluctant to add yet another level of configuration files for texdoc... Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557861: [texdoc] texdoc and support_zipped
On 05/01/2010 18:08, Manuel Pégourié-Gonnard wrote: I'll probably do that. See texdoc 0.62, just commited to TeX Live. Now support_zipped is completely gone, the relevant option is actually zipext_list: by default it is empty. You just need to set it to whatever extensions you need, and define unzip_ext for every one of them. I added comments to texdoc.cnf, and a few warnings. Hope you like it this way! Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557861: [texdoc] Bug#557861: texdoc.tlu: Please enable compressed file support (support_zipped)
On 03/01/2010 08:59, Norbert Preining wrote: On So, 03 Jan 2010, Jean-Sébastien Trottier wrote: Like I said before, it worked perfectly by enabling support_zipped (false-true) in this script: /usr/share/texmf-texlive/scripts/texdoc/constants.tlu Hehe, yes, there it works. Yep, that's how it was intended, though I realise now it wasn't that clear. Indeed, I see the problem: support_zipped is not an option but a constant. To get it to easily fake it as an option you need to add it to known_options (gets you passed the warning) and also create a special case in set_config_element (to change the constant). The set_config_element part I didn't check. Please, if you think support_zipped should be turned into a regular option, tell me and I will do it (if your arguments seem good to me), rather than hacking the code on tour side :-) Now, is there a good reason to make it an option? Having it enabled all the time *should* not cause any issues with non-zipped documentation. I leave that to Manuel to answer. Hum, googd question. At some poiny, I wasn't sure if it was still used, so de-activating it by default was a good way to know if I should keep it. Now I'm sure at least two distros are using it. Then, as Norbert points out, upstream TL doesn't ship compressed doc, so it is sort of useless code here. OTOH, I shouldn't hurt to enable it here. The real problem is that it doesn't work on windows, and I don't really want to spend time making it work here, since AFAIK it is not used in this context. So I feel a little bit incomfortable about activating something that cannot work cross-platform (since texdoc obviously tries to be cross-platform). I'm open to comments. I think you should just set it to true in constants.tlu and remove it from texdoc.cnf. Currently, it has nothing to do in texdoc.cnf :-) Could be done, but then, upstream TeX Live doe snot distribute any gzipped documetnation, and also the TeX Live packages in Debian don't have zipped (gz) documentaiton (pdf is already compressed), but other packages have them ... Precisely. Thanks for the patch. Norbert, please don't hesitate to ask me if you think something should be changed in texdoc (or its documentation). Since I will wait for the texlive to testing transition before doing another upload it will have to wait some days (if nothing bad happens 6 days) Unrelated, but I'm glad to hear that TL09 should soon hit testing (hence be in the next stable). Fingers crossed. Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561785: [texdoc] Bug#561785: texlive-base: texdoc does not use standard pdf-viewer defined in KDE
Hi Frank, On Tue, 22 Dec 2009 23:19:53 +0100, Frank Küster fr...@debian.org wrote: Just my 2 cents: I suggest that we use see wherever possible. I don't care about KDE defaults, but see is the Debian way to say give me the viewer for this file type that is configured on this system. IIRC, 'see' is in the list of default viewers, but quite at the end. I'm not familiar with the current version of texdoc, so I cannot comment whether this is easy or not. Wasn't there a configuration file, which also defines viewer applications? Yes, there is a configuration file which can be used for this purpose. It is TEXMFMAIN/texdoc/texdoc.cnf (installed as /usr/share/texmf-texlive/texdoc/texdoc.cnf in Debian). The comments in the file should be clear enough about how to do this (I hope). I agree that using 'see' as the default viewer on Debian makes a lot of sense in theory, but as a user, I never configured it myself, so it most probably doesn't reflect my real preferences. Anyway... Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561785: [texdoc] Bug#561785: texlive-base: texdoc does not use standard pdf-viewer defined in KDE
On Mon, 21 Dec 2009 20:53:27 +0100, Johannes Fichtinger j...@fichtinger.org wrote: See [1]. There exists another variable called KDE_SESSION_VERSION, which from KDE4 on is set to 4, but was not defined for KDE3.x. This can be used further to distinguish between KDE4 and KDE3. It seems, for gnome exits GNOME_DESKTOP_SESSION_ID, which can be tested for exising, although I couldn't find any reliable source for that. [1] http://techbase.kde.org/KDE_System_Administration/Environment_Variables#KDE_FULL_SESSION Great. Thank you a lot for these interesting informations. I'll look further into it and keep you posted. Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561785: [texdoc] Bug#561785: texlive-base: texdoc does not use standard pdf-viewer defined in KDE
Hi Norbert, hi all, Norbert Preining a écrit : here is a bug report from Debian that suggests something regarding viewer selection. Can you please comment on it? Sure. When calling texdoc PACKAGENAME in KDE, the pdf description of the package is actually opened with GIMP, instead of using the KDE system-wide setting for the default pdf viewer, e.g. okular. It was already reported upstream, so I fixed it by putting gnome-open etc at the end of the list in a later texdoc version. This should make the viewer selection no worse than it was before I added those, but won't recognize kde/gnome/whatever properly. However, see below. Selecting the pdf-viewer based on the existence of eg. gnome-open in the path is incorrect since being in a KDE session still gnome-open might be found in the path. It would be better to base the selection instead on some environment variables. KDE provides eg. declare -x KDE_FULL_SESSION=true which can be used to detect if we are in a running KDE session. Gnome might provide similar variables. This is a good suggestion. I may try to enhance the viewer selection in future versions by looking at those variables also. Do you have a pointer to this in the KDE documentation? In the meanwhile, you can still select your prefered viewer in your local configuration file. For Manuel: This is the texdoc version as shipped on the DVD, not that fixes you put it after release. Ok. I can provide you with a patch against 0.47 so that gnome-open etc come at the end of the list, which is done in current versions of texdoc. Or you can update texdoc from current TL. Or whatever you suggest. Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561530: [tex-live] Bug#561530: texlive-latex-base: \noextrasfrancais macro does not work : frenchb.ldf problem
Norbert Preining a écrit :
when I process it with pdflatex from texlive-latex-base 2009-4
(debian sid), the resulting pdf shows a dash instead of the bullet
that the \noextrasfrancais macro is supposed to produce.
After some investigations, I realized that simply replacing
/usr/share/texmf-texlive/tex/generic/babel/frenchb.ldf with the one
from texlive-latex-base 2007.dfsg.2-4ubuntu1 solved the problem.
So it seems there's something wrong in the new frenchb.ldf file,
unless \noextrasfrancais is not supposed to work as it used to any
more ?
Since frenchb 2.x, the layout (lists, footnotes, etc.) is considered global
(that is, shared by all languages), see third paragraph of section 29.1 in
babel.pdf. Incompatibilities between frenchb 2.x and 1.x are known and
purposeful: the new defaults are supposed to be better, and moreover frenchb 2.x
is more configurable thna previous versions, allowing to restore LaTeX defaults
and/or emulate the behaviour of older version of frenchb.
Manuel.
PS: \addto\extrasfrench{\providecommand{\og}{%etc
I believe this is unnecessary since a long time. (At least frenchb in TL'05
already provides this commands.)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561530: [tex-live] Bug#561530: texlive-latex-base: \noextrasfrancais macro does not work : frenchb.ldf problem
Hi Denis,
Denis Prost a écrit :
Norbert Preining a écrit :
I think that is enough to close this bug.
Denis, do you agree?
I guess I should though I can't say I understood everything Manuel wrote
! I'm not very familiar with latex, using it trough lyx. Manuel, can you
please tell me what I should do to get bullets displayed as bullets and
not dashes in the converted PDF file ?
\frenchbsetup{StandardItemLabels=true} in the preamble if you want only to
prevent frenchb from changing the labels. \frenchbsetup{StandardLists=true} if
you want to prevent frenchb from changing anything to the lists layout. See
section 29.2 in babel.pdf for more options.
I guess this has something to do
with what you mentioned in your PS
(\addto\extrasfrench{\providecommand{\og}{%etc), but I did not know what
to do with it.
Actually, no. This is unrelated. Moreover, it should be harmless, though quite
probably useless.
This discussion may deserve to be continued on a LyX-specific channel (I don't
know LyX a lot, but maybe it could provide an interface to those babel/frenchb
features -- I'd be glad to help LyX maintainers about it if help is required).
Manuel.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548896: [tex-live] Bug#548896: Please rename the texlive binary package to texlive-medium/minimal/whatever
Danai SAE-HAN (韓達耐) a écrit : 2009/9/29 Frank Küster fr...@debian.org: texlive-medium doesn't sound very nice to me. Other suggestions? texlive-standard sounds good IMHO, as well as texlive-typical. As Karl already objected, the standard or typical installation, as far as the TL team is concerned, is a *full* installation. The problem with the current name texlive is precisely that people could think it is the standard, so texlive-standard would be even wors IMHO. I like the texlive-basic proposal by Ulrike, which is quite clear. Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527592: [tex-live] xfrac.sty depends on latex3
Lars Madsen a écrit : which confuses a lot of ubuntu users, so they end up installing everything anyway. It is nice that debian provides TL in so many pacakges, but IMO it just serves as a big confusion for the average user. In my experience, the most confusing fact for users of downstream-packaged version of TeX Live is that a package named texlive exists, which does *not* correspond to the default install scheme of upstream TeX Live (btw this is not specific to Debian, I think). IMHO, it would help a lot if either: - the texlive package installs all (ie, it's texlive-full) - there is no texlive package, but a series of packages like texlive-minimal, texlive-medium, ..., texlive-full. It would avoid a lot of bad surprises and/or misunderstanding for end users. Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527592: [tex-live] xfrac.sty depends on latex3
Norbert Preining a écrit : On Di, 29 Sep 2009, Morten Høgholm wrote: Just leave it as it is - the default for most TeX Live users is to install the whole shebang anyway... That does not help us on Debian where one collection maps to one debian binary package and we need decent dependencies. Is it possible for you in Debian to have Debian-specific dependencies in addition to those coming from upstream TL? That way you could solve the problem in Debian regardless of what is done in TL, since I understand correct depenencies are probably more important for Debian than for upstream TL. However, after a bit of thinking, I can't find any reason not to add the dependeny in TL. Anyway, more and more l2e packages are going to depend on l3 things (most notably expl3), so I don't see any problem with collection-latex3 being installed by most schemes in TL. Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507271: linux-image-2.6.26-1-686: experiencing the same problem: update-grub exits with value 1
Package: linux-image-2.6.26-1-686 Version: 2.6.26-11 Followup-For: Bug #507271 Hi, I'm having the same problem, but it occured while upgrading from Etch to Lenny. thue:~# LC_ALL=C dpkg --configure linux-image-2.6.26-1-686 Setting up linux-image-2.6.26-1-686 (2.6.26-11) ... Running depmod. Running mkinitramfs-kpkg. initrd.img(/boot/initrd.img-2.6.26-1-686 ) points to /boot/initrd.img-2.6.26-1-686 (/boot/initrd.img-2.6.26-1-686) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.26-1-686.postinst line 569. vmlinuz(/boot/vmlinuz-2.6.26-1-686 ) points to /boot/vmlinuz-2.6.26-1-686 (/boot/vmlinuz-2.6.26-1-686) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.26-1-686.postinst line 569. Running postinst hook script update-grub. Searching for GRUB installation directory ... found: /boot/grub User postinst hook script [update-grub] exited with value 1 dpkg: error processing linux-image-2.6.26-1-686 (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: linux-image-2.6.26-1-686 thue:~# By the way, running update-grub on its own does works. Best regards, Manuel. -- Package-specific info: -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-6-686 (SMP w/1 CPU core) Locale: LANG=fr_FR, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-1-686 depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92j tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.26-1-686 recommends: ii libc6-i6862.7-16 GNU C Library: Shared libraries [i Versions of packages linux-image-2.6.26-1-686 suggests: ii grub 0.97-47GRand Unified Bootloader (Legacy v pn linux-doc-2.6.26 none (no description available) -- debconf information: linux-image-2.6.26-1-686/preinst/abort-overwrite-2.6.26-1-686: shared/kernel-image/really-run-bootloader: true linux-image-2.6.26-1-686/postinst/bootloader-error-2.6.26-1-686: linux-image-2.6.26-1-686/postinst/depmod-error-initrd-2.6.26-1-686: false linux-image-2.6.26-1-686/prerm/removing-running-kernel-2.6.26-1-686: true linux-image-2.6.26-1-686/postinst/old-system-map-link-2.6.26-1-686: true linux-image-2.6.26-1-686/preinst/abort-install-2.6.26-1-686: linux-image-2.6.26-1-686/preinst/lilo-has-ramdisk: linux-image-2.6.26-1-686/preinst/bootloader-initrd-2.6.26-1-686: true linux-image-2.6.26-1-686/prerm/would-invalidate-boot-loader-2.6.26-1-686: true linux-image-2.6.26-1-686/preinst/elilo-initrd-2.6.26-1-686: true linux-image-2.6.26-1-686/postinst/kimage-is-a-directory: linux-image-2.6.26-1-686/postinst/old-dir-initrd-link-2.6.26-1-686: true linux-image-2.6.26-1-686/postinst/create-kimage-link-2.6.26-1-686: true linux-image-2.6.26-1-686/preinst/lilo-initrd-2.6.26-1-686: true linux-image-2.6.26-1-686/postinst/old-initrd-link-2.6.26-1-686: true linux-image-2.6.26-1-686/preinst/overwriting-modules-2.6.26-1-686: true linux-image-2.6.26-1-686/postinst/depmod-error-2.6.26-1-686: false linux-image-2.6.26-1-686/postinst/bootloader-test-error-2.6.26-1-686: linux-image-2.6.26-1-686/preinst/failed-to-move-modules-2.6.26-1-686: linux-image-2.6.26-1-686/preinst/initrd-2.6.26-1-686: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507271: linux-image-2.6.26-1-686: [solved] by installing grub2
Manuel Pégourié-Gonnard a écrit : I'm having the same problem, but it occured while upgrading from Etch to Lenny. Well, I just found out the problem magically disappears by install grub-pc. HTH, Manuel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499048: [slim] Should use x-terminal-emulator, not xterm
Mike Massonnet a écrit : Ok, for now I switched to x-terminal-emulator, and I recommend the package xterm. Hum, couldn't you instead recommend the virtual package x-terminal-emulator? It seems to me that this package is (or should be) provided by any x terminal emulator's package. Since APT installs recommends by default, recommending xterm would get it installed automatically even for users (like me) who already have another (prefered) terminal emulator (and I wouldn't like it). Manuel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481606: Questions about MiKTeX package manager for Debian
Frank Küster scripsit (16.07.2008 16:02) Of course it's an issue to have only DFSG-free software packaged in Debian. But how does that affect a package manager? Well, it would be really cool if the package manager was able to display the license of package I am about to download. But it doesn't affect its freeness which license data it downloads have. Mpm does not display the license of things you are about to install. But AFAIK, MikTeX claims that to the best of their knowledge, they only package free stuff. As you know well, to the best of their knowloedge is an important restriction there (I think the situation in MikTeX, upstream TeX Live and Debian is rather similar wrt to lack of comprehensive and reliable licence info). They also claim that for them, free means both FSF-free and DFSG-free (see http://miktex.org/Copying.aspx). But I agree with you that anyway the licence of the package manager itself and of the packages it downloads are different issues, it was just for information. By the way, how do you feel about such a LaTeX package manager for Debian? Do you think it might be useful? Or does TeXlive include a manager which does the same thing? I read somewhere that TeXlive is also (partly) based on MiKTeX. Answering backwards, last question first: No, I don't think TeXliv is based on MikTeX. It's based on teTeX, and teTeX and MikTeX may have some common roots - although I think that rather has MikTeX taken over some ideas from teTeX, and then developped much further. Indeed. Of course there are some common roots: Knuth, the CTAN :-) But things in MikTeX are quite different. Eg, MikTeX is not based on web2c/kpathsea, does have similar but different tools and architecture for updmap, fmtutil, etc. TeX Live is far closer to teTeX than MikTeX is. I do think that a package manager for updating individual packages and for installing add-on packages (new on CTAN, non-free, or not on CTAN at all) would be a nice thing to have. I think so, and I have used a home-compiled mpm for long. But it only install packages in MikTeX obviously, and I think most of them come from CTAN and all of them are free (in theory). As far as I know, TeXLive upstream maintainers already work on such a feature (maybe even with MikTeX-like automatic package installation), but I'm not sure about it's status. I'd be surprised if it would be already in the soon-to-be-released 2008 version. So... surprise! It is in the future TL'08! It's even the main new feature in this release (with net install) imo. It's quite mpm-like (for the package management part) and also has a Perl/Tk GUI frontend. It doens't provide an install-on-the-fly feature though. I asked Norbert in BachoTeX what he wanted to do with it in Debian and he said he thought tlmgr should be configured to install updates in TEXMFLOCAL, iirc. Anyway, you'll probably discuss this with him when he comes back from the mountains... I honestly have no idea how tlmgr and mpm can play well together, and whether mpm has interesting features that tlmgr doesn't. In particular, I don't think you should call the binary package miktex-tools. I'm not used to all of them, but it seems that what you mainly want to make available for Debian is mpm? I guess we do not want initexmf in Debian. I'm not sure initexmf isn't needed but other tools. By the way, maybe mthelp would be cool to have: it doesn't work exactly as texdoc, and if I personally prefer the texdoc way, other people may prefer mthelp or want to use both. Best, Manuel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482915: texlive-doc-en: No license info for some fontinst documentation
Hi, Frank Küster scripsit (02.07.2008 20:45) I thought that there is an automatic way of updating texmf trees from CTAN? Don't your scripts check whether anything has been uploaded to CTAN:/tex-archive/fonts/utilities/fontinst/doc? And if they to, how do you exclude the talks directory? And if they do not - there are some automatic updates, aren't there - why is this part not covered? Well, nothing is really automatic in the CTAN - TL process. There are scripts that make the process semi-automated, namely one checks for CTAN updates and then another one is manually called to convert the trees from ctan form to tds form. Perhaps the most interesting script for you is ctan2tds, which sometimes has messages like die skipping, nosell', thought is is not really intended to be readable. However some things are sometimes updated completely manually, for various reasons, such as last update was long before the current mechanism began, or it takes more time to write the relevant script that to do it manually, or whatever. Looks like the talks subdir of fontinst is in this case: if I would update fontinst now using the scripts, it would no be removed. (By the way, this is a problem, since it means info has been lost about why this directory was previously excluded.) Hope this answers your question: in general as well as this particular case, there's no way to be sure what is excluded from the ctan - tl process (or changed in this process) and why, but in many cases the ctan2tds is your best chance if you manage to read it. Manuel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487149: texlive-doc-en: Source missing for some documentation files
Frank Küster scripsit (24.06.2008 22:07) Ah, I didn't know that. More work for texdoc.tlu - while I hate being shown the Catalogue page if the package documenation has a generic name like manual.pdf, I think it *is* useful when there's nothing available. Same here. And the catalogue page is sometimes a good way to find the actual doc, using the (non-working) documentation link to find the right name. Anyway, Karl wants to remove the catalogue, for the two following reasons (unless I misunderstood him) : (a) it gets outdated very fast and makes a few Mb, which slows down the updates (b) we have a lot of information from the Catalogue in texlive.tlpdb. When I asked him about that, he suggested that when no documentation is found, texdoc prints a message with a link to the package's page on ctan (or the search page in case no package is found on ctan). That's what texdoc does now, but I don't know if Karl already arranged the redirection. Any comments or ideas welcome. Anyway, since we have the project to enable using texlive.tlpdb from texdoc, this problem should not last very long. (There will be other problems, like what do we do with packages from the catalogue with no corresponding TL package, for example when they are parts of bundles...) Manuel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484157: latex.pdf: messed-up PDF table of contents
Patrik Fimml scripsit (02.06.2008 20:52) In /usr/share/texmf-texlive/doc/latex/base/latex.pdf, the hyperrefs that appear in any PDF viewer's table of contents (evince, acroread - also called Bookmarks) are badly messed up. For example, the first entry under /Commands/Counters is labeled as [EMAIL PROTECTED]@ttfam @def [EMAIL PROTECTED] @backslashcurfont } addtocounter instead of just addtocounter. This makes the otherwise very convenient PDF TOC rather useless. This is already fixed in the up-upstream version, I mean the SVN version on http://home.gna.org/latexrefman/ not the version in upstream TeX Live. Will soon be fixed in TeX Live by updating our version, I just need to ask Karl a few things (eg why the document is duplicated as latex.pdf and latex2e.pdf) before doing it. Manuel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479097: [tex-live] Looking for Gilles Robert, author of the bbm fonts
Hi Frank, Frank Küster a écrit : Therefore I'd like to try to contact their author, Gilles Robert. For French mathematicians, a useful resource is generally http://annuaire.math.cnrs.fr/ At the moment, it points to Gilles.Robert'at'math.u-bordeaux.fr Since he has been using this address recently on fr.sci.math, I hope it's the good one. Otherwise, his other address Gilles(dot)Robert(at)ujf-grenoble(dot)fr may be valid too, since his accout in this university looks valid. HTH, Manuel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477152: [Fwd: Re: Licensing info in computational-complexity LaTeX class (Debian Bug#477152)]
Hi, Hilmar Preusse a écrit : Hmm, the file above won't be distributed by the TeX Live packages. However I think it is a good idea to fix that too. But we distribute it in the upstream TeX Live, so it's a problem anyway. Would you be so kind to contact the author? Sure. Cheers, Manuel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477152: Licensing info in computational-complexity LaTeX class
Hi Michael, and sorry for the late answer. Michael Nüsken a écrit : I just uploaded v2.09 to CTAN @ DANTE and expect it to be online within a few days. Please, let me know whether it's ok now. Hmm, I'm afraid there is still a few problems. The ins file states that: %% In particular, NO PERMISSION is granted to modify the contents of this %% file since it contains the legal notices that are placed in the files %% it generates. This implies two problems: 1. It contradicts the LPPL, whose point 10a explicitly allows to distribute a derived work under a different license, as long as it it respect the strong points of the LPPL. 2. Read literally, it means that you can't modify the file at all (even the \generate lines), which is obviously not what is intended anyway. I think the best is to get rid of that statement, since the files are generally distributed unmodified, and if they are, this becomes a derived work which can have its own licence. Another thing I failed to notice last time, is that the journals.bib file has no license statement at all. It should have one, or at least be listed as part of the work in cc.dtx. Regards, Manuel. PS: would you please be so kind as to keep [EMAIL PROTECTED] in the Cc list? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477152: [Fwd: Re: Licensing info in computational-complexity LaTeX class (Debian Bug#477152)]
De: Michael Nüsken [EMAIL PROTECTED] I'll change it as soon as possible. It was indeed updated on CTAN yesterday. License info in generated files now reads: Copyright 2000-\the\year Michael Nusken, Joachim von zur Gathen, computational complexity IMPORTANT NOTICE: This is a generated file. It is part of the computational complexity macro package derived from cc.dtx by 'tex cc.ins'. See cc.dtx for license information. while cc.dtx refers to LPPL v1.2 or latter at your option. One restrictive statement remains in cc.ins : %% In particular, NO PERMISSION is granted to modify the contents of this %% file since it contains the legal notices that are placed in the files %% it generates. but I don't really know wether this is a problem or not. The author asked me in private in I thought everything was ok; I didn't answer him yet. What do you think? Anyway, I updated it in TL svn today (rev 7666) so the bug can be tagged fixed-upstream if you think the new license statement is ok. Manuel. PS: I just noticed the journal.bib has no license statement at all :/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476954: texlive-extra-utils: epstopdf is missing gs
Frank Küster a écrit : [2] wasn't there an attempt to replace bibtex by bibtex8 generally, as MikTeX has done it AFAIK? Hum, not sure it would be a good idea: for me, bibtex8 crashes quite often. I should fill a report for this, but didn't have time atm. Manuel.
Bug#475746: listings: 'Assembler' and 'Basic' languages don't work
Hi,
Eugene V. Lyubimkin a écrit :
Frank Küster wrote:
You have to do it right, it seems you can't use languages with dialects
without specifiying one, even if there is only one:
I'm afraid this is a bit more complicated: you can use a language with
dialects without specifying one only if there is a default dialect for this
language (see table 1, p 12 of the doc). For example, there is a default
dialect for TeX, namely plain, so you can say :
\begin{lstlistings}[language=TeX]
But, somehow surprisingly, there is no predefined default dialect for Basic,
though there is only one dialect. Anyway, you can define a default dialect for
this language with
\lstset{defaultdialect=[Visual]Basic}
in your preamble for example.
I think this can be explained at section that tells about 'listings'
package, it would be logical.
Hum, in LaTeX, each package has a separate documentation. For listings, the
documentation is in
/usr/share/doc/texlive-latex-recommended-doc/latex/listings/listings.pdf
and can easily be found by typing 'texdoc listings' in a terminal.
By the way, I would expect section 2.4 of the documentation to mention the
fact that the optional argument for the dialect is actually mandatory for
languages without predefined default dialect...
Best,
Manuel.
Bug#470141: [todo.sty] bug and suggested fix
Hi,
On the Debian bug tracking system, it was reported that the \todo command from
your todo.sty package sometimes unexpectedly complains about a 'bad space
factor', when used in vertical mode. I checked this out, and I think the
problem arises when the [EMAIL PROTECTED] at the beginning of the \todo command
is
executed in vertical mode, but the [EMAIL PROTECTED] at the end is executed in
horizontal mode. This happens if and only if the default option 'superscript'
is used, and the \todo command is used in vertical mode.
I think the following is a way to fix this:
[EMAIL PROTECTED] %new
\DeclareOption{superscript}{%
[EMAIL PROTECTED]@todosupermark}%
[EMAIL PROTECTED] %new
\DeclareOption{marginpar}{%
[EMAIL PROTECTED]@todomarginpar}%
[EMAIL PROTECTED] %new
[EMAIL PROTECTED]@gobble
[EMAIL PROTECTED] %new
[EMAIL PROTECTED]@[EMAIL PROTECTED]
% the rest as in the current code (only the [EMAIL PROTECTED] added above)
This make the \leavevmode happen earlier than in [EMAIL PROTECTED] with the
super, and in any case either no happen at all, or before the
[EMAIL PROTECTED]/[EMAIL PROTECTED] couple. (I think hard-coding the
\leavevmode at the
beginning of \todo is not a good idea since it makes unwanted vertical space
when using \todo with the 'nothing' option in vertical mode, for example.)
Of course you can also think that \todo should not be used in vertical mode
with the 'superscript' option and not fix this, but maybe it would be a good
idea to mention this restriction in the documentation then.
Best,
Manuel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473049: Please make luatexref-t.pdf accessible
Package: luatex Version: 0.22.0.svn080220-1 Severity: normal --- Please enter the report below this line. --- Hi, The luatex reference manual, installed in /usr/share/doc/luatex/luatexref-t.pdf, is unfortunately not findable by texdoc. I fixed this for myself making a symlink to it in my HOMETEXMF/doc directory, but I think it would be better if the luatex package shipped with a link to luatexref-t.pdf under either /usr/share/texmf-texlive/doc or /usr/share/doc/texmf. Best, Manuel. --- System information. --- Architecture: i386 Kernel: Linux 2.6.22-3-486 Debian Release: lenny/sid 980 testing security.debian.org 980 testing ftp.fr.debian.org 970 testing mirror.home-dn.net 670 unstablemirror.home-dn.net 660 unstableftp.fr.debian.org 570 experimentalmirror.home-dn.net 560 experimentalftp.fr.debian.org 505 grml-testingdeb.grml.org --- Package information. --- Depends (Version) | Installed ==-+-== libc6 (= 2.7-1) | 2.7-6 libpng12-0 (= 1.2.13-4) | 1.2.15~beta5-3 libpoppler2 (= 0.6) | 0.6.4-1 texlive-base-bin | 2007.dfsg.1-2 zlib1g(= 1:1.1.4) | 1:1.2.3.3.dfsg-11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471205: Documentation missing for lastpage
Package: texlive-latex-extra Version: 2007.dfsg.1-1 Severity: normal --- Please enter the report below this line. --- Hi, the pdf documentation for package lastpage is missing. I don't know if it is also missing in the upstream texlive, but it is available on CTAN, at http://tug.ctan.org/tex-archive/macros/latex/contrib/lastpage/lastpage.pdf At the moment, only the README.lastpage file is included. Cheers, Manuel. --- System information. --- Architecture: i386 Kernel: Linux 2.6.22-3-486 Debian Release: lenny/sid 980 testing security.debian.org 980 testing ftp.fr.debian.org 970 testing mirror.home-dn.net 880 stable security.debian.org 880 stable ftp.fr.debian.org 870 stable mirror.home-dn.net 670 unstablemirror.home-dn.net 660 unstableftp.fr.debian.org 570 experimentalmirror.home-dn.net 560 experimentalftp.fr.debian.org 505 grml-testingdeb.grml.org --- Package information. --- Depends(Version) | Installed -+-= preview-latex-style | 11.83-7 texlive-common (= 2007) | 2007-13 texlive-pictures(= 2007-11) | 2007-13 texlive-latex-base (= 2007-11) | 2007-13 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435004: vim doesn't find .spl files...
Package: vim-spellfiles-fr Version: 20060604-1 Severity: normal --- Please enter the report below this line. --- Right after the installation of vim-spellfiles-fr, I ran vim, typed in :set spell spelllang=fr and got the message 'Cannot find word list fr.latin1.spl or fr.ascii.spl'. For the moment, I have it working with a symlink to /usr/share/vim/addons/spell in my ~/.vim directory, but I'm sure there's a better solution. Btw, I'm sing vim 7.1 : ii vim1:7.1-022+1Vi IMproved - enhanced vi editor ii vim-common 1:7.1-022+1Vi IMproved - Common files ii vim-doc1:7.1-022+1Vi IMproved - HTML documentation ii vim-runtime1:7.1-022+1Vi IMproved - Runtime files ii vim-scripts7.1.2 plugins for vim, adding bells and whistles ii vim-spellfiles 20060604-1 French spell files for Vim spell checking ii vimhelp-fr 6.3.013-2 Vi IMproved - Documentation files (French tr Cheers, Manuel. --- System information. --- Architecture: i386 Kernel: Linux 2.6.21-2-486 Debian Release: lenny/sid 980 testing security.debian.org 970 testing mi.mirror.garr.it 960 testing ftp.fr.debian.org 910 testing deb.opera.com 880 stable security.debian.org 870 stable mi.mirror.garr.it 860 stable ftp.fr.debian.org 810 stable deb.opera.com 670 unstablemi.mirror.garr.it 660 unstableftp.fr.debian.org 610 unstabledeb.opera.com 560 experimentalmir1.ovh.net --- Package information. --- Depends (Version) | Installed ===-+-=== | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427161: Should recommend iceweasel too
Package: djvulibre-plugin Version: 3.5.19-2 Severity: minor --- Please enter the report below this line. --- Djvulibre-plugin recommends major popular browsers, but not iceweasel. It's a bit annoying since on every update, aptitude suggests me to install a browser, though I allready have iceweasel installed. --- System information. --- Architecture: i386 Kernel: Linux 2.6.18-4-486 Debian Release: lenny/sid 980 testing security.debian.org 970 testing mi.mirror.garr.it 960 testing ftp.fr.debian.org 910 testing deb.opera.com 880 stable security.debian.org 870 stable mi.mirror.garr.it 860 stable ftp.fr.debian.org 810 stable deb.opera.com 670 unstablemi.mirror.garr.it 660 unstableftp.fr.debian.org 610 unstabledeb.opera.com --- Package information. --- Depends (Version) | Installed ===-+-=== libc6 (= 2.5) | 2.5-9+b1 djview | 3.5.19-2 OR djview4 | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357032: Please make a symlink for the documentation
Package: latex-beamer Version: 3.07-1 --- Please enter the report below this line. --- texdoc beamer shows a catalogue page with following link to the doc : a href=../../../macros/latex/contrib/beamer/doc/beameruserguide.pdf that is, to /usr/share/texmf-texlive/doc/macros/latex/contrib/beamer/doc/beameruserguide.pdf The problem is, beameruserguide.pdf is not in this place. I suggest, to make a symlink from this place to the actual location of the file : /usr/share/doc/latex-beamer/beameruserguide.pdf.gz or to change whatever you want to correct this broken link in the local TeXcatalogue. This documentation-not-available-to-texdoc problem is a violation of Debian TeX sub-policy, see http://people.debian.org/~preining/TeX/Debian-TeX-Policy/ch5.html#s-sec-documentation and could be easily fixed. --- System information. --- Architecture: i386 Kernel: Linux 2.6.18-4-486 Debian Release: lenny/sid 980 testing security.debian.org 970 testing mi.mirror.garr.it 960 testing ftp.fr.debian.org 910 testing deb.opera.com 880 stable security.debian.org 870 stable mi.mirror.garr.it 860 stable ftp.fr.debian.org 810 stable deb.opera.com 670 unstablemi.mirror.garr.it 660 unstableftp.fr.debian.org 610 unstabledeb.opera.com --- Package information. --- Depends (Version) | Installed ==-+- pgf(= 1.00-1) | 1.09-1 latex-xcolor (= 2.00-1) | 2.09-1 tetex-extra| OR texlive-latex-base | 2007-8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425996: Should recommand some kde-i18n package
Package: kile-i18n Version: 1:1.9.3-2 Severity: minor Tags: l10n --- Please enter the report below this line. --- If kile-i18n only is installed, some menu entries are translated, some aren't. In order for all entries to be correctly translated, kde-i18n-?? (with ?? = the current language) has to be installed. Maybe it's not obvious for all users (esp. those not running KDE as their main desktop), and it could be a good idea that kile-i18n (and others kde-soft-i18n) recommend some kde-18n-* package. --- System information. --- Architecture: i386 Kernel: Linux 2.6.18-4-486 Debian Release: lenny/sid 980 testing security.debian.org 970 testing mi.mirror.garr.it 960 testing ftp.fr.debian.org 910 testing deb.opera.com 880 stable security.debian.org 870 stable mi.mirror.garr.it 860 stable ftp.fr.debian.org 810 stable deb.opera.com 670 unstablemi.mirror.garr.it 660 unstableftp.fr.debian.org 610 unstabledeb.opera.com --- Package information. --- Depends (Version) | Installed ===-+-=== kile (= 1:1.9.3-2) | 1:1.9.3-2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
