Bug#1020598: rtkit should depend on polkitd instead of policykit-1
Package: rtkit Version: 0.13-4 rtkit depends on policykit-1, which is now a transitional package that pulls in both polkitd and pkexec. Please update rtkit to depend directly on polkitd, thereby helping users remove pkexec. Thanks.
Bug#995305: wine: New upstream release available (6.0.1)
Package: wine Version: 5.0.3-3 Severity: wishlist Hello, Wine upstream has released 6.0.1 (stable), while Debian remains on 5.0.3. An update would be great. Thanks, Christopher Martin
Bug#925465: gerbera: New upstream release available (1.3.0)
Package: gerbera Version: 1.1.0+dfsg-3 Severity: wishlist Upstream has released version 1.3.0. Even if it's too late for buster, having the new version available would be helpful. Thanks, Christopher Martin
Bug#923461: hostapd@.service can start too soon; should wait until device exists
Package: hostapd Version: 2.7+git20190128+0c1e29f-1 Severity: normal hostapd@.service: [Unit] Description=Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator (%I) -After=network.target +After=network.target sys-subsystem-net-devices-%i.device BindsTo=sys-subsystem-net-devices-%i.device The change above fixes a problem whereby the service will often run before USB wifi devices are detected and setup, resulting in failure. Telling the service to wait until after the device in question exists solves the problem. (The problem may not always be noticeable because the service will restart every two seconds, so it will eventually work, but that's hardly the best solution.) Thanks, Christopher Martin
Bug#918658: [networkd] crash on resume in 240
Package: systemd Version: 240-2 Severity: normal Tags: patch After upgrading to systemd 240, networkd started crashing when resuming from a suspended state. About 30 seconds (give or take) after resume, systemd restarted networkd and thus brought the network back up, but the damage had been done. This is the error from the journal: systemd-networkd[458]: Assertion 'IN_SET(link->state, LINK_STATE_CONFIGURING, LINK_STATE_FAILED, LINK_STATE_LINGER)' failed at ../src/network/networkd-link.c:934, function address_handler(). Aborting. The same error was reported and fixed upstream as https://github.com/systemd/systemd/issues/11272, although the reported circumstances were different. Regardless, fixes have been committed upstream, and grabbing the latest version of the relevant file (systemd/src/network/networkd-link.c) and rebuilding systemd fixes the issue on my machine as well. I bring this to your attention only because the freeze is near and 241 may be a ways off... Thanks, Christopher Martin
Bug#917706: nfs-utils: New upstream release available
Source: nfs-utils Version: 1:1.3.4-2.3 Severity: wishlist Upstream has released 2.3.3 and is getting close to 2.3.4, while Debian remains on 1.3.4, which was released in mid-2016. An update in time for buster would be very much appreciated. Thanks, Christopher Martin
Bug#917464: New upstream release available
Package: rygel Version: 0.36.2-3 Severity: wishlist Version 0.37.1 has been released. Thanks, Christopher Martin
Bug#913517: hplip: patch to support IPv6
You're no doubt right that there's scope for improvement, and I don't want to go too far in defending a patch that I didn't write myself. But I would note that, as I understand matters, the patched hplip would only use IPv6 if either an IPv6 address was explicitly passed, or if the hostname resolved to an IPv6 address (say in /etc/hosts - which is what I tested). If that results in problems, then the system is arguably misconfigured elsewhere. These are (presumably most of the time) local network printers we're dealing with, so the state of their IPv6 support is known and controllable. One possibility might be to test matters via an upload to experimental after the next release and watch for reports of breakage. Cheers, Christopher Martin On Mon, Nov 12, 2018 at 6:40 AM Julian Andres Klode wrote: > > On Sun, Nov 11, 2018 at 02:47:12PM -0500, Christopher Martin wrote: > > Package: hplip > > Version: 3.18.10+dfsg0-2 > > Severity: wishlist > > Tags: patch ipv6 > > > > Please see https://bugs.launchpad.net/hplip/+bug/1724089 for the > > original report, which includes a patch that adds IPv6 support to > > libhpmud. > > > > The patch ensures that libhpmud properly resolves IPv6 addresses and > > hostnames. I've tested it against the latest hplip (3.18.10) and it > > works well. > > Having had the experience with dealing with IPv6 support in apt, I am not > convinced it's a good idea. The assumption that > > "The system's C library automatically selects the appropriate addresses (for > example, it omits ipv6 addresses if there is no ipv6 connectivity)." > > is wrong. We've heard a lot of reports from people without _working_ > IPv6 for which apt did not work, which forced me to implement a variant > of happy eyeballs. > > The patch in question does not try multiple address families in parallel, > nor does it seem to have any time out at all, meaning it will get stuck > indefinitely trying to connect to a broken ipv6 host. > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en
Bug#913517: hplip: patch to support IPv6
Package: hplip
Version: 3.18.10+dfsg0-2
Severity: wishlist
Tags: patch ipv6
Please see https://bugs.launchpad.net/hplip/+bug/1724089 for the
original report, which includes a patch that adds IPv6 support to
libhpmud.
The patch ensures that libhpmud properly resolves IPv6 addresses and
hostnames. I've tested it against the latest hplip (3.18.10) and it
works well.
Please consider merging it into Debian's package.
Thanks,
Christopher Martin
From e7bc4bd41239d2e60f0406415ae0cc3d7a40cc2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Thomas=20B=C3=A4chler?=
Date: Wed, 30 Aug 2017 00:25:32 +0200
Subject: [PATCH] Add ipv6 support to libhpmud
---
io/hpmud/jd.c | 147 ++
1 file changed, 45 insertions(+), 102 deletions(-)
diff --git a/io/hpmud/jd.c b/io/hpmud/jd.c
index 06f5072ee..45d6d36cc 100644
--- a/io/hpmud/jd.c
+++ b/io/hpmud/jd.c
@@ -332,44 +332,49 @@ enum HPMUD_RESULT __attribute__ ((visibility ("hidden"))) jd_channel_close(mud_d
* JetDirect channel functions.
*/
+static int try_connect(const char* address, int port)
+{
+ int s = -1;
+ struct addrinfo *addrinfo = NULL;
+
+ struct addrinfo hints;
+ bzero(, sizeof(struct addrinfo));
+ hints.ai_family = AF_UNSPEC;
+ hints.ai_socktype = SOCK_STREAM;
+ hints.ai_protocol = IPPROTO_TCP;
+ hints.ai_flags = AI_ADDRCONFIG;
+ char service[6];
+ snprintf(service, sizeof(service) / sizeof(service[0]), "%d", port);
+ getaddrinfo(address, service, , );
+
+ const struct addrinfo *a;
+ for(a = addrinfo; a != NULL; a = a->ai_next)
+ {
+ if ((s = socket(a->ai_family, a->ai_socktype, a->ai_protocol)) == -1)
+ continue;
+ if (connect(s, a->ai_addr, a->ai_addrlen) == 0)
+ break;
+ close(s);
+ s = -1;
+ }
+ if (addrinfo != NULL)
+ freeaddrinfo(addrinfo);
+ return s;
+}
+
enum HPMUD_RESULT __attribute__ ((visibility ("hidden"))) jd_s_channel_open(mud_channel *pc)
{
mud_device *pd = >device[pc->dindex];
- struct sockaddr_in pin,tmp_pin;
- struct hostent *he;
char buf[HPMUD_LINE_SIZE];
int r, len, port;
enum HPMUD_RESULT stat = HPMUD_R_IO_ERROR;
- bzero(_pin, sizeof(tmp_pin));
- bzero(, sizeof(pin));
- pin.sin_family = AF_INET;
-
- if(inet_pton(AF_INET, pd->ip, &(tmp_pin.sin_addr))) //Returns 0 when IP is invalid.
-pin.sin_addr.s_addr = inet_addr(pd->ip);
- else
- {
-if((he=gethostbyname(pd->ip)) == NULL)
-{
-BUG("gethostbyname() returned NULL\n");
-goto bugout;
-}
-
-pin.sin_addr = *((struct in_addr *)he->h_addr);
- }
-
switch (pc->index)
{
case HPMUD_PRINT_CHANNEL:
port = PrintPort[pd->port];
- pin.sin_port = htons(port);
- if ((pc->socket = socket(AF_INET, SOCK_STREAM, 0)) == -1)
- {
-BUG("unable to open print port %d: %m %s\n", port, pd->uri);
-goto bugout;
- }
- if (connect(pc->socket, (struct sockaddr *), sizeof(pin)) == -1)
- {
+ if ((pc->socket = try_connect(pd->ip, port)) == -1)
+ {
BUG("unable to connect to print port %d: %m %s\n", port, pd->uri);
goto bugout;
}
@@ -379,14 +384,7 @@ enum HPMUD_RESULT __attribute__ ((visibility ("hidden"))) jd_s_channel_open(mud_
port = ScanPort1[pd->port];
else
port = ScanPort0[pd->port];
- pin.sin_port = htons(port);
-
- if ((pc->socket = socket(AF_INET, SOCK_STREAM, 0)) == -1)
- {
-BUG("unable to open scan port %d: %m %s\n", port, pd->uri);
-goto bugout;
- }
- if (connect(pc->socket, (struct sockaddr *), sizeof(pin)) == -1)
+ if ((pc->socket = try_connect(pd->ip, port)) == -1)
{
BUG("unable to connect to scan err=%d port %d: %m %s\n", errno, port, pd->uri);
goto bugout;
@@ -409,13 +407,7 @@ enum HPMUD_RESULT __attribute__ ((visibility ("hidden"))) jd_s_channel_open(mud_
port = GenericPort1[pd->port];
else
port = GenericPort[pd->port];
- pin.sin_port = htons(port);
- if ((pc->socket = socket(AF_INET, SOCK_STREAM, 0)) == -1)
- {
-BUG("unable to open port %d: %m %s\n", port, pd->uri);
-goto bugout;
- }
- if (connect(pc->socket, (struct sockaddr *), sizeof(pin)) == -1)
+ if ((pc->socket = try_connect(pd->ip, port)) == -1)
{
BUG("unable to connect to port %d: %m %s\n", port, pd->uri);
goto bugout;
@@ -450,13 +442,7 @@ enum HPMUD_RESULT __attribute__ ((visibility ("hidden"))) jd_s_channel
Bug#911191: wide-dhcpv6-client: patch adding support for a random interface id
Package: wide-dhcpv6-client
Version: 20080615-21
Severity: wishlist
Tags: patch, ipv6
Please find attached a patch that adds a new feature to
wide-dhcpv6-client, namely an option ("ifid-random") in the
prefix-interface section of dhcp6c.conf to generate a random interface
id on startup. This is useful if you wish to have the final 64 bits of
your IPv6 address change from time to time - a sort of very rough
equivalent of IPv6 Privacy Extensions. If you do not add "ifid-random"
to the config file, then nothing about the client's current behaviour
changes.
Note that if your prefix-interface section has both the current "ifid
X" option (where X is whatever number you want to manually assign as
your interface id) and the new "ifid-random" option, then the
interface id is randomized and "ifid X" is ignored.
Thanks,
Christopher Martin
--- a/cfparse.y
+++ b/cfparse.y
@@ -104,7 +104,7 @@
%token INTERFACE IFNAME
%token PROFILE PROFILENAME
-%token PREFIX_INTERFACE SLA_ID SLA_LEN IFID DUID_ID
+%token PREFIX_INTERFACE SLA_ID SLA_LEN IFID IFID_RAND DUID_ID
%token ID_ASSOC IA_PD IAID IA_NA
%token ADDRESS
%token REQUEST SEND ALLOW PREFERENCE
@@ -1064,6 +1064,13 @@
l->num = (u_int64_t)$2;
$$ = l;
}
+ | IFID_RAND EOS
+ {
+ struct cf_list *l;
+
+ MAKE_CFLIST(l, IFPARAM_IFID_RAND, NULL, NULL);
+ $$ = l;
+ }
;
ianaconf_list:
--- a/cftoken.l
+++ b/cftoken.l
@@ -244,6 +244,7 @@
sla-id { DECHO; return (SLA_ID); }
sla-len { DECHO; return (SLA_LEN); }
ifid { DECHO; return (IFID); }
+ifid-random { DECHO; return (IFID_RAND); }
/* duration */
infinity { DECHO; return (INFINITY); }
--- a/config.c
+++ b/config.c
@@ -521,6 +521,15 @@
}
break;
case IFPARAM_IFID:
+ if (use_default_ifid) {
+for (i = sizeof(pif->ifid) - 1; i >= 0; i--)
+ pif->ifid[i] = (cfl->num >> 8*(sizeof(pif->ifid) - 1 - i)) & 0xff;
+use_default_ifid = 0;
+ }
+ break;
+ case IFPARAM_IFID_RAND:
+ for (i = 0; i < pif->ifid_len ; i++)
+cfl->num = cfl->num*2 + rand()%2;
for (i = sizeof(pif->ifid) -1; i >= 0; i--)
pif->ifid[i] = (cfl->num >> 8*(sizeof(pif->ifid) - 1 - i)) & 0xff;
use_default_ifid = 0;
--- a/config.h
+++ b/config.h
@@ -266,7 +266,7 @@
DECL_PREFIX, DECL_PREFERENCE, DECL_SCRIPT, DECL_DELAYEDKEY,
DECL_ADDRESS,
DECL_RANGE, DECL_ADDRESSPOOL,
- IFPARAM_SLA_ID, IFPARAM_SLA_LEN, IFPARAM_IFID,
+ IFPARAM_SLA_ID, IFPARAM_SLA_LEN, IFPARAM_IFID, IFPARAM_IFID_RAND,
DHCPOPT_RAPID_COMMIT, DHCPOPT_AUTHINFO,
DHCPOPT_DNS, DHCPOPT_DNSNAME,
DHCPOPT_IA_PD, DHCPOPT_IA_NA, DHCPOPT_NTP,
--- a/dhcp6c.conf.5
+++ b/dhcp6c.conf.5
@@ -453,6 +453,15 @@
prefix and the sla-id to form a complete interface address. The
default is to use the EUI-64 address of the
.Ar interface .
+.It Xo
+.Ic ifid-random ;
+.Xc
+This statement instructs the client to generate a completely random
+interface id. This will override the
+.Ic ifid
+statement, if present. The resulting random interface id will be combined
+with the delegated prefix and the sla-id to form a complete interface
+address.
.El
.El
.\"
Bug#855801: zfs-mount.service / zfs.target should be WantedBy=local-fs.target, not multi-user.target
Package: zfsutils-linux Version: 0.6.5.9-2 Currently, the zfs-mount.service is started through the zfs.target, which is itself in turn WantedBy=multi-user.target. This happens after local-fs.target is reached (which is when local file systems are expected to be mounted). As a result, there is no guarantee that a daemon or other service, many of which are also started through multi-user.target, will be able to see ZFS mounts when they launch. This can cause problems (e.g. a DLNA server that wants to serve files stored on a ZFS array). Instead, I would suggest that zfs-mount.service or the zfs.target (whichever makes most sense) be WantedBy=local-fs.target, thereby mounting ZFS along with all the other local filesystems. That way, daemons etc. started later, through multi-user.target, will reliably be able see the system's ZFS mounts when they launch. Thanks, Christopher Martin
Bug#826071: khotkeys built without XTest
Package: khotkeys Version: 4:5.6.4-1 Hello, Now that 5.6 supports gestures properly again, I turned them back on and found that I could no longer middle click: when not performing a gesture with the middle mouse button, khotkeys wasn't passing my middle clicks through to the underlying applications. A quick search uncovered this: https://www.reddit.com/r/kde/comments/4gffxp/mouse_gestures_break_middle_click Essentially, khotkeys needs to be built with XTest support. It will then pass clicks through to the underlying application once it has determined that no gesture is being made. Armed with this knowledge, I was able to solve the issue by rebuilding khotkeys myself after installing libxtst-dev . The solution thus appears to be simple - add that package to the khotkeys build-depends. Thanks for your work packaging KDE. Christopher Martin
Bug#766979: O: imwheel -- program to support non-standard buttons on mice in Linux
Package: wnpp Version: 1.0.0pre12-12 Severity: normal IMWheel needs a new maintainer.
Bug#764793: Possible fix for HTML5 video in Chromium?
-4 is a large rewrite, and something may by missing from the GYP_DEFINES now. Comparing the before and after rules files should help. Best wishes, Mike I suspect that you're correct. While Vimeo works here, I did notice that the Youtube HTML5 player had stopped working; it automatically reverted to using Flash. The attached one-liner patch to debian/rules seems to address that problem on my system. This line in debian/rules was present in older Chromium packaging. Cheers, Christopher Martin --- a/debian/rules +++ b/debian/rules @@ -64,6 +64,7 @@ # enable proprietary codecs defines+=proprietary_codecs=1 \ + ffmpeg_branding=Chrome \ # icu defines+=use_system_icu=0 \
Bug#748867: Fix/workaround for Google API key problem and crash
Hello, The attached patch to debian/rules restores the ability to sign-in to Chromium, by re-adding the Debian Google API keys that used to be included in older Chromium packaging debian/rules. The patch also resolves the crash that occurred on sign-in with Chromium built against the system protobuf (the solution being, simply enough, not to use the system protobuf - this issue was explained further in Debian bug #764911). With these fixes applied and Chromium re-built, I can upgrade from Chromium 37 to 38 without any need to delete ~/.config/chromium or any such hassle. Hope this helps. Cheers, Christopher Martin --- a/debian/rules +++ b/debian/rules @@ -42,6 +42,11 @@ linux_link_libspeechd=1 \ linux_link_gnome_keyring=1 \ +# Debian Google API Key +defines+=google_api_key=AIzaSyCkfPOPZXDKNn8hhgu3JrA62wIgC93d44k \ + google_default_client_id=811574891467.apps.googleusercontent.com \ + google_default_client_secret=kdloedMFGdGla2P1zacGjAQh \ + # system libraries to use defines+=use_system_re2=1 \ use_system_yasm=1 \ @@ -58,7 +63,7 @@ use_system_libsrtp=1 \ use_system_jsoncpp=1 \ use_system_libevent=1 \ - use_system_protobuf=1 \ + use_system_protobuf=0 \ use_system_harfbuzz=1 \ use_system_xdg_utils=1 \
Bug#764733: ETA on Google API keys fix?
Hi, Do you have an ETA on fixing the (apparent) absence of Google API Keys in the sid package? I assume (correct me if I'm wrong) that it is fixable. I had to revert to chromium in testing to get my browser to start (segfault since I was logged in to chromium previously), and am unwilling to work around this by nuking my ~/.config/chromium and re-configuring. Thanks, Christopher Martin
Bug#623516: New upstream release of kaffeine
Package: kaffeine Version: 1.1-2 Severity: wishlist Just FYI, but version 1.2.2 of kaffeine has been released. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590840: libxine1-misc-plugins: assertion error in kaffeine 0.8.7
I suspect that the crash is related to this problem: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2010-January/014891.html Thus it may be a xine-lib bug after all, as I don't see any InitializeMagick() - or DestroyMagick() for that matter - calls in xine-lib's code. I would guess that libxinevdec/image.c would be the appropriate place to add them. Christopher Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530251: [pkg-mono-group] Bug#530251: [moonlight-plugin-mozilla] new upstream release 1.9.2
On March 13, 2010 19:10:56 Jo Shields wrote: I spoke with Ganneff (i think, or someone else in #debian-ftp), who flat-out said he'd REJECT it if it contained as much bundled stuff as it does. I agree with your points though. removing what's already in the archive might be a good plan if there's no chance of movement on accepting 2.2-1. I obviously missed that IRC exchange, but I wonder how deeply Ganneff thought about the implications of his comment (i.e. no more moonlight in Debian) or whether he realized that bundling was truly unavoidable in the case of this package, and that that is simply how everyone else is doing it (Ubuntu, other distributions I assume). Would an e-mail laying it all out get better results? Who knows... but I wish you luck. Christopher Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530251: [moonlight-plugin-mozilla] new upstream release 1.9.2
On Mon, 2010-01-25 at 18:51 +0200, Riku Voipio wrote: On Mon, Jan 25, 2010 at 03:58:31PM +, Jo Shields wrote: I don't know how to make this packageable, given the bundling restriction. Since it doesn't sound like solveable in a timely manner, would it be possible to have unofficial packages in the meanwhile? I'm going to package this in Ubuntu, and have been told by an Archive Admin (equivalent to ftp-master) that the bundling isn't a blocker. You're welcome to participate and build Debian packages from the source: https://launchpad.net/~moonlight-team Has anyone actually explained the situation to the ftp-masters and asked for an opinion/exemption? It seems that moonlight in Debian is being given up on rather easily. Either an effort should be made to package moonlight 2 and ship it with the next release, or else the ftp-masters reject it and should then be asked to remove moonlight from the archive rather than be forced to support increasingly ancient software. The ftp-masters can then explain to our users why moonlight just isn't good enough for Debian... Christopher Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559712: new ffmpeg snapshot would add support for important codecs (e.g. wmapro)
On January 24, 2010 03:46:36 Reinhard Tartler wrote: On Sa, Jan 23, 2010 at 19:43:41 (CET), Christopher Martin wrote: Hello, Attached is a patch (lacking only a changelog entry and a line in debian/patch/series) that backports wma and wmapro support from an early January ffmpeg snapshot to the ffmpeg in sid (wma and wmapro are intertwined, so it was easier just to update both together). Thanks for your work. Can you please state the exact revision that you have used? I'd like to check the changes you did compared to upstream. Also, do you intend to keep this backport updated? Rev 21012 - I grabbed the source from one of Christian Marillat's packages (dated 20100104), and then made the minimum modifications (mainly reverting specific commits made that were made to to keep up with ffmpeg's internal changes, and backporting necessary functions) as necessary until it built, didn't crash, and didn't output static. As for keeping it updated - I'd hoped that the next ffmpeg upstream snapshot uploaded to Debian would remove the need for the backport... Until that's all sorted out, however, if problems do crop up, I will help you out and look into them, try to keep the patch in sync etc., but my time (and skills and knowledge) is limited, so I won't be able to provide instant fixes. Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#566746: RM: gwenview source package -- obsolete, part of kdegraphics as of KDE4
Package: ftp.debian.org Severity: normal Please remove the gwenview source package from unstable/testing. Rationale: The gwenview binary package is provided by the kdegraphics source package as of KDE 4, leaving the gwenview source package (which built against KDE 3 only) with no purpose (except in stable). Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#560413: RM: gwenview-i18n -- obsolete, part of kde-l10n as of KDE4
Package: ftp.debian.org Severity: normal Please remove the gwenview-i18n source and binary packages from unstable. Rationale: When gwenview built against KDE3 (now only in stable) it was an independent package and so had its own internationalization package. Now, however, gwenview is part of KDE4 (unstable/testing) and so gwenview's translations are provided by the kde-l10n-** packages. Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#527383: Status?
On December 10, 2009 04:50:12 Jan Jabbery wrote: What's the status on this bug? It seems pretty simple to close and the conflict it produces, prevents Debian liveCD's from being created with user-chosen locales if you use KDE4 and gwenview on them. My apologies; the original request slipped through the net on my end. I've filed the appropriate bug (#560413) for removal. Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#559712: new ffmpeg snapshot would add support for important codecs (e.g. wmapro)
Package: ffmpeg Version: 4:0.5+svn20090706-2 Severity: wishlist Hello, With support for so many codecs added to ffmpeg recently, I was wondering whether the upload of a new snapshot was planned for the near future. In particular, I'm interested in wmapro support, which I see was added recently, as per the announcement on the ffmpeg frontpage. Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#523716: [pkg-nvidia-devel] Bug#523716: Another build failure...
On April 13, 2009 11:14:12 Lennart Sorensen wrote: That is no longer a complete set of headers and you can't build against it like that. The kernel team says that is no longer supported. This is what I've done for a long time (changing the kernel in question each time, obviously). Why not use module-assitant? I sure didn't test that old way of doing it when I rewrote the build scripts. I used module-assistant and a hacked up version of linux-modules-nonfree-2.6 and both worked. I did not test make-kpkg or doing it manually (which I stopped doing years ago when I discovered module-assistant). I guess I'll switch to module-assistant - not a problem. But as was pointed out elsewhere, it might be best to make the requirement explicit. Cheers, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#523716: Another build failure...
My build (180.44-1) also failed here: dh_installdocs dh_installmodules dh_installchangelogs dh_installmodules dh_strip dh_compress dh_fixperms dh_installdeb dh_gencontrol -- -v dpkg-gencontrol: unknown option `-v' Usage: dpkg-gencontrol [option ...] Options: -ppackage print control file for package. -ccontrolfile get control info from this file. -lchangelogfileget per-version info from this file. -Fchangelogformat force change log format. -vforceversion set version of binary package. -ffileslistfilewrite files here instead of debian/files. -Ppackagebuilddir temporary build dir instead of debian/tmp. -nfilename assume the package filename will be filename. -O write to stdout, not .../DEBIAN/control. -is, -ip, -isp, -ips deprecated, ignored for compatibility. -Dfield=valueoverride or add a field and value. -Ufieldremove a field. -Vname=value set a substitution variable. -Tvarlistfile read variables here, not debian/substvars. -h, --help show this help message. --versionshow the version. dh_gencontrol: dpkg-gencontrol returned exit code 2 make: *** [binary-modules] Error 1 --- I simply edited debian/rules to change dh_gencontrol -- -v$(VERSION) into dh_gencontrol -- $(VERSION). Seems to work... Hopefully these little glitches can be fixed up soon. Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#523716: Another build failure...
On April 12, 2009 13:36:36 Sven Joachim wrote: Only because $(VERSION) is empty for you, and that is the problem. How did you try to build the module? I tried: cd /usr/src/modules/nvidia-kernel (after unpacking /usr/src/nvidia-kernel.tar.bz2) KSRC=/usr/src/linux-headers-2.6.29-1-686-bigmem \ KVERS=2.6.29-1-686-bigmem debian/rules binary_modules This is what I've done for a long time (changing the kernel in question each time, obviously). Hope that helps, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#523716: Another build failure...
On April 12, 2009 14:10:13 Sven Joachim wrote: I see. The VERSION variable is supposed to be set by including /usr/share/modass/include/generic.make, and you apparently do not have module-assistant installed, do you? Probably nvidia-kernel-source should stop recommending kernel-package and just depend on module-assistant like every other $module-source package does. Correct, I don't have module-assistant installed. signature.asc Description: This is a digitally signed message part.
Bug#517297: [Pkg-hpijs-devel] Bug#517297: hplip udev rules never match
Hi, Just a few observations: 1) The rules in the hplip 3.9.2-1ubuntu1 package don't work for me; the printer node remains in the root group. 2) Using ATTR doesn't seem to work on my system, but ATTRS does. To be honest, I'm not sure exactly what the difference is, but changing back and forth and cycling the printer makes the difference clear. 2) The upstream (and my suggested) rules match on SUBSYSTEM=usb_device as well as SUBSYSTEM=usb; I can report that if I configure the rules to match only SUBSYSTEM=usb, then the rules don't match my printer. I can't find any documentation of when usb_device became relevant, but again, I'm going with what works. My suggested rules break from upstream's in that they don't match OWNER, and don't muck around with sane. As for the rules' order (40-* vs. 55-* vs. z60*) I have no opinion; it might be worth ensuring that the scanner package's rules have a chance to match after hplip's, so that the nodes of multifunction devices are owned by scanner, not lp (if my understanding of udev is correct). Hope that helps, Christopher Martin On March 11, 2009 05:01:41 Till Kamppeter wrote: Mark Purcell wrote: On Tuesday 10 March 2009 10:11:17 Christopher Martin wrote: I'm happy to answer questions. Chris, Till, Seems that the udev rules are again causing problems. Lots of Debian bugs reported :-( Till. You reinstated our own udev rules with 2.8.12-1ubuntu5 which fixed a number of issues for ubuntu. Do we need to rework again, or are upstream 3.9.2 udev rules good? If possible, I wouldn't like to merge from upstream and would rather pass fixes like the enclosed directly upstream: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517297 Aaron, What is the best way we can work with you together on this? Mark I returned to having Ubuntu's own UDEV rules file due to the following bug reports: https://bugs.launchpad.net/bugs/319660 Cannot edit configuration from udev rules https://bugs.launchpad.net/bugs/319661 Must not set OWNER in udev rules https://bugs.launchpad.net/bugs/319662 udev rules should be 40-*.rules unless there's a good reason https://bugs.launchpad.net/bugs/319665 Uses deprecated SYSFS instead of ATTR Till signature.asc Description: This is a digitally signed message part.
Bug#517297: hplip udev rules never match
Thanks for uploading 3.9.2. However, I noticed that the udev rules supplied by the package (z60_hplip.rules, or hplip.udev in the debian folder of the source) still don't ever match, meaning that my printer's node isn't in the lp group, meaning it won't work. Replacing the file with my new version allows my printer to work again. Any reason why the new file I supplied wasn't used? I'm happy to answer questions. Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#517297: hplip udev rules - patch fixing never matches problem
Hello,
I've slightly updated the files to reflect a change in upstream's own
rules from 2.8.12 to 3.9.2 (they added a new device). Everything else
is the same.
Thanks,
Christopher Martin
# Udev rules file for HP printer products.
ACTION!=add, GOTO=hpmud_rules_end
SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, GOTO=pid_test
SUBSYSTEM!=usb_device, GOTO=hpmud_rules_end
LABEL=pid_test
# Check for AiO products (0x03f0xx11).
ATTRS{idVendor}==03f0, ATTRS{idProduct}==??11, GROUP=lp
# Check for Photosmart products without wildcard since cameras and scanners
also used (0x03f0xx02).
# The xx02 pid has been retired so this explicit list should not change.
# photosmart_d2300_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c302, GROUP=lp
# photosmart_100
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3802, GROUP=lp
# photosmart_1115
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3402, GROUP=lp
# photosmart_1215
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3202, GROUP=lp
# photosmart_1218
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3302, GROUP=lp
# photosmart_130
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3902, GROUP=lp
# photosmart_1315
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3602, GROUP=lp
# photosmart_140_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1002, GROUP=lp
# photosmart_230
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3502, GROUP=lp
# photosmart_240_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1102, GROUP=lp
# photosmart_320_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1202, GROUP=lp
# photosmart_330_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1602, GROUP=lp
# photosmart_370_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1302, GROUP=lp
# photosmart_380_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1702, GROUP=lp
# photosmart_420_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1502, GROUP=lp
# photosmart_470_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1802, GROUP=lp
# photosmart_7150
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3a02, GROUP=lp
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3b02, GROUP=lp
# photosmart_7200_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==b002, GROUP=lp
# photosmart_7345
ATTRS{idVendor}==03f0, ATTRS{idProduct}==2002, GROUP=lp
# photosmart_7350
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3c02, GROUP=lp
# photosmart_7400_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==b802, GROUP=lp
# photosmart_7550
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3e02, GROUP=lp
# photosmart_7600_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==b202, GROUP=lp
# photosmart_7700_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==b402, GROUP=lp
# photosmart_7800_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c002, GROUP=lp
# photosmart_7900_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==b602, GROUP=lp
# photosmart_8000_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c102, GROUP=lp
# photosmart_8100_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==ba02, GROUP=lp
# photosmart_8200_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c202, GROUP=lp
# photosmart_8400_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==bb02, GROUP=lp
# photosmart_8700_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==bc02, GROUP=lp
# photosmart_a310_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1d02, GROUP=lp
# photosmart_a320_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1e02, GROUP=lp
# photosmart_a430_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1902, GROUP=lp
# photosmart_a440_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1f02, GROUP=lp
# photosmart_a510_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1a02, GROUP=lp
# photosmart_a520_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==2602, GROUP=lp
# photosmart_a530_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==2b02, GROUP=lp
# photosmart_a610_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1b02, GROUP=lp
# photosmart_a620_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==2702, GROUP=lp
# photosmart_a630_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==2c02, GROUP=lp
# photosmart_a710_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1c02, GROUP=lp
# photosmart_a820_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==2902, GROUP=lp
# photosmart_d5060_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c802, GROUP=lp
# photosmart_d5100_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c402, GROUP=lp
# photosmart_d6100_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c502, GROUP=lp
# photosmart_d7100_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c602, GROUP=lp
# photosmart_d7300_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c702, GROUP=lp
# photosmart_pro_b8300_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==be02, GROUP=lp
# photosmart_b8800_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==d002, GROUP=lp
# photosmart_pro_b9100_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==bd02, GROUP=lp
# Photosmart_B8500_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==d102, GROUP=lp
# Check for Business Inkjet products (0x03f0xx12).
ATTRS{idVendor}==03f0, ATTRS{idProduct}==??12, GROUP=lp
# Check for Deskjet products
Bug#517297: hplip udev rules - patch fixing never matches problem
tags 517297 patch
stop
Hello,
Borrowing from the hplip upstream udev rules (included in the hplip
source), and looking at the udev documentation, I've come up with the
following new hplip.rules file (also provided as a patch against the
current file, debian/hplip.udev) which updates them so that they now
work with recent kernels and udev versions (while leaving out some of
the more esoteric changes in the upstream rules).
Critically, the rules now handle both SUBSYSTEM=usb and
SUBSYSTEM=usb_device. They also use ATTRS, not ATTR. ATTR doesn't
seem to work at all for what we ask of it.
With this update, my printer's node is now correctly in the lp group,
allowing hplip to work; before, printing simply wasn't possible as a
regular user. I don't recall when exactly things broke, but it's been a
while...
Please include this fix in the next hplip upload.
Thanks,
Christopher Martin
--- hplip.udev.orig
+++ hplip.udev.new
@@ -1,118 +1,126 @@
# Udev rules file for HP printer products.
+ACTION!=add, GOTO=hpmud_rules_end
+SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, GOTO=pid_test
+SUBSYSTEM!=usb_device, GOTO=hpmud_rules_end
+
+LABEL=pid_test
+
# Check for AiO products (0x03f0xx11).
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==??11, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==??11, GROUP=lp
# Check for Photosmart products without wildcard since cameras and scanners also used (0x03f0xx02).
# The xx02 pid has been retired so this explicit list should not change.
# photosmart_d2300_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==c302, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==c302, GROUP=lp
# photosmart_100
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3802, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3802, GROUP=lp
# photosmart_1115
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3402, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3402, GROUP=lp
# photosmart_1215
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3202, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3202, GROUP=lp
# photosmart_1218
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3302, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3302, GROUP=lp
# photosmart_130
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3902, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3902, GROUP=lp
# photosmart_1315
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3602, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3602, GROUP=lp
# photosmart_140_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1002, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1002, GROUP=lp
# photosmart_230
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3502, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3502, GROUP=lp
# photosmart_240_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1102, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1102, GROUP=lp
# photosmart_320_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1202, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1202, GROUP=lp
# photosmart_330_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1602, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1602, GROUP=lp
# photosmart_370_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1302, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1302, GROUP=lp
# photosmart_380_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1702, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1702, GROUP=lp
# photosmart_420_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1502, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1502, GROUP=lp
# photosmart_470_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==1802, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==1802, GROUP=lp
# photosmart_7150
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3a02, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==3a02, GROUP=lp
# photosmart_7200_series
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==b002, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==b002, GROUP=lp
# photosmart_7345
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==2002, GROUP=lp
+ATTRS{idVendor}==03f0, ATTRS{idProduct}==2002, GROUP=lp
# photosmart_7350
-SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, ATTR{idVendor}==03f0, ATTR{idProduct}==3c02, GROUP
Bug#505726: Not fixed - symlink still not in correct location
reopen 505726 severity 505726 important stop Since the plugin still does not work in Iceweasel without manual intervention, this bug should not be closed. Instead of placing the symlink in /usr/lib/xulrunner-addons/plugins, the package should place it in /usr/lib/mozilla/plugins (as was explained by others in this report). Then the plugin will work out-of-the-box. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508934: gwenview: Pause to load images (or no images?)
I'm sorry, could you please restate the problem? I didn't quite get the nature of the problem from your description. Thanks! On December 16, 2008 14:10:22 psycheye wrote: Package: gwenview Version: 1.4.2-5+b1 Severity: normal In the file manager, when I click on a folder that contains lot of images there's a long pause, so I don't if gwenview loading images or there aren't any images. thanks psycheye -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501990: gwenview: Gwenview crashes when trying Copy to from a tar.gz file
severity 501990 normal
tags 501990 experimental
stop
Unless I'm misreading, there is no data loss since the tar.gz is not
deleted nor its contents affected. The problem is that files can't be
extracted from tar.gz using Gwenview.
Correct me if I'm wrong...
Thanks,
Christopher Martin
On October 12, 2008 10:03:54 Saulo Soares de Toledo wrote:
Package: gwenview
Version: 4:4.1.2-1
Severity: grave
Justification: causes non-serious data loss
1) Open a tar.gz file in Dolphin
2) Open with a image file inside this tar.gz with Gwenview, here it's
possible navigate at image files
3) Select Copy to option, the window to copy files will open
4) When try change the folder to Home or other directory, Gwenview
crashes. I don't know exactily this last pass, but will crash.
The backtrace:
Aplicativo: Gwenview (gwenview), sinal SIGABRT
[Thread debugging using libthread_db enabled]
[New Thread 0xb5e8a6c0 (LWP 4272)]
[KCrash handler]
#6 0xb7f97424 in __kernel_vsyscall ()
#7 0xb68e4640 in raise () from /lib/i686/cmov/libc.so.6
#8 0xb68e6018 in abort () from /lib/i686/cmov/libc.so.6
#9 0xb6b506cd in qt_message_output (msgType=QtFatalMsg,
buf=0xbf9ad570 ASSERT: \!isEmpty()\ in file
#/usr/include/qt4/QtCore/qlist.h, line 252) at
global/qglobal.cpp:2102 #10 0xb6b50796 in qFatal (msg=0xb6c98438
ASSERT: \%s\ in file %s, line #%d)
at global/qglobal.cpp:2303
#11 0xb6b50825 in qt_assert (assertion=0xb769cdd7 !isEmpty(),
file=0xb769c7d4 /usr/include/qt4/QtCore/qlist.h, line=252)
at global/qglobal.cpp:1872
#12 0xb7657018 in KDirOperator::Private::_k_slotSelectionChanged (
this=0x9019440) at /usr/include/qt4/QtCore/qlist.h:252
#13 0xb765eb9f in KDirOperator::qt_metacall (this=0x900afe8,
_c=QMetaObject::InvokeMetaMethod, _id=56, _a=0xbf9af6d8)
at
/tmp/buildd/kde4libs-4.1.2/obj-i486-linux-gnu/kfile/kdiroperator.moc:
226 #14 0xb6c5cbd0 in QMetaObject::activate (sender=0x915b120,
from_signal_index=4, to_signal_index=4, argv=0xbf9af6d8)
at kernel/qobject.cpp:3031
#15 0xb6c5d952 in QMetaObject::activate (sender=0x915b120,
m=0xb761bff0, local_signal_index=0, argv=0xbf9af6d8) at
kernel/qobject.cpp:3101 #16 0xb737dbe9 in
QItemSelectionModel::selectionChanged (this=0x915b120,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at .moc/release-shared/moc_qitemselectionmodel.cpp:144
#17 0xb7385770 in QItemSelectionModel::emitSelectionChanged
(this=0x915b120, [EMAIL PROTECTED], [EMAIL PROTECTED])
at itemviews/qitemselectionmodel.cpp:1454
#18 0xb7385a76 in QItemSelectionModel::select (this=0x915b120,
[EMAIL PROTECTED], command={i = -1080363004})
at itemviews/qitemselectionmodel.cpp:1013
#19 0xb7380820 in QItemSelectionModel::select (this=0x915b120,
[EMAIL PROTECTED], command={i = -1080362952})
at itemviews/qitemselectionmodel.cpp:901
#20 0xb7664007 in KDirOperatorDetailView::currentChanged
(this=0x90a6d10, [EMAIL PROTECTED], [EMAIL PROTECTED])
at
/tmp/buildd/kde4libs-4.1.2/kfile/kdiroperatordetailview.cpp:136 #21
0xb73319fc in QAbstractItemView::qt_metacall (this=0x90a6d10,
_c=QMetaObject::InvokeMetaMethod, _id=20, _a=0xbf9af9b8) at
.moc/release-shared/moc_qabstractitemview.cpp:227
#22 0xb7374e2a in QTreeView::qt_metacall (this=0x90a6d10,
_c=QMetaObject::InvokeMetaMethod, _id=51, _a=0xbf9af9b8)
at .moc/release-shared/moc_qtreeview.cpp:121
#23 0xb765418a in KDirOperatorDetailView::qt_metacall
(this=0x90a6d10, _c=QMetaObject::InvokeMetaMethod, _id=51,
_a=0xbf9af9b8) at
/tmp/buildd/kde4libs-4.1.2/obj-i486-linux-gnu/kfile/moc_kdiroperatord
etailview_p.cpp:62 #24 0xb6c5cbd0 in QMetaObject::activate
(sender=0x915b120,
from_signal_index=5, to_signal_index=5, argv=0xbf9af9b8)
at kernel/qobject.cpp:3031
#25 0xb6c5d952 in QMetaObject::activate (sender=0x915b120,
m=0xb761bff0, local_signal_index=1, argv=0xbf9af9b8) at
kernel/qobject.cpp:3101 #26 0xb737db99 in
QItemSelectionModel::currentChanged (this=0x915b120, [EMAIL PROTECTED],
[EMAIL PROTECTED])
at .moc/release-shared/moc_qitemselectionmodel.cpp:151
#27 0xb737dd3d in QItemSelectionModel::setCurrentIndex
(this=0x915b120, [EMAIL PROTECTED], command={i = -1080362272})
at itemviews/qitemselectionmodel.cpp:1082
#28 0xb732fb8a in QAbstractItemView::mousePressEvent (this=0x90a6d10,
event=0xbf9b04ac) at itemviews/qabstractitemview.cpp:1470
#29 0xb7373527 in QTreeView::mousePressEvent (this=0x90a6d10,
event=0xbf9b04ac) at itemviews/qtreeview.cpp:1761
#30 0xb766404f in KDirOperatorDetailView::mousePressEvent
(this=0x90a6d10, event=0xbf9b04ac)
at
/tmp/buildd/kde4libs-4.1.2/kfile/kdiroperatordetailview.cpp:122 #31
0xb6ec17a9 in QWidget::event (this=0x90a6d10, event=0xbf9b04ac) at
kernel/qwidget.cpp:7159
#32 0xb71f4ca3 in QFrame::event (this=0x90a6d10, e=0xbf9b04ac)
at widgets/qframe.cpp:651
#33 0xb728b3cf in QAbstractScrollArea::viewportEvent (this=0x90a6d10,
e=0x6
Bug#488637: NMU for xine-plugin
Hello, I've prepared a NMU for xine-plugin, which updates it to the long-ago released 1.0.1 version, and fixes the crashes with Iceweasel 3 and Epiphany, as far as I can tell. Please test this and let me know if it makes a difference for you. http://people.debian.org/~chrsmrtn The file 'debian.diff' contains the changes within the debian directory only; look at the .diff.gz for the source changes against upstream release 1.0.1. I've done a little more housecleaning than is normally encouraged for a NMU, so Darren, let me know what you think! I'd like to get a bit of feedback before uploading. Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#484882: gtk-qt-engine: fix focus rect drawing routine
Hello, I'm running a patched gtk-qt-engine with Andrew Shadoura's collection of patches. They fix most of the theme issues I'm having with FF3. One exception is the tab bar, which is still really ugly and needs improvement. Also, in Edit - Preferences - Advanced, you'll see that under the tabs of General/Network/Update/Encryption a strange rectangle appears. My question is whether a fixed gtk-qt-engine upload will take place before lenny? Andrew has posted some valuable fixes... Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#484882: gtk-qt-engine: fix focus rect drawing routine
I guess I didn't test all the patches thoroughly; I just noted that the obvious visual glitch that I noticed at first went away, so I assumed that the other problems mentioned were covered as well... Well, thanks for working on it. At least the one fix works! On July 20, 2008 18:17:18 Andrew O. Shadoura wrote: Hello. On 21 July 2008, Christopher Martin wrote: I'm running a patched gtk-qt-engine with Andrew Shadoura's collection of patches. They fix most of the theme issues I'm having with FF3. Indeed, these patches are totally wrong except for the first one. Others *can* works sometimes, or not work. It's totally a side effect if they work. One exception is the tab bar, which is still really ugly and needs improvement. Yes, tabs needs to be re-written, but I don't know how to do that at this moment. My question is whether a fixed gtk-qt-engine upload will take place before lenny? Andrew has posted some valuable fixes... As I said, the only first fix has some value. The others are simply wrong because of strange way Mozilla interacts with GTK+. I've tried to dig into both Mozilla's and GTK-Qt-Engine's sources, but still cannot find the right solution. Sorry. signature.asc Description: This is a digitally signed message part.
Bug#483619: New upstream available (173.14.05) (adds support for many GeForce 9 series cards)
Package: nvidia-kernel-source Version: 169.12-4 Severity: wishlist Upstream has released a major new non-beta version, 173.14.05. http://www.nvidia.com/object/linux_display_ia32_173.14.05.html It would be great to see this in the archive, as it adds support for the latest cards. Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#476306: [gwenview] rotating an image does not change mtime
On April 15, 2008 14:13:51 Georg Neis wrote: Package: gwenview Version: 1.4.2-4 Severity: normal --- Please enter the report below this line. --- Rotating an image changes the content of the corresponding file but its mtime stays unchanged. Hello, Hmmm, I can't reproduce this. The mtime is definitely updated on my system. Are you sure that Gwenview is saving the changes to the disk? It might be set to silently discard the rotation. (Settings - Configure Gwenview, Misc pane) Let me know. Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#471742: gwenview crashes on some jpg files
On April 12, 2008 11:08:37 Mark Florian wrote: Okay, so this bug is fixed in Debian unstable... great. The original bug is for Debian etch, stable. What use is there in saying it's fixed in unstable? Stable isn't updated for all but the most absolutely terrible bugs or security issues. So unfortunately there isn't much I can do but fix it in unstable (and once the build daemons complete their work, testing). The bug tracking system notes the version that contained the fix, so it is still clear that the bug is present in stable. signature.asc Description: This is a digitally signed message part.
Bug#452348: HPLIP doesn't mention new user-in-scanner-group requirement, other issues
On November 22, 2007 07:43:12 Josselin Mouette wrote: Please don't do that. As long as hplip is part of the default installation, this pollutes the main menu with a vendor-specific application with zero integration to the rest of the desktop. The default etch installation looks like an advertisement for HP, let's not extend this to lenny. If you install such a desktop file, I recommend that you add a NotShowIn=KDE;GNOME stanza so that it doesn't show up by default. It can then be enabled on a per-user basis simply by editing the menu. ..if, of course, the user ever realizes that the software (meaning the toolbox and associated features) exists. Because it won't be obvious without a KDE/GNOME menu entry to any GNOME/KDE user who doesn't already use the software. And getting the entry back isn't all that easy, at least in KDE, since the user will then have to know what file to look for in /usr/share/applciations, what to edit, etc. That strikes me as an exceedingly unreasonable thing to do to render accessible software that is already installed. A much more user-friendly approach would be to include the entry, and let people who hate the entry hide it. Or uninstall the software. And if an HP icon is so inappropriate for the default desktop, then maybe the default desktop should be changed, so that HPLIP isn't installed for everyone. But that's not an hplip package problem, and so shouldn't be solved at the expense of the package's usability. On November 22, 2007 12:59:38 Mark Purcell wrote: Just one point, we need to have one issue per report, otherwise we don't know to close when all/ some or one of the issues are resolved. I'll replicate your report to cover the multi-issues. Sorry, I got carried away. Thanks for looking into things. Cheers, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#452348: HPLIP doesn't mention new user-in-scanner-group requirement, other issues
On November 22, 2007 18:40:38 Mark Purcell wrote: On Thursday 22 November 2007, Christopher Martin wrote: On November 22, 2007 07:43:12 Josselin Mouette wrote: If you install such a desktop file, I recommend that you add a NotShowIn=KDE;GNOME stanza so that it doesn't show up by default. It can then be enabled on a per-user basis simply by editing the menu. ..if, of course, the user ever realizes that the software (meaning the toolbox and associated features) exists. I must admit I'm with Christopher on this one, if the package is installed it's icon should be included in the menu. Asking a user of a GUI to edit a txt file before they see the icons sounds like crazyness.. That said the .desktop files have actually been moved into a hplip-gui package, so if you want the icons you can install the hplip-gui package and if you don't want the icons then you can just install the hplip package. So Christopher, installing hplip-gui may solve your icon issue. Joss, if hplip is deemed worthy of the default installation, then why wouldn't a user want the icons shown? Mark Aha! And I see that hplip-gui is Recommended, so that problem's solved. Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#452348: HPLIP doesn't mention new user-in-scanner-group requirement, other issues
Package: hplip Version: 2.7.10-2 Severity: important It's great to see the new version of hplip in the archive, but I have to report a few issues: 1) The old package's hplip.desktop file, which added a convenient KDE/GNOME menu entry, has disappeared. Please re-add it. I see that the file exists in the debian/ dir - you just need to install it, and remove the NotShowIn=KDE line. And install the matching icons, also in the debian/ dir. 2) The hp-toolbox and other features didn't work at all until I added my user to the scanner group. I wasn't informed of this new requirement. And why the scanner group? To be honest, I don't like this new requirement at all, but if group membership really must be required, I'd much rather it be something like plugdev. Really, all use of the scanner group should go, and all external plugable devices should use plugdev. But I'm ranting :) At least, though, document the change in a NEWS entry, and the README.Debian. 3) In CUPS, when adding a printer, I noticed that all HP printer choices were doubled - that is, they all appeared twice. It looks to me like CUPS looks in multiple directories, and was finding the same PPDs twice, because of hpijs-ppds' symlink in /usr/share/cups/model. I deleted that symlink, and the problem vanished. 4) hplip recommends openprinting.org-ppds, which is the Ubuntu package. Debian's equivalent is still called linuxprinting.org-ppds (unless you want to take over and rename the seemingly neglected foomatic packages as well...). Again, thanks for the new package. Cheers, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#443911: Please package more recent snapshot
Package: ffmpeg Version: 0.cvs20070307-6 Severity: wishlist FFmpeg in Debian is quite old. It would be nice to have bugfixes and new features of newer versions. Indeed, is there an updated package in the works? The current package is 8 months old. Thanks, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#427911: kaffeine crashes using libxine after upgrade to 0.8.4-3 or 0.8.4-4
After the update to kaffeine 0.8.4-3 or kaffeine 0.8.4-4 kaffeine crashes as soon as its trying to access libxine (either trying to play video or just entering the xine configuration settings dialog). Downgrading to kaffeine 0.8.4-2 fixes this problem. I experience this crash as well, but only if using the opengl video output plugin. Switching to xv eliminates the problem. In any case, there would appear to be an incompatibility between the XCB support (which is what changed in 0.8.4-3) and the opengl plugin. Cheers, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#429466: gwenview crashed on menu entering
Hello, Thanks for the report. Could you explain exactly what you mean by the Modules menu? Do you mean the list of KIPI plugins for activation/deactivation, or something else? Also, please update your libkipi0 and kipi-plugins to the versions available in unstable, and tell me if the problem is affected. Thanks, Christopher Martin On June 18, 2007 05:39:48 Paul Romanchenko wrote: Package: gwenview Version: 1.4.1-1+b2 Severity: grave Justification: renders package unusable When clicking Modules menu, gwenview crashed. Console error text follows: terminate called after throwing an instance of 'Exiv2::Error' what(): MakerTagInfo registry full KCrash: Application 'gwenview' crashing... Stack trace follows (from kde crash dialog): (no debugging symbols found) Using host libthread_db library /lib/i686/cmov/libthread_db.so.1. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1237096752 (LWP 5380)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) 0xe410 in ?? () #0 0xe410 in ?? () #1 0xbf9129a8 in ?? () #2 0xb7df0ff4 in ?? () from /lib/i686/cmov/libc.so.6 #3 0xbf912994 in ?? () #4 0xb7d42760 in nanosleep () from /lib/i686/cmov/libc.so.6 #5 0xb7d425af in sleep () from /lib/i686/cmov/libc.so.6 #6 0xb71e9117 in KCrash::startDrKonqi () from /usr/lib/libkdecore.so.4 #7 0xb71ff127 in KCrash::defaultCrashHandler () from /usr/lib/libkdecore.so.4 #8 0xe420 in ?? () #9 0x0006 in ?? () #10 0x0033 in ?? () #11 0xc02a in ?? () #12 0x007b in ?? () #13 0xbf91007b in ?? () #14 0xb7df0ff4 in ?? () from /lib/i686/cmov/libc.so.6 #15 0xbf914fec in ?? () #16 0xbf914f4c in ?? () #17 0xbf914f34 in ?? () #18 0x1504 in ?? () #19 0x0006 in ?? () #20 0x1504 in ?? () #21 0x in ?? () -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.22-rc3-686 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Versions of packages gwenview depends on: ii kdelibs4c2a 4:3.5.7.dfsg.1-1 core libraries and binaries for al ii libart-2.0-22.3.19-3 Library of functions for 2D graphi ii libaudio2 1.9-2 The Network Audio System (NAS). (s ii libc6 2.5-7GNU C Library: Shared libraries ii libexiv2-0 0.14-1 EXIF/IPTC metadata manipulation li ii libfontconfig1 2.4.2-1 generic font configuration library ii libfreetype62.2.1-5 FreeType 2 font engine, shared lib ii libgcc1 1:4.2-20070516-1 GCC support library ii libice6 1:1.0.3-1X11 Inter-Client Exchange library ii libidn110.6.5-1 GNU libidn library, implementation ii libjpeg62 6b-10The Independent JPEG Group's JPEG ii libkipi0 0.1.5-1 library for apps that want to use ii libmng1 1.0.8-1 Multiple-image Network Graphics li ii libpng12-0
Bug#416451: gwenview: Pounding the delete key causes error
forward 416451 http://bugs.kde.org/146655 stop I'm forwarding the problem upstream. Cheers, Christopher Martin On May 24, 2007 01:52:45 JT Hundley wrote: Local files, jpegs between 100K and 200K. I just tried it again, the bug is still present. Christopher Martin wrote: Hello, I can't reproduce this problem, though my system is pretty new, so it may be too quick. Are the files particularly large? Are they local files or remote? Thanks for any information, Christopher Martin signature.asc Description: This is a digitally signed message part.
Bug#416451: gwenview: Pounding the delete key causes error
Hello, I can't reproduce this problem, though my system is pretty new, so it may be too quick. Are the files particularly large? Are they local files or remote? Thanks for any information, Christopher Martin On March 27, 2007 22:19:15 JT Hundley wrote: Package: gwenview Version: 1.4.1-1+b1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When deleting many pictures at once by hitting the delete key quickly and repeatedly, gwenview will try to delete the same file twice. The error reads: The file or folder .../cassiariley4danni 00.jpg does not exist. - -- System Information: Debian Release: 4.0 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20.1suspend Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages gwenview depends on: ii kdelibs4c2a4:3.5.5a.dfsg.1-6 core libraries and binaries for al ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libaudio2 1.8-3 The Network Audio System (NAS). (s ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libexiv2-0.12 0.12-1EXIF/IPTC metadata manipulation li ii libfontconfig1 2.4.2-1.2 generic font configuration library ii libfreetype6 2.2.1-5 FreeType 2 font engine, shared lib ii libgcc11:4.1.1-21GCC support library ii libice61:1.0.1-2 X11 Inter-Client Exchange library ii libidn11 0.6.5-1 GNU libidn library, implementation ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libkipi0 0.1.5-2 library for apps that want to use ii libmng11.0.9-1 Multiple-image Network Graphics li ii libpng12-0 1.2.15~beta5-1PNG library - runtime ii libqt3-mt 3:3.3.7-3 Qt GUI Library (Threaded runtime v ii libsm6 1:1.0.1-3 X11 Session Management library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-6 X11 client-side library ii libxcursor11.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxft22.1.8.2-8 FreeType-based font drawing librar ii libxi6 1:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxrandr2 2:1.1.0.2-5 X11 RandR extension library ii libxrender11:0.9.1-3 X Rendering Extension client libra ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library ii zlib1g 1:1.2.3-13compression library - runtime Versions of packages gwenview recommends: ii kdegraphics-kfile-plugins 4:3.5.5-3 KDE metainfo plugins for graphic f ii kipi-plugins 0.1.2-3image manipulation/handling plugin signature.asc Description: This is a digitally signed message part.
Bug#403291: gwenview: hogging CPU when working with GUI
forwarded 403291 http://bugs.kde.org/139399 stop OK, there definitely is a lot of wasted repainting going on. I've forwarded this problem upstream. If you want to add further comments on what's broken (related to this issue) please do so at the upstream report, so the authors can see them. Thanks, Christopher Martin On Tuesday 26 December 2006 14:20, Jiří Paleček wrote: Hello, On Sat, 23 Dec 2006 18:49:10 +0100, Christopher Martin [EMAIL PROTECTED] wrote: On Tuesday 19 December 2006 17:39, Jiří Paleček wrote: Open a big image (eg. a photo from 3MPix camera), set zoom to fit to window. Then, work with the menus. If you have some top-like program running, it would show you gwenview is using 100% CPU for (not so short) periods of time. It sounds like Gwenview is taking a lot of CPU to process the image the image to fit the window. Some CPU usage here is unavoidable, and while that processing is occurring, the rest of the GUI is going to be (unavoidably) slowed and less responsive. What setting do you have for Settings -- Configure Gwenview -- Image View, Smoothing? Try changing it to Fast or None. The Best setting, for instance, is very high quality, but does indeed take an _enormous_ amount of CPU time and power. So let me know if lowering that setting improves the situation. Well, yes and no. I lowered the settings to Fast, and it's slightly faster. However, I don't think that the smoothing time should be a problem. The problem is that Gwenview smoothes the image every time it needs repaint, and that it seems to do that to the whole image. The situation is not that the GUI is unusable for short periods of time after loading an image, as you have proposed. It is unusable, for example, when you open a menu which will obstruct the image and then open another menu -- you will have to wait for the former menu to close, and the image to repaint. For example, when in fullscreen mode, the OSD (the sliding blue thing in the top-left corner of the screen) is almost unusable because you have to wait for numerous repaints (and smoothings). Also, the earlier version was much better in this. Reagrds Jiri Palecek pgpIM2uwfwQWR.pgp Description: PGP signature
Bug#403291: gwenview: hogging CPU when working with GUI
On Tuesday 19 December 2006 17:39, Jiří Paleček wrote: Open a big image (eg. a photo from 3MPix camera), set zoom to fit to window. Then, work with the menus. If you have some top-like program running, it would show you gwenview is using 100% CPU for (not so short) periods of time. Hi, It sounds like Gwenview is taking a lot of CPU to process the image the image to fit the window. Some CPU usage here is unavoidable, and while that processing is occurring, the rest of the GUI is going to be (unavoidably) slowed and less responsive. What setting do you have for Settings -- Configure Gwenview -- Image View, Smoothing? Try changing it to Fast or None. The Best setting, for instance, is very high quality, but does indeed take an _enormous_ amount of CPU time and power. So let me know if lowering that setting improves the situation. Thanks, Christopher Martin pgpALji3jtUJf.pgp Description: PGP signature
Bug#403291: gwenview: hogging CPU when working with GUI
Hello, Thanks for the report. I can't reproduice any unusual behaviour on my machine. Could you give me more details, steps to reproduce, etc.? Thanks, Christopher Martin On Friday 15 December 2006 18:11, Jiří Paleček wrote: Package: gwenview Version: 1.4.1-1 Severity: normal Hello, when I work with the GUI (eg. menu, or zoom combobox), gwenview uses 100% CPU for a while. This slows the whole GUI down. Regards Jiri Palecek -- System Information: Debian Release: 4.0 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17.3 Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-2) (ignored: LC_ALL set to cs_CZ) Versions of packages gwenview depends on: ii kdelibs4c2a4:3.5.5a.dfsg.1-5 core libraries and binaries for al ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libaudio2 1.8-2 The Network Audio System (NAS). (s ii libc6 2.5-0exp3 GNU C Library: Shared libraries ii libexiv2-0.10 0.10-1.3 EXIF/IPTC metadata manipulation li ii libfontconfig1 2.4.1-2 generic font configuration library ii libfreetype6 2.2.1-5 FreeType 2 font engine, shared lib ii libgcc11:4.1.1-19GCC support library ii libice61:1.0.1-2 X11 Inter-Client Exchange library ii libidn11 0.6.5-1 GNU libidn library, implementation ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libkipi0 0.1.4-1 library for apps that want to use ii libmng11.0.9-1 Multiple-image Network Graphics li ii libpng12-0 1.2.13-4 PNG library - runtime ii libqt3-mt 3:3.3.7-1 Qt GUI Library (Threaded runtime v ii libsm6 1:1.0.1-3 X11 Session Management library ii libstdc++6 4.1.1-19 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-4 X11 client-side library ii libxcursor11.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxft22.1.8.2-8 FreeType-based font drawing librar ii libxi6 1:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxrandr2 2:1.1.0.2-5 X11 RandR extension library ii libxrender11:0.9.1-3 X Rendering Extension client libra ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library ii zlib1g 1:1.2.3-13compression library - runtime Versions of packages gwenview recommends: ii kdegraphics-kfile-plugins 4:3.5.5-2 KDE metainfo plugins for graphic f ii kipi-plugins 0.1.2-3image manipulation/handling plugin -- no debconf information pgp2Qq7gwbeAt.pgp Description: PGP signature
Bug#392052: More info from someone with same problem
On Monday 23 October 2006 19:55, Robert L Mathews wrote: I also recently (2006-10-22) did a dist-upgrade and started experiencing the same problem described here: nothing in KDE would print any more, and I saw the same error when looking at Printers in the KDE Control Center: Connection to CUPS server failed. Check that the CUPS server is correctly installed and running. Error: localhost: read failed (15). However, I am using the testing distribution, so my kdeprint is still version 3.5.4-2+b1, and kdebase is still 3.5.4-2. On other words, kdeprint has not changed for some time on my machine. What *did* change on my machine as a result of the dist-upgrade is most of the other KDE components (to 3.5.5). So I suspect the problem actually lies elsewhere (I don't know where). Could you please upgrade your kdebase (and therefore kdeprint) to the version in Sid/unstable, 3.5.5? Then tell me if the problem persists (I guess you'll have to try printing with both Host=localhost and Host=127.0.0.1). Sorry to be a pain, but I want to be certain whether or not the problem still exists in 3.5.5, given that the Etch release isn't too far off. Thanks, Christopher Martin In response to the last poster, I looked at my ~/.kde/share/config/kdeprintrc file. It also has not changed in a long time, but I started playing with it to see if I could modify it to fix the problem. I found that this line in the [CUPS] section causes it to fail: Host=localhost But if I change that line to this, it works(!): Host=127.0.0.1 My machine has /etc/hosts set up correctly for localhost: $ host localhost localhost has address 127.0.0.1 So. This seems to indicate that some other KDE component in 3.5.5, other than kdeprint, has somehow broken the ability for hostnames to be resolved from kdeprintrc. Does that makes sense? Not to me. Hope it's useful to someone else If anyone cares, I can send along my /var/log/dpkg to show the exact 383 packages that were upgraded when the problem started. -- Robert L Mathews, Tiger Technologieshttp://www.tigertech.net/ pgpt2A0z2gLuo.pgp Description: PGP signature
Bug#394531: eject: new upstream release (2.1.5)
Package: eject Version: 2.1.4-2.1 Severity: wishlist Upstream has put out a minor but nice-to-have-for-Etch update to eject, 2.1.5. It would be great if you could upload it. Thanks, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393159: kdebase-bin: kdesu fails to accept a valid root password
On Sunday 15 October 2006 07:08, Vesa Savolainen wrote: Package: kdebase-bin Version: 4:3.5.4-2+b1 Severity: important kdesu gives me an error message claiming that the root password I gave it is invalid. But I know that I typed the valid root password. I tried several times with the same result. I think this must be a bug in kdesu. If you upgrade to the kdebase in unstable, does the problem go away? (Be sure to also use the kdelibs from unstable). Thanks, Christopher Martin pgpkeANDXKr3f.pgp Description: PGP signature
Bug#392959: ssmtp uninstallable on i386
Package: ssmtp Severity: serious Version: 2.61-9 The latest ssmtp was built against an obsolete libgnutls on i386 (presumably the arch on which it was uploaded). ssmtp/i386 unsatisfiable Depends: libgnutls11 (= 1.0.16) ... and consequently can't be installed on a Sid system that doesn't have this old library left over. Please have ssmtp rebuilt against libgnutls13. Thanks, Christopher Martin pgp0nxSm9EGOu.pgp Description: PGP signature
Bug#391502: closed by Christopher Martin [EMAIL PROTECTED] (Re: Bug#391502: Incorrect dependency on pmount)
On Wednesday 11 October 2006 11:01, Michael Biebl wrote: Oh dear, what a mess. Seems you were right, Christopher. Being part of the Debian Utopia team (which amongst others maintains hal), I knew, that the mount code (actually bash scripts) in 0.5.7 had some problems and we used to patch them to make use of pmount. Beginning with hal-0.5.8 we dropped these pmount patches from hal, as the mount code in hal was more robust and better dealt with non-removable/removable devices, or devices configured in /etc/fstab. Before I filed this bug report, I grepped the sources of kdebase and couldn't find a reference to pmount/pumount. I also did some tests with my cdrom drive. I removed the pmount binaries, and mounting/unmounting of the drive was still possible as an un-priviledged user (no matter if the device was configured in /etc/fstab or not). Only ejecting without having it unmounted first did not work without pmount. I therefore thought kded media manager properly uses hal to mount/unmount devices and it would be safe to remove the dependency on pmount. Today a friend of mine brought me an USB stick. I plugged it in, the icon appeared on the desktop and I was able to mount the device without problems. Unfortunately the option Safely Remove from the context menu did not have any effect. Only after installing pmount, I was able to unmount the USB stick. So, indeed, KDE seems to need pmount for successfully mounting/unmounting devices, and I was wrong requesting the removal of the dependency. The real problem though seems to be, that KDE doesn't use hal properly, to do the mounting/unmounting/ejecting. Unfortunately the code in kioslave/media/mediamanager/ is quite complex and large, so I couldn't easily spot the problem. Someone with more knowledge of this code should take a look at this and fix the hal support there. To make a long story short, I think the hal related mount code in KDE is somewhat broken atm and should be fixed in the long term. As a short term solution it's probably better to add the pmount dependency back. Will do. Thanks for the information. And yes, the KDE code is almost certainly to blame here. Hopefully KDE4 will clean things up. Cheers, Christopher Martin pgpLu22QEKLgO.pgp Description: PGP signature
Bug#392451: Undefined symbol in konqueror modules
tags 392451 unreproducible
severity 392451 important
stop
These types of errors are occassionally encountered when upgrading. A
restart of X (or the whole system) should almost certainly fix it
(we've had such reports in the past, and they always go away). Rather
than block the release, I'm downgrading this bug's severity for the
moment, but if I'm wrong and a reset doesn't make the problem go away,
let us know.
Cheers,
Christopher Martin
Brian Bassett wrote:
Package: konqueror
Version: 4:3.5.5-1
Severity: grave
Upon starting konqueror as a file manager (using the Home (Personal
Files) link on the K menu, popups indicate there were errors loading
modules used by Konqueror, all reporting that the
_ZN6KParts16BrowserExtension12itemsRemovedERK8QPtrListI9KFileItemE
symbol is undefined in /usr/lib/kde3/konq_{icon,list}view.so.
Konqueror then starts up in the Photobook mode, with no images
displayed (since I don't have any in my home directory).
The specific error messages that pop up are:
pgpBBKfQyJfX7.pgp
Description: PGP signature
Bug#392245: save doesnt work
tags 392245 unreproducible severity 392245 important notfound 392245 4:3.5.5a-1 stop I can't reproduce this using an up-to-date system. Unless it can be confirmed to happen on something recent, I don't think it should be an RC release blocker. Let us know what you find. Thanks, Christopher Martin On Tuesday 10 October 2006 17:32, Rafal Maj wrote: Package: kmenuedit Version: 3.5.3-2 Severity: grave Save function do not work, making the kmenueditor totally useless. The Updating system configuration shows up as usuall, it takes it time, it reaches 100% and then closes (no error report) but then chnages are not visible in KDE Menu. Although one thing do work - editing shorcut keys. ii kmenuedit 3.5.3-2 -- Rafał Maj www.Raf256.org C++ pgpr4G7TPQarx.pgp Description: PGP signature
Bug#391502: closed by Christopher Martin [EMAIL PROTECTED] (Re: Bug#391502: Incorrect dependency on pmount)
On Tuesday 10 October 2006 18:05, Michael Biebl wrote: reopen 391502 thanks On Friday 06 October 2006 18:45, Michael Biebl wrote: Package: kdebase Version: 4:3.5.5-1 Severity: serious Justification: violates policy The latest package update introduced a strict dependency on hal and pmount. While the hal dependency is correct, the pmount dependency is not. KDE simply calls the hal Mount()/Unmount() methods, nowhere in the KDE code, pmount is actually used. If hal would use pmount internally to do the actual mounting[1], fine, let the hal package declare the correct dependencies. Adding the pmount dependency to kdebase is simply wrong and violates the policy, which states that strict dependencies have to reflect that the depended-on package is required for the depending package to provide a significant amount of functionality which is not the case here. Please see also #388341, the Recommends: pmount of kdebase-kio-plugins does not directly violate the policy, still it should be removed for the same reasons. If the user does not have a line in /etc/fstab for a drive, then HAL will not be able to mount the drive in a way that works properly with KDE. Strange but true. That is, of course, unless pmount is installed, in which case HAL uses it to mount devices, in a way which works with KDE. Thus the depends/recommends on pmount makes perfect sense, and is by no means a policy violation. Seems, you didn't read my email carefully. Since version 0.5.8, hal does not use pmount anymore to do the mounting. Please check the source code, if you don't believe me. So now I have pmount installed, without any good reason. Argh, you're right, I didn't read the last blurb. Thanks. That said, pmount is still used (_directly_ by KDE) in some code, so while I'll drop it from kdebase's Depends, it'll stay as a Recommends with kdebase-kio-plugins. And still, it's up to the hal package, to add the dependency on pmount or not, because only the hal package knows, which tools it uses internally to do the mounting. I still disagree here, because this was an unusual case where the backend's choice of tool affected the frontend in an important way. But now it doesn't matter anyway. Cheers, Christopher Martin pgpho6DrK5z1L.pgp Description: PGP signature
Bug#384325: Patch for Bug#384325: libqt3-mt: Floating point exception in QPaintDevice::~QPaintDevice
On Friday 29 September 2006 05:48, Jean Parpaillon wrote: Just to confirm: in my xorg.conf file, I've specified the size of my monitor and fonts are displayed correctly in apps using qt, so the issue comes from the detection of the resolution of the monitor with fglrx driver. Yes. I wonder if the reason setting the DPI in Qt doesn't result in reasonable fonts is because it isn't really Qt that controls font rendering in most circumstances. It's fontconfig/freetype, the basic font rendering bits of Linux. That would explain why while I could fix the crash, I couldn't force fonts to render sensibly. Fontconfig still was trying to render based on the following information: $ xdpyinfo | grep -A1 dimen dimensions:1280x1024 pixels (0x0 millimeters) resolution:-2147483648x-2147483648 dots per inch ... that you provided to me in your previous message. Note the ridiculous dots per inch values. Hence the tiny fonts. If my understanding of the situation is correct, then there is no point in patching Qt. Users will simply have to provide monitor dimensions in xorg.conf if they use the fglrx driver. A pain, but at least it works. Cheers, Christopher Martin pgpHQMELDem7J.pgp Description: PGP signature
Bug#384325: Patch for Bug#384325: libqt3-mt: Floating point exception in QPaintDevice::~QPaintDevice
On Thursday 28 September 2006 03:10, Jean Parpaillon wrote: Le 28.09.2006 01:06, Christopher Martin a écrit : OK, thanks for the feedback. I can't reproduce that problem here, but then I'm not using fglrx (you are using that?). Thank you, that's a big issue for me :-( Yes, I'm using fglrx Deep down, this is a fglrx issue, and it's causing problems in apps other than those using Qt. But that doesn't mean I'm not trying to come up with a workaround... I'm assuming that you're using fglrx 8.28.8? There is a new upstream release, unfortunately not yet packaged officially for Debian, 8.29.6. I don't suppose upgrading to it makes a difference? I've updated the packages at: http://people.debian.org/~chrsmrtn/qt-x11-free-test ... with some minor changes. Sorry to be a pain, but could you please test them again? Ok, I've updated and... it's worse. Smaller. Sorry, I can't help more than testing. I appreciate you taking the time to test the packages. This baffles me - a DPI of 75 (the fallback) should not cause tiny fonts, it's a perfectly reasonable DPI. There must be another aspect of the problem I'm overlooking. If you run 'xdpyinfo | grep -A1 dimen' from a xterm, what results do you get? Be sure not to be running any Qt apps at the time. Note, you forgot to upload the Packages.gz file. Fixed now, thanks. Cheers, Christopher Martin pgpq6HQpXi9zH.pgp Description: PGP signature
Bug#384325: Patch for Bug#384325: libqt3-mt: Floating point exception in QPaintDevice::~QPaintDevice
OK, thanks for the feedback. I can't reproduce that problem here, but then I'm not using fglrx (you are using that?). I've updated the packages at: http://people.debian.org/~chrsmrtn/qt-x11-free-test ... with some minor changes. Sorry to be a pain, but could you please test them again? I appreciate it. And other people can test them as well... If they still don't work (or your fonts are still hopeless) then I'm out of ideas for the moment. Qt should now fall back to a dpi of 75, same as X's default value, so the fonts may not be perfect, but they shouldn't be messed up like yours were. Thanks, Christopher Martin On Wednesday 27 September 2006 08:25, Jean Parpaillon wrote: Le 27.09.2006 04:11, Christopher Martin a écrit : I've also built qt-x11-free packages which contain a patch that _might_ fix your problems. Please update your Qt packages (libqt3-mt in particular) using the packages at: http://people.debian.org/~chrsmrtn/qt-x11-free-test ... then restart, and let me know if things start to work and are otherwise OK. Hi, Using this package, qt applications starts but fonts are incredibily small (see joined file) for all apps. Jean Thanks, Christopher Martin On Tuesday 26 September 2006 21:06, Christopher Martin wrote: Does everyone who suffers from the Qt3 crashes use ATI's proprietary fglrx driver? We have a report of a switch away from fglrx fixing the crashes in Qt/KDE, and other apps. Please let me know either way.
Bug#384325: libqt3-mt: Floating point exception in QPaintDevice::~QPaintDevice
Does everyone who suffers from the Qt3 crashes use ATI's proprietary fglrx driver? We have a report of a switch away from fglrx fixing the crashes in Qt/KDE, and other apps. Please let me know either way. Thanks, Christopher Martin pgp0Czqz13Ls0.pgp Description: PGP signature
Bug#384325: Patch for Bug#384325: libqt3-mt: Floating point exception in QPaintDevice::~QPaintDevice
I've also built qt-x11-free packages which contain a patch that _might_ fix your problems. Please update your Qt packages (libqt3-mt in particular) using the packages at: http://people.debian.org/~chrsmrtn/qt-x11-free-test ... then restart, and let me know if things start to work and are otherwise OK. Thanks, Christopher Martin On Tuesday 26 September 2006 21:06, Christopher Martin wrote: Does everyone who suffers from the Qt3 crashes use ATI's proprietary fglrx driver? We have a report of a switch away from fglrx fixing the crashes in Qt/KDE, and other apps. Please let me know either way. pgpoVNxhbvMcO.pgp Description: PGP signature
Bug#384106: Kopete crashes whole system
Hello, It looks like KDE 3.5.5 will have Kopete 0.12.x, a big update over the version shipped in KDE 3.5.4. Could you please test whether that version of Kopete still suffers from the bug? It's currently available unofficially from http://manfred.cp69.de/debian. I'd really appreciate it if those affected could give it a try and let us know if the problem still happens. Thanks, Christopher Martin Bastian Venthur wrote: Package: kopete Version: 4:3.5.4-2 Severity: critical The latest version of kopete regulary hangs the whole system. I don't know how to reproduce this bug, but it appears randomly every few days. If it happens, kde hangs completely, leaving the user unable to switch to a different terminal or even to restart X. The mouse is not reacting anymore and the system does not respond on any keystrokes. pgpq6AFEFOEPI.pgp Description: PGP signature
Bug#388092: kdesdk: FTBFS: Build-Depends dependency for kdesdk cannot be satisfied because no available versions of package libsvn0-dev can satisfy version requirements
reopen 388092 stop I'm wrong. It looks like we'll have to switch over to libdb4.4-dev, and kdepim will need a rebuild against the new libpisock9. Thanks for the tip. Note to self: get more sleep. On Tuesday 19 September 2006 17:33, Christopher Martin wrote: kdesdk: FTBFS: Build-Depends dependency for kdesdk cannot be satisfied because no available versions of package libsvn0-dev can satisfy version requirements Works fine on i386. This must be arch-specific uninstallability. On many architectures a lot of KDE packages are currently unbuildable, not because of a problem in the module, but due to something down the chain needing a rebuild to fix installability. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284699: Upgrade
On Sunday 17 September 2006 03:59, Filipus Klutiero wrote: severity 284699 serious found 284699 4:3.5.4-2 thanks From what I understood, upstream KDE completely ignores licensing questions regarding non-source files beyond distributability. Other icons from crystalsvg seem non-free, such as icons for Thunderbird, Adobe Reader, Realplayer. A full inspection should be done. Yikes. Well, short of a full review, at least the icons which originate from Mozilla and non-free projects should be examined. Would you be willing to help do this, find replacement icons, etc.? The rest of the team is pretty much swamped right now, so help would be much appreciated, especially with the Etch freeze coming. I have kde-svn access, so I can ensure that good fixes make 3.5.5. Thanks, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326619: Bugs fixed by Qt/KDE team upload
These bugs are marked fixed in an NMU, but for all intents and purposes they were Qt/KDE team uploads, so I'm formally closing them as well. Cheers, Christopher Martin pgpkLkch00Ian.pgp Description: PGP signature
Bug#384325: libqt3-mt: Floating point exception in QPaintDevice::~QPaintDevice
We've had reports that the libqt3-mt crashing bug can be fixed by upgrading to the latest X and other libraries. Certainly, it would appear that it was a change in some library which Qt uses which triggered the problem. I'd very much like to receive confirmation (or denials if the problem persists after upgrade + reboot, to be safe) from some other users, since it's an important bug and I can't reproduce it myself. Thanks, Christopher Martin pgpTLGj8OomCA.pgp Description: PGP signature
Bug#386031: please drop the build dependency on g++-4.0 on alpha
On Monday 04 September 2006 15:51, Matthias Klose wrote: Package: kdegraphics Version: 4:3.5.4-2 Severity: important please drop the build dependency on g++-4.0 on alpha, compiling kviewshell/plugins/djvu/libdjvu/GString.cpp using -O0 on alpha. We use g++-4.0 because 4.1 FTBFSes. See bug #381717. Once that's fixed, then of course we'll switch back to 4.1. Let me know if there's something going on here that I don't understand. Cheers, Christopher Martin pgppeggQlYrQI.pgp Description: PGP signature
Bug#385194: closed by Christopher Martin [EMAIL PROTECTED] (reply to Christopher Martin [EMAIL PROTECTED]) (Re: Bug#385194: kdebase source is missing debian/debian-kde_default.png)
Hi, The file is uuencoded in 21_default_background_image.diff.uu, so when the build process applies the patches, the file is created. So it is present to be copied into the .debs when they're built. Cheers, Christopher Martin On Wednesday 30 August 2006 20:29, Sean Meiners wrote: What version did 'apt-get source kdebase' get you? For me it gets: Get:1 ftp://ftp.us.debian.org unstable/main kdebase 4:3.5.4-2 (dsc) [1810B] Get:2 ftp://ftp.us.debian.org unstable/main kdebase 4:3.5.4-2 (tar) [28.2MB] Get:3 ftp://ftp.us.debian.org unstable/main kdebase 4:3.5.4-2 (diff) [1789kB] And when unpacked ' grep -r debian-kde_default debian/*' finds several references to the file, but 'ls debian/debian-kde_default.png' finds nothing. On Wednesday 30 August 2006 17:04, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #385194: kdebase source is missing debian/debian-kde_default.png, which was filed against the kdebase package. It has been closed by Christopher Martin [EMAIL PROTECTED] (reply to Christopher Martin [EMAIL PROTECTED]). Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Christopher Martin [EMAIL PROTECTED] (reply to Christopher Martin [EMAIL PROTECTED]) by replying to this email. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381232: firefox: No font anti-aliasing (anymore)
Hello, On Sunday 13 August 2006 22:34, Branden Robinson wrote: Would it make sense for kdebase to assume anti-aliasing is on in the absence of an XftAntialias parameter setting in kdeglobals? Yes, it would - thanks for the analysis. Changing that assumption appears to resolve the issue, as I understand it. I've committed the fix (and some others - antialiasing being on/off wasn't the only issue I found with KDE's font defaults) so the next kdebase upload should resolve matters. Cheers, Christopher Martin pgpCK2Roj5zBD.pgp Description: PGP signature
Bug#384106: crashes whole system
On Monday 21 August 2006 17:40, Bastian Venthur wrote: Package: kopete Version: 4:3.5.4-2 Severity: critical The latest version of kopete regulary hangs the whole system. I don't know how to reproduce this bug, but it appears randomly every few days. If it happens, kde hangs completely, leaving the user unable to switch to a different terminal or even to restart X. The mouse is not reacting anymore and the system does not respond on any keystrokes. Sometimes it is possible to ssh into the box from another box and kill kopete which instantly resurrects the system. But if you wait too long, the box does not even answer to ping requests and you have to restart the hard way. After running Kopete for a while, does it consume a more than reasonable amount of memory? When it finally goes berserk, does it eat CPU cycles, suddenly eat memory, etc.? Also, are you always using a certain protocol when the problem happens, any fancy plugins, etc.? Thanks, Christopher Martin pgphRepFZLR1b.pgp Description: PGP signature
Bug#384325: libqt3-mt: Floating point exception in QPaintDevice::~QPaintDevice
On Wednesday 23 August 2006 10:11, Jean Parpaillon wrote: Package: libqt3-mt Version: 3:3.3.6-3 Severity: grave Justification: renders package unusable All apps using libqt3-mt end on a flaoting point exception. After compiling with debug an tracing amarok, it seems to fail in QPaintDevice::~QPaintDevice: Program received signal SIGFPE, Arithmetic exception. [Switching to Thread -1476536640 (LWP 8061)] 0x4129318d in QPaintDevice::~QPaintDevice () from /usr/lib/libqt-mt.so.3 Strange that such a problem would only be reported by one person. You mention amarok, but also that all apps are afflicted. When you say all Qt apps end on a SIGFPE, do you mean that instead of quitting properly they blow up? Or that they just don't run? I don't suppose that you could attach a full backtrace? Does downgrading to libqt3-mt 3.3.6-2 from testing/etch make any difference? I'd appreciate more information; otherwise, there isn't much I can do. Cheers, Christopher Martin pgpO4ImmhqGLM.pgp Description: PGP signature
Bug#369729: openoffice.org-kde: Interface fonts are severely jagged suddenly in Etch
Package: openoffice.org-kde Version: 2.0.1-5 Severity: important The interface fonts of Openoffice.org have become very jagged and difficult to read. They look very different from fonts from other apps. Here's a screenshot to demonstrate the difference: http://img343.imageshack.us/img343/2286/fokfont7si.png This regression was confirmed by another person, so it seems I'm not the only one with this problem, hence the report. A temporary fix is to enable anti-aliasing, even though it makes the fonts fuzzy instead. This problem still exists in Sid. It can be worked around by using an older libfreetype6, and described in an earlier post, but not, AFAICT, by any other means. I'm sorely tempted to raise this to RC, since we really shouldn't ship an Etch where users of openoffice.org-kde and openoffice.org-gnome (i.e. a lot of people) have to put up with garbage fonts in a major application. Is upstream aware of this issue? Is it really a bug in OOO.org? Cheers, Christopher Martin pgpRQEH8px2Rd.pgp Description: PGP signature
Bug#373832: Requests for Kopete 0.12.x in Sid/Testing
tags 373832 wontfix tags 378383 wontfix tags 382874 wontfix stop Kopete 0.12.x was promised for KDE 3.5.4. However, the Kopete team didn't get around to merging it into KDE in time. Whether they'll merge for KDE 3.5.5 I can't possibly say, but even if they do, KDE 3.5.5 might not ship with Etch. Manually grafting Kopete 0.12.x onto the existing kdenetwork module would be a huge undertaking, and would be a support and bug tracking nightmare for the lifespan of the Etch release, because it would represent a huge divergence from upstream KDE and its support systems, security, etc. No one on the Debian KDE team has expressed any commitment to such an undertaking, so don't expect this solution to happen. Also, it isn't easy to upload Kopete 0.12.x as a separate package. It would have to remain forever in experimental, since having 2 source packages provide the same binary pacakge in Sid/Etch, both of which are supported, just doesn't work. And this would only happen if we could convince the FTP masters that it was a good idea (which it isn't) and therefore to let the package pass the NEW queue. So I'm afraid that if you want to use Kopete 0.12.x, you'll have to use unofficial packages. http://manfred.cp69.de/debian is kindly offering packages, and IIRC other people have built their own (see the recent debian-kde list archives). So users who really want the latest and greatest can certainly get it. I hope this clarifies the situation. Cheers, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370513: Sarge gwenview not saving brightness changes
forwarded 370513 https://bugs.kde.org/132429 severity 370513 wishlist stop I've forwarded this request upstream. It's really a feature request, so I'm chaning the severity to 'wishlist'. Cheers, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377689: HAL policy breaks mounting for next KDE
On Tuesday 08 August 2006 18:09, Martin Pitt wrote: Sjoerd Simons [2006-08-08 22:23 +0200]: The problem with the fix is that some parts of debian will use pmount and other part hal callouts, while i would prefer that all desktops use the same way of mounting removable media. What was the reason for KDE to drop pmount and switch to hal callouts ? For the record, we recently had the very same problem, so I changed ubuntu's hal to enable the storage scripts again, and patched them to use pmount. So we get the best of both worlds: the rigid pmount policy checks, and the rather convenient hal interface, which has already become a standard interface in both KDE and gnome-volume-manager. FYI I attach the relevant bzr diffs (sorry, a bit messy). This sounds perfect, though I haven't yet had time to test it. Sjoerd, any thoughts? Cheers, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342545: qt-x11-free FTBFS
reassign 342545 libgcc2 stop On Thursday 10 August 2006 00:25, Steve Langasek wrote: It hasn't been, because I can't see any way that libglu1-mesa could have anything to do with the failure in question. libglu1-mesa should not be a dependency of the tool that's failing with SIGBUS in the build log. I would suggest that someone should investigate this further and get a clear answer on the nature of the bug, because I really don't buy that libgcc skew is to blame. Fair enough, but before I take off for the weekend, I'm sending this report back to libgcc2, since it seems to have been established long ago that this isn't a Qt bug, and it really should be assigned to something in the toolchain. I note that, for a time, the problem was thought to be in glibc, so perhaps the glibc team would again be worth consulting. Cheers, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382031: Error updating koffice-i18n-es to 1.5.2-1
severity 382031 serious stop Uh oh, looks like a conflict. kde-i18n has had this file for a while, so I think the correct course of action would be for koffice-i10n to simply drop that file (and any others that conflict as well) for all languages. Upstream might want to know as well, just to save other distros the trouble; or there might even be a reason for what they're doing. Cheers, Christopher Martin On Tuesday 08 August 2006 08:28, Raúl Sánchez Siles wrote: Package: koffice-i18n-es Version: 1.5.1-1 Severity: normal I can't upgrade from 1.5.1-1 to 1.5.2-1 look at this: Preparando para reemplazar koffice-i18n-es 1.5.1-1 (usando .../koffice-i18n-es_1.5.2-1_all.deb) ... Desempaquetando el reemplazo de koffice-i18n-es ... dpkg: error al procesar /var/cache/apt/archives/koffice-i18n-es_1.5.2-1_all.deb (--unpack): intentando sobreescribir `/usr/share/doc/kde/HTML/es/api/kfontdialog.png', que está también en el paquete kde-i18n-es dpkg-deb: el subproceso paste fue terminado por la señal (Tubería rota) Se encontraron errores al procesar: /var/cache/apt/archives/koffice-i18n-es_1.5.2-1_all.deb It seems that a file the kfontdialog.png file also belongs to another package (kde-i18n-es).
Bug#381572: [m68k] ICE in extract_insn, at recog.c:2084
severity 381572 grave stop Stephen R Marenka wrote: Package: gcc-4.1 Version: 4.1.1-9 Severity: important While debugging binutils and kdelibs I came across an ICE in extract_insn, at recog.c:2084. I'm not sure if this is related to 375522 since that also involves instruction issues. This problem also affects kdegraphics on alpha: /build/buildd/kdegraphics-3.5.4/./kviewshell/plugins/djvu/libdjvu/GString.cpp: In member function 'GPGStringRep GStringRep::vformat(va_list) const': /build/buildd/kdegraphics-3.5.4/./kviewshell/plugins/djvu/libdjvu/GString.cpp:1731: error: unrecognizable insn: (insn 238 237 239 16 /build/buildd/kdegraphics-3.5.4/./kviewshell/plugins/djvu/libdjvu/GString.cpp:1719 (set (reg:DI 162) (plus:DI (reg:DI 69 [ buffer.6150 ]) (const_int 32768 [0x8000]))) -1 (nil) (nil)) /build/buildd/kdegraphics-3.5.4/./kviewshell/plugins/djvu/libdjvu/GString.cpp:1731: internal compiler error: in extract_insn, at recog.c:2084 I'm upping the severity, since this affects a release architecture. The full log is available at: http://buildd.debian.org/fetch.php?pkg=kdegraphicsver=4%3A3.5.4-1arch=alphastamp=1154331232file=logas=raw Cheers, Christopher Martin pgpvRCL4V5nUG.pgp Description: PGP signature
Bug#380370: FTBFS: arts on arm due to segmentation fault (program as)
FYI, this also appears to have broken a kdepim build: http://buildd.debian.org/fetch.php?pkg=kdepimver=4%3A3.5.3-3arch=armstamp=1153287934file=logas=raw Cheers, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342545: qt-x11-free FTBFS
On Sunday 30 July 2006 17:50, Marc 'HE' Brockschmidt wrote: Discussion in IRC showed that doko suspects libgcc2 deps in one of the build-deps to be the problem. A quick check revealed that libglu1-mesa still does that, so I requested a bin-NMU. Hopefully, after that was done, a reschedule will work out. qt-x11-free was retried on hppa, but failed again. However, I see no evidence that a bin-NMU of libglu1-mesa was ever done, so this isn't shocking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381321: kopete: Client is too old for ICQ
On Saturday 05 August 2006 08:16, Daniel Huhardeaux wrote: Please ignore, it's working. I forgot to close the running instance. Sorry for the noise :-( No problem; it happens. Glad it's now working for you. Cheers, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381321: kopete: Client is too old for ICQ
On Saturday 05 August 2006 08:12, Daniel Huhardeaux wrote: Christopher Martin wrote: As stated elsewhere, a fixed package is now in the archive. It looks like the ftp.us.debian.org mirror (and perhaps others?) is having problems, however, as it has not been updated in several days. Try another mirror, and the fixed packages should be available. I tried: ftp.fr.debian.org and got a new version ii kopete3.5.4-2 instant messenger for KDE Same problem. I then change to ftp.de.debian.org ftp2.de.debian.org No updates, so problem still remain. So you installed kopete 3.5.4-2, restarted KDE (let's err on the side of caution here) and kopete still doesn't work with ICQ? Can you confirm that? Because KDE upstream claims to have fixed the problem... Cheers, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381578: kdelibs4c2a: katepart crashes when pressing Return insider doxygen comments
severity 381578 important stop I don't think that it's a data-loss issue more than any other crash in an editor, browser, etc., so I don't think it's truly RC. BTW, I really appreciate your efforts to forward bugs upstream. Cheers, Christopher Martin On Saturday 05 August 2006 11:30, Andreas Pakulat wrote: Package: kdelibs4c2a Version: 4:3.5.4-3 Severity: critical Justification: causes serious data loss Hi, just found this out. Creating a doxygen comment block (beginning with /**) inside kate and then pressing Return crashes Kate with the following backtrace: #0 0xb465b9ce in KateTextLine::stringAtPos (this=0x9fe72e0, pos=4294967295, [EMAIL PROTECTED]) at /home/sid-user/kdelibs/kdelibs-3.5.4/./kate/part/katetextline.cpp:196 #1 0xb46e2b16 in KateCSAndSIndent::handleDoxygen (this=0x90823b0, [EMAIL PROTECTED]) at /home/sid-user/kdelibs/kdelibs-3.5.4/./kate/part/kateautoindent.cpp:1 497 #2 0xb46e2e9c in KateCSAndSIndent::processNewline (this=0x90823b0, [EMAIL PROTECTED]) at /home/sid-user/kdelibs/kdelibs-3.5.4/./kate/part/kateautoindent.cpp:1 522 #3 0xb46fb6fb in KateDocument::newLine (this=0x917cc90, [EMAIL PROTECTED], v=0x91c8b20) at /home/sid-user/kdelibs/kdelibs-3.5.4/./kate/part/katedocument.cpp:300 1 #4 0xb47101d4 in KateViewInternal::doReturn (this=0x91c8b20) at /home/sid-user/kdelibs/kdelibs-3.5.4/./kate/part/kateviewinternal.cpp :893 #5 0xb4739d93 in KateView::keyReturn (this=0x91e2e28) at /home/sid-user/kdelibs/kdelibs-3.5.4/./kate/part/kateview.h:329 #6 0xb4724daa in KateViewInternal::keyPressEvent (this=0x91c8b20, e=0xbfce4b10) at /home/sid-user/kdelibs/kdelibs-3.5.4/./kate/part/kateviewinternal.cpp :2507 #7 0xb470c5e8 in KateViewInternal::eventFilter (this=0x91c8b20, obj=0x91c8b20, e=0xbfce4b10) at /home/sid-user/kdelibs/kdelibs-3.5.4/./kate/part/kateviewinternal.cpp :2439 #8 0xb680d17a in QObject::activate_filters (this=0x91c8b20, e=0xbfce4b10) at kernel/qobject.cpp:903 #9 0xb680d1f8 in QObject::event (this=0x91c8b20, e=0xbfce4b10) at kernel/qobject.cpp:735 #10 0xb684448a in QWidget::event (this=0x91c8b20, e=0xbfce4b10) at kernel/qwidget.cpp:4678 #11 0xb67a5b2a in QApplication::internalNotify (this=0xbfce4ff4, receiver=0x91c8b20, e=0xbfce4b10) at kernel/qapplication.cpp:2635 This can cause data loss when one just wanted to add a comment to a file and didn't save before writing it. If you feel this is not that important please downgrade severity. I currently am unable to report this upstream, because I think it is an upstream issue, but I will do as soon as bugs.kde.org works again. Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334698: closed by Christopher Martin [EMAIL PROTECTED] (reply to Christopher Martin [EMAIL PROTECTED]) (Re: Bug#334698: htdig: AMD64 arch corrupts databases)
Hi, Actually, Debian has never had more than one version of htdig in the archive. This was 3.1 until my recent upload, which replaced it with 3.2b6. The 3.1 package was hopelessly uninstallable and RC buggy - the official count didn't take into consideration bugs (like #334698) which weren't listed as RC but should have been. I reasoned that slower software that our users could actually install and would be in our release was better than fast software no one would/could use without massive annoyances and a trip to archive.debian.net. Since 3.2b6 resolves bug #334698, it was entirely appropriate for me to close the report. If you really want to keep using htdig 3.1, then you should: 1) Fix all the RC bugs the package had, not just the libdb2 issue. 2) File an ITP and upload a new htdig3.1 or htdig-legacy package. 3) Be prepared to maintain it without upstream support. Cheers, Christopher Martin On Friday 04 August 2006 04:50, Jeff Breidenbach wrote: Debian uses a separate package for the 3.2 and 3.1 versions due to large performance difference (3.2 does more, but is much more resource hungry). Please reopen and mark wontfix. On Thu, 3 Aug 2006 5:55 pm, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #334698: htdig: AMD64 arch corrupts databases, which was filed against the htdig package. It has been closed by Christopher Martin [EMAIL PROTECTED] (reply to Christopher Martin [EMAIL PROTECTED]). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381321: kopete: Client is too old for ICQ
As stated elsewhere, a fixed package is now in the archive. It looks like the ftp.us.debian.org mirror (and perhaps others?) is having problems, however, as it has not been updated in several days. Try another mirror, and the fixed packages should be available. Cheers, Christopher Martin On Thursday 03 August 2006 15:50, daniel huhardeaux wrote: Package: kopete Version: 4:3.5.4-1 Followup-For: Bug #381321 I confirm this, only for ICQ. Popup window ask to report a bug to http://bugs.kde.org -- 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.17-custom.1 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages kopete depends on: ii kdelibs4c2a 4:3.5.4-2core libraries and binaries for al ii libacl1 2.2.41-1 Access control list shared library ii libart-2.0-22.3.17-1 Library of functions for 2D graphi ii libattr1 2.4.32-1 Extended attribute shared library ii libaudio2 1.8-1The Network Audio System (NAS). (s ii libc6 2.3.6-16 GNU C Library: Shared libraries ii libfontconfig1 2.3.2-7 generic font configuration library ii libfreetype62.2.1-2 FreeType 2 font engine, shared lib ii libgadu3 1:1.6+20060616-1 Gadu-Gadu protocol library - runti ii libgamin0 [libfam0] 0.1.7-3 Client library for the gamin file ii libgcc1 1:4.1.1-10 GCC support library ii libglib2.0-02.10.3-3 The GLib library of C routines ii libice6 1:1.0.0-3X11 Inter-Client Exchange library ii libidn110.6.5-1 GNU libidn library, implementation ii libjpeg62 6b-13The Independent JPEG Group's JPEG ii libmeanwhile1 1.0.2-2 open implementation of the Lotus S ii libpcre36.4-2Perl 5 Compatible Regular Expressi ii libpng12-0 1.2.8rel-5.2 PNG library - runtime ii libqt3-mt 3:3.3.6-3Qt GUI Library (Threaded runtime v ii libsm6 1:1.0.0-4X11 Session Management library ii libstdc++6 4.1.1-10 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.0-7X11 client-side library ii libxcursor1 1.1.5.2-5X cursor management library ii libxext6 1:1.0.0-4X11 miscellaneous extension librar ii libxft2 2.1.8.2-8FreeType-based font drawing librar ii libxi6 1:1.0.0-5X11 Input extension library ii libxinerama11:1.0.1-4X11 Xinerama extension library ii libxml2 2.6.26.dfsg-3GNOME XML library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender1 1:0.9.0.2-4 X Rendering Extension client libra ii libxslt1.1 1.1.17-2 XSLT processing library - runtime ii libxss1 1:1.0.1-4X11 Screen Saver extension library ii libxt6 1:1.0.0-5X11 toolkit intrinsics library ii zlib1g 1:1.2.3-13 compression library - runtime Versions of packages kopete recommends: ii qca-tls 1.0-3 TLS plugin for the Qt Cryptographi -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381326: kate-plugins: .la file references libX*.la
fixed 381331 4:3.5.3-1 fixed 381329 4:3.5.3-1 stop In response to all the bugs filed against KDE modules concerning this issue: The kdebindings package seems to have been fixed with the 3.5.3-1 upload. As for the others, they will be fixed once a new kdepim is uploaded by Daniel Schepler, and the KDE team follows with the few modules not yet at the 3.5.4 version. Thanks, Christopher Martin On Thursday 03 August 2006 13:13, Jiri Palecek wrote: Package: kate-plugins Version: 4:3.5.2-1 Severity: normal Hello, package kate-plugins contains the files /usr/lib/kde3/katecppsymbolviewerplugin.la /usr/lib/kde3/katexmltoolsplugin.la /usr/lib/kde3/katetextfilterplugin.la /usr/lib/kde3/katexmlcheckplugin.la /usr/lib/kde3/kateinsertcommandplugin.la /usr/lib/kde3/katefiletemplates.la /usr/lib/kde3/katefll_plugin.la /usr/lib/kde3/libkatetabbarextensionplugin.la /usr/lib/kde3/katehelloworldplugin.la /usr/lib/kde3/katemakeplugin.la /usr/lib/kde3/katemodelineplugin.la /usr/lib/kde3/kateopenheaderplugin.la /usr/lib/kde3/katesnippetsplugin.la /usr/lib/kde3/katepybrowseplugin.la /usr/lib/kde3/katehtmltoolsplugin.la that reference a libX\*.la file as a dependency. However, in the xorg 7.x.x packages, there are no such files. According to http://bugs.debian.org/354674 , packages containing such references need to be rebuilt. Also, see that bugreport for details. Please, just close this bug if the referenced file is not from xorg (but has just a similar name). Regards Jiri Palecek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381323: gwenview: .la file references libX*.la
Hi, Thanks for the reminder. A new Gwenview should be uploaded soonish - upstream is busy working on a new release. It should make Etch. Cheers, Christopher Martin On Thursday 03 August 2006 13:13, Jiri Palecek wrote: Package: gwenview Version: 1.3.1-2 Severity: normal Hello, package gwenview contains the files /usr/lib/kde3/gwenview.la /usr/lib/kde3/libgvimagepart.la /usr/lib/kde3/libgvdirpart.la /usr/lib/libgwenviewcore.la /usr/lib/libkdeinit_gwenview.la that reference a libX\*.la file as a dependency. However, in the xorg 7.x.x packages, there are no such files. According to http://bugs.debian.org/354674 , packages containing such references need to be rebuilt. Also, see that bugreport for details. Please, just close this bug if the referenced file is not from xorg (but has just a similar name). Regards Jiri Palecek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377147: kdebase: libcairo2 issue still not fixed?
On Monday 31 July 2006 10:53, Mau wrote: As you can see I'm running a mixed 3.5.3+3.5.4 KDE install: after upgrade to 3.5.4-2 of some kdebase-derived binaries I'm having exactly the issue described previously, so I preferred to downgrade some packages. There were really two problems. One was fixed in KDE 3.5.4 (try enabling/disabling anti-aliasing, then again, to see if your problems are fixed) and another more basic problem in Cairo, which is not yet fixed. It is bug #376714, FYI. You may be experiencing the later. Cheers, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377689: HAL policy breaks mounting for next KDE
Package: hal Version: 0.5.7-2 Severity: important The next release of KDE, 3.5.4, brings changes to how removable devices are mounted (by changing how dbus/HAL/pmount is used), and this has uncovered a problem with Debian's HAL. Now that KDE 3.5.4 is in the archive, we're getting reports of breakage. It would be nice, therefore, if this issue were resolved. Do you plan to accept the included fix, reject it, have an ETA on the next upload, etc.? Thanks, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380685: kdebase-kio-plugins: tar io-slave totally broken since upgrade to 3.5.4
On Monday 31 July 2006 16:58, Andreas Pakulat wrote: Package: kdebase-kio-plugins Version: 4:3.5.4-2 Severity: important just found out that the tar io-slave doesn't work on tar.gz's anymore (didn't test plain tar or tar.bz2), it extracts all files with 0 size. Could this be related to the recent changes in tar? I would've raised the severity, but wasn't sure if it is justified, it totally breaks project creation in kdevelop because the template files are inside tar.gz's. Works for me. Do you have any files we could use to test? Thanks, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380688: kdebase-kio-plugins: Devices are not mounted as user
On Monday 31 July 2006 17:16, Markus Huber wrote: kde-kio-plugins 3.5.4-2 do not mount devices as user, instead there is a failure text from kio_media_mounthelper: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface org.freedesktop.Hal.Device.Volume member Mount error name (unset) destination org.freedesktop.Hal). The root of the problem is bug #377689 in HAL. Feel free to read that for more details. You can work around the issue for now by ensuring that all your drives have lines in /etc/fstab with the user option. Cheers, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348578: libnss-mdns: please modify /etc/nsswitch.conf at install time
unmerge 348578 reopen 348578 found 348578 0.8-1 tags 348578 - fixed stop I'm reopening the request to have libnss-mdns automatically modify /etc/nsswitch.conf, now that base-files no longer treats it as a conffile and it can be legally modified (i.e. base-files will not make the change; it is up to libnss-mdns to do it, preferably during the package installation and removal phases). Otherwise Etch will ship without a proper mdns setup by default, if I understand correctly. Thanks, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342545: qt-x11-free FTBFS on hppa (again)
On Sunday 30 July 2006 09:18, Matthias Klose wrote: Please see http://lists.debian.org/debian-hppa/2006/05/msg0.html the binaries in qt-x11-free still depend on libgcc2, so these should be rebuilt first (and all depending ones), then we should revisit this report. If the problem persists, please reassign the report again. Sorry to be a pain; perhaps I'm just dense, but what exactly should I do? I uploaded qt-x11-free, and the hppa buildd tried to build it with g++-4.1. This failed. How does the old version of qt-x11-free depending on libgcc2 relates to the failure of the current build? Is there something else I should have done? Are there other packages that need to be rebuilt before qt-x11-free will build? If yes, then this bug should be reassigned to them. If no, then what should I do? Thanks for your help, Christopher Martin Christopher Martin writes: I'm not quite sure I understand. The build did try to use g++-4.1, and it failed. This was long ago determined to be a glibc or gcc problem, not a qt-x11-free problem, so why was it reassigned to qt-x11-free? On Saturday 29 July 2006 18:48, Matthias Klose wrote: reassign 342545 qt-x11-free thanks please make sure, that qt-x11-free is built using g++-4.1 on hppa. The binary packages still depend on libgcc2 in some way. Note, that (before the release) we need to rebuild all binaries depending on libgcc2 on hppa, so that the dependency is replaced by libgcc4. Christopher Martin writes: reopen 342545 2.3.6-15 severity 342545 grave stop Unfortunately, the qt-x11-free FTBFS on hppa has re-occurred: http://buildd.debian.org/fetch.php?pkg=qt-x11-freever=3%3A3.3 .6-3 arch=hppastamp=1153689954file=logas=raw The error is exactly the same as before: /build/buildd/qt-x11-free-3.3.6/bin/uic -L /build/buildd/qt-x11-free-3.3.6/plugins pixmapfunction.ui -o pixmapfunction.h make[4]: *** [pixmapfunction.h] Bus error -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380499: cdbs 0.4.45 simple-patchsys.mk doesn't properly distinguish patches
Package: cdbs Version: 0.4.45 Severity: critical apt-get source kdelibs, and in the top-level source directory, try: fakeroot debian/rules apply-patches Notice how debian/patches/04_am_maintainer_mode.diff is skipped because it's already applied even though it clearly isn't? There is a similarly named but different patch, debian/patches/common/04_am_maintainer_mode.diff, which is perhaps confusing CDBS. Then of course if you try: fakeroot debian/rules clean ...we get an error, since it can't unapply a patch that wasn't actually applied. This could mess up a number of KDE builds, so a quick fix would be great. CDBS 0.4.44 worked fine. Thanks, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380370: FTBFS: arts on arm due to segmentation fault (program as)
Package: binutils Version: 2.17-1 Severity: serious The package 'arts' failed to build on arm, using binutils 2.17-1. Log is available at: http://buildd.debian.org/fetch.php?pkg=artsver=1.5.4-1arch=armstamp=1153922700file=logas=raw The interesting bit: /usr/lib/gcc/arm-linux-gnu/4.0.4/../../../../include/c++/4.0.4/bits/basic_string.h:278: warning: cast from 'char*' to 'std::basic_stringchar, std::char_traitschar, std::allocatorchar ::_Rep*' increases required alignment of target type g++: Internal error: Segmentation fault (program as) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.0/README.Bugs. Perhaps binutils related? I'll send the report to you for now. Thanks, Christopher Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
