Bug#973471: [PATCH] The obvious patch fixes the problem -- but subject to locale
I'm just writing to confirm that after applying the attached patch (adding -f
to the sole occurrence of `sort' in debian/rules) to scowl-2020.12.07-2, the
test I gave before:
while read -r i; do
look "$i" | fgrep -q -w "$i" || echo " $i";
done < /usr/share/dict/words
no longer identifies any words that look doesn't find (when
/usr/share/dict/words
points via /etc/dictionaries-common/words to /usr/share/dict/american-english,
and look is provided by bsdextrautils 2.36.1-8+deb11u1, whose source package is
util-linux).
I do wonder whether there are any locales with interesting LC_COLLATE (or
LC_CTYPE) behaviour that could cause the above test to fail for some word
lists; though I'd think that that would be a bug to be fixed in util-linux, not
in scowl. scowl's sort command in question already explicitly sets LC_ALL to C,
which seems like the right behaviour for scowl to me: I don't think one could
really do better even if the sort were delayed until installation time.
util-linux misc-utils/look.c calls setlocale(LC_ALL, "") at startup (i.e.
setting all locale categories from the environment), with no other occurrence
of setlocale in the source file; and its compare() function uses isalnum and
isblank (which are documented to use current locale), and strncasecmp (whose
behaviour is explicitly unspecified in its documentation, outside of POSIX
locale). So it does seem like one could at least construct locales for which
this implementation of look would fail. However, I have not tested this
conclusion (which is formed from a cursory look at the source by someone not
an expert in locales).
pjrm.
diff -dur scowl-2020.12.07/debian/rules scowl-2020.12.07-f/debian/rules
--- scowl-2020.12.07/debian/rules 2022-01-20 16:14:35.0 +1100
+++ scowl-2020.12.07-f/debian/rules 2023-07-03 11:14:50.909568820 +1000
@@ -55,7 +55,7 @@
echo " $${word_list}" >> w$$SPELLING$$SIZE.scowl-word-lists-used;\
fi;\
done; \
- cat $$SPELLING-english$$SIZE.unsorted | LC_ALL=C sort -d | uniq | iconv -f 'iso8859-1' -t 'utf-8' > $$SPELLING-english$$SIZE; rm $$SPELLING-english$$SIZE.unsorted;\
+ cat $$SPELLING-english$$SIZE.unsorted | LC_ALL=C sort -d -f | uniq | iconv -f 'iso8859-1' -t 'utf-8' > $$SPELLING-english$$SIZE; rm $$SPELLING-english$$SIZE.unsorted;\
done;\
done
cd speller && $(MAKE) hunspell
Bug#973471: See also #1040126
If the sort order of the wordlist is changed (as #1040126 suggests), then that would resolve this bug. There would still be a question of whether the look tool ought to require the wordlist to be sorted. Other implementations of look(1) do (in absence of explicit filename), so my feeling is that providers of /usr/share/dict/words should ensure that the file is sorted with -d -f. That being the case, my feeling is that look(1) should indeed make use of that sort order: i.e. I feel that the benefit of the reduced number of reads should outweigh the chance of a misconfigured system (though see next para). However, there is a question of how bsdextrautils should allow for the fact that the existing version of scowl does supply an inappropriately ordered wordlist: perhaps bsdextrautils should Conflict with existing versions, or perhaps it should for now switch to not requiring sortedness, and later go back to requiring orderedness and adding a Conflicts on existing scowl versions. pjrm.
Bug#1040126: wamerican: wordlist should be sorted ignoring case
Package: wamerican Version: 2020.12.07-2 Severity: normal [Arguably the same bug as #987857, but with more information about what is needed to fix it.] How to reproduce: $ look apostol $ grep '^apostol' /usr/share/dict/words apostolic I would expect that the first command would show the same words found by the second. The util-linux look(1) command "ignore[s] the case of alphabetic characters ... by default if no file is specified", and it requires that "the lines in file must be sorted (where sort(1) was given the same options -d and/or -f that look is invoked with)". This sort order (of -f -d in absence of filename given as argument) is the same as that mentioned at https://man.openbsd.org/look, so I think the wordlist is the right place to address this discrepancy, rather than in util-linux. (I.e. changing the expected sort order in util-linux look(1) would make it difficult to change between different implementations of look(1); whereas I'm not aware of very strong reasons for one sort order over another in word lists other than matching what look(1) expects.) If I make /usr/share/dict/words be a file sorted with -f -d, then while read -r i;do look "$i" | fgrep -q -w "$i" || echo " $i";done < /usr/share/dict/words finds no missing words, i.e. every word present in the wordlist can be found by look. So the solution seems to be to ensure that all files that are candidates for the /usr/share/dict/words alternative are sorted with ‘-d -f’. pjrm.
Bug#858875: dict-gcide: 0.48.3 misbuild: missing all words that begin with [ao]
On Thu, Mar 30, 2017 at 02:22:32PM +0530, Ritesh Raj Sarraf wrote: > Now that's much more weird. > > rrs@learner:~/rrs-home/Community/Packaging/dict-gcide (master)$ git diff > [no change wrt gcide.a, gcide.o] There's a fair chance that git is an example of software that's ignoring *.[oa] files. man gitignore for a list of files that influence what files git ignores. If you do a manual diff between freshly extracted .tar files, you can see that earlier versions have cide.a and cide.o and 0.48.3 does not. [I should note that I actually tried it only with 0.48.1 rather than 0.48.2, just because my local mirror doesn't have a copy of the 0.48.2 source.] pjrm.
Bug#858875: dict-gcide: 0.48.3 misbuild: missing all words that begin with [ao]
On Tue, Mar 28, 2017 at 01:56:25PM +0530, Ritesh Raj Sarraf wrote: > Control: tag -1 +confirmed > > Thank you fore reporting this bug. I am not sure which version has caused > this problem. Perhaps the first step would be to pick older versions from > snapshot.debian.org and try. I can confirm that the binary for 0.48.2 has O and A entries. Now that I've looked at the source package, and seen that the source files are named cide.o etc., I think we can guess that what's happened is that some software has decided that *.o and *.a files can and should be discarded (thinking that they're object files). The most reliable fix probably involves a rename (say cide-o or cide-o.xml), as there's plenty of other software around that would make the same guess even if you avoid it happening again with the particular software that discarded them this time. pjrm.
Bug#655201: reproducing with libreoffice
To reproduce the problem and its fix in libreoffice writer: Start libreoffice, and click the Text file button. Type a paragraph consisting of many repeats of contrecœur contrecœur contrecœur contrecœur... Select all, right-click, select Character style, and change the Language (in lower right of dialog box) to French (France). Click OK. Right-click, select Paragraph style, go to the Text Flow tab, and tick the Hyphenation Automatically box. Optionally go to the Alignment tab in that same Paragraph style dialog box, and select Justified. Click OK. Drag the page width (right extent of white area in ruler at top of screen) to a little less than three words wide. Result: two words per line, no hyphenation opportunities found. If justified, then those two words are very widely spaced. Save file, exit. As root, edit /usr/share/hyphen/hyph_fr.dic and append a 5 to the first line, i.e. change from ISO8859-1 to ISO8859-15. Back as a normal user, run libreoffice on the saved file. Result: Some lines now end in a hyphenation of contre-/cœur, as they should be. pjrm. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576501: Retraction of proposed resolution
Since writing that last message, I've been convinced that NULL is not in fact valid for memcpy etc. I give my (revised) reasoning at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44081#c8 Consequently, I retract my last message, and now suggest rejecting the bug as invalid. (Original submitter cc'd to ensure opportunity to express acceptance or rejection of this revised reading and consequent suggested rejection of the bug. Apologies if this results in you getting more than one copy: I've heard of a case where the original submitter claimed not to have automatically received replies to the bug, so I'm cc'ing just in case.) pjrm. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576501: better example; and comments on resolution
In case the provided example seems too rare to expend much effort on, then consider the common practice of returning NULL for a memory allocation request of zero bytes. As for the appropriate resolution of this bug: The documentation of the nonnull attribute claims that The compiler may also choose to make optimizations based on the knowledge that certain function arguments will not be null. Thus, for function arguments where NULL is indeed a permissible value, it is indeed a bug to mark those arguments with the nonnull attribute (at least in the presence of a compiler that does in fact make misoptimizations as a result; I haven't checked whether any released version of gcc does, for example). (Whereas if the attribute's only effect were to issue warnings, then I would instead recommend marking the bug as WONTFIX: it's permissible for warnings to give false positives, and I suspect that the value of the true positives outweighs the cost of the false positives, because I suspect it rare that the compiler would falsely issue the warning.) As for whether or not qsort, memcmp, memcpy, memmove etc. do in fact permit NULLs: I see nothing in the documentation saying that the results are undefined for NULLs, so presumably definedness is based only on whether any of the memory accesses implied by the documentation are invalid; so I concur that NULL is indeed a valid argument value when n==0. Perhaps the aim of the nonnull attribute in these cases can be better achieved with something along the lines of __builtin_object_size. In addition, I would be inclined to file a bug against the gcc documenation, given that it uses a memcpy-like function as an example of its use: I should think that a warning about this issue would be appropriate. pjrm. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570523: Not yet available
The 0.17 version is just a prototype, whose README.txt says “The source code for Dunnart is not currently available”. It is expected to be rewritten in GPL'd form (with Qt instead of the current custom toolkit on SDL); and it's hoped that there'll be something released but not usable around mid-year, and something usable by the end of the year. (In the meantime, anyone looking for similar software might look at the software mentioned at http://en.wikipedia.org/wiki/Dia_(software)#See_also. Note too that some parts of Dunnart (connector routing, removing node overlap) have already been added to Inkscape.) Programming language: The programming language for 0.17 is C++, and presumably the redeveloped version is too. I see that the source tree includes some software called Cider (a sort of yacc for parsing diagrams instead of text files) written in Java, though I don't know offhand whether Dunnart currently uses that, or whether that was for some other experiment that just happened to use the Dunnart canvas. pjrm. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#158015: tidy: reexplanation of numeric entity bug with -big5
The two URLs that Dan gave are unfortunately no longer valid for this bug report, in that the current versions use utf-8. The wayback machine doesn't have a copy of either page from before the bug report was filed, but the versions it does have (e.g. http://web.archive.org/web/20021025151116/http://jidanni.org/lang/pinyin/19970607tai_ke.html), are enough that I think I know what the bug is that Dan was trying to explain; I'll give a smaller example here. The problem that I see (in at least versions 20091223cvs-1 and 20080116cvs-2) is that numeric entities get munged in big5 documents: e.g. given an input document of htmlheadtitleIPA ng: #331;/titleheadbody#331;/bodyhtml (with or without meta http-equiv=Content-Type content=text/html; charset=big5 in the head) when run through `tidy -big5' will wrongly get output with each #331; converted to amp;#331;. The correct behaviour would be to retain them in #331; form (IPA `ng' symbol). (I don't know whether or not the following is the source of the bug, but note that numeric entities refer to unicode code points, not big5 code points. The html4 spec is a little misleading on this point: the confusion arises from the phrase the document character set (in Numeric character references specify the code position of a character in the document character set.), which on a casual reading might be taken to mean the document encoding, but section 5.1 (and indeed the sentence immediately following that misleading sentence) clarify that they do refer to unicode (iso10646) code points.) pjrm. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563239: automake alternatives: information towards a fix
The bug is still present in 1.11.1-1, though I see the minor variation that /usr/bin/aclocal and /etc/alternatives/aclocal are now like the corresponding automake files (ultimately a broken symlink): lrwxrwxrwx ... /etc/alternatives/aclocal - /usr/bin/aclocal-1.10 lrwxrwxrwx ... /etc/alternatives/automake - /usr/bin/automake-1.10 lrwxrwxrwx ... /usr/bin/aclocal - /etc/alternatives/aclocal lrwxrwxrwx ... /usr/bin/automake - /etc/alternatives/automake I'm just about to go to bed, and haven't finished debugging this, but I suspect that there's a step missing in the how to reproduce instructions: I suspect that this bug only occurs after having automake 1.10 installed and then upgrading to automake 1.11 (or 1.11.1). So first install automake 1.10 (I used 1.10.1-3), then do `update-alternatives --auto automake', then install automake 1.11.1. When upgrading to 1.11.1, first automake 1.10's prerm is called with $1=upgrade (and $2=1:1.11.1-1), so it doesn't do its update-alternatives --remove command, even though /usr/bin/automake-1.10 and /usr/bin/aclocal-1.10 are disappearing. Then when automake 1.11.1's postinst gets run, it unconditionally runs `update-alternatives --install ...', but update-alternatives apparently decides that the setting is manual: it leaves automake pointing to /usr/bin/automake-1.10. If I modify /usr/sbin/update-alternatives to make its initial/default $verbosemode value from 0 to 1, then it gives the following when upgrading from 1.10 to 1.11.1: Alternative for automake points to /usr/bin/automake-1.10 - which wasn't found. Removing from list of alternatives. /etc/alternatives/automake has been changed (manually or by a script). Switching to manual updates only. Checking available versions of automake, updating links in /etc/alternatives ... (You may modify the symlinks there yourself if desired - see `man ln'.) Automatic updates of /etc/alternatives/automake are disabled, leaving it alone. To return to automatic updates use `update-alternatives --auto automake'. Given that we can't change the already-released automake 1.10.1-3 prerm, perhaps for the fix the new scripts should start by calling `update-alternatives --remove automake /usr/bin/automake-1.10'. I haven't checked how --remove behaves if /usr/bin/automake-1.10 isn't present, so it may be best for this to be in preinst, which is run when the previous version's files are still present on the filesystem. However, note that this won't be enough if automake 1.11.1-1 has already been installed (causing update-alternatives to mark in its database that the automake group is set manually). The best fix I can think of for that case is to be a bit brutal: manually check whether automake points to a non-existent 1.10, and if so then call update-alternatives --auto automake. (`readlink' has been in coreutils since v4.5.5, present in Debian unstable since Feb 2003, so present in both Debian v4.0 (etch) and v5.0 (lenny), and coreutils has apparently been `Essential: yes' as long as the package has existed, so we can assume its presence via the Debian does not support upgrading across more than one stable release rule, so it should be fine to use the readlink program without adding a versioned dependency.) It's now well past my bedtime, but I hope that's a good start towards understanding how this bug is occurring, and what a fix might be. Btw, just in case you wish to consult it, the sequence for when the prerm etc. scripts get called and with what arguments isn't in the first couple of places I looked for it (developers-reference, dpkg documentation, /usr/share/doc/debian), it's actually in /usr/share/doc/debian-policy/policy.*. pjrm. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#185010: workarounds
On a Nokia 770 (64MB RAM, 256MB swap), locale-gen (in a Debian chroot) sometimes causes oom killer (with a utf-8 locale) even when no other apps are running in the chroot (OK, I think ssh may still have been listening with no active connections, but nothing else). Doing `echo 100 /proc/sys/vm/swappiness' is enough to let it complete instead of being terminated with out of memory error in dmesg. I haven't tested other values. It's tempting to do that in the locales postinst, though there are some issues to do with restoring the value that make me at least hesitate to do that. Currently this bug discussion doesn't mention the workaround of installing locales-all, so I'll do so here: install locales-all instead of locales if you have limited memory but don't mind an extra 70-80MiB of space used in /usr. I gather that people have been looking at the question of the right way of distributing locale-specific data (mainly meaning translations). How to distribute finer-grained pre-built locales-* packages may be amenable to the same solutions (whatever they are). A problem with the locales-all solution is that systems with little memory often also have little disk space. Is it worthwhile distributing a locales-en-us-utf8 package containing a single prebuilt utf-8 locale, for embedded use? I don't know if http://www.emdebian.org/locale/ is related. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500649: ttf-arphic-bkai00mp: Depends on xutils
Package: ttf-arphic-bkai00mp Version: 2.10-6.1 Severity: wishlist [This also applies to ttf-arphic-bsmi00lp, ttf-arphic-gbsn00lp and ttf-arphic-gkai00mp, but they share the same maintainer, so I'm filing just one bug (on the asciibetically first package name) for convenience. There are also three font packages not maintained by Anthony Fok that Depend on xutils; for the moment I won't file bugs on those packages, in the hope of first learning more about the bug from this bug report.] Various font packages Depend on xutils, and I was going to file a wishlist bug asking to switch to a more specific package (perhaps with `| xutils') now that xutils has been split into smaller packages; but looking at the contents of ttf-arphic-bkai00mp and some of the other packages (including at least one of the packages not maintained by Anthony Fok), I can't actually see why xutils is a dependency. The control scripts use defoma (which is already separately in the Depends list), and no other non-essential/base package. There are no other scripts in the packages I've looked at. I haven't yet tried forcing a purge of xutils and its dependencies and checking whether I can still install and use these fonts. I note that x-ttcidfont-conf (Suggest'ed by ttf-arphic-bkai00mp) Depends on xfonts-utils (for mkfontdir); I don't know if this is related. Another clue is that the font packages that Depend on xutils are all non-Roman fonts: Chinese, Japanese, Mongolian Cyrillic, and APL. Do you remember why xutils is in the Depends list? Can it be simply removed? Are the other three fonts (ttf-arhangai, ttf-mona, xfonts-kapl) likely to be the same? pjrm. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ttf-arphic-bkai00mp depends on: ii defoma 0.11.10-0.2 Debian Font Manager -- automatic f ii xutils 1:7.3+16X Window System utility programs m ttf-arphic-bkai00mp recommends no packages. Versions of packages ttf-arphic-bkai00mp suggests: pn tfm-arphic-bkai00mp none (no description available) ii x-ttcidfont-conf 29 TrueType and CID fonts configurati ii xfs 1:1.0.8-2 X font server -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499483: mouseemu: newer upstream available; please re-sync
Package: mouseemu
Version: 0.15-8
Severity: normal
[Re severity: newer upstream is very minor severity because
the only thing it adds beyond Debian's 0.15-5 is a new upstream URL
and maintainer. The please resync part is severity normal on the
unverified assumption that the remaining diffs haven't yet been sent
upstream as per Debian policy §4.3 or item 2 of the social contract.]
There is a newer upstream version available, 0.16.
My local Debian mirror doesn't have 0.15-5.diff.gz, but based on
0.15-6.diff.gz and debian/changelog, it looks like 0.16 is equal to
Debian's 0.15-5 except for noting a new maintainer and new canonical
download location.
On the subject of resyncing with upstream:
write_error.dpatch doesn't look right to me: if the
`if (write(fd, buf, n) n)' test was previously succeeding in such a
way that `... = 0' (the version introduced by write_error.dpatch)
wouldn't succeed (i.e. if write_error.dpatch actually makes a difference
to execution), then I believe the right thing to do is to loop until all
of buf has been written: i.e. introduce a function such as (untested):
static ssize_t write_all(int fd, void const *buf, size_t count)
{
while (count) {
ssize_t w = write(fd, buf, count);
if (w 0) {
if (errno == EINTR)
continue;
return -1;
}
count -= w;
buf = (void const *)((char const *)buf + w);
}
return 0;
}
and use `if (write_all(fd, event, sizeof(event)) 0) perror(...);'.
(If OTOH write_error.dpatch is believed not to make a difference to
execution, then I still think it is wrong: if in fact it turns out that
there is a difference, then we want the perror to execute, to alert us
to the fact that there is in fact a difference, in which case the
write_all suggestion applies.)
pjrm.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443232: fixed in 1.0.9
This appears to be fixed in v1.0.9 (or earlier), which is already in testing. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483791: FreeSans: Pango-WARNING **: Error loading GPOS table 5503
Package: ttf-freefont Version: 20080323-3 Severity: normal I noticed that gucharmap was giving an Error loading GPOS table message on stderr, so I googled for that error, and apparently it's when pango believes that a font has an error. Note that in one case in the past, it turned out that pango needed to be modified to change its test. You may wish to discuss this error with the harfbuzz developers. Here's an end-user-visible way of reproducing: Start gedit from a terminal (so you can see its stderr). EditPreferencesFont Colors Click the Editor Font button Click in the Family list Use down arrow until you get to FreeSans Note that nothing is produced on stderr until you get to the FreeSans item, at which point the following is produced on stderr: (gedit:27436): Pango-WARNING **: Error loading GPOS table 5503 (You could then try exiting gedit, starting it again, and this time selecting the font family after FreeSans in the list, and use down-arrow key to iterate over all remaining fonts, and note that no other font family produces an error. At least, no other font family installed on my system produces an error.) A more useful way of reproducing is with the test program included in pango: apt-get install libpango1.0-dev apt-get source pango1.0 # I usually use apt-get source -d with separate dpkg-source -x -sn # step so that I can extract it as a non-root user. cd pango1.0-1.20.2/pango/opentype gcc -g -Wall `pkg-config --cflags pangoft2` -o harfbuzz-dump \ harfbuzz-dump-main.c harfbuzz-dump.c harfbuzz-gpos.c harfbuzz-gsub.c \ harfbuzz-buffer.c harfbuzz-gdef.c harfbuzz-open.c harfbuzz-stream.c \ harfbuzz-impl.c `pkg-config --libs pangoft2` # `make harfbuzz-dump' after configuring with `--disable-shared' and # `CFLAGS=-g' would probably work too. # At this point one might like to check whether FreeSans.ttf is the only # font on the system that gives an error: for i in $(find /usr/share/fonts/truetype -type f); do ./harfbuzz-dump $i 21 | grep -i 'error' printf '%s\n\n' $i ;done # Or just go straight to FreeSans.ttf: ./harfbuzz-dump /usr/share/fonts/truetype/freefont/FreeSans.ttf /dev/null After some search from within gdb, I get to the following point where the error in question is produced: Load_Anchor (an=0x807b540, stream=0x8070398) at harfbuzz-gpos.c:566 (gdb) n (gdb) (gdb) (gdb) p an-PosFormat $27 = 56 (gdb) bt #0 Load_Anchor (an=0x807b540, stream=0x8070398) at harfbuzz-gpos.c:573 #1 0x08051724 in Load_Mark2Array (m2a=0x80757a0, num_classes=2, stream=0x8070398) at harfbuzz-gpos.c:2803 #2 0x08051c94 in Load_MarkMarkPos (st=0x8075778, stream=0x8070398) at harfbuzz-gpos.c:2927 #3 0x08058559 in _HB_GPOS_Load_SubTable (st=0x8075778, stream=0x8070398, lookup_type=6) at harfbuzz-gpos.c:5878 #4 0x08066112 in Load_SubTable (st=0x8075778, stream=0x8070398, table_type=HB_Type_GPOS, lookup_type=6) at harfbuzz-open.c:458 #5 0x080664de in Load_Lookup (l=0x807b3b0, stream=0x8070398, type=HB_Type_GPOS) at harfbuzz-open.c:536 #6 0x080667d9 in _HB_OPEN_Load_LookupList (ll=0x8074ba4, stream=0x8070398, type=HB_Type_GPOS) at harfbuzz-open.c:618 #7 0x0804bb98 in HB_Load_GPOS_Table (font=0x80703c8, retptr=0xbf8ef070, gdef=0x0) at harfbuzz-gpos.c:141 #8 0x08048a1a in main (argc=2, argv=0xbf8ef124) at harfbuzz-dump-main.c:211 (gdb) (To get to this point, do b Load_Mark2Array, and do `n' (next) until the second iteration of the `for n' loop, i.e. where n = 1.) pjrm. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ttf-freefont depends on: ii defoma 0.11.10-0.2 Debian Font Manager -- automatic f Versions of packages ttf-freefont recommends: ii x-ttcidfont-conf 27 TrueType and CID fonts configurati -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474637: could Depends: console-tools | uswsusp
My understanding, based solely on the existing messages in this bug report, is that console-tools is redundant if uswsusp is installed, but that behaviour is wrong if neither console-tools nor uswsusp is present. If so, then I suggest either Depends: console-tools | uswsusp or Depends: uswsusp | console-tools pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466292: Suggested changes to documentation
The initial m is mandatory in Single Unix Spec too, to judge from
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html .
I don't know whether or not {,n} was allowed by earlier versions of GNU
grep [update: see below], but I would guess that it's deliberately not
allowed by current GNU grep, to promote portability among other POSIX
regular expression implementations.
Thus, I suggest simply removing mention of {,n} from the documentation,
and noting in the documentation of {m,n} that m is not optional.
OK, I've just checked the changelog: the 1999-10-02 entry mentions
Remove (broken) support for {,M} meaning {0,M}. The NEWS entry for
v2.4 correspondingly says:
- The lower bound of an interval is not optional.
You must use an explicit zero, e.g. `x{0,10}' instead of `x{,10}'.
(The old documentation incorrectly claimed that it was optional.)
It's still a little unclear to me from those descriptions how `x{,n}'
was handled in earlier versions, but even if it did previously handle
`x{,n}' as equivalent to `x{0,n}', I'd still be inclined not to mention
this historical detail in the current man page.
Another couple of notes now that I've looked at that Single Unix Spec
page:
The paragraph mentioning \, \, \b, \B, \w and \W might add `These are
GNU extensions; the behaviour of these sequences is explicitly
unspecified by the Single Unix specification of regular expressions.' or
simply `(These are GNU extensions.)'.
I also note that the current man page doesn't mention collating symbol
expressions (`[.ch.]' inside a bracket expression) or equivalence class
expressions (`[=C=]' inside a bracket expression). I haven't checked
whether either of these are implemented, but I think they should be
mentioned whether they are implemented (even if only with a request for
documentation to be added) or unimplemented (Note: ... are not yet
implemented) or implementation status is unknown (Note: The Single
Unix specification of ... mentions ..., but the author of this man page
is unaware of their implementation status in GNU grep. Please consider
[sending such documentation to the appropriate place].).
pjrm.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475341: documentation of `install'/`remove'; suggested replacement text
Package: apt Version: 0.7.11 Severity: minor [A related bug is #462962 `apt-get --no-install-recommends is not documented in man page'.] The fact that apt-get now automatically installs packages that are merely recommended isn't documented, and the existing documentation for `apt-get install' is misleading. install is followed by one or more packages desired for installation. [...] All packages required by the package(s) specified for installation will also be retrieved and installed. I interpret `required by the package(s)' as referring only to Depends, not Recommends. As it explicitly mentions installation of not only the specified packages but also their requirements, I take this to be the complete set of packages that are installed by this command, not merely a subset. (One could argue whether or not this is the best interpretation, but nevertheless it is the interpretation that I made of the documentation, and I'm a native english speaker, and I suppose that many people will have this erroneous interpretation. It would be good to avoid having people come to the wrong impression about the behaviour if we can.) It should be explicitly specified what the behaviour of `apt-get install foo.*-' is, i.e. whether the trailing hyphen-minus is considered part of the regular expression or a request to remove any packages matching the specified regular expression. The current documentation is unclear about this: it says that `install' is followed by one or more packages..., and that a hyphen may be appended to a `package name', but then describes how the given expression may be interpreted as a regexp. There is no definition of what expression means here (e.g. whether it includes any specified plus/minus/slash/equals suffix), and it is unclear whether such suffixes may be used with regular expressions. The documentation that clarifies the meaning of `foo.*-' should in particular draw attention to the meaning/legality of `foo.\+'. The current documentation says `followed by one or more packages'; i.e. the current documentation doesn't document the command `apt-get install' (with no following package names). The current documentation says `is followed by one or more packages desired for installation', making it unclear whether `apt-get install foo-' is legal (or alternatively what its behaviour is, i.e. whether desired for installation trumps the description of the hyphen suffix). Less importantly, it might be good to draw attention to the behaviour for alternates (`|') and virtual package names. Or at least somehow draw attention to the fact that there may be other solutions besides what apt-get suggests. I suggest the following text; though note that I haven't checked the behaviour for some of the issues raised above, so the below text may be incorrect. install REQUEST... Installs or uninstalls packages according to the specified requests. Each REQUEST consists of a package name specification, optionally immediately followed (with no intervening space) by a suffix (see below). In the usual case, REQUEST consists solely of a package name, and represents a request to install or upgrade the package of the given name. More generally, the package name specification is first interpreted as a package name. If no package of the specified name is found[*1], and the given specification contains any of the characters `.', `?' or `*' [fixme: what about `[' or `\' ? The reason to include `\' is for `\+'. Note that if `\' is mentioned then we should probably retract the test for `?'.], then it is interpreted as a POSIX basic regular expression, and refers to the set of package names in the database[*2] that match this regular expression. Note that matching is done by substring so `lo.*' matches `how-lo' and `lowest'. If this is undesired, anchor the regular expression with a `^' or `$' character, or create a more specific regular expression. [fixme: Document the behaviour if no package names match this regexp, i.e. whether it's silently treated as an empty set or whether it's considered an error.] [*1 fixme: What exactly does no matching package is found mean? E.g. if the user requests to remove foo.bar and no foo.bar package is installed but the package list does include a foo.bar package, then does that count as found or not found? What if /var/lib/dpkg/status includes a foo.bar package but its status is config-files or purged? What if it's unremovable for some other reason such as being Required or Essential?] [*2 fixme: Similarly, define what the database means, i.e. whether it includes /var/lib/dpkg/info, whether it includes lists of available packages, and whether this is affected by whether the package is requested for installation or removal.] [fixme: Specify that the regular expression may not contain
Bug#459166: fix (brace expansion) [patch]
I was surprised to find that brace expansion isn't in Single Unix Spec
(http://www.opengroup.org/onlinepubs/007908799/xcu/shellix.html);
a google search for brace expansion suggests that the feature is
specific to bash and zsh.
I attach a patch. (Only debian/rules is affected.)
I've checked that the new package builds (with /bin/sh linked to dash)
and that the resulting wacom-tools binary doesn't contain the three
files /usr/lib/libwacomcfg.{a,la,so}. No other testing done.
Perhaps lintian should use checkbashisms.
pjrm.
diff -dur wacom-tools-0.7.9.3/debian/rules
wacom-tools-0.7.9.3-fixbashism/debian/rules
--- wacom-tools-0.7.9.3/debian/rules2008-02-05 09:50:57.0 +1100
+++ wacom-tools-0.7.9.3-fixbashism/debian/rules 2008-02-05 09:53:12.0
+1100
@@ -263,7 +263,9 @@
# Remove these for the moment, they belong in
# a -dev package but nothing needs it yet.
$(RM) -r debian/$(package_tools)/usr/include
- $(RM) -r debian/$(package_tools)/usr/lib/libwacomcfg.{a,la,so}
+ $(RM) debian/$(package_tools)/usr/lib/libwacomcfg.a \
+ debian/$(package_tools)/usr/lib/libwacomcfg.la\
+ debian/$(package_tools)/usr/lib/libwacomcfg.so
# Remove this too, it belongs in $package_xorg
$(RM) -r debian/$(package_tools)/usr/share/man/man4
Bug#455613: fix for not detecting build errors [patch]
Add ‘set -e; ’ to the definition of DOSUBDIRS in the top-level makefile. pjrm. diff -dur exmap-0.10/Makefile exmap-0.10-pjrm/Makefile --- exmap-0.10/Makefile 2006-09-29 02:52:25.0 +1000 +++ exmap-0.10-pjrm/Makefile2008-01-29 05:03:07.0 +1100 @@ -8,7 +8,7 @@ .PHONY: build clean test $(SUBDIRS) -DOSUBDIRS=for dir in $(SUBDIRS); do \ +DOSUBDIRS=set -e; for dir in $(SUBDIRS); do \ $(MAKE) -C $$dir $@; \ done
Bug#461492: doc-debian: Debian FAQ §11.6: init.d scripts
Package: doc-debian Version: 3.1.5 Severity: wishlist Tags: patch In §11.6 ‘It looks as if Debian does not use rc.local to customize the boot process; what facilities are provided?’, the two sentences Scripts beginning with 'S' in /etc/rcN.d/ are executed when runlevel N is entered. Scripts beginning with a 'K' are executed when leaving runlevel N. imply that /etc/rcN.d/K* scripts are run when leaving runlevel N, whereas the previous subsection (§11.5) implies that /etc/rcN.d/K* scripts are run when entering runlevel N (before running the /etc/rcN.d/S* scripts). I believe §11.5 is correct and §11.6 is incorrect. (See /etc/init.d/rc and description of Default-Stop at http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html.) I suggest changing to: When entering runlevel N, first /etc/rcN.d/K* scripts are run with an argument of ‘stop’ to kill the services corresponding with those K* scripts, and then /etc/rcN.d/S* scripts are run with an argument of ‘start’ to start the services corresponding to those S* scripts. Now that I look at the section, I notice a few other changes that might be made: - Rebooting the system is a bit heavy-handed. I suggest changing the Reboot the system bullet point to: Consider rebooting the system to check that the service starts correctly (assuming that you've asked for it to be started in the default runlevel). Otherwise, manually start it by running /etc/init.d/foo start - I suggest changing the description of the `19' argument to change containing to whose number is, and explicitly mentioning the corollary about numbers less than 19, and adding have completed as we do so to clarify what we mean by called before 19 scripts are started: after all scripts whose number is less than 19 have completed, and before all scripts whose number is greater than 19. - The argument ‘defaults’ does not mean simply to start the service in runlevels 2 through 5; rather, it means (in sysv-rc) to use the start/stop runlevels specified in the LSB comments, starting the service in runlevels 2 through 5 if no Default-Start is specified, and stopping the service in runlevels 0,1,6 if no Default-Stop is specified. file-rc's update-rc.d, OTOH, doesn't parse the LSB comments (at least in version 0.8.10), so the argument ‘defaults’ simply means to start the service in runlevels 2 through 5 *and* to stop the service in runlevels 0,1,6. - The details about symlinks in /etc/rc?.d directories are specific to sysv-rc, and are wrong for file-rc. It would be nice to start with generic text about the script being started or stopped in various runlevels, and then (optionally) at the end of the section have details as they apply to sysv-rc. Thus, the existing to set up links between the (command-line-specified) directories rc?.d and /etc/init.d/foo. Here, '?' is a number from 0 through 6 and corresponds to each of the System V runlevels. would become to specify which runlevels should start the service, and which runlevels should stop the service. Then move the foo example paragraph to just after the list (i.e. before any coverage of sysv-rc details). The foo paragraph would change ‘installing the links with’ to simply ‘running’. I'm inclined to drop the details about sysv-rc altogether: that's for the sysv-rc package to describe, or for a separate question: indeed, the previous question already pretty much covers it. I attach a patch to make these changes (choosing to drop the sysv-rc details from this question rather than making the S/K changes that I described at the beginning of this message). Note that the patch introduces UTF-8 single-quote characters (‘ ’), I hope that's OK; otherwise s/‘/lsquo;/g;s/’/rsquo;/g. pjrm. diff -dur doc-debian-3.1.5/FAQ/customizing.sgml doc-debian-3.1.5-pjrm/FAQ/customizing.sgml --- doc-debian-3.1.5/FAQ/customizing.sgml 2007-01-17 20:17:16.0 +1100 +++ doc-debian-3.1.5-pjrm/FAQ/customizing.sgml 2008-01-19 10:49:33.0 +1100 @@ -102,25 +102,26 @@ list itemEnter the script ttfoo/tt into the directory tt/etc/init.d//tt. itemRun the Debian command ttupdate-rc.d/tt with appropriate - arguments, to set up links between the (command-line-specified) directories - rc?.d and tt/etc/init.d/foo/tt. Here, '?' is a number from 0 through 6 - and corresponds to each of the System V runlevels. - itemReboot the system. + arguments, to specify which runlevels should start the service, and which + runlevels should stop the service. + itemConsider rebooting the system to check that the service starts + correctly (assuming that you've asked for it to be started in the + default runlevel). Otherwise, manually start it by running + ‘tt/etc/init.d/foo start/tt’. /list -pThe command
Bug#454097: gdm sourcing .profile, and using `alias' in .profile
[In the subject-line and presumably also in the quoted text, ‘.profile’ is shorthand for ‘/etc/profile then ~/.profile then /etc/xprofile and then ~/.xprofile’.] Is there any good reason for gdm's Xsession to source ~/.profile? It is very contrary to the principle of least surprise: nothing else other than a login shell sources ~/.profile. gdm provides login, and effectively acts as a (graphical) login shell. In particular, I believe it's the only way that one's preferred environment variable settings take effect in X. The primary bug here is aliasing ls to give non-standard behaviour in non-interactive contexts. Anything in startup scripts that makes standard commands behave contrary to standard behaviour (i.e. contrary to the behaviour expected by scripts) should be conditional on being in an interactive context, which in Bourne-like shells is typically done like so: if [ -n $PS1 ]; then alias ls='ls --color=auto' set -P ... fi (Furthermore, one would generally want to put this in ~/.bashrc rather than ~/.profile, so that it's available even in non-login interactive shells such as launched by xterm or text editors or the like. Then one would usually make sure that one's ~/.bash_profile contains if [ -f ~/.bashrc ]; then . ~/.bashrc fi (which /etc/skel/.bash_profile and a new user's default ~/.bash_profile already do). ~/.bashrc and ~/.bash_profile are specific to bash; to get the approach to work for any POSIX shell, have .profile export ENV=$HOME/my-shell-init and use ~/my-shell-init instead of ~/.bashrc. Indeed, one could have ~/.bashrc source ~/my-shell-init, or even export ENV=$HOME/.bashrc so long as it will never contain bashisms.) And [gdm's sourcing of .profile] seems to create a lot of hard-to-debug login problems. What are examples of such problems that are likely to occur ? Is it feasible for some task (possibly /etc/gdm/Xsession) to detect the most common problems and warn about them ? pjrm.
Bug#360610: various comments
I don't propose a solution, but here are some things I think relevant to the discussion: - For the one application that I ever run in wine, installing msttcorefonts made the difference between whether that application was usable under wine or not: without msttcorefonts, most text fields just didn't show up, making the application impossible to use. If that were true of every application (a premise I suppose to be false, but I wouldn't know), and if there's no other package that can be installed to get text to show up, then Recommends or even Depends really would be appropriate, even if that meant that wine belongs in contrib: under these premises, it really would practically depend on non-free components. - If, rather, there's no other package that can be installed to get text to show up, but it affects only *most* applications, then Suggests may well be sufficient: the question is only whether enough DFSG software can be run without installing msttcorefonts that it's worthwhile having wine in the archive; how much software it can't run is irrelevant. The package description may well need to be changed accordingly, making it clear that this package only enables running this small set of software, not windows software generally. - Regarding the statement ‘Not all policy violations are serious bugs.’, some relevant Debian policy excerpts: Packages that do not conform to the guidelines denoted by _must_ (or _required_) will generally not be considered acceptable for the Debian distribution. ... These classifications are roughly equivalent to the bug severities _serious_ (for _must_ or _required_ directive violations), [other correspondances elided]. (The policy directive that this bug violates, cited above, uses `must'.) The most relevant excerpt from the http://release.debian.org/etch_rc_policy.txt file that's already been mentioned is that Recommends: lines do not count as requirements. (in the context of non-free dependencies). Of course, this file is specific to the etch release, and was cited prior to the etch release. The relevant excerpt from the http://release.debian.org/lenny-goals.txt file that's been mentioned is: * No unmet recommends relations inside main Advocate: Luk Claes Description: Packages in main should be able to satisfy all recommend relations in main. Bug-Tag: recommends State: confirmed OTOH, the file itself only describes these as goals, and doesn't explicitly say that all such bugs should be marked as severity Serious or higher. Do we have any other information as to whether such bugs should be marked as Serious or whether it suffices to have the specified Bug-Tag ? - The deduction Since Wine is all about emulating a non-free OS, it makes sense to recommend something that's an integral part of that OS, its fonts; undoubtedly, many applications Wine is trying to run will assume they're there. does not follow. Linux and the Gnu tools are all about emulating the proprietary Unix OS, but that doesn't mean that they should recommend non-free components, even components that one might consider as core to Unix as Windows' fonts are to Windows, and even if that means that many Unix applications won't run on Linux/Gnu platform. What's important is is what software does run, not what software doesn't run. - If the proposition Anyone willing to run Wine in the first place is unlikely to be against installing anything from contrib or the stronger proposition everyone who runs wine is as willing to install anything from contrib as they are software from main were true, then it may well support putting wine in contrib, but it wouldn't be sufficient to support allowing wine in main to recommend or depend on software in contrib or non-free. That would require propositions about the definition or purpose of the main/contrib distinction. As for whether the above propositions are true, it is relevant to note that wine isn't exlusively for running non-Free software, just as computers generally aren't exclusively for running non-Free software, even if the majority of software or the majority of Windows software were non-Free. A search on sourceforge reveals a number of Free software packages that are written against the Windows API. - Unfortunately there appears not to have been any news re the liberation fonts. Does anyone know how to allow software to be usable without installing either msttcorefonts or the liberation fonts, such as by using the ttf-freefont and ttf-bitstream-vera packages already mentioned (or ttf-dejavu) ? pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of
Bug#447690: MathML output not honoured by iceweasel
retitle 447690 MathML output problems with iceweasel severity 447690 wishlist quit (If I'm correct that konqueror doesn't support MathML, then I'll keep konqueror out of the bug title. I originally mentioned konqueror just because it's an example of a major browser in Debian that doesn't display tex4ht's MathML; it was irrelevant in that context whether the reason lies in konqueror code or tex4ht code.) Regarding the new bug title MathML output problems with iceweasel[/konqueror] I'll accept this as mainly user error (my use of htlatex filename xhtml,mathml instead of e.g. mk4ht mzlatex filename html,mathplayer .) The only remaining part of the bug would be a wishlist bug for htlatex filename.tex xhtml,mathml to nevertheless name its output as filename.xht (or filename.xhtml) instead of the filename.html that it currently uses: clearly the user at least requested xhtml and mathml output, even if they didn't use one of the commands recommended in the online HTML documentation, so it would be nice if this command would either abort with an error message or run but name its output as filename.xht (or filename.xhtml) so that it's more likely to be understood as an xhtml/mathml file than the filename.html that it currently produces. I'll create a new bug report to continue the discussion of \email handling to reduce the mixing of unrelated issues in one bug number. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447690: tex4ht: Should Recommends: dvipng
Package: tex4ht Version: 20070717-2 Severity: normal (Presumably version 20070904-1 has the same issue: at least, it doesn't Recommends or Suggests dvipng, and I'd guess that its use of dvipng is essentially unchanged, but haven't tested.) After ‘apt-get install tex4ht’ and reading through the manual, I run htlatex foo.tex, only to find that tex4ht's default installation/settings produces an HTML file with references to non-existent .png files if dvipng isn't installed. I've since discovered that dvipng is mentioned in tex4ht's Description field, but it doesn't explicitly say that using dvipng requires installing a separate package, and in any case apt-get doesn't parse the Description field. So tex4ht should have dvipng in its Suggests or Recommends fields. Excerpt from debian-policy for your convenience of deciding between the two: `Recommends' This declares a strong, but not absolute, dependency. The `Recommends' field should list packages that would be found together with this one in all but unusual installations. `Suggests' This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable. I suggest that Recommends is the appropriate choice, though this may depend on what proportion of installations of tex4ht you expect to involve calls to dvipng. E.g. if you think that many people never process documents containing mathematical equations, or if you change the default to use mathml rather than dvipng, then you might use Suggests rather than Recommends. (TeX/LaTeX/tex4ht's handling of equations is often cited among the 1-3 main reasons for using them, so I would guess that most users of / documents intended for tex4ht would use equations. Tex4ht's MathML output doesn't come out right for me in either iceweasel or konqueror, which makes me think that all but unusual tex4ht users will continue to use the default of using bitmaps and in particular dvipng for the moment. So it appears to me that Recommends is the right choice.) pjrm. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tex4ht depends on: ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries ii libkpathsea4 2007-14TeX Live: path search library for ii tetex-bin 2007-12TeX Live: teTeX transitional packa ii tex4ht-common 20070717-2 LaTeX and TeX for Hypertext (HTML) ii texlive-base-bin 2007-14TeX Live: Essential binaries tex4ht recommends no packages. -- no debconf information
Bug#447690: MathML Re: Bug#447690: tex4ht: Should Recommends: dvipng
On Tue, Oct 23, 2007 at 08:41:25PM -0400, Eitan Gurari wrote:
Tex4ht's MathML output doesn't come out right for me in either
iceweasel or konqueror
Any concrete example of what is going wrong there, unless the problem
is with the browsers.
(This is off-topic for a bug entitled `Should Recommends: dvipng';
we should consider creating a new bug to help other people looking for
information on the topic of MathML.)
It appears that konqueror doesn't support MathML, in which case nothing
in tex4ht's mathml output can help there.
If I copy just a math element from tex4ht's output into a separate
file and run mathmlsvg (from libgtkmathview-bin package) on that file,
then the output looks correct, whereas that same equation in iceweasel
isn't coming up for me. So there's at least one piece of software that
can read the mathml element itself.
It looks as if iceweasel just isn't recognizing it as mathml for some
reason; or rather (a lesser claim) there's no evidence in the rendering
that it's even trying to render it as mathml.
The http://www.mozilla.org/projects/mathml/start.xhtml page comes up
very badly for me (lots of hex squares, black regions and wrong glyphs,
much of which is presumably just because I'm missing at least one font),
but it does at least look like it's trying to render as mathml.
So I suppose the trick is to look at differences between tex4ht's output
and that page, paying particular attention to doctype etc. bits and xmlns
use and so on.
If I copy the same math element from tex4ht into the start.xhtml
document, then iceweasel displays it much like the rest of the page:
it's all in gobbledigook glyphs, but at least it's evidently recognizing
it as mathml.
OK, the following two changes are enough for iceweasel to render
tex4ht's output in the same gobbledigook as its start.xhtml page
[that may well appear correctly to someone with the right fonts]:
- Change the file name from .html to .xhtml. (Btw, I passed options
xhtml,mathml as the second argument to htlatex.)
- Fix tex4ht's invalid output for the \email command for the .tex file
in question. The \email command in question is:
\email{\{Kim.Marriott, Peter.Moulder, [EMAIL PROTECTED]
It's understandable for tex4ht not to produce a valid mailto URL
from this brace notation, but it really is a bug that tex4ht's
output for this isn't even valid html/xhtml:
a
href=mailto:\protect \T1\textbraceleft Kim.Marriott,
Peter.Moulder, Nathan.Hurst\protect \T1\textbraceright
@infotech.monash.edu.au
Note that those last two lines are outside of the href attribute
(see the ‘’ at the end of line 2, where the first space in the
\email argument appears).
This bug makes me wonder how many other constructs can result in
invalid html/xhtml. A good way of avoiding this when writing a new
application is for each command handler to produce not raw
supposed-html but rather an intermediate format like a libxml tree.
Whether it's worth applying this to an already-existing program
instead of fixing bugs one by one as they're reported is another
matter :) .
pjrm.
Bug#447690: More on \email problem
[Note: I started writing this e-mail message before receiving your reply
you sent privately, and this email message doesn't address the comments
in your reply.]
Having downloaded tex4ht source, I see that \email magic is handled in
part by \Link[mailto:#1]{}{}.
In my previous message, I wrote that the closing ‘’ appears where the
first space is. Seeing that ‘#1’ usage makes me wonder whether a more
accurate characterization would be ‘after the first comma’ rather than
‘where the first space is’; but I've just now tried removing the spaces
and retaining commas, and in that case it produces correct HTML (with
still invalid mailto URI of course):
a
href=mailto:\protect \T1\textbraceleft
Kim.Marriott,Peter.Moulder,Nathan.Hurst\protect \T1\textbraceright
@infotech.monash.edu.au
So ‘where the first space is’ does seem to be the correct
characterization.
If instead I wrap the \email argument in a pair of braces while
retaining the spaces after the commas:
\email{{\{Kim.Marriott, Peter.Moulder, [EMAIL PROTECTED]
then again we get correct HTML (with invalid mailto URI):
a
href=mailto:{\protect \T1\textbraceleft Kim.Marriott, Peter.Moulder,
Nathan.Hurst\protect \T1\textbraceright @infotech.monash.edu.au}
My LaTeX skills are not good enough to know how tex4ht should be changed to,
say, give an error for the original construct (that lacked the protective brace
wrapping) let alone to behave the same as with the extra braces. (The latter
would be nice given that a standard pdflatex run on the file appears to produce
correct results without the extra brace wrapping; but aborting with an error
message would also be reasonable behaviour.)
The other half of the \email problem is that the produced mailto URIs
have insufficient quoting. According to the relevant RFC
(http://tools.ietf.org/html/rfc2368):
all URL reserved characters in [the destination part of the URL] must
be encoded: in particular, parentheses, commas, and the percent sign
(%), which commonly occur in the mailbox syntax.
and gives the example of mailto:addr1%2C%20addr2 to represent a
destination of addr1, addr2.
See §2.2 of RFC1738 (http://tools.ietf.org/html/rfc1738) for URL
reserved characters. Note, however, that its second-last paragraph
isn't an entirely accurate summary of the rest of the section; in
particular, it's not necessary to escape [EMAIL PROTECTED] One might also note
that
RFC1738 says it's always safe to leave ASCII comma unencoded, despite
its encoding in the example I cited above (previous paragraph).
pjrm.
Bug#231116: how to implement without changing gdb
I too dislike the idea of gdb unconditionally setting a particular environment variable. My first suggestion is that if you want to do this, then do alias gdb='IN_GDB=yes gdb' Note that both with this implementation and the implementation proposed by the submitter, it only works for processes initiated by gdb, not when one uses gdb to attach to an existing process. I suggest that the program test this variable only on startup, and set a variable, and subsequently test that variable rather than call getenv. This isn't just about efficiency, this is to cover the attach case: when attaching to a program, you can do p in_gdb = 1 and then p in_gdb = 0 when detaching. See section ‘User-defined command hooks’ in the gdb manual (http://www.delorie.com/gnu/docs/gdb/gdb_190.html) for how to have these happen automatically every time you attach or detach the program. (See also section ‘Command files’ for description of .gdbinit processing, and section ‘User-defined commands’ for the general syntax for defining functions in gdb. If you implement this, then I suggest posting the resulting .gdbinit file/fragment to this bug report for the benefit of anyone else looking at this bug report and wanting to do the same thing.) Finally, if you really want to test for being debugged without help from .gdbinit files or any other user help, man ptrace and see what it says about how gdb becomes effectively the parent for many purposes. If using Linux, then man 5 proc and look at the descriptions of the stat and status files. However, I don't recommend this: it's harder to implement than .gdbinit files, and it probably only serves to mystify the person using the debugger rather than help them. I suggest closing this bug. pjrm.
Bug#297551: yes, bug still exists
[Sorry if this reply should have been sent to -quiet, the triaging
message didn't specify where to reply.]
The bug still exists, the only difference being that the assertion is
now on line 4187 instead of 4003 of rcs.c.
I haven't checked that the patch still applies [with an offset of
4187-4003=184 lines] and fixes the bug, though a look at the patch
without looking at the new source file suggests that it should still fix
the bug.
For your convenience, I'll reformat those shell commands as a shell
script (appended).
pjrm.
#! /bin/sh
set -ex
mkdir /tmp/frog
cvs -d /tmp/frog init
mkdir /tmp/bull
cd /tmp/bull
cvs -d /tmp/frog import -m '' hello acme empty
cvs -d /tmp/frog co hello
cd hello
(echo '#include stdio.h';echo 'int main(void) { printf(hi\n); }') hello.c
cvs add -ko hello.c
cvs commit -m new hello.c
rm hello.c ;cvs rm hello.c
cvs diff -r BASE -r HEAD hello.c
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415640: now fixed upstream
I've committed a fix for this upstream (r15167 of SVN). Though this won't help until we package a newer version of inkscape (say 0.46) for Debian. Some alternatives if we want to address this bug for Debian earlier: - Apply the patch to 0.45.1 in Debian. - Change libgnomevfs' approach to getting its home dir: either: - Change libgnomevfs to check $HOME before calling g_get_home_dir. - Change libglib2.0 implementation of g_get_home_dir to give priority to $HOME like it did in previous versions. This carries the risk of breaking other things, but OTOH it can act as a test for how safe it is for upstream to use this behaviour. Should drop a note to http://bugzilla.gnome.org/show_bug.cgi?id=142568 if taking this option. - Make libglib2.0 give priority to $HOME but only on buildd's. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326273: Upstream bug reference
http://bugzilla.gnome.org/show_bug.cgi?id=142568 discusses the issue of how g_get_home_dir should behave. If anyone following #326273 questions whether g_get_home_dir is doing the right thing, or think its documentation should be changed, then read the discussion there and then consider adding to the discussion. (I disagree with g_get_home_dir's current behaviour, so I'd like either for people to add weight to my request to change it, or to help me understand why the current behaviour is correct.) pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415640: gnome_vfs_init is failing
I've just run under gdb, with /etc/passwd giving a non-existent home dir. The first warning about not being able to create ~/.gnome2 comes from within gnome_vfs_init(). The `hash_table != NULL' assertion failure comes from within gnome_vfs_transform_get(file). Ah, I see that gnome_vfs_init returns a boolean indicating success or not, which Inkscape is ignoring. It would be nice if gnome_vfs_init documentation were explicit in saying that one shouldn't call other gnome_vfs functions if it returns false. (E.g. copy from gnome_vfs_initialized documentation.) I suggest that the fix is to search Inkscape source for use of gnome-vfs, and make them all conditional on gnome_vfs_initialized() (falling back to the corresponding !WITH_GNOME_VFS behaviour if not initialized). See also http://bugzilla.gnome.org/show_bug.cgi?id=340234, requesting that gnome-vfs not require $HOME to be writable (or rather not requiring ~/.gnome2 to exist or something). As for whether Inkscape should test $HOME before calling g_get_home_dir, that's (in effect) being discussed at http://bugzilla.gnome.org/show_bug.cgi?id=142568 (discussing the desired behaviour/documentation for g_get_home_dir). It has been suggested in that discussion that ignoring $HOME is a good thing; so I suggest waiting a bit to see how that discussion develops before changing inkscape to prefer $HOME over g_get_home_dir. (FWIW, my current opinion is that we should prefer $HOME over getpwent, but I'll see what further evidence gets posted to that discussion.) pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427946: No, can't use libcroco 0.6.1
libcroco-0.6.1 is not suitable for use in inkscape; the src/libcroco directory has some modifications as explained in src/libcroco/README. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424038: reason for compiler name in library names
I haven't read the libboost documentation, but I speculate that the
reason that the upstream library names all include `gcc41' is because
different C++ compilers give a different ABI for a given piece of code
(different name mangling, calling conventions etc.). This is comparable
to debian's practice of putting `c2a' in package names (see
http://lists.debian.org/debian-release/2005/04/msg00153.html for the c2
part; I can't find an authoritative explanation of the `a' part, but it
indicates an ABI-incompatible change in the default allocator used by
libstdc++).
Including an indicator of the compiler (or ABI) in the library name is
presumably intended to allow having multiple ABI versions installed at
once.
As I say, that's just my guesses without having looked at libboost
documentation or speaking with libboost maintainers.
As for how calling programs should determine what ABI version
to link against, I suppose we either
- hard-code the answer (e.g. have a symlink that doesn't include a
compiler/ABI version, or a pkg-config name that doesn't mention
compiler/ABI version) and handle C++ ABI transitions much the same
as other libraries; and/or
- provide an autoconf macro that does something like
lb_ABI=`${CXX} -E -dM - /dev/null 21 |grep ABI`
case $lb_ABI in
'#define __GXX_ABI_VERSION 1002') lb_abi_str=-gcc41 ;;
'#define __GXX_ABI_VERSION 102') lb_abi_str=-gcc33 ;;
...
esac
The libboost source might give a clue as to what tests to use and/or
what library names libboost uses for different compilers (-gcc33 was
just my guess).
pjrm.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425071: suggested resolution
The above-referenced libboost issue #424038 may take a while to be resolved, and it isn't clear that -lboost_regex will come back once it has been resolved. However, we don't need to wait to resolve the FTBFS bug. We can restore the existing behaviour by changing the link from -lboost_regex to -lboost_regex-mt, or change to -lboost_regex-st if confident that bmpx doesn't access libboost from more than one thread. (The -mt and -st suffixes denote respectively multi-threaded and single-threaded.) Based on what's written at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424038, this should work both for the problem-causing version 1.34.0-1 and for the previously-working 1.33.*. (Apart from resolving a Severity:serious bug, I think addressing this now would allow cairomm 1.* to enter testing once the bmpx rebuild is ready to enter testing.) pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411271: New version addresses at least minor bugs
severity 411271 minor thanks I'm changing the severity from wishlist to minor because the upstream version addresses a minor bug I was about to report: doing as the existing documentation says results in deprecation warnings. Btw, when updating to the newer upstream version, remember to update the URL in debian/copyright, and update the copyright years (s/2004/2004–2006/). (Btw, I've just checked http://www.pygtk.org/docs/pygtk/pygtk-reference-copyright.html, and the authorship and license remain the same; only the URL and copyright years need changing.) pjrm.
Bug#414502: Small file NEWS.Debian is compressed; or non-existent file /usr/share/doc/vtun/NEWS.Debian
Package: vtun Version: 2.6-7 Severity: minor Upgrading from vtun 2.6-6 to 2.6-7 gave me: /etc/vtund-start.conf has been replaced! Please read /usr/share/doc/vtun/NEWS.Debian However, /usr/share/doc/vtun/NEWS.Debian does not exist: rather there is a file /usr/share/doc/vtun/NEWS.Debian.gz. $ gzip -l /usr/share/doc/vtun/NEWS.Debian.gz compresseduncompressed ratio uncompressed_name 404 588 36.4% /usr/share/doc/vtun/NEWS.Debian The uncompressed size 588 bytes is smaller than the smallest possible block size of ext2/ext3 and I'd guess most filesystems other than reiserfs, so compressing does not in fact save disk space in most cases. The small/rare savings in disk space should be balanced against the fact that compressed files are less convenient to operate on than uncompressed files. Looking to Debian policy for guidance (searching for `compress'): §12.3 ‘Additional documentation’ suggests that it “should be ... compressed ... unless it is small”. It doesn't actually give a threshold for ‘small’, though I suppose 588 bytes qualifies. It doesn't unambiguously say that it should not be compressed if it is small. (Other somewhat-related guidance is that copyright files /must/ not be compressed, and that changelog files should be compressed even if small, on the grounds that changelog files are expected to become large over time.) Based on the above, I believe that the best resolution of this bug is not to compress this small NEWS.Debian file; but that either fix is defensible and acceptable. pjrm.
Bug#268120: What are CTRL+ALT key combinations for creating international characters ... that Windows uses ?
A specification would be helpful in how this is to be implemented. The best I could find was http://en.wikipedia.org/wiki/Unicode#Input_methods and http://en.wikipedia.org/wiki/Alt_codes; though these are a little vague as to e.g. how long Alt must be held down, or whether decimal or hexadecimal, and neither mentions Ctrl key. (Incidentally, you may also be interested in the Gnome Character Map program gucharmap, and http://en.wikipedia.org/wiki/Compose_key (useful for keyboard entry of common symbols like ‘’“”é槶™⁸⁹«»), and http://en.wikipedia.org/wiki/List_of_input_methods_for_UNIX_platforms for entering extended portions of text in other languages including CJK and indic.) pjrm.
Bug#323994: Please close: works in etch
The versions of xterm, libxt6 etc. currently in testing do not exhibit this overlapping memcpy regions bug. (Incidentally, this bug was wrongly reassigned from xlibs to xkb-data: it should have gone to libxt6 if anywhere.) Tested with: xterm 222-1etch2 and 224-1 libxt6 1.0.2-2 valgrind 3.2.1-1 on a machine that (for the most part) tracks testing. [valgrind does still give a warning about close(-1) and a write from uninitialized data, though it gives no backtrace for the first, and the backtrace for the second seems incorrect, even when compiled with -g -O0.] pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413620: xkb-data: Description falsely claims to conflict with replace xlibs
Package: xkb-data Version: 0.9-4 Severity: minor (Related in some way to #410903.) Excerpt of xkb-data Description field: This package comes from xkeyboard-config, and thus conflicts with and replaces the xlibs package which is part of the XFree86 server. I read this as meaning that the xkb-data binary package has Conflicts and Replaces fields that refer to xlibs, whereas in fact xkb-data has neither a Conflicts nor a Replaces field. The relationship between the xkb-data and xlibs packages isn't immediately clear to me: e.g. it isn't obvious to me whether xlibs' files are being consulted if xorg and xkb-data are installed, and hence whether it makes any difference if xlibs is still installed or removed. If the xlibs package is entirely ignored when xorg and xkb-data are installed, then I suppose xlibs' Description should note this. pjrm. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686-smp Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396583: Please assign back to libgcj-common: missing symlink handling
reassign 396583 libgcj-common
thanks
Brendan O'Dea's message of 3 Nov 2006 to #396583 indicates a failure of
libgcj-common's control scripts to clean up a symlink created by a
previous version (apparently libgcj-common 1:4.1.0-2j1, see below).
The result is that /usr/share/doc/$P/{changelog.Debian.gz,copyright}
(for P in one of libgcj-common or gcj-4.1-base, depending on which was
less recently installed) describe the wrong package, causing a violation
of the Debian policy sections ‘Copyright: `debian/copyright'’ and
‘Changelog files’.
Furthermore, this is not a bug of debsums: debsums is correctly pointing
out that the currently-installed versions of files do not match the
versions originally installed, which has led to the discovery of the
bugs mentioned above.
pjrm.
Reason for belief that libgcj-common 1:4.1.0-2j1 created the
/usr/share/doc/libgcj-common - gcj-4.1-base symlink:
$ ls -l --full-time /usr/share/doc/libgcj-common
lrwxrwxrwx 1 root root 12 2006-06-20 07:40:25.0 +1000
/usr/share/doc/libgcj-common - gcj-4.1-base
Searching /var/log/dpkg.log* for entries around that time finds
2006-06-20 07:40:25 install gcj-4.1-base none 4.1.0-2j1
2006-06-20 07:40:25 install libgcj-common none 1:4.1.0-2j1
2006-06-20 07:40:25 install libgcj7 none 4.1.0-2j1
(and some unrelated packages).
I haven't checked by looking in the libgcj-common 1:4.1.0-2j1 package,
though.
Bug#403171: linux-image-2.6.18-3-686: Please update yaird Depends version to = 0.0.12-15
Package: linux-image-2.6.18-3-686 Version: 2.6.18-8 Severity: important Configuring linux-image-2.6.18-3-686 with yaird 0.0.12-14 fails (“bad value in /boot/config-2.6.18-3-686: CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config”), whereas 0.0.12-18 succeeds. (See partial transcript below.) Looking at yaird's changelog.Debian.gz, I see that 0.0.12-15 includes a change to “[e]xtend patch 1002 to allow $ in KConfig regex (as introduced in 2.6.17-rc1-mm3).” I conclude that the ...$UNAME_RELEASE... value in /boot/config-2.6.18-3-686 requires a yaird of version 0.0.12-15 or greater. Please accordingly change linux-image-2.6.18-3-686's Depends line from ‘yaird (= 0.0.12-8)’ to ‘yaird (= 0.0.12-15)’. Thanks, pjrm. Partial transcript showing failure, upgrade of yaird, and subsequent success of configuring: # apt-get install linux-image-2.6-686 ... Running depmod. Finding valid ramdisk creators. Using mkinitrd.yaird to build the ramdisk. yaird error: bad value in /boot/config-2.6.18-3-686: CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config (fatal) mkinitrd.yaird failed to create initrd image. Failed to create initrd image. dpkg: error processing linux-image-2.6.18-3-686 (--configure): subprocess post-installation script returned error exit status 9 dpkg: dependency problems prevent configuration of linux-image-2.6-686: linux-image-2.6-686 depends on linux-image-2.6.18-3-686; however: Package linux-image-2.6.18-3-686 is not configured yet. dpkg: error processing linux-image-2.6-686 (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: linux-image-2.6.18-3-686 linux-image-2.6-686 E: Sub-process /usr/bin/dpkg returned an error code (1) # apt-get install yaird ... Preparing to replace yaird 0.0.12-14 (using .../yaird_0.0.12-18_i386.deb) ... ... Setting up linux-image-2.6.18-3-686 (2.6.18-7) ... Running depmod. Finding valid ramdisk creators. Using mkinitrd.yaird to build the ramdisk. Setting up linux-image-2.6-686 (2.6.18+5) ... # -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686-smp Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.18-3-686 depends on: ii coreutils 5.97-5 The GNU core utilities ii debconf [debconf-2.0] 1.5.8 Debian configuration management sy ii module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.12-18 Yet Another mkInitRD Versions of packages linux-image-2.6.18-3-686 recommends: pn libc6-i686none (no description available) -- debconf information: linux-image-2.6.18-3-686/postinst/bootloader-error-2.6.18-3-686: linux-image-2.6.18-3-686/postinst/old-dir-initrd-link-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/kimage-is-a-directory: linux-image-2.6.18-3-686/postinst/old-system-map-link-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/create-kimage-link-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/bootloader-test-error-2.6.18-3-686: linux-image-2.6.18-3-686/preinst/abort-overwrite-2.6.18-3-686: linux-image-2.6.18-3-686/postinst/old-initrd-link-2.6.18-3-686: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-3-686/preinst/elilo-initrd-2.6.18-3-686: true linux-image-2.6.18-3-686/preinst/lilo-initrd-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/depmod-error-initrd-2.6.18-3-686: false linux-image-2.6.18-3-686/preinst/bootloader-initrd-2.6.18-3-686: true linux-image-2.6.18-3-686/prerm/removing-running-kernel-2.6.18-3-686: true linux-image-2.6.18-3-686/prerm/would-invalidate-boot-loader-2.6.18-3-686: true linux-image-2.6.18-3-686/preinst/abort-install-2.6.18-3-686: linux-image-2.6.18-3-686/preinst/overwriting-modules-2.6.18-3-686: true linux-image-2.6.18-3-686/preinst/initrd-2.6.18-3-686: linux-image-2.6.18-3-686/preinst/lilo-has-ramdisk: linux-image-2.6.18-3-686/preinst/already-running-this-2.6.18-3-686: linux-image-2.6.18-3-686/postinst/depmod-error-2.6.18-3-686: false linux-image-2.6.18-3-686/preinst/failed-to-move-modules-2.6.18-3-686:
Bug#388351: Wrong encoding for xtraceroute.desktop
Package: xt Version: 0.9.1-8 Severity: normal Message on terminal: [Invalid UTF-8] Could not parse file '/usr/share/applications/xtraceroute.desktop': desktop entry contain line 'Comment[es]=Un traceroute gr\xe1fico' which is not UTF-8 xtraceroute.desktop claims Encoding=UTF-8 but the above es translation appears to be in latin1. Suggested fix: recode l1..u8 xtraceroute.desktop (modifies the file in place). Alternatively, change it to `gráfico' (in utf-8: \xc3\xa1) manually; or perhaps change the encoding setting to ISO-8859-1 (or latin1 or whatever the necessary spelling), though utf-8 may be more future-safe. pjrm. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages xt depends on: ii bind9-host [host] 1:9.3.2-P1-1 Version of 'host' bundled with BIN ii gtkglarea5 1.2.3-2.1Gimp Toolkit OpenGL area widget sh ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii libgdk-pixbuf2 0.22.0-11The GdkPixBuf image library, gtk+ ii libgl1-mesa-glx [libgl1]6.4.2-1 A free implementation of the OpenG ii libglib1.2 1.2.10-10.1 The GLib library of C routines ii libglu1-mesa [libglu1] 6.4.2-1 The OpenGL utility library (GLU) ii libgtk1.2 1.2.10-18The GIMP Toolkit set of widgets fo ii libx11-62:1.0.0-8X11 client-side library ii libxext61:1.0.1-2X11 miscellaneous extension librar ii libxi6 1:1.0.1-3X11 Input extension library ii traceroute 1.4a12-20traces the route taken by packets xt recommends no packages. -- no debconf information
Bug#385732: downgrade severity?
Can this bug's title be changed to Source package contains useless files, and accordingly its severity be reduced to minor or wishlist ? pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#248122: nobody-owned files
On Fri, Jun 30, 2006 at 02:39:01PM -0400, Justin Pryzby wrote: On Fri, Jun 30, 2006 at 03:16:27PM +1000, Peter Moulder wrote: As root (assuming running with set -e): d=`mktemp -d` install -d -m 700 -o nobody $d/writable (cd $d/writable su nobody -c 'wget ...') User `nobody' can write into this `writable' directory, but only for a process that has already cd'd into it as root before becoming nobody: the $d directory is executable only by root. I think it is intended that nobody never owns any files. I believe that the reason for this is so that no `nobody'-owned process can read/write non-world-accessible files other than its own. The above approach does achieve this result even though it does literally create a file as `nobody': no other non-root process can access the file. So the right way to do it probably involves dynamically creating a user I believe that many things would benefit at least slightly in security from such a facility: even things that don't need to read/write files would still be less exposed to denial of service by being killed by other nobody-owned processes. However, in the short term, I suggest using the only-root-readable directory approach: it already gets us most of the way there, avoiding giving the wget executable privileges of an important user like root (or sys or operator). pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#248122: Another approach to permissions
As root (assuming running with set -e): d=`mktemp -d` install -d -m 700 -o nobody $d/writable (cd $d/writable su nobody -c 'wget ...') User `nobody' can write into this `writable' directory, but only for a process that has already cd'd into it as root before becoming nobody: the $d directory is executable only by root. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370600: Alternative fix for the failure to compile problem
Passing through `expand -t 4' and then appending a colon to the `if' condition of line 371 fixes the problem better than the suggested noisy patch. Of course, where there are bugs, there are more bugs: the fact that it contained even compile errors shows that the original coder hadn't tested it at all before submitting. I haven't tried reviewing the diffs myself. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366688: new upstream available; and completions/apropros.fish bug
Package: fish Severity: wishlist (I wouldn't normally use a single mail for two such different matters, but in this case I think it sensible.) 1.21.6 is available. Looking at the changelog, the changes aren't too major, except that there is one crash bug fixed. I've just filed a bug report upstream (http://thread.gmane.org/gmane.comp.shells.fish.user/483) about a missing `\' in share/completions/apropos.fish (before the second `$' on line 5: the `$' indicating end-of-line regexp rather than being part of `$str'). You may wish either to apply this to 1.21.6 (after checking that thread just in case people there have any comments), or wait until Axel has time to release the next version. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363445: More dependencies
I wrote too soon: must also depend on the following packages: (Package, Version known not to contain the relevant .pc file, Version known to contain the relevant .pc file) libxext-dev 6.9.0.dfsg.1-5 1:1.0.0-3 libxfixes-dev 6.9.0.dfsg.1-5 1:3.0.1.2-2+b1 libxi-dev 6.9.0.dfsg.1-5 1:1.0.0-3 libxinerama-dev 6.9.0.dfsg.1-5 1:1.0.1-2 libxrandr-dev 6.9.0.dfsg.1-5 2:1.1.0.2-3 Without having looked at the changelog or recent diffs for these packages, I'd suggest adding the following Depends (including the aforementioned libx11-dev): libx11-dev (= 2:1.0.0), libxext-dev (= 1:1.0.0), libxfixes-dev (= 1:3.0.0), libxi-dev (= 1:1.0.0), libxinerama-dev (= 1:1.0.0), libxrandr-dev (= 2:1.1.0.0) pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363445: libgtk2.0-dev: Should depend on version of libx11-dev that provides x11.pc
Package: libgtk2.0-dev Version: 2.8.17-1 Severity: normal $ pkg-config --cflags gdk-2.0 Package x11 was not found in the pkg-config search path. Perhaps you should add the directory containing `x11.pc' to the PKG_CONFIG_PATH environment variable Package 'x11', required by 'GDK', not found Note that it doesn't in fact display the necessary -I flags. Consequently, gtk programs that use pkg-config now fail to compile, unless the x11.pc file is present. libx11-dev 6.9.0.dfsg.1-5 does not contain this file; version 2:1.0.0-6 does contain the file. I'd guess that an appropriate versioned Depends would be libx11-dev (= 2:1.0.0). pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356148: Please close / merge with #345479
This is fixed in glibc 2.3.6, which entered testing on Sunday (with just a week to spare). However, I don't know whether Debian stable has been updated yet (just the zoneinfo files, I mean, not necessarily updating to 2.3.6). pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343060: yes, need to rebuild
To reproduce a crash with the existing aspell build (0.60.4-1_i386): # apt-get install scim-pinyin $ GTK_IM_MODULE=scim gedit On my machine at work, gedit crashes on startup, i.e. with just the above procedure. On my home machine, the following addition is needed: Press Ctrl+Space A short bar should appear at the bottom of the screen; select Chinese (simplified) Smart Pinyin. Type `w'. Should crash at this point: *** glibc detected *** free(): invalid pointer: 0x082d35d8 *** If I then install some aspell packages that I recompiled from source (aspell_0.60.4-1_i386.deb libaspell-dev_0.60.4-1_i386.deb libaspell15_0.60.4-1_i386.deb libaspell15c2_0.60.4-1_all.deb), and repeat the above procedure, then it correctly presents a list of chinese characters, and I can press `1' for it to insert `我', and all is happy. [Actually, all is not entirely happy: I can produce ** (gedit:5473): CRITICAL **: get_next_misspelled_word: assertion `word != NULL' failed when I mix different languages in a document, but I assume that that is unrelated.] pjrm.
Bug#343060: yes, need to rebuild
On Thu, Dec 15, 2005 at 02:02:20PM +0200, Brian Nelson wrote: I don't see how libaspell could be blamed... blame may not be the appropriate concept; but the relevant point is that installing recompiled libaspell fixed the problem for me. (Also relevant, though I didn't mention it in my bug report, is that the crash only appeared after I upgraded libstdc++6 from 4.0.2-2 to 4.0.2-5, giving further evidence that the cause of the crash is related to the libstdc++ change and that recompiling against the newer libstdc++ might fix the problem for others.) The backtrace for that crash on my machine looks like: (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0x4a3ad691 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0x4a3aef5b in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x4a3e3bb7 in __libc_message () from /lib/tls/i686/cmov/libc.so.6 #4 0x4a3ea187 in _int_free () from /lib/tls/i686/cmov/libc.so.6 #5 0x4a3ea622 in free () from /lib/tls/i686/cmov/libc.so.6 #6 0x410e8dc1 in operator delete () from /usr/lib/libstdc++.so.6 #7 0xb7a47dea in scim::CommonLookupTable::~CommonLookupTable () from /usr/lib/libscim-1.0.so.8 Note that this is a crash in memory deallocation; so it seems entirely reasonable that this crash is due to the change in default memory allocators, and thus reasonable that recompiling aspell to use the new allocation defaults might fix the problem -- and indeed it seems to have fixed the problem for me. Granted, the caller here (#7) is scim rather than aspell. Without having thought much about it, I suppose that this can occur because of the aggregation of allocations that libstdc++ does. However, I'm not familiar with libstdc++ memory allocation, and this suggested cause is pure speculation. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343313: see also #343060
Bug #343060 requests a rebuild of the aspell packages, and I've added some information there. The aspell maintainer points out that the backtrace for the crash I get has one of scim's rather than libaspell's functions as the caller of the delete that causes the double-free crash, which (combined with the fact that libaspell doesn't export any C++ symbols) makes him think that rebuilding aspell might not be the best fix. With your expertise on libstdc++ and the effects of changing default allocator, you may wish to add a comment to that bug. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343060: yes, need to rebuild
On Thu, Dec 15, 2005 at 02:02:20PM +0200, Brian Nelson wrote: The backtrace for that crash on my machine looks like: (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0x4a3ad691 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0x4a3aef5b in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x4a3e3bb7 in __libc_message () from /lib/tls/i686/cmov/libc.so.6 #4 0x4a3ea187 in _int_free () from /lib/tls/i686/cmov/libc.so.6 #5 0x4a3ea622 in free () from /lib/tls/i686/cmov/libc.so.6 #6 0x410e8dc1 in operator delete () from /usr/lib/libstdc++.so.6 #7 0xb7a47dea in scim::CommonLookupTable::~CommonLookupTable () from /usr/lib/libscim-1.0.so.8 [rest of backtrace snipped] I don't see how libaspell could be blamed... If you think that the backtrace indicates that another fix might be available, and that rebuilding aspell is avoidable / merely papering over a problem, then that would be good, as it would also avoid needing to get people to upgrade libaspell15 (via Conflicts in libstdc++6, or even more obtrusive); and (more importantly) the fix that avoids needing to rebuild aspell might also avoid needing to rebuild other libraries. Unfortunately I can't think right now how to find another fix, but maybe you or the libstdc++6 maintainers will have an idea. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343313: libstdc++6: upgrade breaks existing applications with scim 1.0.2-3
Package: libstdc++6 Version: 4.0.2-5 Severity: important Upgrading libstdc++6 from 4.0.2-2 to 4.0.2-5 causes crashes in various gtk programs when GTK_IM_MODULE=scim is in the environment. I have the following scim-related packages: ii scim 1.0.2-3Smart Common Input Method platform ii scim-config-socket 1.0.2-3Socket configure module for SCIM ii scim-frontend-socket 1.0.2-3Socket front end module for SCIM ii scim-gtk2-immodule 1.0.2-3GTK2 IMModule with SCIM as backend ii scim-server-socket 1.0.2-3Socket IM engine module for SCIM With libstdc++6 4.0.2-5 installed: $ GTK_IM_MODULE=scim gedit *** glibc detected *** malloc(): memory corruption: 0x0822f3b8 *** $ GTK_IM_MODULE=scim inkscape Launching a SCIM daemon with Socket FrontEnd... *** glibc detected *** corrupted double-linked list: 0x089562e8 *** Emergency save activated! ... galeon doesn't exactly crash, but goes into sleep state before showing its main window. These programs appear to work fine when GTK_IM_MODULE is unset or if I downgrade to libstdc++6 4.0.2-2 or if I upgrade scim to 1.4.2-1. Thus, without really understanding the problem, I suggest that libstdc++6 Conflict with scim ( 1.4.2-1). scim bug report #342198 may be related. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.4.27-2-686-smp Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages libstdc++6 depends on: ii gcc-4.0-base 4.0.2-5The GNU Compiler Collection (base ii libc6 2.3.5-8GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-5 GCC support library libstdc++6 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343313: libstdc++6: upgrade breaks existing applications with scim 1.0.2-3
[I haven't cc'd debian-release@lists.debian.org or [EMAIL PROTECTED] On Wed, Dec 14, 2005 at 12:48:50PM +0100, Matthias Klose wrote: I think it's wrong to add conflicts to libstdc++6. we'll end up with an unmanagable long list of conflicts. can the conflict be added to some basic gtk package instead? `apt-get install scim' (which upgraded no packages other than some others from the scim source package) was enough to fix the problem.[*1] In particular, no basic gtk package was upgraded between the bug occurring and not occurring. [*1]: Though possibly my testing wasn't thorough enough to detect a problem: see below. If I downgrade scim back to 1.0.2-3, and upgrade gedit and all of its direct dependencies to the versions in unstable, then the problem still persists. If I then re-upgrade scim to 1.4.2-1 then... Oh. gedit comes up OK, but I can get it to crash with a bit of typing using scim. I can fix that crash by recompiling aspell from source. Having found problems with scim and now aspell, I wonder what other crashes are waiting to be discovered? The choices I see (all unpleasant) are: (i) libstdc++6 Conflicts with both scim ( 1.4.2-1) and libaspell15 ( 0.60.4-2) [which doesn't even exist yet] and hope these are the only two needed packages. (ii) Do nothing: the crashes will eventually go away when people get around to upgrading their scim and aspell packages. (iii) Force mass recompiles again, e.g. by renaming the libstdc++6 package and bumping the soname. (iv) Maybe some clever runtime trick to detect the problem and give a more helpful error message? Hopefully I've missed something. So far my preferences are (i) and perhaps (iv). pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333768: pls reduce severity; pls test with 0.43
A grave bug is one serious enough to prevent the release of the package. The description of this priority (in bug-maint-info.txt) does mention data loss as a possible justification for marking a bug as grave, but the data loss described in this bug report (qualified as minor in the submitter's justification tag) is not of sufficient seriousness that users would prefer not to have the package at all compared to having the package with this bug. (Indeed, I'd question whether it even merits important severity, i.e. I don't think the bug has a major effect on the usability of [the] package: (i) I haven't managed to reproduce this bug in 0.42.2-1, and previous comments here mention difficulty in reproducing. (ii) At least two work-arounds exist, namely to edit the text in-line (if I've correctly understood from the original bug report) or to use the XML editor. (iii) I'm not sure I've seen this bug reported before in the bug tracker or on #inkscape, so I suppose it's not a major problem for most people. Indeed, I'd say most SVG files don't even contain text; text editing is not a major part of inkscape use, which suggests that most text-editing bugs don't have a major effect on [usability].) So first of all, please reduce the severity (I'd suggest normal), which will allow inkscape 0.43 to enter testing, which in turn might make it easier for some people to confirm whether the bug is still in 0.43-1 or not. (At least one bug related to line-spacing has been fixed upstream between 0.42 and 0.43.) Can someone report on their experiences reproduce this on 0.43-1 ? (I haven't managed to reproduce the bug even in the version where this bug was originally reported (0.42.2-1).) If you can reproduce it, then please attach an example file and steps of how to reproduce the bug, to assist in fixing the bug. I believe Debian's 0.43-1 isn't very heavily patched relative to upstream, so I'd guess that the bug isn't Debian-specific; so you might consider reporting the bug upstream: see the Bug reports link on the left of http://inkscape.org/. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325598: debugging information
I've had trouble reproducing this on will: installing ( purging) the
same font package twice gives the warnings only on the first install, so
presumably dpkg --purge and the prerm/postrm scripts aren't completely
reverting the system state.
Looking at the file, I see lines like
/BousungEG-Light-GB /FileType /TrueType /Path
(/usr/share/fonts/truetype/arphic/gbsn00lp.ttf) /SubfontID 0 /CSI [(GB1) ] ;
/KochiMincho-Regular-JaH /FileType /TrueType /Path
(/usr/share/fonts/truetype/kochi/kochi-mincho-subst.ttf) /SubfontID 0 /CSI
[(Japan2) ] ;
/ShanHeiSun-Light /FileType /TrueType /Path
(/usr/share/fonts/truetype/arphic/bsmi00lp.ttf) /SubfontID 0 /CSI [(CNS1) ] ;
/KochiMincho-Regular /FileType /TrueType /Path
(/usr/share/fonts/truetype/kochi/kochi-mincho-subst.ttf) /SubfontID 0 /CSI
[(Japan1) ] ;
Comparing with line 108, it seems that only $hh{$h[6]} is undefined,
where $h[6] is GB1, Japan2, CNS1 or Japan1 respectively.
Searching for `hh' finds only its declaration and the cmap loop on lines
98-105.
$IdCmap's value appears (based solely on a quick search for IdCmap in
that file) to come from the init sub in that file: $IdCmap =
defoma_id_open_cache('cmap'). defoma_id_open_cache is defined in
/usr/share/perl5/Debian/Defoma/Id.pm. It constructs a
Debian::Defoma::IdCache with first argument being a filename of basename
id-cache.cmap (given the 'cmap' argument used in this case).
On my system, `locate id-cache.cmap' finds no matches.
(`locate id-cache' finds several matches.)
I'd guess (based on a glance at defoma_id_get_font's definition) that if
id-cache.cmap doesn't exist, then %hh will be empty, which is why
printing $hh{GB1} etc. gives this uninitialized value warning.
HTH,
pjrm.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297217: the proposed patch looks wrong
Messages on the mailing list suggest that gcc-4 presents a number of problems. It may be that the best fix is to force CC=gcc-3.3 until we have a corrected upstream version. The above-proposed patch of making the non-gnuc version unconditional looks wrong in light of the following comment immediately above the changed code: /* ** GNU C allows lvalue casts, so if we have gcc, use them. ** If we don't have gcc, then we can use *(type *)lval, ** but that wouldn't work for gcc since lval might be a global ** register in which case we couldn't take [its] address. ** Similarly for comma expressions and conditional expressions. */ Thus, I believe a better fix would be to change #ifdef __GNUC__ to #if defined(__GNUC__) __GNUC__ 4 This is a no-op change from upstream for gcc-3.3. If gcc-4 is used, then sticking to the hlc grades might be enough to avoid gcc-4 problems. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271616: automake1.8: [PATCH] check_JAVA files compiled before `make check'
On Sat, Jul 30, 2005 at 02:29:13AM -0400, Eric Dorland wrote:
Wow, sorry this slipped through my net for a long time. Is this still
a problem in the latest automake 1.9?
It's been a while since I've done java work, but the function to which
the patch applies hasn't been changed between current (Debian unstable)
1.8 and 1.9. I haven't actually tested that the bug hasn't been fixed
in some other way, though.
Attached is an updated patch (produced mechanically from patch, diff3
-m, diff) for /usr/bin/automake-1.9 from 1.9.6-1. Untested.
pjrm.
--- /usr/bin/automake-1.9 2005-07-13 16:04:52.0 +1000
+++ /home/pmoulder/src/automake-1.9 2005-07-30 18:16:31.0 +1000
@@ -4515,7 +4515,10 @@ sub handle_java
}
-push (@all, 'class' . $dir . '.stamp');
+if $dir ne 'check')
+ {
+ push (@all, 'class' . $dir . '.stamp');
+ }
}
Bug#310864: fixed upstream
Reproduced in inkscape_0.41-2; whereas CVS build has no problem exporting a large (15841 x 19425px) ellipse to png. I've checked that resulting png claims the right dimensions and that it opens OK in gimp. pjrm. -- bbyak: swatches, rich text, gradient on canvas... JonCruz: The answer to the ultimate question of life, the universe, and everything... JonCruz: Inkscape 0.42!!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303385: please close
Open group is the Enter group function that Bulia mentioned (in the context menu from right-click on the group); it is already present in 0.41-2. There may be a valid user interface / documentation bug to be addressed upstream (Vincent: you might add to that RFE to make more concrete suggestions about how the documentation or user interface could be changed), but I think the debian side of the bug report can be closed. pjrm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299140: [PATCH] intltool-update: FindPackageName: wrong shell variable names for PACKAGE_NAME
Package: intltool
Version: 0.33-1
Severity: normal
If a package's configure.ac file has
GETTEXT_PACKAGE=$PACKAGE_NAME
then FindPackageName fails to expand it.
AC_INIT(mypackage, myversion) defines AC_PACKAGE_NAME m4 macro and
PACKAGE_NAME shell variable (AC_SUBST). Whereas FindPackageName was
assuming that the shell variable was also called $AC_PACKAGE_NAME.
The appended patch is intended to address this problem.
N.B. I haven't tested this patch, as I don't know fully how to reproduce
the original problem; it was reported to me by a user of some software I
help to maintain. I'm sending this patch now just to make sure I don't
forget about it. If I see the user again then I'll ask them about it.
pjrm.
diff -dur intltool-0.33/intltool-update.in.in
intltool-0.33-pjrm/intltool-update.in.in
--- intltool-0.33/intltool-update.in.in 2005-01-24 11:48:34.0 +1100
+++ intltool-0.33-pjrm/intltool-update.in.in2005-03-12 11:40:09.947127608
+1100
@@ -989,9 +989,9 @@
($name, $version) = ($1, $2);
$name=~ s/[\[\]\s]//g;
$version =~ s/[\[\]\s]//g;
- $varhash{AC_PACKAGE_NAME} = $name;
+ $varhash{PACKAGE_NAME} = $name;
$varhash{PACKAGE} = $name;
- $varhash{AC_PACKAGE_VERSION} = $version;
+ $varhash{PACKAGE_VERSION} = $version;
$varhash{VERSION} = $version;
}
@@ -1000,19 +1000,18 @@
($name, $version) = ($1, $2);
$name=~ s/[\[\]\s]//g;
$version =~ s/[\[\]\s]//g;
- $varhash{AC_PACKAGE_NAME} = $name;
+ $varhash{PACKAGE_NAME} = $name;
$varhash{PACKAGE} = $name;
- $varhash{AC_PACKAGE_VERSION} = $version;
+ $varhash{PACKAGE_VERSION} = $version;
$varhash{VERSION} = $version;
}
# \s makes this not work, why?
$name = $1 if $conf_source =~ /^GETTEXT_PACKAGE=\[?([^\n\]]+)/m;
-# prepend '$' to auto* internal variables, usually they are
-# used in configure.in/ac without the '$'
-$name =~ s/AC_/\$AC_/g;
-$name =~ s/\$\$/\$/g;
+# m4 macros AC_PACKAGE_NAME, AC_PACKAGE_VERSION etc. have same value
+# as corresponding $PACKAGE_NAME, $PACKAGE_VERSION etc. shell variables.
+$name =~ s/\bAC_PACKAGE_/\$PACKAGE_/g;
$name = $domain if $domain;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297551: [PATCH] RCS_checkout: Assertion `rev == ((void *)0) || ...ISdigit)' failed
Package: cvs
Version: 1:1.12.9-11
Severity: normal
Short steps to reproduce:
rm foo.c; cvs rm foo.c (for some existing file foo.c in CVS)
cvs -t diff -r BASE -r HEAD foo.c
(Longer steps, starting from cvs init, given below.)
The `cvs rm' should negate the version number of foo.c in CVS/Entries,
which is queried for `-r BASE'.
Then RCS_checkout is passed a negative revision number, and the
assert (rev == NULL || isdigit (*rev)) assertion fails.
Appended is a patch that addresses one side of the problem: this patch
fixes the problem if the server has this patch applied (whether or not the
client cvs is patched), but this patch change the client not to send
bad data over the wire to begin with; so if the client has the
appended patch applied but the server doesn't, then the assertion will
still fire (on the unpatched server cvs).
I've tested the patch by creating a local repository, and checking that
cvs 1:1.12.9-10 causes the failed assertion and that the patched version
doesn't fail. Session extract follows (with some commands' output
omitted):
$ mkdir /tmp/frog
$ cvs -d /tmp/frog init
$ mkdir /tmp/bull
$ cd /tmp/bull
$ cvs -d /tmp/frog import -m '' hello acme empty
$ cvs -d /tmp/frog co hello
$ cd hello
$ (echo '#include stdio.h';echo 'int main(void) { printf(hi\n); }')
hello.c
$ cvs add -ko hello.c
$ cvs commit -m new hello.c
$ rm hello.c ;cvs rm hello.c
$ cvs diff -r BASE -r HEAD hello.c
cvs: rcs.c:4003: RCS_checkout: Assertion `rev == ((void *)0) ||
((*__ctype_b_loc ())[(int) (((unsigned char) *rev))] (unsigned short int)
_ISdigit)' failed.
cvs [diff aborted]: received abort signal
$ ~/build/cvs/cvs-1.12.9/build-tree/cvs-1.12.9/src/cvs diff -r BASE -r HEAD
hello.c
$
The appended patch assumes that it is to be applied after all existing
rcs.c patches, i.e. after 63_add_commit_dir.
pjrm.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-k7
Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Versions of packages cvs depends on:
ii debconf 1.4.30.11Debian configuration management sy
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libpam-runtime 0.76-22 Runtime support for the PAM librar
ii libpam0g0.76-22 Pluggable Authentication Modules l
ii zlib1g 1:1.2.2-3compression library - runtime
-- debconf information excluded
diff -ruN cvs-1.12.9-old/src/rcs.c cvs-1.12.9/src/rcs.c
--- cvs-1.12.9-old/src/rcs.c2005-03-01 10:59:48.0 +1100
+++ cvs-1.12.9/src/rcs.c2005-03-01 21:41:08.0 +1100
@@ -4000,6 +4000,9 @@
: (sout != RUN_TTY ? sout
: (stdout) ) ) ) );
+if (rev *rev == '-')
+ ++rev;
+
assert (rev == NULL || isdigit ((unsigned char) *rev));
if (noexec workfile != NULL)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
