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
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
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
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.
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
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
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
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
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
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.
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 ...
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
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
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
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]
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
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:
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
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'
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
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
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
[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
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
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
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
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
[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
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
[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
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
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
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
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]
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
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
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
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.
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,
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
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
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
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
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
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]
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
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
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
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
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
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
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
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
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
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
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
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
[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
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
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
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
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
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
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
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
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
66 matches
Mail list logo
