Bug#1033140: emacs-gtk: M-x woman fails on grep man page with cryptic message
Package: emacs-gtk
Version: 1:28.2+1-10
I'm not sure whether this is a bug in Emacs or a bug in the grep man
page, but since man(1) and 'M-x man' both handle the page fine, I
thought I'd start here.
Reproducible with 'emacs -Q' or 'emacs -q'. Installed version of grep
is 3.8-5.
Entering 'M-x woman RET grep RET' results in an error:
Search failed: "\\({\\|el[ ]*}\\)\\|\\(
[.']\\)?[ ]*}[ ]*"
Looking in *Messages*, this is preceded by "woman0-if".
Bug#1013958: more info
I have learned more about this. It turns out that it only happens if the user has not set the xfce default browser app! Without a user-set default, exo-open defaults to using x-www-browser, but xfce4-terminal's context menu prefers chromium! Once a user setting _exists_, the context menu happily uses it, but until then, it will choose chromium over x-www-browser. This is a minor bug, since there's an easy workaround: the user can actually set their default apps. But I think it's still a bug. (Also, it seems odd that the context menu doesn't just call exo-open, but there may be reasons for that.)
Bug#1013958: xfce4-terminal: open URL ignores exo-open settings (and debian settings)
Package: xfce4-terminal Version: 1.0.4-1 Severity: normal If I right-click on a URL in the terminal, and then choose "Open Link" on the pop-up menu, the link is opened in Chromium, even though I have Firefox selected as the default for both exo-open and Debian's x-www-browser alternative. If I type "exo-open --launch WebBrowser http://debian.org";, the URL is opened in Firefox (as expected), but xfce4-terminal's internal code seems to ignore all my settings!
Bug#925371: for Emacs 26.2, I guess
Apparently this request (Enable dynamic modules) doesn't really make sense for Debian before 26.2 is packaged; with 26.1 and earlier, it can't be used outside the Emacs source tree. But with 26.2 (which I assume we'll see soon now that Buster is released), "[t]he emacs-module.h file is now installed in the system-wide include directory as part of the Emacs installation", according to the NEWS file in GNU's git. (You probably know all this; I just thought it should be on record in the BTS report.) cheers
Bug#910231: Problem was in libfontconfig
The message "Unable to revert mtime: /usr/local/share/fonts" comes from libfontconfig1, and has nothing to do with emacs per se. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909728 Submitter: if you're still seeing this, you might want to talk to the fontconfig folks. Maintainer: depending on what submitter has to say, you can probably either close this or reassign it.
Bug#925371: Enable dynamic module support
Source: emacs
Version: 1:26.1+1-3.2
Severity: wishlist
Hi!
This is a request to add the "--with-modules" option to the
configuration options of emacs-{gtk,ludid,nox}.
This is definitely not an important feature, so no rush, but it's
something I'd like to play around with in the not-too-distant-future,
if at all possible.
cheers
Bug#891063:
On Sun, Aug 26, 2018 at 2:57 PM Vincent Lefevre wrote: > > On 2018-08-24 18:04:29 -0700, Chris Waters wrote: > > Ok, sorry that I can't remember *all* the ways that "su" without a > > login option is broken. Even with that, it's still plenty broken, as > > you have observed, > > No, it had worked very well for *years*, until it got broken by > dconf. That's dconf that introduced the breakage. The fact that it had worked for years doesn't mean it was ever safe or reliable. Lots of things can work for years while having the potential for great disaster: race conditions, unsanitized input, etc. Calling su without the login option is just one more of those. > > There are simply too many things that can break when you have random > > environment variables left around pointing who-knows-where. > > In general, that's the problem of the end user. The problem here is > that environment variables are set behind his back. Programs are allowed to use the environment to communicate with each other. Programs *do*. If you assume they won't, you're likely to experience more "breakage". The problem is not with these programs; the problem is with your assumptions. > I've reported a bug against su: The behavior of su is defined by POSIX and the Single User Spec. It's not a bug. > And you're suggesting sudo while there will be the same issue. No. The sudo -e option doesn't run your editor as root; it makes a temporary copy, allows you to edit that *as yourself*, then copies the file back as root. So there's no problem. On the other hand, if you *don't* use the -e option (which I've never used), and just say "sudo emacs", then the environment is properly cleaned up, but the working directory remains. Which seems to be exactly what you were trying to achieve in the first place. But we're drifting off topic, which is emacs itself. There are, as you can see, many many ways to avoid the problem you experienced. Which was caused by your reliance on unsafe behavior. Not a bug in emacs.
Bug#891063:
On Fri, Aug 24, 2018 at 6:24 AM Vincent Lefevre wrote: > > On 2018-08-14 10:51:41 -0700, Chris Waters wrote: > > Vincent Lefevre writes: > > > But in any case, the bug needs to be fixed. > > > > Yeah, I don't believe this can reasonably be called a bug. Emacs, like > > a lot of big complex apps, can and does write to various parts of the > > filesystem when used. There's a good chance that if you check your > > home directory, you'll find more files owned by root. Files like > > .emacs.d/recentf or .emacs.d/auto-save-list/* or .emacs-places. > > Wrong. The "su" command changes the value of HOME to the home of the > root user. Thus there are no issues with these files. Ok, sorry that I can't remember *all* the ways that "su" without a login option is broken. Even with that, it's still plenty broken, as you have observed, which is why the man page for su recommends *not using it without the login option*. There are simply too many things that can break when you have random environment variables left around pointing who-knows-where. Blaming emacs for a problem with su which is documented by the su man page, though, is simply not reasonable. If you're going to insist on using su instead of sudo, then it's your job to vet all your environment variables to make sure you don't get this sort of well-documented side effect. Which can affect all sorts of programs--not just emacs.
Bug#891063:
Vincent Lefevre writes: > But in any case, the bug needs to be fixed. Yeah, I don't believe this can reasonably be called a bug. Emacs, like a lot of big complex apps, can and does write to various parts of the filesystem when used. There's a good chance that if you check your home directory, you'll find more files owned by root. Files like .emacs.d/recentf or .emacs.d/auto-save-list/* or .emacs-places. At least, those are some of the files that Emacs has silently modified recently on *my* system. It may depend on which emacs features you have enabled, but that's something you shouldn't have to worry about. Typing "su emacs [filename]" is simply not something you can reasonably expect to do safely. Which is why emacs has features to work around that. Like typing "emacs /su::[filename]" instead. Or using "C-x C-f /su::[filename]" from within emacs. (Or, better yet, "emacs /sudo::[filename]" or "C-x C-f /sudo::[filename]".) If it *really* bothers you to type the pathname, you can make an alias like: "eroot='emacs /sudo::$(pwd)/$1'". Or even "su -l emacs $(pwd)/$1". However, turning off dbus access for emacs, which is something some of us actually *use*, just to support a non-standard and unnecessary workflow, is *not* a good option.
Bug#894757: libmypaint-common: file conflict with mypaint-data
One possible solution here is to change the translation domain used either by libmypaint or by mypaint. I think it would be better to change the domain used by mypaint (to, e.g., "mypaint12"), since that change would only have to be a temporary one, until the next version comes out, which will (if I understand correctly) *use* libmypaint. But of course, you'd have to coordinate with the maintainer(s) to make that happen. I took a look at the mypaint source, and unfortunately they don't have a centralized location where the translation domain is defined. (Say what you want about autoconf, but if they used it, this wouldn't have been a problem.) I think I *might* be able to make a patch, but it's enough effort (without autoconf) that I'd want to know the mypaint maintainer was interested before I bothered. Or you could change the translation domain used by libmypaint (perhaps to "libmypaint"), but that is a lesser solution, since the patch wouldn't have a clearly defined expiration date.
Bug#826281: Term "language" in package description is ambiguous
Source: libexttextcat Version: 3.4.4-1 Severity: minor Package descriptions for the various libexttextcat packages say: "It was primarily developed for language guessing". It's unclear whether this refers to computer languages (C vs. Python) or natural languages (English vs. Estonian). Given that it's a software library, it could easily be either one. Mentioning Cavnar & Trenkle, "N-Gram-Based Text Categorization" is *suggestive*, but users who aren't familiar with that work shouldn't have to guess what it implies. If it can recognize natural languages, it would be really nice if the description said so. In addition to being more clear, it would probably help package searches if the string "natural language" appeared in the package description. For bonus points, the common abbreviation "NLP" (for "natural language processing") could appear as well, which would probably aid computational linguists, if no one else. But that's much less important.
Bug#712861: patch doesn't work
For those who are running jessie/testing, and may not have the fixed
package for an unknown amount of time, here's a patch that worked for
me.
--- js/ui/status/bluetooth.js.orig 2013-06-30 12:26:05.0 -0700
+++ js/ui/status/bluetooth.js 2013-06-30 12:30:16.0 -0700
@@ -5,6 +5,7 @@
const GLib = imports.gi.GLib;
const Gio = imports.gi.Gio;
const GnomeBluetoothApplet = imports.gi.GnomeBluetoothApplet;
+const GnomeBluetooth = imports.gi.GnomeBluetooth;
const Gtk = imports.gi.Gtk;
const Lang = imports.lang;
const Mainloop = imports.mainloop;
@@ -36,11 +37,11 @@
this._applet.connect('notify::killswitch-state', Lang.bind(this, this._updateKillswitch));
this._killswitch.connect('toggled', Lang.bind(this, function() {
let current_state = this._applet.killswitch_state;
-if (current_state != GnomeBluetoothApplet.BluetoothKillswitchState.HARD_BLOCKED &&
-current_state != GnomeBluetoothApplet.BluetoothKillswitchState.NO_ADAPTER) {
+if (current_state != GnomeBluetooth.KillswitchState.HARD_BLOCKED &&
+current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER) {
this._applet.killswitch_state = this._killswitch.state ?
-GnomeBluetoothApplet.BluetoothKillswitchState.UNBLOCKED:
-GnomeBluetoothApplet.BluetoothKillswitchState.SOFT_BLOCKED;
+GnomeBluetooth.KillswitchState.UNBLOCKED:
+GnomeBluetooth.KillswitchState.SOFT_BLOCKED;
} else
this._killswitch.setToggleState(false);
}));
@@ -94,10 +95,10 @@
_updateKillswitch: function() {
let current_state = this._applet.killswitch_state;
-let on = current_state == GnomeBluetoothApplet.BluetoothKillswitchState.UNBLOCKED;
-let has_adapter = current_state != GnomeBluetoothApplet.BluetoothKillswitchState.NO_ADAPTER;
-let can_toggle = current_state != GnomeBluetoothApplet.BluetoothKillswitchState.NO_ADAPTER &&
- current_state != GnomeBluetoothApplet.BluetoothKillswitchState.HARD_BLOCKED;
+let on = current_state == GnomeBluetooth.KillswitchState.UNBLOCKED;
+let has_adapter = current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER;
+let can_toggle = current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER &&
+ current_state != GnomeBluetooth.KillswitchState.HARD_BLOCKED;
this._killswitch.setToggleState(on);
if (can_toggle)
Bug#190133: Bug #190133: extract wxcopy and wxpaste from wmaker?
Hi, this bug appears to be a duplicate of bug #78119, except that 78119 suggests including wmsetbg as well, and calling the package wmutils, or something like that. As someone who installs wmaker mainly to get wmsetbg (though I occasionally use it for various tests), I prefer the suggestion in 78119. I also think it might be appropriate to merge the bugs.
Bug#676463: problematic scripts
This seems to be the source of the problem:
~ $ dpkg-query -W -f='${Conffiles} ${Version}\n' fuse|grep obsolete
/etc/init.d/fuse 453b0e3f3f8facb9efc6cc73df8a7f05 obsolete 2.9.0-1
~ $ dpkg-query -W -f='${Conffiles} ${Version}\n' initscripts|grep obsolete
/etc/init.d/stop-bootlogd 4544c7e1a2d0c713d29424d02faad237 obsolete
/etc/init.d/bootlogd 267ceea04f703171e6c62f506fda3305 obsolete
/etc/init.d/stop-bootlogd-single 648d8624e708151500c5e299a6005afe
obsolete 2.88dsf-27
I think the problem here comes from the sysv-rc package's assumption that
files marked obsolete must come from packages which have been deleted
but not purged. This assumption is clearly incorrect, and I recommend
changing it.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#473006: planned NMU for blt
Hi, sorry, thought I'd turned blt over to the Tcl team already. Feel free to change the Maintainer field to reflect team maintainership. thanks, Chris On Thu, Feb 26, 2009 at 04:38:19PM +0100, Matthias Klose wrote: > planning to upload a NMU for this report. The Tcl team wants to remove 8.3, > and > I would like to build python-tk using 8.5 when introducing new python > versions. > > Matthias > > > -- Chris Waters | Pneumonoultra-osis is too long xt...@debian.org | microscopicsilico-to fit into a single or xt...@speakeasy.net | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#503967: xarclock: Please add a .desktop file
On Debian, the menu package will generate .desktop files for you if (and only if) you have software that uses .desktop files installed, so including them in each package would be pointless, counterproductive and wasteful. Including a .desktop file makes sense for some packages--mainly, those which are tightly integrated with one of the desktop environments that uses .desktop files. Xarclock is not such a package (to put it mildly). In general, though, including .desktop files with random Debian packages is, in my opinion, an extremely bad idea. I may be prejudiced since on my system they serve no purpose except to waste inodes, but I see no reason why Debian should do stupid things simply because Ubuntu foolishly refuses to incorporate menu in their core. On Wed, Oct 29, 2008 at 11:55:56PM +0100, Martin Pitt wrote: > Package: xarclock > Version: 1.0-12 > Severity: wishlist > Tags: patch > User: [EMAIL PROTECTED] > Usertags: ubuntu-patch origin-ubuntu > > Hello, > > a while ago, Vassilis Pandis contributed a .desktop file in > https://launchpad.net/bugs/45399. It does not include i18n > infrastructure, but it's better than not having one at all. > > Thanks, > > Martin > > -- > Martin Pitt| http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) > diff -pruN 1.0-11.1/debian/rules 1.0-11.1ubuntu2/debian/rules > --- 1.0-11.1/debian/rules 2007-09-18 22:02:33.0 +0100 > +++ 1.0-11.1ubuntu2/debian/rules 2007-09-18 20:14:50.0 +0100 > @@ -33,6 +33,9 @@ install-stamp: build-stamp > `pwd`/debian/xarclock/usr/bin/xarclock > touch install-stamp > > + install -d `pwd`/debian/xarclock/usr/share/applications > + install -m644 debian/xarclock.desktop > `pwd`/debian/xarclock/usr/share/applications > + > # Build architecture-independent files here. > binary-indep: build install > # We have nothing to do by default. > diff -pruN 1.0-11.1/debian/xarclock.desktop > 1.0-11.1ubuntu2/debian/xarclock.desktop > --- 1.0-11.1/debian/xarclock.desktop 1970-01-01 01:00:00.0 +0100 > +++ 1.0-11.1ubuntu2/debian/xarclock.desktop 2007-09-18 20:14:50.0 > +0100 > @@ -0,0 +1,9 @@ > +[Desktop Entry] > +Version=1.0 > +Type=Application > +Name=Counter-clockwise clock > +GenericName=Counter-clockwise clock > +Comment=If clocks had been invented in the southern hemisphere, they would > run counter-clockwise. > +Icon=xarclock > +Exec=xarclock > +Categories=Clock;Amusement;Utility; -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477630: 'man xarclock' typo: "recyled"
On Thu, Apr 24, 2008 at 12:39:03AM -0400, A. Costa wrote: > Found a typo in '/usr/share/man/man1/xarclock.1.gz', see attached '.diff'. > Hope this helps... Wow, don't get many bug reports for this package these days! :) Anyway, thanks, I'll definitely include it in the next upload. cheers, -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397939: Lintian: outdated-autotools-helper-file
On Sun, Feb 17, 2008 at 08:08:47PM +0100, Bas Wijnen wrote: > Let's compare it with a Java program. Would you consider it acceptable > for the packager to build it, uuencode it, put it in the diff.gz and > from debian/rules just uudecode it, instead of regenerating it? Well, I see one big difference. I often get patches from downstream to configure. I, of course, make sure to apply them to the appropriate .am (or whatever), as well as forwarding them upstream. But to me, this indicates that downstream often considers the configure file to be a readable source format. This cannot be said of a uuencoded binary. I think that's an important distinction. Whether that distinction is sufficient to justify a different set of rules, I reserve judgement on at this time. But honestly, I think our job is to deliver full source and binaries. I _don't_ think we necessarily have to exercise every bit of the source (e.g. the .am files) on every build. In fact, my primary objections to the java example would be a) that it confounds user expectations, and b) that it would result in huge diffs. I'm not sure that either of those objections would apply to the autoconf case. > The fact that there exist packages which work properly without > recompiling from source doesn't mean it's a good default. IMO the > default should be to always compile from source. Yes, that means hassle > for the packager; it's pretty much the whole task of packaging. I think there's a big difference between recompiling from source as an end user would do and (re)generating _everything_ as an upstream might do. I suspect the ultimate question here is: does Debian serve as a) a proxy for the user, generating binaries so they don't have to, or b) as a proxy for upstream? I tend to lean towards the former position; it sounds like you lean towards the latter. Bottom line: it sounds like you think the java example is fundamentally wrong; I merely see it as flawed, awkward and hard to maintain: a bad idea in general, but not necessarily wrong. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456031: Found workaround
On Mon, Dec 17, 2007 at 07:59:29PM -0800, H. S. Teoh wrote: > I found a workaround for this problem, just thought I should > document this in the bug in case anyone else runs into it in the > future. Congrats on getting it to work, and good idea documenting it. Thanks. > Note that this workaround isn't the best, since you lose all ability to > resize the window and have to live with the default dimensions xbomb > chooses. But at least xbomb and ratpoison won't fight over resize > events. You don't actually have to live with the defaults: xbomb recognizes most standard X command-line arguments, like -geometry to set the size. See the OPTIONS section of the X(7) man page for a list of standard arguments. You can also override the defaults more permanently by setting X resources. See the xrdb and xbomb man pages for more. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456302: ted never opens anything
On Mon, Dec 17, 2007 at 09:47:48AM -0600, hugo vanwoerkom wrote: > SOLVED. Ted needs the transcoded fonts. > Chris, I really appreciate your help. Thanks a lot! Cool, glad you got it working. Wish I had an easier solution, but that's going to require some more time and effort. cheers, Chris -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456031: XBomb interacts badly with ratpoison
On Sun, Dec 16, 2007 at 08:02:35AM -0800, H. S. Teoh wrote: > But what about terminal windows? They seem to always have sizes of an > integral multiple of the base font size. Ratpoison does respect this. Or > is this a totally different mechanism altogether? It's a different mechanism. Xterm has: WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified resize increment: 9 by 18 Xbomb's increments are non-linear (they're proportional to the sizes of the sides of the hexagons and triangles it needs to draw). And, of course, the ratio of width to height has to remain constant. I'm not aware of any WM hints to support either of those (but I'd be happy to learn otherwise). > Feel free to reassign this bug to ratpoison if you wish. I'll probably keep this around as a wishlist item while I investigate further options, but I might make a copy for ratpoison. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456302: ted never opens anything
On Sun, Dec 16, 2007 at 05:12:23AM -0600, hugo vanwoerkom wrote: > Those are installed: > ... > ii xfonts-100dpi 1:1.0.0-4 >100 dpi fonts for X [...] > It would be strange if the standard default install of Etch not > installed xfonts. Yes, but Ted seems to need the transcoded fonts, which are more compatible with the 1990s era Motif-based systems that Ted was designed to work with. Please install the "xfonts-100dpi-transcoded and xfonts-75dpi-transcoded packages and see if that fixes your problem. thanks, Chris -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456302: ted never opens anything
On Sat, Dec 15, 2007 at 04:37:19PM -0600, hugo vanwoerkom wrote:
> I have tried this on 2 systems with the same result:
One possibility: do you have xfonts-{75,100}dpi-transcoded installed?
And if not, could you try installing them to see if that fixes the
problem? If so, it's a known bug for which I have a partial-but-
incomplete fix. Otherwise, I may have to try to get you a debug
version.
--
Chris Waters | Pneumonoultra-osis is too long
[EMAIL PROTECTED] | microscopicsilico-to fit into a single
or [EMAIL PROTECTED] | volcaniconi- standalone haiku
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456302: ted never opens anything
On Fri, Dec 14, 2007 at 06:51:01AM -0600, hugo vanwoerkom wrote: > ted never opens anything. > the initial picture just stays there. > with new file I get this on the console: I can't reproduce this. I do see all those messages on the console, (and it;s possible that the first one indicates that Ted should be relinked sometime soon), but Ted opens up a new document window or an existing file just fine for me. Can you provide some more information about your environment? What window manager or desktop environment are you using? -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456031: XBomb interacts badly with ratpoison
On Wed, Dec 12, 2007 at 05:04:46PM -0800, H. S. Teoh wrote: > Something must be wrong with the way xbomb resizes itself, because > non-maximal windows are possible under ratpoison (e.g. transients in > games like freedroid-rpg, xscavenger, etc., which manage to get a > non-maximal size without being in an infinite loop fighting with the > WM). Nothing is wrong with the way xbomb resizes itself. There is no way to mark a window as "resizeable only in fixed increments" like there is for non-resizeable windows. Ratpoison respects the latter (because it has to); it also needs to respect the former by not attempting to resize a window more than once (or, at least, not more than once within a given short time period). If an application rejects the size that ratpoison selects for it, ratpoison needs to respect that. The question really is: who knows more about an application's needs--the application itself, or the window manager? I think it's pretty obviously the application itself. If there's an X-hint of some sort I can add to xbomb to make ratpoison more willing to respect its needs, then I'm willing to do that, but further than that I'm really not willing to go. In the mean time, there are several possible workarounds: 1. Run Xnest and run xbomb under that. 2. Create a ratpoison frame of a size that xbomb will accept before launching xbomb. 3. Possibly tell ratpoison that xbomb's window should be unmanaged (note: I was not able to get this to work, but I'm not a ratpoison expert.) But my opinion is that the bug here is in ratpoison. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#450651: libmtp: signed/unsigned int problems in examples/utils
On Thu, Nov 08, 2007 at 10:29:23PM +0100, Rafael Laboissiere wrote:
> Thanks for finding and fixing this bug. Could you please also check whether
> version 0.2.3-1 (in experimental) is also affected by this bug?
Yes 0.2.3 has the same problem and the patch file applies cleanly
(with patch -p1 from the base directory).
> I think I will wait until the libmtp6/amarok/gnomad2 transition into
> testing is completed.
That makes sense. Plus, I don't think any uploads are being processed
right now because of the server problems.
> Yes, it would be great if you could provide two separate patches, one for
> each problem.
I've made a patch just for the signed/unsigned issue (attached). I
don't have a complete solution for the memory leaks yet, and it's a
much more minor issue, so it will have to wait till I have more time.
cheers
--
Chris Waters | Pneumonoultra-osis is too long
[EMAIL PROTECTED] | microscopicsilico-to fit into a single
or [EMAIL PROTECTED] | volcaniconi- standalone haiku
diff -ur libmtp-0.2.2.old/examples/albumart.c libmtp-0.2.2/examples/albumart.c
--- libmtp-0.2.2.old/examples/albumart.c2007-03-28 23:00:40.0
-0700
+++ libmtp-0.2.2/examples/albumart.c2007-11-07 22:48:24.0 -0800
@@ -43,6 +43,7 @@
char *imagedata = NULL;
char *albumname = NULL;
char *path = NULL;
+ char *rest;
struct stat statbuff;
fprintf(stdout, "libmtp version: " LIBMTP_VERSION_STRING "\n\n");
@@ -58,7 +59,7 @@
return 1;
}
ids = tmp;
- ids[(idcount-1)] = atoi(strdup(optarg));
+ ids[(idcount-1)] = strtoul(optarg, &rest, 0);
break;
case 'n':
albumname = strdup(optarg);
diff -ur libmtp-0.2.2.old/examples/newplaylist.c
libmtp-0.2.2/examples/newplaylist.c
--- libmtp-0.2.2.old/examples/newplaylist.c 2007-03-28 23:00:41.0
-0700
+++ libmtp-0.2.2/examples/newplaylist.c 2007-11-07 22:46:39.0 -0800
@@ -39,6 +39,7 @@
uint32_t *ids = NULL;
uint32_t *tmp = NULL;
char *playlistname = NULL;
+ char *rest;
fprintf(stdout, "libmtp version: " LIBMTP_VERSION_STRING "\n\n");
@@ -53,7 +54,7 @@
return 1;
}
ids = tmp;
- ids[(idcount-1)] = atoi(strdup(optarg));
+ ids[(idcount-1)] = strtoul(optarg, &rest, 0);
break;
case 'n':
playlistname = strdup(optarg);
diff -ur libmtp-0.2.2.old/examples/pathutils.c libmtp-0.2.2/examples/pathutils.c
--- libmtp-0.2.2.old/examples/pathutils.c 2007-03-16 08:19:44.0
-0700
+++ libmtp-0.2.2/examples/pathutils.c 2007-11-07 22:58:01.0 -0800
@@ -56,9 +56,11 @@
int
parse_path (char * path, LIBMTP_file_t * files, LIBMTP_folder_t * folders)
{
+ char *rest;
// Check if path is an item_id
if (*path != '/') {
-int item_id = atoi(path);
+int item_id = strtoul(path, &rest, 0);
+// really should check contents of "rest" here...
return item_id;
}
// Check if path is a folder
diff -ur libmtp-0.2.2.old/examples/thumb.c libmtp-0.2.2/examples/thumb.c
--- libmtp-0.2.2.old/examples/thumb.c 2007-03-28 23:00:41.0 -0700
+++ libmtp-0.2.2/examples/thumb.c 2007-11-07 23:02:36.0 -0800
@@ -41,6 +41,7 @@
uint64_t filesize;
uint8_t *imagedata = NULL;
char *path = NULL;
+ char *rest;
struct stat statbuff;
int ret;
@@ -51,7 +52,7 @@
case 'h':
usage();
case 'i':
- id = atoi(strdup(optarg));
+ id = strtoul(optarg, &rest, 0);
break;
default:
usage();
Bug#450651: libmtp: signed/unsigned int problems in examples/utils
Package: mtp-tools
Version: 0.2.2-2
Tags: patch
The example code which comes with libmtp and which is used to create
the command-line tools in the mtp-tools package uses atoi(3) for some
of its command-line parsing, which has problems if the file ids on the
mtp device are greater than INT_MAX. I managed to crash my mp3 player
by making a playlist with bad data because of this bug.
I've patched the utils to use strtoul instead, and the rebuilt package
is working great here, so I'm sending you the patch. You may want to
forward this to upstream as well.
My patch also fixes a few (though not all) minor memory leaks.
Apparently someone didn't realize that strdup(3) calls malloc(3).
These leaks are probably mostly harmless, since the programs exit
after doing their work, which frees all the leaked memory, but as a
matter of general principle, I tried to fix the most obvious ones I
spotted. If you'd prefer, I can send you a trimmed-down patch which
only fixes the signed/unsigned problems.
cheers
--
Chris Waters | Pneumonoultra-osis is too long
[EMAIL PROTECTED] | microscopicsilico-to fit into a single
or [EMAIL PROTECTED] | volcaniconi- standalone haiku
diff -ur libmtp-0.2.2.old/examples/albumart.c libmtp-0.2.2/examples/albumart.c
--- libmtp-0.2.2.old/examples/albumart.c2007-03-28 23:00:40.0
-0700
+++ libmtp-0.2.2/examples/albumart.c2007-11-07 22:48:24.0 -0800
@@ -43,6 +43,7 @@
char *imagedata = NULL;
char *albumname = NULL;
char *path = NULL;
+ char *rest;
struct stat statbuff;
fprintf(stdout, "libmtp version: " LIBMTP_VERSION_STRING "\n\n");
@@ -58,7 +59,7 @@
return 1;
}
ids = tmp;
- ids[(idcount-1)] = atoi(strdup(optarg));
+ ids[(idcount-1)] = strtoul(optarg, &rest, 0);
break;
case 'n':
albumname = strdup(optarg);
diff -ur libmtp-0.2.2.old/examples/newplaylist.c
libmtp-0.2.2/examples/newplaylist.c
--- libmtp-0.2.2.old/examples/newplaylist.c 2007-03-28 23:00:41.0
-0700
+++ libmtp-0.2.2/examples/newplaylist.c 2007-11-07 22:46:39.0 -0800
@@ -39,6 +39,7 @@
uint32_t *ids = NULL;
uint32_t *tmp = NULL;
char *playlistname = NULL;
+ char *rest;
fprintf(stdout, "libmtp version: " LIBMTP_VERSION_STRING "\n\n");
@@ -53,7 +54,7 @@
return 1;
}
ids = tmp;
- ids[(idcount-1)] = atoi(strdup(optarg));
+ ids[(idcount-1)] = strtoul(optarg, &rest, 0);
break;
case 'n':
playlistname = strdup(optarg);
diff -ur libmtp-0.2.2.old/examples/pathutils.c libmtp-0.2.2/examples/pathutils.c
--- libmtp-0.2.2.old/examples/pathutils.c 2007-03-16 08:19:44.0
-0700
+++ libmtp-0.2.2/examples/pathutils.c 2007-11-07 22:58:01.0 -0800
@@ -56,9 +56,11 @@
int
parse_path (char * path, LIBMTP_file_t * files, LIBMTP_folder_t * folders)
{
+ char *rest;
// Check if path is an item_id
if (*path != '/') {
-int item_id = atoi(path);
+int item_id = strtoul(path, &rest, 0);
+// really should check contents of "rest" here...
return item_id;
}
// Check if path is a folder
@@ -83,11 +85,13 @@
if (file->parent_id == parent_id) {
if (strcasecmp (file->filename, filename) == 0) {
int item_id = file->item_id;
+ free(dirc); free(basec);
return item_id;
}
}
file = file->next;
}
+free(dirc); free(basec);
} else {
return item_id;
}
diff -ur libmtp-0.2.2.old/examples/thumb.c libmtp-0.2.2/examples/thumb.c
--- libmtp-0.2.2.old/examples/thumb.c 2007-03-28 23:00:41.0 -0700
+++ libmtp-0.2.2/examples/thumb.c 2007-11-07 23:02:36.0 -0800
@@ -41,6 +41,7 @@
uint64_t filesize;
uint8_t *imagedata = NULL;
char *path = NULL;
+ char *rest;
struct stat statbuff;
int ret;
@@ -51,7 +52,7 @@
case 'h':
usage();
case 'i':
- id = atoi(strdup(optarg));
+ id = strtoul(optarg, &rest, 0);
break;
default:
usage();
Bug#432128: battleball menu entry: please move it to Games/Action
On Sat, Jul 07, 2007 at 10:23:52PM +0200, Bill Allombert wrote:
> A minor point:
> command="battleball $DISPLAY comp"
> should work too: command should be executed by the equivalent of
> execl("/bin/sh","sh","-c",command,NULL)
> If you know window manager where
> command="/bin/sh -c 'exec /usr/games/battleball $DISPLAY comp'"
> work but not
> command="battleball $DISPLAY comp"
> please tell me.
According to the changelog, I fixed the battleball menu to use the
"sh -c exec" hack in response to bug #245697. The archived report
simply refers to "Gnome", and I'm not sure if it's still a problem
there, but I'm reluctant to revert without a more clear indication
that reverting will be safe. The current code, though admittedly
baroque, should work with anything.
The other changes in the menu file are ready, and will be uploaded
ASAP, thanks.
--
Chris Waters | Pneumonoultra-osis is too long
[EMAIL PROTECTED] | microscopicsilico-to fit into a single
or [EMAIL PROTECTED] | volcaniconi- standalone haiku
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404872: tcl exec and open cannot pass certain arguments
On Thu, Dec 28, 2006 at 07:46:53PM +, Ian Jackson wrote:
> The exercise is to allow for example what would be achieved in sh with
>echo ">" not a redirect >filename
Well, it may be a workaround, but:
tclsh8.4 [~]exec sh -c {echo '>'}
>
tclsh8.4 [~]
Works For Me(TM). :)
For a more sophisticated example:
tclsh8.4 [~]set a [open {|sh -c "echo '>'"} r]
file6
tclsh8.4 [~]set b [read $a]
>
tclsh8.4 [~]close $a
tclsh8.4 [~]puts $b
>
tclsh8.4 [~]
I can report the issue upstream, but unless you can find an example
that can't be worked around, I doubt if it will be much of a priority.
cheers
--
Chris Waters | Pneumonoultra-osis is too long
[EMAIL PROTECTED] | microscopicsilico-to fit into a single
or [EMAIL PROTECTED] | volcaniconi- standalone haiku
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Sun, Oct 15, 2006 at 09:13:11PM +0100, Neil McGovern wrote: > On Sun, Oct 15, 2006 at 11:57:47AM -0700, Chris Waters wrote: > > I don't know if it can always be avoided. > [snip lots of good examples where this is unavoidable] > > I would go for strongly discouraging the practice, but I think that > > flat-out forbidding it might be excessive at this point. > Hence this being "should not", rather than "must not". We're aware > that it's not alwars possible, and you phrased it wonderfully. We want > to strongly discourage it, rather than flat-out forbidding it :) "Should not" says that it's always a bug--just not an RC bug. I'm saying that perhaps sometimes it's not a bug. Although I strongly agree that it should _usually_ be a bug. In fact, as the tcl/tk maintainer, I have a vested interest in making it always be a bug. But I'm trying to bend over backwards to be fair to my dependents...or non-dependents, as the case may be. I would love to see perl-tk built against my packages. But I realize there are valid reasons why it's currently not. Anyway, I'm not going to formally object or anything. I just wanted to toss the notion out and see what happened. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392362: [PROPOSAL] Add should not embed code from other packages
On Sun, Oct 15, 2006 at 11:24:22AM +0100, Neil McGovern wrote: > We want to avoid packages shipping their own versions of libraries, > as then if a security problem or major bug is discovered in that > library, we have lots of packages to update, and there's no garuntee > we'll even know which packages it affects. I don't know if it can always be avoided. The perl-tk package, for example, embeds its own versions of tcl and tk, but that's an upstream choice. Basically, they maintain their own fork. On the one hand, if a hole is found in tcl or tk, it might go unnoticed in perl-tk BUT on the other hand, there's no guarantee that any other version of tcl or tk will even work with perl-tk! Can we force perl-tk upstream to merge their fork? I doubt it would be easy, but you're welcome to try. Should we re-fork perl-tk on our own? That sounds like madness, but you're welcome to try. In either case, though, I think there's a whole lot of required work before perl-tk could be brought in line with this proposal. Also, some libraries come with compile-time options, and a particular package may need a version built with different options than the main version of the library in Debian. Ideally, we would provide an alternate version of the library package, but it's not always that easy. I would go for strongly discouraging the practice, but I think that flat-out forbidding it might be excessive at this point. At the very least, I think we should get some feedback from the people who are engaging in this practice before passing any absolute bans. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390739: blank screen (no output) with mga g400
Ok, I force-downgraded to the following packages from testing: xserver-xorg-core_1.0.2-9_i386.deb xserver-xorg-input-kbd_1.0.1.3-2_i386.deb xserver-xorg-input-mouse_1.0.4-3_i386.deb xserver-xorg-video-mga_1.2.1.3.dfsg.1-2_i386.deb And with no other changes or reconfiguration, X works again. So it definitely looks like a nasty bug somewhere in X7.1. Probably in xserver-xorg-video-mga, possibly in xserver-xorg-core. If you need anything more from me to help track this down, please don't hestitate to ask. I'm more than willing to re-break my system to help debug. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390739: blank screen (no output) with mga g400
Package: xserver-xorg Version: 1:7.1.0-1 Severity: important I'm using an MGA G400, and with the new update to xorg 7.1, my screen suddenly stopped working. I can switch to the console at vt1, and the screen comes back. And X appears to be running fine (all the processes look ok, and I can hear WMMail make noise when mail comes in), but when I'm on vt7, the monitor reports "no input signal" and nothing is visible. Keyboard and mouse input seem to be fine, although it's hard to tell when you can't see anything, but I can use ctrl-alt-bksp to kill the Xserver. It all worked fine with 7.0, and nothing (that I know of) has changed, other than the Xserver version. I've tried reconfiguring without success. I'm generally pretty good at figuring out odd X server problems, but this one has me stumped. At this point, I'm pretty sure this is a bug, and not misconfiguration -- though I'd be happy to be proved wrong. Anyway, I'm completely without a usable X at the moment. Help! One thing that might be relevant: I tried reconfiguring with autodetect, and it seemed to want to use the on-board SiS controller (piece of junk) on my motherboard rather than the G400. I'm wondering if it's still somewhat confused even with the manual configuration. But it used to work just fine! I'll happily provide any log files or other information that isn't automatically attached to this report, if it will help. Just let me know what you want. TIA -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages xserver-xorg depends on: ii debconf 1.5.5Debian configuration management sy ii x11-common 1:7.1.0-1X Window System (X.Org) infrastruc ii xbase-clients 1:7.1.ds-3 miscellaneous X clients ii xkb-data0.8-15 X Keyboard Extension (XKB) configu ii xserver-xorg-core 2:1.1.1-9X.Org X server -- core server ii xserver-xorg-input-evde 1:1.1.2-3X.Org X server -- evdev input driv ii xserver-xorg-input-kbd 1:1.1.0-3X.Org X server -- keyboard input d ii xserver-xorg-input-mous 1:1.1.1-3X.Org X server -- mouse input driv ii xserver-xorg-video-apm 1:1.1.1-3X.Org X server -- APM display driv ii xserver-xorg-video-ark 1:0.6.0-3X.Org X server -- ark display driv ii xserver-xorg-video-ati 1:6.6.2-2X.Org X server -- ATI display driv ii xserver-xorg-video-chip 1:1.1.1-4X.Org X server -- Chips display dr ii xserver-xorg-video-cirr 1:1.1.0-3X.Org X server -- Cirrus display d ii xserver-xorg-video-cyri 1:1.1.0-4X.Org X server -- Cyrix display dr ii xserver-xorg-video-dumm 1:0.2.0-3X.Org X server -- dummy display dr ii xserver-xorg-video-fbde 1:0.3.0-3X.Org X server -- fbdev display dr ii xserver-xorg-video-glin 1:1.1.1-3X.Org X server -- Glint display dr ii xserver-xorg-video-i128 1:1.2.0-3X.Org X server -- i128 display dri ii xserver-xorg-video-i740 1:1.1.0-3X.Org X server -- i740 display dri ii xserver-xorg-video-i810 2:1.6.5-3X.Org X server -- Intel i8xx, i9xx ii xserver-xorg-video-imst 1:1.1.0-3X.Org X server -- IMSTT display dr ii xserver-xorg-video-mga 1:1.4.1.dfsg.1-4 X.Org X server -- MGA display driv ii xserver-xorg-video-neom 1:1.1.1-4X.Org X server -- Neomagic display ii xserver-xorg-video-newp 1:0.2.0-3X.Org X server -- Newport display ii xserver-xorg-video-nsc 1:2.8.1-3X.Org X server -- NSC display driv ii xserver-xorg-video-nv [ 1:1.2.0-3X.Org X server -- NV display drive ii xserver-xorg-video-rend 1:4.1.0.dfsg.1-4 X.Org X server -- Rendition displa ii xserver-xorg-video-s3vi 1:1.9.1-3X.Org X server -- S3 ViRGE display ii xserver-xorg-video-sava 1:2.1.2-1X.Org X server -- Savage display d ii xserver-xorg-video-sili 1:1.4.1-4X.Org X server -- SiliconMotion di ii xserver-xorg-video-sis 1:0.9.1-3X.Org X server -- SiS display driv ii xserver-xorg-video-sisu 1:0.8.1-3X.Org X server -- SiS USB display ii xserver-xorg-video-tdfx 1:1.2.1-5X.Org X server -- tdfx display dri ii xserver-xorg-video-tga 1:1.1.0-3X.Org X server -- TGA display driv ii xserver-xorg-video-trid 1:1.2.1-3X.Org X server -- Trident display ii xserver-xorg-video-tsen 1:1.1.0-3X.Org X server -- Tseng display dr ii xserver-xorg-video-vesa 1:1.2.1-3X.Org X server -- VESA display dri ii xserver-xorg-video-vga 1:4.1.0-3X.Org X server -- VGA display driv ii xserver-xorg-video-via 1:0.2.1-5X.Org X server -- VIA display driv ii xserver-xorg-video-vmwa 1:10.13.0-3 X.Org X server -- VMware display d ii xserver-xorg-video-vood 1:1.1.0-3X.Org X server
Bug#384720: tk8.4: error messages with "wish -h"
Hi, Just got back from enforced vacation (dead machine). The patch looks ok, but I think I want to check with upstream before replacing an error return from a function with an exit. It all seems sensible to me, but I want to make sure there's no hidden side-effects before incorporating it. thanks -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367821: No .desktop file
On Thu, May 18, 2006 at 12:24:39PM +0100, Vassilis Pandis wrote: > I'm attaching a .desktop file for xarclock Debian does not use .desktop files. Such files are generated automatically only if needed. There does seem to be a problem with the menu file used to generate menu entries (including .desktop files). I'll include a fix with the next release. Thanks for calling this to my attention. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366930: 'man tclreadline' typos: "compatiblity" and "succes"
On Fri, May 12, 2006 at 03:37:11AM -0400, A Costa wrote: > Found a few typos in '/usr/share/man/man3/tclreadline.3tclrl.gz', Cool, thanks, will be patched in the next upload. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366512: ted: Fails to display file
On Tue, May 09, 2006 at 09:29:20PM -0400, Neil Roeth wrote: > The major font-related thing I did recently was switching to the new X11R7 > scheme where all fonts are in /usr/share/fonts/X11 rather than > /usr/X11R6/lib/X11/fonts. Hmm, ok, that looks like a place I can investigate further. I wouldn't think that would affect it, but Ted does do some funny things with fonts. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366512: ted: Fails to display file
package ted tags 366512 unreproducible moreinfo thanks On Tue, May 09, 2006 at 06:47:20AM -0400, Neil Roeth wrote: > Starting Ted like so: > $ ted /usr/share/ted/Ted/TedDocument-en_US.rtf > makes the initial screen pop up, but the file that I am trying to > edit does not. Since I cannot even see the document I am trying to > edit, much less edit it, I consider that unuseable. Well, that sounds like a reasonable asssessment. Unfortunately, I cannot reproduce your problem here. I'll need more information to get to the bottom of this. > The following messages appear in the xterm from which I started Ted: > appFont.c(812) aff->affFontFamilyName="Helvetica" afe->afeXfontFamilies=0x0 [...] Hmm, it seems to be complaining that it can't find anything to use as a Helvetica font for that document. What happens if you do: xlsfont | grep -i helvetica Note that providing appropriate fonts is up to you. Debian packages cannot depend on particular fonts, because your Xserver and/or your font server may be located on different machines. Furthermore, there is no way for Ted to know which fonts might be required, because those are defined by the documents. Hence, as I say, providing the fonts you need is up to you. However, if this is the problem, then I do think that Ted could provide a more helpful error message! If access to fonts is not the problem, then I'm really not sure what to think. In any case, please send me the output of the command above. That should at least give me a starting point. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365542: file-roller needs to Replace: old gnome-icon-theme package
Package: file-roller Version: 2.14.2-1 Severity: normal The file /usr/share/icons/hicolor/48x48/apps/file-roller.png is also found in version 2.12.1-2 of the gnome-icon-theme package (and possibly in other older versions as well). This can cause errors when upgrading or installing. Adding "Replaces: gnome-icon-theme (<< 2.14.0)" should solve the problem. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages file-roller depends on: ii bzip2 1.0.3-2high-quality block-sorting file co ii gconf22.14.0-1 GNOME configuration database syste ii gzip 1.3.5-12 The GNU compression utility ii libatk1.0-0 1.11.3-1 The ATK accessibility toolkit ii libbonobo2-0 2.14.0-1 Bonobo CORBA interfaces library ii libc6 2.3.6-7GNU C Library: Shared libraries ii libcairo2 1.0.2-3The Cairo 2D vector graphics libra ii libfontconfig12.3.2-5generic font configuration library ii libgconf2-4 2.14.0-1 GNOME configuration database syste ii libglade2-0 1:2.5.1-2 library to load .glade files at ru ii libglib2.0-0 2.10.1-2 The GLib library of C routines ii libgnome2-0 2.14.0-1 The GNOME 2 library - runtime file ii libgnomeui-0 2.12.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-02.14.1-1 GNOME virtual file-system (runtime ii libgtk2.0-0 2.8.13-1 The GTK+ graphical user interface ii libnautilus-extension12.12.2-2 libraries for nautilus components ii liborbit2 1:2.14.0-1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.12.1-2 Layout and rendering of internatio ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libx11-6 6.9.0.dfsg.1-5 X Window System protocol client li ii libxcursor1 1.1.3-1X cursor management library ii libxext6 6.9.0.dfsg.1-5 X Window System miscellaneous exte ii libxfixes36.9.0.dfsg.1-5 X Window System miscellaneous 'fix ii libxi66.9.0.dfsg.1-5 X Window System Input extension li ii libxinerama1 6.9.0.dfsg.1-5 X Window System multi-head display ii libxrandr26.9.0.dfsg.1-5 X Window System Resize, Rotate and ii libxrender1 1:0.9.0.2-1X Rendering Extension client libra ii tar 1.15.1-6 GNU tar ii unzip 5.52-7 De-archiver for .zip files ii zip 2.31-3 Archiver for .zip files Versions of packages file-roller recommends: ii arj 3.10.22-2 archiver for .arj files ii lzop 1.01-4 fast compression program ii mkisofs 4:2.01+01a03-5 Creates ISO-9660 CD-ROM filesystem ii p7zip 4.33.dfsg-17-Zip is a file archiver with high ii rpm 4.4.1-8Red Hat package manager ii sharutils 1:4.2.1-15 shar, unshar, uuencode, uudecode -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365126: HELP!! Re: Bug#365126: wmrack - FTBFS: error: WMRack needs X Windows!!!
On Sat, Apr 29, 2006 at 02:03:28PM +0200, Andreas Metzler wrote: > On 2006-04-29 Daniel Stone <[EMAIL PROTECTED]> wrote: > > Er, no, that's AC_PATH_XTRA. AC_PATH_X searches for > > [X11],[X11/Xlib.h],[XrmInitialize ()]. > [...] > Only in Debian (yet) and only since since autoconf 2.59a-4 (#327655). Right, and in this case, while upstream (which is me) uses Debian, he (I) accidentally used autoconf 2.13, which doesn't seem to have the relevant fix. And I don't really want to make a new upstream release just for this. (Although I am going to put Aaron's patch in the project patches section for future inclusion.) So, anyway, I'm pretty sure that Andreas has the right solution. It matches everything I know about the problem. We'll know for sure after my next upload hits the autobuilders. :) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365126: wmrack - FTBFS: error: WMRack needs X Windows!!!
On Fri, Apr 28, 2006 at 09:11:59AM +0200, Bastian Blank wrote: > There was an error while trying to autobuild your package: > [...] > > ** Using build dependencies supplied by package: > > Build-Depends: libx11-dev, libxext-dev, libxpm-dev, xutils, debhelper (>= > > 4.0.0) > > checking for X... no > > configure: error: WMRack needs X Windows!!! > > make: *** [stamp-build] Error 1 Aargh, thanks. But--speaking as upstream and debian maintainer-- almost nothing changed between this version and the previous one (which autobuilt just fine). I am seriously confused. Maybe it's related to the newest X packages. I'll ask around. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361724: wmrack: FTBFS on GNU/kFreeBSD and GNU/Hurd
On Sun, Apr 09, 2006 at 11:30:18PM +0200, Samuel Thibault wrote: > The current version of wmrack fails to build on GNU/kFreeBSD and > GNU/Hurd, because linux/soundcard.h is Linux specific. sys/soundcard.h > should be included instead on *BSD and Hurd. Please find attached a > patch to fix that. It would be nice if you could include it in the next > upload. Hi, thanks, this will be fixed in the next upstream release, which is only waiting on one more bug-fix at the moment. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354492: ted: Add standard Ctrl-Q acceleration key to exit program
On Sun, Feb 26, 2006 at 10:56:26PM +0200, Jari Aalto wrote: > The de facto exit key for graphical programs is Ctrl-Q. Please > add this acceleration key shotcut. I'll suggest this to upstream. In the meantime, you can control this yourself with X resources: Ted.appFileMenuQuitKey: Ctrl q Ted.appFileMenuQuitKeyText: ^Q -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354470: misleading message about permissions when real state is non-existent device file
On Sun, Feb 26, 2006 at 10:43:13AM -0500, Daniel B. wrote: > PilotManager reports a misleading error message when the PDA device file > does not exist. Hi, thanks, that sounds sensible. I'll look into it. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310367: More 'spliting'
On Mon, May 23, 2005 at 04:26:16AM -0400, Alfie Costa wrote: > Besides 'hierbox' the same typo is in 'hiertable' and 'treeview'... Whoops, I missed this addendum when I was going through the list of bug reports. Can you file this as a new bug report so I don't forget next time? Or, if you prefer, I can just go ahead and do it myself, but please let me know. Thanks! -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349276: tk8.0: obsolete package, should be removed?
On Sat, Jan 21, 2006 at 03:06:51PM -0800, Steve Langasek wrote: > It's my impression that the tk8.0 package doesn't serve a purpose anymore in > etch; we have both tk8.3 and tk8.4 which supersede it, and its only > reverse-deps are itcl3.0 and blt Hi, thanks, I completely agree. I'll go ahead and reassign this and upload an updated blt. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347052: intent to upload sponsored NMU to fix xlibs-dev bug
On Tue, Jan 17, 2006 at 10:57:10PM -0500, Justin Pryzby wrote: > package wmmail > tag 347052 patch > thanks > I intend to NMU a fix for this bug sponsored by some member of the QA > group; patch attached. Already handled by maintainer upload, thanks. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346909: intent to upload sponsored NMU to fix xlibs-dev bug
On Wed, Jan 18, 2006 at 01:07:22PM -0500, Justin Pryzby wrote: > package tk8.0 > tag 346909 patch > thanks > I intend to NMU a fix for this bug sponsored by some member of the QA > group; patch attached. An NMU for this package has already been prepared and uploaded, but thanks anyway. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346983: intent to upload sponsored NMU to fix xlibs-dev bug
On Tue, Jan 17, 2006 at 10:55:54PM -0500, Justin Pryzby wrote: > I intend to NMU a fix for this bug sponsored by some member of the QA > group; patch attached. Already handled by maintainer upload, thanks. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346898: intent to upload sponsored NMU to fix xlibs-dev bug
On Tue, Jan 17, 2006 at 10:54:48PM -0500, Justin Pryzby wrote: > package wmrack > tag 346898 patch > thanks > I intend to NMU a fix for this bug sponsored by some member of the QA > group; patch attached. I have some upstream work to finish on this package; an NMU for the Debian package in the meantime would be greatly appreciated, thanks. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
On Wed, Jan 11, 2006 at 11:19:05AM -0500, Kevin B. McCarty wrote: > Could Policy be amended slightly to explicitly permit library source > packages to create a -headers package containing include files? I would rather see it modified to not forbid it than add a whole paragraph to explicitly permit it. I think the suggested text is much too long. I'm not objecting to the idea; merely the wording. [proposed paragraph elided] > Without this or a similar text, it is not clear to me that source > packages creating -headers binary packages are in compliance > with Policy, which currently says "The development files associated to a > shared library need to be placed in a package called > librarynamesoversion-dev, or if you prefer only to support one > development version at a time, libraryname-dev." I would rather see that last sentence modified slightly to allow a little more flexibility. Perhaps changing "placed in" to "placed in or installed by". Or something along those lines. If you can come up with something like that which allows you to do what you want, without going into excessive and unnecessary detail, I can probably be persuaded to second it. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343989: tcl8.* and tk8.* NMUs for configure errors
On Fri, Jan 06, 2006 at 10:49:26AM +0100, Daniel Schepler wrote: > I intend to prepare NMUs for tcl8.[034] and tk8.[34] to fix this bug > over the weekend, and upload Monday morning, unless you object or do > your own uploads before then. I'll also fix the xlibs-dev > dependency of tk8.3 while I'm at it. 8.0 is scheduled for removal -- there was one non-free package still depending on it, but I think that just got fixed recently, so the removal can go ahead, as soon as I update blt. So there's not much point in patching it 8.0. There's a new upstream of 8.4 that I'm currently working on. As for 8.3, I'll have new packages uploaded today (they'd be up already, but I had some problems with one of my HDs). But thanks for the offer. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334898: tcl8.4: tclcurl FTBFS because tclsh SEGVs on hppa
tags 334898 + help thanks On Thu, Oct 20, 2005 at 05:33:26PM +0200, Domenico Andreoli wrote: > it looks like tclsh8.4 chokes on the > following 1liner script: > pkg_mkIndex . libTclCurl0.14.1.so tclcurl.tcl \; exit; Well, pkg_mkIndex actually attempts to load and initialize the package, so it's not clear at this point if the problem is in tcl or in the initialization code of tclcurl. I think we may need to call in an hppa expert here. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#226565: Intent to NMU
On Tue, Oct 11, 2005 at 11:28:55PM -0400, dann frazier wrote: > As this bug has been open with a patch for 30 days without a > response from the maintainer, I intend to NMU in 1 week (or earlier, > at the maintainer's request). Hi, sorry, I have been a bit swamped lately; an NMU for tclreadline to fix bug#226565 would be greatly appreciated. thanks -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku signature.asc Description: Digital signature
Bug#314808: Incorrect directory for web applications.
On Mon, Jun 20, 2005 at 12:39:12AM +0100, Julian Gilbey wrote: > On Mon, Jun 20, 2005 at 12:03:01AM +0200, Miguel Gea Milvaques wrote: > > > Also, as this is a draft, the useage of "/usr/share/PACKAGE/www" may > > > change. IMO, it's probably not going to, but it may be worth keeping > > > (main) policy as is until we are in a position to release 1.0 of the > > > WebApps policy. > > > > No problem for me. But It could give little problems. On one of my > > machines a was beholden to remove /usr/share/doc directory, it broke my > > ldap-account-manager installation. > > Note: /usr/share/PACKAGE/www, not /usr/share/doc/PACKAGE/www. > Removing /usr/share/doc should not impact this web suggestion. And what happens if my WebApp package is named "doc"? Or "applnk"? Or "keymaps" or "locale" or "pixmaps" or "zoneinfo"? While /usr/share/* is not the world's most overloaded namespace, its overloaded enough to cause me some concern, and if there are any reasonable alternatives (and I think there are), I would recommend using one instead. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312444: RE : Bug#312444: tcl8.4: tcl compiled with --enable-threads incompatible with forking
On Wed, Jun 08, 2005 at 01:54:15PM +0200, Alain Degreffe wrote: > Right, > But expect package is linked with tcl8.4, so use 8.3 will not work. > What's the best solution ? In my point of view, a fix from upstream or > simply a tcl.8.4-nothread release for expect. Oh man, I thought it was still using 8.3. We should get the expect maintainer into this discussion. An 8.4-nothread package introduces a whole set of its own problems. (Like unexpected conflicts.) My preferred solution _for now_ would be to have expect built against 8.3. But since it's not my package I've been trying to get a debian-tcltk list set up to help discuss and coordinate issues of this sort, but it hasn't happened yet. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312444: tcl8.4: tcl compiled with --enable-threads incompatible with forking
Yes, I'm sorry, but if you need a non-threaded tcl core, you'll have to use the tcl8.3 packages, which are still provided for just this reason. As Francesco pointed out, some packages require a threaded tcl. This is not a bug, though I realize that the situation is far from perfect. I hope to have a better solution by the time etch is released, but for sarge, I'm afraid you'll just have to stick with 8.3. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304805: blt: mention lack of bltwish in readme
On Thu, Apr 14, 2005 at 04:06:01PM +0100, Dave Love wrote: > I think README.Debian should say it's not packaged and explain what > to do instead of invoking it. (That isn't obvious to a Tcl > ignoramus faced with a script which starts > #!/usr/local/bin/bltwish.) Good suggestion, thanks. In the meantime, what to do is, replace that line with: #!/usr/bin/env wish package require BLT -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295649: tk8.4: spinbox widget gets stuck in infinite repeat
On Thu, Feb 17, 2005 at 08:09:40AM +, Adam M. Costello wrote: > The bug is in /usr/lib/tk8.4/spinbox.tcl. It's possible for a spinbox > button to get effectively "stuck down" so that its action gets invoked > repeatedly until the application is killed. Hmm, you did some good research on this bug. > But some window managers can cause a event without any > dragging and without any corresponding button release. In my case, > olvwm allows me to select a window (to give it the focus) by clicking > on it while holding down the WMGrab modifier (which I have configured > to be Control, but I don't think that's relevant). As a side effect, > this causes a event (I don't know why), but no button > release. I'm a little confused by the fact that there's no button release when you click. Seems to me that a click should involve a button-down event followed by a button-release event. But I know it's not always that simple. Anyway, I'll pass this along to upstream and see what they say. Thanks for the report. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294351: Please extend 9.4's ellipsis style requirement tocover maintainer scripts and dpkg
On Mon, Feb 14, 2005 at 06:15:34PM +0100, Christian Perrier wrote: > Quoting Chris Waters ([EMAIL PROTECTED]): > > I could say I want guidance from policy on what color of shirt I wear > > to my next LUG meeting. That doesn't mean it's a matter for policy. > Well, I'm not sure that irony is the best way to handle something that > could be considered from different points of view...Anyway...:) Hmm, fair criticism. It was mostly just that I found the dpkg maintainer's quote to be very odd, and was trying to show by example just how odd I thought it was. > My own opinion about this is that enforcing this in the policy would > probably open the door for far too much such changes. Yup, I fully agree. > *However*, Thomas is certainly right in trying to get some consistency > there. Yes, I very much like Thomas' idea. I just don't think it's a matter for policy, since it's just a suggestion for a single package. Having looked into this a little more, I now think that simple misunderstanding may be why this turned into a major debate. The original wishlist said something like, "please have dpkg follow policy." Of course, what Thomas meant was, "please copy the style mentioned in policy for something unrelated," not "please stop violating policy." And, while hes tried to clarify this distinction later, it's possible that an overworked dpkg maintainer simply didn't take the time to read Thomas' followups with the care that they perhaps deserved. But I'm still not sure. If the dpkg maintainer had answered with a simple "yes" or "no" or even "I'll think about it," that would have made sense, but the request to make this a policy matter really didn't, and that's why I'd like to get more feedback from the dpkg maintainer (assuming he's not sick of the whole matter already). -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294351: Please extend 9.4's ellipsis style requirement tocover maintainer scripts and dpkg
On Mon, Feb 14, 2005 at 11:20:19AM +, [EMAIL PROTECTED] wrote: > No shenanigans here. The dpkg maintainer says that he wants guidance > from policy. I could say I want guidance from policy on what color of shirt I wear to my next LUG meeting. That doesn't mean it's a matter for policy. > He wrote: > Actually my position is that if harmonisation of output > during install/upgrade is to occur, it should be mandated > by policy. Hmm. That's a very peculiar thing for him to say. Perhaps you should ask him why he said that, when the general opinion on the policy list seems to be that this is not at all a matter for policy, and he is free to "harmonize" or not, at his discretion. I can think of three possible reasons he said that: 1. He misunderstands the purpose and scope of policy, 2. He was trying to give you a polite brush-off by setting you an impossible task, or 3. He misunderstood what you were asking for. And that is why I think you should ask for more information - to see which of those three reasons is correct (or if there's some other reason I've overlooked). I tend to think the second reason is most likely, but perhaps I'm judging too harshly. > No my complaint is the one I voiced, that the Debian of today can be > bureaucratic. Making simple changes can sometimes be an > unnecessarily long and disagreeable process. This is exacerbated by people who hide behind the bureaucracy to avoid making decisions they are capable, competent and qualified to make. Few, if any, of us want to or enjoy playing bureaucrat, and thus, you shouldn't be surprised when there is a refusal to decide what color of t-shirt you or the dpkg maintainer should wear, or where you should put the newlines in your own programs' output. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289083: SPARCstn 5 [2004/12/19 daily]: suceeded w/ difficulty
Hi Jurij, You sent a followup to my installation report, but neglected to send me a copy, so I never saw it until just now, when I was looking to respond to a post on the debian-sparc list. Please remember: mail sent to @bugs.debian.org does not get sent forwarded to the originator. If you want (as in this case) moreinfo, you need to make sure to explicitly send the originator a copy. In this case, you're lucky. I was about to put the machine into service on our home LAN, but since I saw your request in time, I'll go ahead and do the more testing you asked for first. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#290672: tcl8.4: man page lsearch(3tcl) is unviewable, emacs comment confuses man
On Sat, Jan 15, 2005 at 10:03:01PM +, Adam M. Costello wrote: > The first line of the lsearch(3tcl) man page (unlike all other 3tcl man > pages) begins with a comment intended for emacs: > '\" -*- nroff -*- > Unfortunately man thinks this is directed at itself, indicating > preprocessors to run, and it fails to display the man page. Hmm, when I try it, I get messages about "ignoring unknown preprocessor" sent to stderr, but the man page itself displays just fine. That would still, I suppose, qualify as a minor bug, but I'm curious why it works on my system but not yours... Anyway, thanks for the report, I'll patch it up as soon. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
