Bug#804204:
This and #798931 are the same bug though phrased differently. As of Kubuntu Bionic the command service seems to be replaced by systemctl so the requisite steps are: #! /bin/sh sudo a2enmod cgid sudo systemctl restart apache2 -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा ူ၆ိျိါအူိ၆ါး
Bug#798931:
This and #804204 are the same bug though phrased differently. As of Kubuntu Bionic the command service seems to be replaced by systemctl so the requisite steps are: #! /bin/sh sudo a2enmod cgid sudo systemctl restart apache2 -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा ူ၆ိျိါအူိ၆ါး
Bug#748534: Report with similar intents
Looks like this bug is similar to bug #608283. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Bug#608283: Report with similar intents
Looks like this bug is similar to bug #748534. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Bug#603339: Update please?
Hello. I hope either Deepti or Paul can take the time to repackage this and upload. I can't even find the tentative package that Deepti mentions at https://lists.debian.org/debian-mentors/2011/04/msg00295.html that she has uploaded to http://mentors.debian.net/debian/pool/main/a/ansifilter. I'd really like to see this in Debian and my downstream Kubuntu. Topstream is currently at v1.15: http://www.andre-simon.de/doku/ansifilter/en/changelog.php -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Bug#804204: man2html installation should automatically enable Apache CGI module
Package: man2html Version: 1.6g-8 The man2html package description says to just visit http://localhost/cgi-bin/man/man2html after installation. However, this does not work and we get an error saying: Not Found The requested URL /cgi-bin/man/man2html was not found on this server. The solution as posted at http://ubuntuforums.org/showthread.php?t=2199030 and https://answers.launchpad.net/ubuntu/+source/man2html/+question/242116 is to enable the Apache CGI module by doing: sudo a2enmod cgid and then restarting the Apache server by: sudo service apache2 restart It seems this is a job for the postinst script or such so that immediately upon installing man2html we are able to use it. Please fix this. Thanks. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Bug#794188: python-pyftpdlib 1.2.0 is two years old; update needed
Package: python-pyftpdlib Version: 1.2.0-1 Hello. As you can see from https://github.com/giampaolo/pyftpdlib/releases, the current version packaged on Debian i.e. 1.2.0 is from over two years ago i.e. 2013-Apr-25. The most recent version of the software is 1.4.0 from last year 2014-Jun-04 and has also moved from Google Code (which is shutting down) to GitHub. Please repackage the latest version. Thank you very much! P.S.: I tried building the latest version with the current Debian packaging specs but something has changed and the package so built doesn't include the actual library but only includes the demos. This needs to be checked when repackaging. Thanks. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774141: kdevelop-python should be renamed kdevelop-python3
Package: kdevelop-python Version: 1.7.0-1 https://packages.debian.org/sid/kdevelop-python gives the description of this package as Python 3 plugin for KDevelop. Normally IIUC python3 related packages are marked as python3 and not just as python. I submit that it would be advisable to rename the package as kdevelop-python3 and instead package the Python 2 plugin as kdevelop-python. (Should I report a separate bug asking for Py 2 plugin?) Downstream Kubuntu has already independently packaged the Python 2 plugin as kdev-python since last two releases (http://packages.ubuntu.com/search?keywords=kdev-pythonsearchon=names), and is also now inheriting the kdevelop-python package from Debian (http://packages.ubuntu.com/source/vivid/kdevelop-python) which leads to an infelicitous naming situation there i.e. kdev-python for Py 2 vs kdevelop-python for Py 3. While I am going to report a separate bug downstream to align with Debian on the naming issue, I believe Debian should also rename the kdevelop-python package to kdevelop-python3 to make way for kdevelop-python for a Py 2 package. Thanks. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747716: closed by Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com (Not a bug)
I haven't disregarded anything you/Scott said. I specifically mentioned in that thread that developers say such-and-such. Didn't you notice that? I suppose I have the freedom to disagree with your opinion and try to elicit community opinion. That is what I did. And note that I am not unnecessarily continuing to make noise by saying developers are not listening to users etc etc. I voiced my opinion as a user, didn't get overmuch support for it from other users, and gave in to the developers' opinion then. I suppose that's a good democratic process. Please don't be sarcastic when someone is just trying to improve the Debian packaging or documentation by submitting/voicing their opinion or trying to mobilize community opinion. Lisandro was nice enough to say Even if we might disagree is good to have feedback from our users. I suppose you can be polite like that too. Thank you for your good work on Debian. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748534: Making it easy for user to specify GRUB text/menu colors
Package: grub-common
Version: 2.02~beta2-10
Hello. I am using Kubuntu Trusty. Since GRUB is not modified
downstream for Ubuntu, I'm filing this bug (actually an enhancement
request) against Debian. Perhaps some of these could be actually
included in topstream GRUB, but I leave it to the developers.
Currently it is unnecessarily difficult to specify the colors *and*
background image for GRUB 2. From
https://help.ubuntu.com/community/Grub2/Displays (I am not aware of
the equivalent Debian page) one learns that: To specify the background
image one has to edit /etc/default/grub and provide a GRUB_BACKGROUND=
entry, which seems a logical thing to do. But one is not able to
specify the colors therein as well. To get the required colors, one
can not specify custom colors in a settings file per se (i.e. meant
to be user-editable) but one is required to edit/alter files directly
part of packages[1], which seems awkward. And furthermore, there are
*two* files to edit, /etc/grub.d/05_debian_theme if a background image
is present and /lib/plymouth/themes/default.grub if not.
This is all totally sub-optimal IMO and I submit the attached patch as
a remedy. (While I'm using Trusty's GRUB 2.02~beta2-9, I am able to
successfully apply this patch on the recent 2.02*-10 tree too.)
This patch allows the colors to be specified in /etc/default/grub by
the variables GRUB_COLOR_{NORMAL,HIGHLIGHT} and
GRUB_MENU_COLOR_{NORMAL,HIGHLIGHT} just like the background image is
specified by GRUB_BACKGROUND. It also streamlines the selection of a
background image and its linkup with the colors being specified (i.e.
if there is a user-specified image, the user-specified colors are used
only if the image could be loaded at bootup). It also ties in
correctly with desktop-base[2] providing a default theme, with any
user-specified theme overriding that default. Further comments are
included inline in the patch.
A few related points:
1) I thought maybe I should patch debian/default/grub.md5sum too since
from the name one would assume it's an md5sum of the actual
debian/default/grub file but apparently it has lots of outdated
md5sum-s so I leave it to the developers to decide what to do with
that.
2) I've patched grub.texi documenting the new GRUB_*COLOR* variables.
I presume the info page (and any other documentation) will be
generated from that by the build process.
3) Two of the files to be patched (05_debian_theme and
grub-mkconfig.in) go into the grub-common package and two
(default/grub and grub.texi) go into the grub2-common package. I'm not
sure why these two are separate and I am sure not whether to specify
both packages or not. I am filing against grub-common only. Please
clone if needed.
Thanks.
Shriramana Sharma.
Footnotes:
[1 = I mean /etc/default/grub is not directly a part of a package but
is copied from /usr/share/grub/default/grub in package grub2-common by
its postinst.in lines 363 and 379 so the original from the package is
untouched by user configuration.]
[2 = The only requirement of the desktop-base for this integration is
that its grub_background.sh should also henceforth use the same
spellings for the image/colors as /etc/default/grub: GRUB_BACKGROUND,
GRUB_COLOR_* and GRUB_MENU_COLOR_*.]
--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
diff --git a/debian/default/grub b/debian/default/grub
index 7617f01..9cb55af 100644
--- a/debian/default/grub
+++ b/debian/default/grub
@@ -30,3 +30,34 @@ GRUB_CMDLINE_LINUX=
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE=480 440 1
+
+# Uncomment and set path to specify background image.
+# A relative path will be taken w.r.t. /boot/grub/.
+# Note that this is not required if the image is directly under this directory
+# (e.g. /boot/grub/splash.png) and is the only image there.
+#GRUB_BACKGROUND=grub-background.png
+
+# Uncomment and set colors below to avoid default colors or those specified by
+# the desktop-base package. Colors are specified in pairs -- foreground/background.
# I feel it important to specify the color name spellings here.
# One should not need to navigate through the info page for such a simple thing.
+# Valid color names are:
+# black dark-gray light-gray white
+# blue cyan green magenta red
+# light-blue light-cyan light-green light-magenta light-red
+# brown yellow
+#GRUB_COLOR_NORMAL=light-cyan/black
+#GRUB_COLOR_HIGHLIGHT=yellow/brown
+#GRUB_MENU_COLOR_NORMAL=white/black
+#GRUB_MENU_COLOR_HIGHLIGHT=white/green
+
# These notes should be highly visible too IMO:
+# Notes on images colors:
+# 1) If a background image is used, a background color of black is taken as
+#transparent. Remember that any other background color will block the image,
+#especially in GRUB_COLOR_NORMAL.
+# 2) If both a background image and a color scheme are specified, the color scheme
+#will be applied only if the background image is successfully loaded at bootup
+#time, else a default theme will be used. This is because the color scheme
Bug#748586: python-setuptools-doc: html files should not go directly under /usr/share/doc/(html/)
Package: python-setuptools-doc Version: 3.4.4-1 Please see https://packages.debian.org/sid/all/python-setuptools-doc/filelist -- all the html files are being installed directly under /usr/share/doc/html/. Going by other packages like python3-doc putting its html files under /usr/share/doc/python3-doc/html/ or python-qt4-doc using /usr/share/doc/python-qt4-doc/html/, I would say the html files of python-setuptools-doc should go under /usr/share/doc/python-setuptools-doc/html/ but for some strange reason /usr/share/doc/python-setuptools-doc/html is a symlink to ../html. Please fix the packaging so that the html files correctly go under /usr/share/doc/python-setuptools-doc/html/. Also, the packaging creates a symlink /usr/share/doc/python-setuptools/html which also points to ../html. I think this may be safely removed since in other (like above) cases when you have a separate doc package, there is no /usr/share/doc/python-qt4/html pointing to /usr/share/doc/python-qt4-doc/html/ and so on. Thank you. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747716: closed by Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com (Not a bug)
Hello and thanks for your kind words while closing the bug. As you may have noticed I tried to elicit community opinion on debian-user, but there weren't many responses -- just two, one for and one against. So I guess it's going to be as it is. But at least please update the packaging documentation on Depends and Recommends to clarify that when a package contains multiple programs [that word nowadays seems quite archaic! :-)], the dependency of only one of those programs will be considered a Recommends and not a Depends. Thank you. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747716: Fwd: KDbg should be upgraded to latest version to work with latest GDB
Package: qttools-opensource-src Version: 5.2.1-8build1 I am using Kubuntu Trusty 64 bit. Since the relevant package is not modified downstream for Ubuntu, I am reporting this bug against Debian. https://packages.debian.org/sid/qttools5-dev-tools shows that libqt5sql5-sqlite is only a Recommends. However, without installing the latter, I am not able to run Qt 5 Assistant at all: $ assistant -qt=5 QSqlDatabase: QSQLITE driver not loaded QSqlDatabase: available drivers: Error reading collection file '/home/samjnaa/.local/share/QtProject/Assistant/qthelpcollection_5.2.1.qhc': Cannot load sqlite database driver!. Installing the libqt5sql5-sqlite package allows Qt 5 Assistant to load. Apparently this is a hard dependency which is mistakenly labeled as a Recommends. Please fix this. Thank you. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747716: Fwd: KDbg should be upgraded to latest version to work with latest GDB
Hello. You say it is not a hard depends, but https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#control says to use Depends if your program absolutely will not run (or will cause severe breakage) unless a particular package is present. Given that assistant is one of the programs installed by this package, and it does not run without the libqt*sqlite package, IMO it stands to reason that the latter is indeed a Depends. The page above does not seem to say anything special re many programs installed by a single package. In any case, if I install a package, I expect to be able to run the programs installed by it. Hence the dependency of one of the programs of the package should be a dependency of the package. If it is felt important to avoid installing that dependency unless absolutely necessary, then the program should be put in a separate package IMO. BTW apologies for botching up the title/version number. Also, I had provided the source package name based on Launchpad experience -- I can now see it in Debian should be the binary package with the source package given as part of the version. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747716: qttools5-dev-tools: libqt5sql5-sqlite should be a hard dependency
On 5/11/14, Scott Kitterman deb...@kitterman.com wrote: On Sunday, May 11, 2014 18:52:31 Shriramana Sharma wrote: Hello. You say it is not a hard depends, but https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#control says to use Depends if your program absolutely will not run (or will cause severe breakage) unless a particular package is present. Given that assistant is one of the programs installed by this package, and it does not run without the libqt*sqlite package, IMO it stands to reason that the latter is indeed a Depends. You are misreading that. In this case Recommends is what is typically used. You say typically used -- you are saying this is current existing practice of package maintainers. Fine. But it is not as per the policy as it is stated in the above page. Please point out where in the specification does it say Recommends is used for packages which are a dependency of one/some but not all of the programs installed by a package? The policy as it stands as to what are Depends, Recommends and Suggests is quite sane, but it seems to speak as if one package installs one program only. One would assume that what is said by the wording for one program is true in general, and hence program would be read as programs. In which case, whatever one of the programmed installed by a package cannot be executed without is indeed a dependency. Debian (and Ubuntu) install Recommends by default, so the only reason you wouldn't have Recommends installed too is if your system is in a non-standard configuration. If so, that's the problem, not the package. I do not install recommends by default because I am not on a very high speed connection. Probably others may choose it because they are on a connected billed by bandwidth used. Whatever be the reason for not installing recommends, I expect that when I install a package using apt-get, it should pull in the hard dependencies, and the hard dependencies are those which are required to execute whatever is installed by the package. As I said earlier, the dependency of one program installed by the package should be a dependency of the package. If not, it is simply counter-intuitive. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678464: xplanet should be upgraded to 1.3.0 to read JPL files
This is a +1 on this bug. Please see http://xplanet.sourceforge.net/FUDforum2/index.php?t=msgth=614. Currently xplanet 1.2.1 on Debian (and Ubuntu) is unable to read even the older JPL DE405 files. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Bug#715031: KDbg should be upgraded to latest version to work with latest GDB
Package: kdbg Version: 2.5.1-1 Current version of kdbg in sid/quantal/raring is 2.5.1-1. However the corresponding version of gdb is 7.5+. As can be seen from the upstream changelog linked below, only kdbg 2.5.2 supports gdb 7.5: http://repo.or.cz/w/kdbg.git?a=blob;f=ReleaseNotes-2.5.2;hb=kdbg-2.5.2 As a result the kdbg currently distributed with sid/quantal/raring does not work with the gdb coming with the same distro. I compiled/installed KDbg 2.5.3 on Kubuntu Raring and it works for me with the stock Raring GDB. Therefore please upgrade kdbg to the latest version i.e. currently 2.5.3. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712570: dvipsnam
For future reference, upstream author indicates that dvipsnam.def will be the first preference in a future version rather than xcolors.sty: http://lists.nongnu.org/archive/html/dvipng/2013-06/msg9.html. One might want to ensure that the dependency will then be corrected accordingly if necessary. (Currently the only TeX-related packages dvipng depends on AFAICS are libkpathsea6 and texlive-base-bin and I'm not sure whether the dependency tree will include texlive-latex-base which currently contains dvipsnam.def.) -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712570: dvipng package should depend on latex-xcolor
Package: dvipng
Version: 1.14-1
DVIPNG currently requires the presence of xcolor.sty provided by
latex-xcolor. Otherwise if colours are provided for
foreground/background it segfaults even on dvi-s coming even from
simple LaTeX files like:
\documentclass[16pt]{article}
\usepackage{amsmath,amssymb}
\usepackage{breqn}
\pagestyle{empty}
\begin{document}
$ \infty $
\end{document}
For details please see the thread on the upstream mailing list:
http://lists.nongnu.org/archive/html/dvipng/2013-06/msg0.html and
the bug I filed for this downstream on LaunchPad:
https://bugs.launchpad.net/ubuntu/+source/dvipng/+bug/1191673.
Upstream author notes (see thread above) that currently latex-xcolor
is a dependency for dvipng although it may become merely a recommends
in the future. Until then, please add latex-xcolor as a dependency for
dvipng. Thank you.
--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695554: ipython-doc should not require ipython(2)
Package: ipython Version: 0.13.1-1 Ideally ipython-doc should not need to have a dependency on ipython. I do not see why a set of HTML files should require an actual ipy installation to be there. If it is because of the examples, I suppose depending on either ipython|ipython3 would be appropriate, rather than needing users to install ipython when they do not wish to use Py2 in favour of Py3 and ipython3. Please consider removing the dependency or at least change it to depend on ipython|ipython3. Thanks! -- Shriramana Sharma -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693612: Menu items should be added for ipython3 and ipython3-qtconsole
Package: ipython Version: 0.13.1-1 The ipython and ipython-qtconsole packages which are both built for Py2 currently provide the menu files /usr/share/applications/ipython.desktop and /usr/share/applications/ipython-qtconsole.desktop due to which we are able to access them from the menu and KDE KRunner. However, the Py3 equivalents ipython3 and ipython3-qtconsole packages do not provide equivalent menu items. Since Py3 is the future, please add such desktop files so that we can execute them from the menu and KRunner. Thanks. -- Shriramana Sharma -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684109: fontforge should be updated to 20120731 version
Package: fontforge Version: 0.0.20120101+git-2 Hello. There has been a fontforge 20120731 release: http://sourceforge.net/mailarchive/message.php?msg_id=29620722 http://sourceforge.net/mailarchive/message.php?msg_id=29625605 Please update the Debian fontforge package to this latest version. As per the second message, the b-version is the one to be used as the first version does not build on 64-bit systems. BTW can we just remove the 0.0. from the versioning and have the release date as the version like it is seen upstream? Thank you. -- Shriramana Sharma -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680243: graphite2 package does not include gr2fonttest and other gr2 utils
Package: graphite2 Version: 1.1.3-1 I was just backporting latest gr2 1.1.3 from http://packages.debian.org/source/sid/graphite2 to Kubuntu Precise and I found that gr2fonttest is not included into any of the resultant packages. The debian/ dir doesn't refer to this except in the copyright file at all! I tried doing cmake -G Unix Makefiles and make myself, and found that there are other utilities being produced (like featuremaptest) which might also be useful to package. However their names seem too generic and might conflict with other executables and probably prefixing them with gr2 (just like gr2fonttest) would be a good idea if they are going to be packaged. I request that these utils also be packaged, perhaps in a separate deb. -- Shriramana Sharma -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661898: Rachana Malayalam font has false mappings for non-encoded characters
Package: ttf-malayalam-fonts Version: 1:0.5.14 The Rachana Malayalam font that is distributed with Debian false mappings for non-encoded characters. That is, characters which are not even encoded in Unicode, for example 0D00, 0D01 and so on throughout the Malayalam block till 0D7F are assigned a glyph which looks like 00AE REGISTERED SIGN ®. It is not appropriate for a font in a distribution to have unencoded characters mapped to any glyph. The rendering engine will automatically take care of such characters and display them using the .notdef glyph in the font. Providing such wrong mappings fools the rendering engine to think that the font actually caters to these characters which are not even encoded. Therefore please remove these false mappings. -- Shriramana Sharma
Bug#661905: Rachana Malayalam font has wrong glyphs for many characters
Package: ttf-malayalam-fonts Version: 1:0.5.14 The Rachana Malayalam font that is distributed with Debian has wrong glyphs for many characters. I have separately reported the bug #661898 that this font also gives false mappings for non-encoded characters, displaying for them a glyph which looks like 00AE REGISTERED SIGN ®. The same is true for many encoded characters also. Specifically the following characters are displayed as ®: Sanskrit-use characters: 0D44 MALAYALAM VOWEL SIGN VOCALIC RR 0D62 MALAYALAM VOWEL SIGN VOCALIC L 0D63 MALAYALAM VOWEL SIGN VOCALIC LL Pedantic-use characters: 0D29 MALAYALAM LETTER NNNA 0D3A MALAYALAM LETTER TTTA Old dot reph: 0D4E MALAYALAM LETTER DOT REPH Numerals and fractions: 0D71 MALAYALAM NUMBER ONE HUNDRED 0D72 MALAYALAM NUMBER ONE THOUSAND 0D73 MALAYALAM FRACTION ONE QUARTER 0D74 MALAYALAM FRACTION ONE HALF 0D75 MALAYALAM FRACTION THREE QUARTERS Date mark: 0D79 MALAYALAM DATE MARK Chillu characters: 0D7A MALAYALAM LETTER CHILLU NN 0D7B MALAYALAM LETTER CHILLU N 0D7C MALAYALAM LETTER CHILLU RR 0D7D MALAYALAM LETTER CHILLU L 0D7E MALAYALAM LETTER CHILLU LL 0D7F MALAYALAM LETTER CHILLU K The following character is displayed as a fullstop .: 0D70 MALAYALAM NUMBER TEN Many of these characters were encoded after the initial publication of this font. As such, bug #661898 regarding non-encoded characters would have applied before, but now that these characters are encoded, either the font should provide the proper glyphs or should not provide any mappings for these characters at all. It is not appropriate for a font in a distribution to have encoded characters mapped to the wrong glyph. If the font does not provide a glyph for a character, the rendering engine will automatically take care of such characters and display them using the .notdef glyph in the font. Providing such wrong mappings fools the rendering engine to think that the font actually caters to these characters which is not right. Therefore please either provide the correct glyphs or remove these mappings. Seeing Santosh's feedback on the bug #661898, I have now downloaded the latest repo version of the Rachana font. I see that the bad glyphs have been removed. But this bug should be closed *after* that version is released just to keep track of things. -- Shriramana Sharma -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661905: Minor corrections to bug report
This is a follow-up. Actually the bug title should have read Rachana Malayalam font has bad place-filler glyphs for many characters. There are other wrong-glyph problems which I will be separately reporting. This particular bug is to report that the font is using bad place-filler glyphs in the absence of proper glyphs for encoded characters. Someone with the administrative rights to change the subject of the bug, please change it as requested above. Sorry for the inadvertent error. Thanks. -- Shriramana Sharma -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661923: Rachana Malayalam font has wrong glyph for 0D66 MALAYALAM DIGIT ZERO
Package: ttf-malayalam-fonts Version: 1:0.5.14 The Rachana Malayalam font that is distributed with Debian shows the wrong glyph for 0D66 MALAYALAM DIGIT ZERO. I have separately reported bug #661905 that this font displays many encoded characters wrongly as ® or as full stop. Those are purely bad glyphs intended as fillers which should be removed. However this is a different bug. The glyph already existing in the font for 0D66 MALAYALAM DIGIT ZERO is actually that of the later encoded 0D73 MALAYALAM FRACTION ONE QUARTER. Previously the old Unicode chart had this wrong glyph, however the current chart has been updated to show the actual Malayalam digit zero which is just like the other zeroes of (South) Indian scripts: http://www.unicode.org/charts/PDF/U0D00.pdf Not only the currently Debian-distributed font, but also the latest Rachana version in the Savannah repository is having this wrong glyph. Santosh Thottingal had written in the feedback on the bug #661898 that the latest Rachana font with many fixes is about to be uploaded. I recommend that before uploading, this bug also (and other few bugs I am going to report now) should also be corrected. -- Shriramana Sharma -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661924: Rachana Malayalam has misleading internal glyph for 0D4C MALAYALAM VOWEL SIGN AU
Package: ttf-malayalam-fonts Version: 1:0.5.14 This is not a very serious problem for end-users but it could be a problem for those that are hacking on fonts. Especially when a font is GPL and there are potentially derivatives, even the internals of the font should be ideally maintained correctly. Both in the currently distributed Rachana font and in the Rachana font in the Savannah repository, the internal glyph for 0D4C MALAYALAM VOWEL SIGN AU is given as purely the right-half glyph of ൌ, i.e. the glyph of 0D57 MALAYALAM AU LENGTH MARK ൗ. However, the two part vowel signs are normally internally shown as containing both the components within a single glyph. Refer the glyphs within the font for 0D4A MALAYALAM VOWEL SIGN O, 0D4B MALAYALAM VOWEL SIGN OO. It is suggested that likewise the internal glyph for 0D4C MALAYALAM VOWEL SIGN AU should also be made likewise. I have attached the required glyph as TTF format. (I hope the bug report system will accept email attachments.) Please replace the internal glyph for 0D4C MALAYALAM VOWEL SIGN AU with the attached glyph, so that whoever is working on corrections or derivatives to this font can be aware that it is a placeholder for the two-part vowel sign. While the final rendering will be coming correctly for all two-part vowel signs because the rendering engine will actually use the separate components, it is advisable to have the correct glyphs inside the font for consistency and clarity. -- Shriramana Sharma Malayalam-Vowel-Sign-AU-Glyph.ttf Description: application/font-ttf
Bug#661925: Rachana Malayalam font does not correctly map existing glyph of 0D79 MALAYALAM DATE MARK
Package: ttf-malayalam-fonts Version: 1:0.5.14 The Rachana Malayalam font, both in the current Debian distribution and the Savannah repository, contains the glyph for 0D79 MALAYALAM DATE MARK but does not provide a character mapping for it. Therefore it is unavailable to end-users. Appropriate character mapping of 0D79 MALAYALAM DATE MARK should be added for this glyph so that this glyph is available to end-users. For convenience sake may I mention that the postscript name of the glyph is NameMe_195550 (which may be changed to something more meaningful). In the current distribution its glyph ID is 0xEC and in the Savannah repo it is 0xC2. -- Shriramana Sharma -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661923: Reply to Santosh
Sir I think you have misunderstood my report. I was pointing out that the current glyph in the Rachana font whether in the Debian distribution or the upstream Savannah repository is having the shape of the MALAYALAM DIGIT ZERO as a circle with a tail to the right. The point is not whether the circle is closed or not. The point is that as per the Unicode chart, a circle with tail to the right is representing the FRACTION ONE QUARTER and *not* DIGIT ZERO. For DIGIT ZERO the glyph must be only a circle (whether closed or not) and there should be no tail. -- Shriramana Sharma -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535599: Rename source package sip4-qt3 to sip4
Package: sip4-qt3 Version: 4.8.1-1 Hello. I do not know for what reason originally the sip4-qt3 package was tagged with the word qt3 but currently there is no connection between Qt 3 and SIP specifically, and in fact PythonQt which is the software that mainly uses SIP is now for Qt 4. So I suggest that this source package be renamed. Shriramana Sharma. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#500653: apt-get must use faster download algorithms or aria2 as a backend downloader
Package: apt Version: 0.7.14 apt-get apparently currently uses some simple wget-type sequential download algorithm for all its functions that download anything from the net, like update, install, dist-upgrade, upgrade, build-dep, source etc. This really does not well use the available broadband bandwidth of most users. Hence I am forced to use home-cooked scripts to extract the URLs to download and then pass them to aria2 (GPL) to download, so that the thing is done faster. If it is built-in, everyone can benefit. Granted, the user may not want his entire bandwidth hogged by apt-get, but at least provide this as an option -- use a faster split-download algorithm, or at least use a good backend downloader like aria2 which provides high-speed downloading. I am a downstream (Ubuntu) user of Debian apt, and the downstream people redirected me to here from http://bugs.launchpad.net/bugs/275994 Shriramana Sharma. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500654: gzip does not provide keep input files option
Package: gzip
Version: 1.3.12
bzip2 gives a -k or --keep option which prevents the source files from
being deleted. gzip does not have this. It is highly useful when a
number of files have to be compressed/decompressed. Otherwise we are
forced to write a for x in $(ls *.gz) kind of script when just two
letters -k will solve the problem.
I created a patch for this.
Shriramana Sharma.
--- gzip.c.orig 2007-03-20 10:39:51.0 +0530
+++ gzip.c 2007-04-15 17:32:43.0 +0530
@@ -189,6 +189,7 @@
int recursive = 0;/* recurse through directories (-r) */
int list = 0; /* list the file contents (-l) */
int verbose = 0; /* be verbose (-v) */
+int keep_input_files = 0; /* do not delete input files */
int quiet = 0;/* be very quiet (-q) */
int do_lzw = 0; /* generate output compatible with old compress (-Z) */
int test = 0; /* test .gz file integrity */
@@ -243,7 +244,8 @@
/* {encrypt,0, 0, 'e'},encrypt */
{force, 0, 0, 'f'}, /* force overwrite of output file */
{help, 0, 0, 'h'}, /* give help */
- /* {pkzip, 0, 0, 'k'},force output in pkzip format */
+ /* {pkzip, 0, 0, 'k'},force output in pkzip format */ /* IF THIS IS ENABLED IT WILL CONFLICT WITH KEEP */
+{keep, 0, 0, 'k'}, /* keep input files */
{list, 0, 0, 'l'}, /* list .gz file contents */
{license,0, 0, 'L'}, /* display software license */
{no-name,0, 0, 'n'}, /* don't save or restore original name time */
@@ -318,7 +320,8 @@
/* -e, --encrypt encrypt */
-f, --force force overwrite of output file and compress links,
-h, --helpgive this help,
-/* -k, --pkzip force output in pkzip format */
+/* -k, --pkzip force output in pkzip format */ /* IF THIS IS ENABLED IT WILL CONFLICT WITH KEEP */
+ -k, --keepkeep (don't delete) input files,
-l, --listlist compressed file contents,
-L, --license display software license,
#ifdef UNDOCUMENTED
@@ -417,13 +420,13 @@
decompress = 1;
else if (strequ (program_name + 1, cat) /* zcat, pcat, gcat */
|| strequ (program_name, gzcat)) /* gzcat */
- decompress = to_stdout = 1;
+ decompress = to_stdout = keep_input_files = 1;
#endif
z_suffix = Z_SUFFIX;
z_len = strlen(z_suffix);
-while ((optc = getopt_long (argc, argv, ab:cdfhH?lLmMnNqrS:tvVZ123456789,
+while ((optc = getopt_long (argc, argv, ab:cdfhH?klLmMnNqrS:tvVZ123456789,
longopts, (int *)0)) != -1) {
switch (optc) {
case 'a':
@@ -439,15 +442,17 @@
}
break;
case 'c':
- to_stdout = 1; break;
+ to_stdout = keep_input_files = 1; break;
case 'd':
decompress = 1; break;
+ case 'k':
+ keep_input_files = 1; break;
case 'f':
force++; break;
case 'h': case 'H':
help(); do_exit(OK); break;
case 'l':
- list = decompress = to_stdout = 1; break;
+ list = decompress = to_stdout = keep_input_files = 1; break;
case 'L':
license(); do_exit(OK); break;
case 'm': /* undocumented, may change later */
@@ -477,7 +482,7 @@
z_suffix = optarg;
break;
case 't':
- test = decompress = to_stdout = 1;
+ test = decompress = to_stdout = keep_input_files = 1;
break;
case 'v':
verbose++; quiet = 0; break;
@@ -701,7 +706,7 @@
return;
}
-if (! to_stdout)
+if (! keep_input_files)
{
if (! S_ISREG (istat.st_mode))
{
@@ -822,12 +827,13 @@
if (close (ifd) != 0)
read_error ();
-if (!to_stdout)
+if (!to_stdout) copy_stat (istat);
+
+if (!keep_input_files)
{
sigset_t oldset;
int unlink_errno;
- copy_stat (istat);
if (close (ofd) != 0)
write_error ();
Bug#500653:
I just note that this *may* be related to: 158486 -- having parallel downloads from the same server. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487946:
Why limit this comment to apt-get *source* ? Any command that causes apt-get to download suffers from this. apt's sources.list should be revised to read like this: [Mirrors] ftp.de.debian.org ftp.us.debian.org osuosl.org/ftp.debian.org [Distributions] sid sid-updates sid-backports [Components] free non-free This would be equivalent to many lines specifying all the components for each distribution for each mirror. For catering to cases where this appropriate is not appropriate (eg local self-styled repos and third-party repos that do not follow Debian's component system etc), have an Old-style section where the user can enter old-style lines like: [Old-style] deb file:///home/ramram/local-deb-repo / deb http://wine.budgetdedicated.com/apt sid main deb http://apt.wxwidgets.org/ sid-wx main deb http://download.virtualbox.org/virtualbox/debian sid non-free So lines in this old-style section will be processed as before, and the newer type lines will be construed to apply for all mirrors listed. Shriramana Sharma. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284092: apt-get should not add epoch numbers to the filenames of downloaded packages
Hello. On all Debian (and Ubuntu) mirrors the filenames of the deb packages do not contain the epoch information. The epoch information is only used by the apt system to determine which package should be considered newer than which and this information is present inside the deb file itself. So it is not really required in the filename. Further, seeing as the deb packages on the Debian mirrors do not contain this epoch information, apt-get should not add this %3a1 or such characters to the file names. I encounted problems maintaining my local repository (of downloaded packages) due to this meaningless behaviour of apt. Please disable this mis-behaviour of apt. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
