Bug#515200: Providing an openssl-linked pycurl
Guido Trotter wrote: According to my understandment: - OpenSSL is released under a license which is GPL incompatible, unless an exception to the GPL is used in the software compiled with it. Debian cannot distribute GPL software released under the unmodified GPL and linked against OpenSSL. - pycurl is released under the LGPL (2.1 or later) or a MIT/X derivative license based on the one of curl itself. Neither of these licenses is incompatible with OpenSSL, and as for curl itself we should be able to provide a version of pycurl which uses openssl. Am I correct up to here? http://packages.debian.org/changelogs/pool/main/p/pycurl/current/copyright suggests so. Now, what would be the status of (unmodified) GPL python software which imports pycurl? Is this considered the same as linking, and would it have to make sure it uses the GNUTLS version, by depending on it? What GNUTLS version? Oh, it looks like that's the current version. As I understand it, if the GPL python software were derived from openssl in some way, then there would be a problem. Otherwise, not. If it worked with a GNUTLS version of pycurl unmodified/interchangably, I think it's unlikely there's a problem. But then the GNUTLS version must exist to be sure things work, so why not use the GNUTLS version? In the case of bug 515200, the report about www1.banking.first-direct.com has a solution in bug 532752 (which maybe could be used by some setopt call in pycurl?), while the dynamic routing firewall problem awaits more information in bug 532752 since June 2009. If there are bugs in GNUTLS or remote servers, please try to help their maintainers to debug them, rather than rebuilding every single gnutls-using package to use openssl and spread a licensing can of worms which gnutls helps to keep closed. Also, is rebuilding even a proper fix for 515200? It looks like www1.banking.first-direct.com might have a problem and I suspect maybe if/when openssl supports whatever feature is causing connection problems (TLS1.1?), it might fail too then. This might open discussions about how to provide the feature tecnically (different module names in python, conflicting packages, etc) and make sure legality is kept, but in the meantime we'd just like a legal opinion on what would or would not be ok. (also considering it's OK for a user to use GPL+OpenSSL software if he wants, it's just not OK for us to distribute it). To be clear: I do not offer a legal opinion. I am not a lawyer. Ask one if you want legal opinion. If you want the debian project to ask, I think you need to persuade some official (ftp-master or leader seem most likely) to request it. Hope that explains, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587215: [linux-image-2.6.32-5-686]
Hello Ben, OK maybe it technically transfers data. When I first reported this bug I said it did not, because the ACT led on the device is not blinking. At least not much. I also said that dmesg shows link eth2 is up, but when I try to configure it with DHCP it will try forever and will not obtain an IP. I also tried to 1assign static IP/gateway etc, but then I am also not able to make a connection. The lan cable does not seem to be the problem als it works ALL the time when I use the manufacturers driver, it also works with the on board LAN. I also tried a different patch cable, same issue. Have a good day, Barry On Wed, Jun 30, 2010 at 3:47 AM, Ben Hutchings b...@decadent.org.uk wrote: On Tue, 2010-06-29 at 07:35 +0200, ing. Barry B.F. de Graaff (debian) wrote: [...] On Sun, Jun 27, 2010 at 7:40 PM, Ben Hutchings b...@decadent.org.uk wrote: OK, and for comparison, can you repeat that while using the original driver? (Temporarily remove the driver you got from the manufacturer.) [...] [ 428.084108] eth2: register 'asix' at usb-:00:1d.7-7, ASIX AX88178 USB 2.0 Ethernet, 00:0e:c6:88:09:28 [ 428.084137] usbcore: registered new interface driver asix [ 493.600293] b44: eth0: powering down PHY [ 493.704834] eth2: link down [ 493.707183] ADDRCONF(NETDEV_UP): eth2: link is not ready [ 503.123908] ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready [ 503.126016] eth2: link up, 1000Mbps, full-duplex, lpa 0xCDE1 [ 513.272023] eth2: no IPv6 routers present [ 560.087747] eth2: link up, 1000Mbps, full-duplex, lpa 0xCDE1 [ 563.511322] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 570.622539] b44: eth0: powering down PHY [ 570.704834] eth2: link up, 1000Mbps, full-duplex, lpa 0xCDE1 [ 581.576024] eth2: no IPv6 routers present So, it reported link up... [...] *** Device statistics: Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 eth0: 502382 809 0 0 0 0 0 64 128514 786 0 0 0 0 0 0 eth2: 736 16 0 0 0 0 0 0 9860 43 0 0 0 0 0 0 [...] and apparently it was able to send and receive packets without errors. So what is your basis for saying it can't transfer data? How are you testing it? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587587: insserv: safe-upgrade fails several loop between service X and Y if started
[Leonidas Spyropoulos] When I tried to aptitude safe-upgrade today I got some strange errors coming from insserv package. Right. Good to see that the loop detection and prevention system work. :) More specific the nxserver and nxsensor are producing a banch of loop errors: I guess these are the ones that need to be fixed. They do not seem to belong to a pacage in Debian. Can you provide their LSB headers? insserv: Starting nxsensor depends on rmnologin and therefore on system facility `$all' which can not be true! insserv: Starting nxserver depends on rmnologin and therefore on system facility `$all' which can not be true! These two issues are real problems that should be fixed. nxsensor and nxserver should not depend on rmnologin, as it causes in impossible boot sequence. insserv: Max recursions depth 99 reached insserv: There is a loop between service rmnologin and mountnfs if started insserv: loop involving service mountnfs at depth 6 insserv: loop involving service nfs-common at depth 5 insserv: There is a loop between service nxsensor and checkroot if started insserv: loop involving service checkroot at depth 3 insserv: loop involving service keyboard-setup at depth 2 insserv: loop involving service module-init-tools at depth 4 insserv: loop involving service alsa-utils at depth 10 insserv: There is a loop between service rmnologin and mountoverflowtmp if started insserv: loop involving service mountoverflowtmp at depth 8 insserv: loop involving service mountall-bootclean at depth 7 insserv: There is a loop between service rmnologin and checkfs if started insserv: loop involving service checkfs at depth 5 insserv: loop involving service mtab at depth 4 insserv: There is a loop at service rmnologin if started insserv: There is a loop at service nxsensor if started insserv: loop involving service nxsensor at depth 1 insserv: There is a loop between service rmnologin and ifupdown-clean if started insserv: loop involving service ifupdown-clean at depth 4 insserv: There is a loop between service rmnologin and mountkernfs if started insserv: loop involving service mountkernfs at depth 1 insserv: There is a loop between service nxsensor and mountdevsubfs if started insserv: loop involving service mountdevsubfs at depth 1 insserv: loop involving service networking at depth 10 insserv: loop involving service mountall at depth 7 insserv: exiting now without changing boot order! update-rc.d: error: insserv rejected the script header update-rc.d from sysv-rc rightly rejected the upgrade to avoid messing up the boot sequence. I suspect bugs in the packages providing the nxsensor and nxserver scripts. I think that the upgrading packages are not the real problem, just something that is triggering that infinite loops, because I had that issue before and what I did was uninstall nxserver, nxnode and nxclient to safe-upgrade my system. Sound to me like it is better to fix the bugs in nxserver, nxnode and nxclient. Time to talk to their package maintainer? Given that you know it solve the problem to remove these packages, it seem the obvious place to fix it too. PS: This is my first bug report so please tell me if what other info I should provide. The output from /usr/share/insserv/make-testsuite is useful for reproducing your problem and knowing the content of the buggy init.d scripts. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585064: isc-dhcp upload to unstable imminent
[Andrew Pollock] If you'd like a patch or an NMU of your package to address this, please let me know. A patch for debian-edu-config moving the existing conffiles from the old to the new location and symlinking from the old to the new location would be most welcome. This way the package do not need to conflict or break the old package and will also work with the new package. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587594: [ksirk] Wrong agreement Each country contain in extended description
Package: ksirk Version: 4:4.4.4-1 Severity: minor The extended description contains: Each country contain one army represented by an infantryman. Each country is the third person, so contain should be at the third person too, which needs a final s. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587556: gitolite: [INTL:fr] French debconf templates translation update
Quoting Gerfried Fuchs (rho...@deb.at): Hi! * Christian Perrier bubu...@debian.org [2010-06-29 21:38:49 CEST]: Please find attached the french debconf templates update, proofread by the debian-l10n-french mailing list contributors. Thanks for taking care of warning translators before uploading a new version with string changes. It's highly appreciated. Thanks for ignoring me all together and trying to explicitly work against me wherever you can, it is truly appreciated. Also thank you very much for your fine and helpful snide joking comments all the time, it really makes my work feel appreciated. Nevertheless I did send you an explicit informational request to do a swift review the day I did upload the package. The upload was done and not delayed until you got around for the review process (which as I understand it would be longer than just the usual 10 day translator delay) because it was considered more important to get the update out because it fixed some important packaging problems and also an upgrade issue. But yes, this was all done just to piss you off, I confess, this is the sole purpose of my doings. I don't really understand what, in my bug report, can be taken as rude. I have two templates for sending translation updates: one is quite long and pedantic and basically says you should have called for a translation update but here's the french translation anyway and another one is the above one which is mostly meant for caseswhere I don't want to be fingerpointing the maintainer. Maybe should I have a third template for cases where the maintainer didn't formally call for a translation update but I don't want to appear as fingerpointing him|herwhich was indeed the case for this gitolite update. So, maybe you think there was irony because of our past miscommunication historybut, really, there wasn't. This bug report is meant for what it is: sending you the update of the French translation. I was not expecting it to hurt your feelings in any way. signature.asc Description: Digital signature
Bug#587595: hitchhiker: missing dependency on Bazaar
Package: hitchhiker
Version: 0.01~20091129+bzr41-1ubuntu1
Severity: normal
Hitchhiker uses Bazaar for its transport implementation, but it doesn't
declare the dependency on Bazaar. Something like this will fix it.
See also
https://bugs.edge.launchpad.net/ubuntu/+source/hitchhiker/+bug/60
=== modified file 'debian/changelog'
--- debian/changelog2009-11-29 18:35:02 +
+++ debian/changelog2010-06-30 06:33:22 +
@@ -1,3 +1,9 @@
+hitchhiker (0.01~20091129+bzr41-1ubuntu1) maverick; urgency=low
+
+ * hitchhiker depends on bzr (LP: #60).
+
+ -- Martin Pool m...@sourcefrog.net Wed, 30 Jun 2010 16:29:08 +1000
+
hitchhiker (0.01~20091129+bzr41-1) unstable; urgency=low
* Initial release (Closes: # 549104)
=== modified file 'debian/control'
--- debian/control 2009-11-29 18:35:02 +
+++ debian/control 2010-06-30 06:33:22 +
@@ -10,7 +10,7 @@
Package: hitchhiker
Architecture: all
-Depends: python (= 2.4), ${misc:Depends}
+Depends: python (= 2.4), bzr (= 2.0.0), ${misc:Depends}
Description: access locations using Bazaar transports
A client to access bzr transports, namely the Bazaar version control
repositories. This utility can be used to log into the remote host
-- System Information:
Debian Release: squeeze/sid
APT prefers maverick-updates
APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500,
'maverick-backports'), (500, 'maverick')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.35-6-generic (SMP w/6 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages hitchhiker depends on:
ii bzr 2.1.2-1easy to use distributed version co
ii python2.6.5-5ubuntu2 An interactive high-level object-o
hitchhiker recommends no packages.
hitchhiker suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587556: gitolite: [INTL:fr] French debconf templates translation update
Hi! * Christian PERRIER bubu...@debian.org [2010-06-30 08:41:35 CEST]: Quoting Gerfried Fuchs (rho...@deb.at): * Christian Perrier bubu...@debian.org [2010-06-29 21:38:49 CEST]: Please find attached the french debconf templates update, proofread by the debian-l10n-french mailing list contributors. Thanks for taking care of warning translators before uploading a new version with string changes. It's highly appreciated. ^ Thanks for ignoring me all together and trying to explicitly work against me wherever you can, it is truly appreciated. Also thank you very much for your fine and helpful snide joking comments all the time, it really makes my work feel appreciated. Nevertheless I did send you an explicit informational request to do a swift review the day I did upload the package. The upload was done and not delayed until you got around for the review process (which as I understand it would be longer than just the usual 10 day translator delay) because it was considered more important to get the update out because it fixed some important packaging problems and also an upgrade issue. But yes, this was all done just to piss you off, I confess, this is the sole purpose of my doings. I don't really understand what, in my bug report, can be taken as rude. The *more* than overdoing cynical undertone of the message in the light of the whole issue is what itches me here, heavily. You might consider it funny, I don't, at all. That's why I tried to point out the reasoning behind my approach to give you the chance to understand why I did the upload now and not send out a call for translations before - mostly also because I don't have a clue how to send out a swift review process request and in your inital mail you stated that you wanted to start such a process. Thanks for the fish, Rhonda -- Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder Mensch auch ein Privatleben haben sollte. -- http://www.karriere.at/artikel/884/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586830: [Debian-med-packaging] Bug#586830: marked as done (hardcodes Python 2.5)
[Charles Plessy, 2010-06-30] What makes you think that autodocktools works with python 2.6 if upstream hardcoded it for 2.5. Have you tested the package before uploading? I understand that you may be disapointed that we have not answered your bug report, but please consider that people may be busy, and that the absence of answer does not mean that we were not thinking about the question (can autodock run with python = 2.5?). I am still puzzled why a NMU with no consultation with the maintainer was chosen instead of simply removing the package from Testing. yeah, I did some code reviewing and didn't spot anything that doesn't work with 2.6. Could you point me to what is not working so that I can fix it since you're busy? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587596: selinux-policy-default: can't upgrade selinuc default policy
Package: selinux-policy-default Version: 2:0.2.20100524-1 Severity: normal selinux-policy-upgrade Failed with message: Updating default policy libsepol.context_from_record: type httpd_nagios_script_exec_t is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:httpd_nagios_script_exec_t:s0 to sid invalid context system_u:object_r:httpd_nagios_script_exec_t:s0 libsemanage.semanage_install_active: setfiles returned error code 1. semodule: Failed! -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.34-1-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages selinux-policy-default depends on: ii libpam-modules1.1.1-3Pluggable Authentication Modules f ii libselinux1 2.0.94-1 SELinux runtime shared libraries ii libsepol1 2.0.41-1 SELinux library for manipulating b ii policycoreutils 2.0.82-2 SELinux core policy utilities ii python2.6.5-5An interactive high-level object-o Versions of packages selinux-policy-default recommends: ii checkpolicy 2.0.21-1SELinux policy compiler ii setools 3.3.6.ds-7.2+b1 tools for Security Enhanced Linux Versions of packages selinux-policy-default suggests: ii logcheck 1.3.10 mails anomalies in the system logf pn syslog-summarynone (no description available) -- Configuration Files: /etc/selinux/default/modules/active/file_contexts.local [Errno 13] Permission denied: u'/etc/selinux/default/modules/active/file_contexts.local' /etc/selinux/default/modules/semanage.read.LOCK [Errno 13] Permission denied: u'/etc/selinux/default/modules/semanage.read.LOCK' -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587597: cron runs apticron twice a day
Package: apticron Version: 1.1.42 Severity: normal apticron provides two files for cron: - /etc/cron.daily/apticron - /etc/cron.d/apticron In /etc/cron.daily/apticron apticron is invoked without --cron option which apparently causes sending mail twice a day. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apticron depends on: ii apt 0.7.25.3 Advanced front-end for dpkg ii cron 3.0pl1-113 process scheduling daemon ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy ii heirloom-mailx [mailx]12.4-2 feature-rich BSD mail(1) ii ucf 3.0025 Update Configuration File: preserv Versions of packages apticron recommends: ii apt-listchanges 2.84 package change history notificatio ii iproute 20100519-2 networking and traffic control too apticron suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587598: override: please change section for all -gcj packages
Package: ftp.debian.org Severity: normal Owner: Torsten Werner twer...@debian.org Please change the section of all *-gcj packages to java. Some of them are still in the libs section but they better fit into java. Torsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587550: mdadm: --manage --remove faulty does not remove all faulty disks
On Tue, 29 Jun 2010 14:24:07 -0400
Jim Paris j...@jtan.com wrote:
My guess is that in Manage.c:Manage_subdevs, the loops like
for (; j array.raid_disks + array.nr_disks ; j++) {
are missing disks because the disk numbers are changing as they are
removed, but I didn't have the time to follow the code in detail.
Thanks for the report.
Good guess.
This is the patch that I have just checked in to mdadm.
Thanks,
NeilBrown
commit b3b4e8a7a229a915421329a5319f996b0842
Author: NeilBrown ne...@suse.de
Date: Wed Jun 30 17:20:38 2010 +1000
Avoid skipping devices where removing all faulty/detached devices.
When using 0.90 metadata, devices can be renumbered when
earlier devices are removed.
So when iterating all devices looking for 'failed' or 'detached'
devices, we need to re-check the same slot we checked last time
to see if maybe it has a different device now.
Reported-by: Jim Paris j...@jtan.com
Resolves-Debian-Bug: 587550
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/Manage.c b/Manage.c
index 6bc5d0a..edf41e9 100644
--- a/Manage.c
+++ b/Manage.c
@@ -376,6 +376,7 @@ int Manage_subdevs(char *devname, int fd,
return 1;
}
+ stb.st_rdev = 0;
for (dv = devlist, j=0 ; dv; dv = next, j = jnext) {
unsigned long long ldsize;
char dvname[20];
@@ -394,6 +395,7 @@ int Manage_subdevs(char *devname, int fd,
return 1;
}
for (; j array.raid_disks + array.nr_disks ; j++) {
+ int dev;
disc.number = j;
if (ioctl(fd, GET_DISK_INFO, disc))
continue;
@@ -401,9 +403,15 @@ int Manage_subdevs(char *devname, int fd,
continue;
if ((disc.state 1) == 0) /* faulty */
continue;
- stb.st_rdev = makedev(disc.major, disc.minor);
+ dev = makedev(disc.major, disc.minor);
+ if (stb.st_rdev == dev)
+ /* already did that one */
+ continue;
+ stb.st_rdev = dev;
next = dv;
- jnext = j+1;
+ /* same slot again next time - things might
+* have reshuffled */
+ jnext = j;
sprintf(dvname,%d:%d, disc.major, disc.minor);
dnprintable = dvname;
break;
@@ -419,6 +427,7 @@ int Manage_subdevs(char *devname, int fd,
}
for (; j array.raid_disks + array.nr_disks; j++) {
int sfd;
+ int dev;
disc.number = j;
if (ioctl(fd, GET_DISK_INFO, disc))
continue;
@@ -435,9 +444,15 @@ int Manage_subdevs(char *devname, int fd,
continue;
if (errno != ENXIO)
continue;
- stb.st_rdev = makedev(disc.major, disc.minor);
+ dev = makedev(disc.major, disc.minor);
+ if (stb.st_rdev == dev)
+ /* already did that one */
+ continue;
+ stb.st_rdev = dev;
next = dv;
- jnext = j+1;
+ /* same slot again next time - things might
+* have reshuffled */
+ jnext = j;
dnprintable = dvname;
break;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586839: mgltools-gle: depends on python ( 2.6)
After the recent transition of phython-2.6 to testing, this makes mgltools-gle also uninstallable in testing. -Ralf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587547: [INTL:fa] Persian(farsi) D-I iso-codes translation
package iso-codes tag 587198 pending tag 587547 pending thanks Am Mittwoch, den 30.06.2010, 01:38 +0800 schrieb behrad eslami: Please find attached the Persian (Farsi) update of translation of the iso-codes package. Hi, thanks for the update, it's committed to the repository. Regards, Tobias -- Tobias Quathamer | I don't care to belong to a club that accepts people Hamburg, Germany | like me as members. -- Groucho Marx signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#587599: acpi-support: syntax error in /usr/share/acpi-support/policy-funcs
Package: acpi-support Version: 0.137-2 Severity: important Tags: patch I noticed the following error message upon boot: , | Checking battery state.../usr/share/acpi-support/policy-funcs: 24: Syntax error: ) unexpected (expecting then) | done. ` Among other things, this breaks the power button if no desktop environment is running. Here is a patch for this: --8---cut here---start-8--- diff --git a/debian/patches/policy-funcs.diff b/debian/patches/policy-funcs.diff index 1bdedcb..cc7ad8a 100644 --- a/debian/patches/policy-funcs.diff +++ b/debian/patches/policy-funcs.diff @@ -25,7 +25,7 @@ PMS=$PMS guidance-power-manager.py dalston-power-applet if pidof -x $PMS /dev/null || - (pidof dcopserver /dev/null test -x /usr/bin/dcop /usr/bin/dcop kded kded loadedModules | grep -q klaptopdaemon) || -+ test $XUSER != pidof dcopserver /dev/null test -x /usr/bin/dcop /usr/bin/dcop --user $XUSER kded kded loadedModules | grep -q klaptopdaemon) || ++ test $XUSER != (pidof dcopserver /dev/null test -x /usr/bin/dcop /usr/bin/dcop --user $XUSER kded kded loadedModules | grep -q klaptopdaemon) || PowerDevilRunning ; then echo 0; else --8---cut here---end---8--- -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.34-kms Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages acpi-support depends on: ii acpi-fakekey 0.137-2tool to generate fake key events ii acpi-support-base 0.137-2scripts for handling base ACPI eve ii acpid 1:2.0.6-1 Advanced Configuration and Power I ii lsb-base 3.2-23.1 Linux Standard Base 3.2 init scrip ii pm-utils 1.3.0-2utilities and scripts for power ma ii x11-xserver-utils 7.5+1+b1 X server utilities Versions of packages acpi-support recommends: ii dbus 1.2.24-1 simple interprocess messaging syst pn radeontoolnone (no description available) ii vbetool 1.1-2 run real-mode video BIOS code to a pn xscreensaver | gnome-screensa none (no description available) Versions of packages acpi-support suggests: pn rfkillnone (no description available) pn xinputnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587537: [INTL:sv] Updated Swedish strings for gitolite debconf
Hmm, somehow I don't find the file - did you forgot to attach it? Can you please try again? ;) Indeed I did. New try now then. Also, please make sure that you used the latest template, there was changes in the recent upload to unstable. For your convenience find attached the current version with the fuzzy strings. It had the same POT date so I think it was the latest. I Just took care of the two fuzzy strings and corrected a spelling error in the old one. -- brother http://sis.bthstudent.se # Translation of gitolite debconf template to Swedish # Copyright (C) 2010 Martin Bagge brot...@bsnet.se # This file is distributed under the same license as the gitolite package. # # Martin Bagge brot...@bsnet.se, 2010 msgid msgstr Project-Id-Version: gitolite 1.3-2\n Report-Msgid-Bugs-To: gitol...@packages.debian.org\n POT-Creation-Date: 2010-06-21 20:33+0200\n PO-Revision-Date: 2010-06-30 09:17+0100\n Last-Translator: Martin Bagge / brother brot...@bsnet.se\n Language-Team: Swedish debian-l10n-swed...@lists.debian.org\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n X-Poedit-Language: Swedish\n X-Poedit-Country: Sweden\n #. Type: string #. Description #: ../templates:1001 msgid The name of the system user to create: msgstr Namn på systemanvändaren som ska skapas: #. Type: string #. Description #: ../templates:1001 msgid Please enter the name for the system user which should be used by gitolite. msgstr Ange namnet för systemanvändaren som ska användas av gitolite. #. Type: string #. Description #: ../templates:2001 msgid The directory to contain the repositories: msgstr Katalog som innehåller förråden: #. Type: string #. Description #: ../templates:2001 #| msgid #| Please enter the path for the directory in which you want to store the #| git repositories guarded by gitolite. msgid Please enter the path for the directory in which you want to store the git repositories guarded by gitolite. This will also become the home of the former entered username. msgstr Ange sökvägen till katalogen som ska användas för att lagra git-förråden som skyddas av gitolite. Detta kommer även att vara hemkatalog för användaren vars användarnamn tidigare angavs. #. Type: string #. Description #: ../templates:3001 msgid The key for the admin user: msgstr Nyckel för administrationsanvändaren: #. Type: string #. Description #: ../templates:3001 #| msgid #| Please specify the key of the user that will administer the access #| configuration of gitolite. You can either give the filename or paste the #| ssh public key. msgid Please specify the key of the user that will administer the access configuration of gitolite. You can either give the filename or paste the ssh public key. Leave empty if you do not want to set up gitolite in the directory specified earlier. msgstr Ange nyckeln för användaren som ska administrera åtkomst till gitolite. Antingen kan du ange filnamnet eller klistra in den publika SSH-nyckeln. Lämna fältet tomt om du inte vill installera gitolite i katalogen som angavs tidigare.
Bug#587588: build on kfreebsd
user debian-...@lists.debian.org severity 587588 important tag 587588 patch usertag 587588 kfreebsd thanks (control@ bcc'd.) Hi Tuco. Tuco tuco@gmail.com (30/06/2010): Package: pwlib Version: 1.10.10-3 Severity: serious This patch fixes build problems of pwlib on kfreebsd. Thanks for that. Some comments: - it'd be nice to tag the bug as having a patch. - it'd also be nice to usertag the bug when submitting. - it's not a serious bug, since pwlib never built on kfreebsd-*, that's only important. Mraw, KiBi. signature.asc Description: Digital signature
Bug#519781: manpages-dev: does not install pthread_* manpages (Re: LinuxThreads manual pages)
Aurelien Jarno wrote: On Tue, Jun 29, 2010 at 05:30:47AM -0500, Jonathan Nieder wrote: Hi Joey, Jonathan Nieder wrote: - The pages in man-pages are usable and maintained, and I think we should ship them. This requires coordination between the two packages. Actually, manpages-dev should be changed first (with Replaces: glibc-doc, this requires no action by the glibc maintainers). Any thoughts on this? Would you be more comfortable with a versioned Replaces: (which requires a little more coordination with glibc maintainers), or is there anything else I can do to help make this happen? In particular, if the problem is lack of time, I would be glad to work on finding a DD willing to sponsor staging this in experimental so we could try out both changes (manpages-dev, glibc-doc). There is no need to go through experimental. Once the change is done on manpages-dev, we can upload a fixed glibc-doc. A Replaces: is the way to go. I'll include pthread manpages in the next upload again. Regards, Joey -- Life is too short to run proprietary software. -- Bdale Garbee Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587600: revelation: Saving the file via SSH failed
Package: revelation Version: 0.4.11-6+b1 Severity: normal Tags: patch Saving the file via SSH failed with this error: Traceback (most recent call last): File /usr/bin/revelation, line 195, in lambda action.connect(activate, lambda w: self.file_save(self.datafile.get_file(), self.datafile.get_password())) File /usr/bin/revelation, line 1488, in file_save self.datafile.save(self.entrystore, file, password) File /usr/lib/python2.5/site-packages/revelation/io.py, line 126, in save file_write(file, self.__handler.export_data(entrystore, password)) File /usr/lib/python2.5/site-packages/revelation/io.py, line 243, in file_write os.rename(file, backup) OSError: [Errno 2] No such file or directory I attach the file io.py with my patch and the diff file. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages revelation depends on: ii gconf2 2.28.1-3GNOME configuration database syste ii gnome-icon-theme 2.30.3-1GNOME Desktop icon theme ii libc62.11.2-2Embedded GNU C Library: Shared lib ii libcrack22.8.16-2pro-active password checker librar ii python 2.6.5-5 An interactive high-level object-o ii python-central 0.6.14+nmu2 register and build utility for Pyt ii python-crypto2.1.0-2 cryptographic algorithms and proto ii python-gnome22.28.1-1Python bindings for the GNOME desk ii python-gtk2 2.17.0-2Python bindings for the GTK+ widge ii shared-mime-info 0.71-3 FreeDesktop.org shared MIME databa revelation recommends no packages. revelation suggests no packages. io.py Description: application/symlink 240a241,244 #if file_exists(file) == True: # backup = file + .bak # os.rename(file, backup) 243,244c247,250 os.rename(file, backup) --- f = gnomevfs.create(backup, gnomevfs.OPEN_WRITE) f.write(gnomevfs.read_entire_file(file)) f.close()
Bug#587601: RFP: series60-remote -- S60 mobile phone management application
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: series60-remote Version : 0.3.93 Upstream Author : Lukas Hetzenecker l...@gmx.at * URL : http://series60-remote.sf.net * License : GPL2 Programming Lang: Python Description : S60 mobile phone management application Series60-Remote is an application to manage your mobile phone. You can send and receive SMS messages directly on your computer. It also provides a complex contact and file management. In case somebody will need sponsoring upload, I'm definitely available. - -- Michal Čihař | http://cihar.com | http://blog.cihar.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwq+DkACgkQ3DVS6DbnVgTKFgCfRab7R83xGkjoj5RKs1SwPOt8 NigAoJWiUfnKsSMxhpXFKm0zGipFiDFo =AU6c -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585056: [Pkg-samba-maint] Bug#585056: isc-dhcp upload to unstable imminent
Quoting Andrew Pollock (apoll...@debian.org): Hello, The release team has permitted me to upload isc-dhcp to unstable, and I plan on uploading it this weekend. This is your advance notice. I think the best way to proceed is to add a Breaks: dhcp3-client ( 4.1.0-1) to your package, and if you have a dependency or recommendation on dhcp3-client, change it to isc-dhcp-client instead. If you'd like a patch or an NMU of your package to address this, please let me know. What I'm sure about is that I can't update samba in unstable until next week-end. Let-'s give Steve Langasek a chance to do it. Otherwise, an NMU would be OK. signature.asc Description: Digital signature
Bug#586984: closed by Russ Allbery r...@debian.org (Bug#586984: fixed in lintian 2.4.2)
Raphael Geissert wrote: ... preinst diverts the following files: /usr/lib/$file ... Since lintian doesn't know what $file actually means, it replaces it with a wildcard (represented by '*' in the output.) So, when it goes and looks for a file shipped by the package matching /usr/lib/* it does find some (any file in /usr/lib counts as a valid match [1].) There's no bug in lintian then. OK, thanks for explaining. The preinst is now too clever for lintian :-) Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587007: salome: Porting patches to Salome 5.1.4 for upstream inclusion
Hello Adam, ... The second issue is the Debian constraint to build Salome with a HDF5 library needing MPI. The corresponding patches (kernel-hdf5-needs-mpi.patch, kernel-mpi-includes.patch, kernel-mpi-libs.patch and so on) are not so welcomed by upstream. Really? Did they give an indication of why? Well, that's a relatively small patch for us to maintain. From what I understood, building hdf5 with MPI is considered as unsupported. But I think that we can submit those patches and see if their politics change for a next release. Hopefully an alternative way of using HDF5 may be provided as suggested by Sylvestre: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576004 Thanks. Unfortunately, the HDF5 group tends to take a long time to respond to such requests (often many months, even when a patch is available), so we shouldn't count on this to happen before our next upload. I have to confess that I had better hope on that point. ... In conclusion what could be the organization for welcoming the future Salome 5.1.4 release? Should it be progressively ported on a separate branch by using the up-to-date sources [2]? Or would you prefer a one-shot transition from 5.1.3? If upstream is not going to accept patches before 5.1.4, then I think the one-shot transition makes the most sense. But I appreciate your examination of the upstream git repository to determine in advance what changes we will need to make in order to port our patches to 5.1.4. Ok, it sounds fine to me. I am going to be unavailable until the end of August, then I can try the 5.1.4 transition at the beginning of September if needed. By the way, the 5.1.4 Salome version is now available at: http://www.salome-platform.org/downloads/salome-v5.1.4 All the best, André -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587602: sendmail-base: update_tls should check for tls in submit.mc too.
Package: sendmail-base
Version: 8.14.3-5+lenny1
Severity: wishlist
update_tls scans sendmail.mc for a line like
include(`/etc/mail/tls/starttls.m4')dnl
and if not found, a warning message is printed and /etc/mail/tls/starttls.m4
is overwritten.
We use only the submit portion of sendmail, with client certificate
authentication to a mail hub. Now we have to add the line to sendmail.mc,
even though this file is not used for anything alse.
If update_tls could additionally check submit.mc for then line, and set REFD=1
also in that case, we would not have to make any changes to sendmail.mc at all.
Thanks
Arne
-- Package-specific info:
Ouput of /usr/share/bug/sendmail-base/script:
ls -alR /etc/mail:
/etc/mail:
total 268
drwxr-sr-x 7 smmta smmsp 4096 2010-03-10 09:30 .
drwxr-xr-x 114 root root 12288 2010-06-30 02:56 ..
-rw--- 1 root smmsp 4261 2010-03-10 09:30 access
-rw-r- 1 smmta smmsp 12288 2010-03-10 09:30 access.db
-rw-r--r-- 1 root root281 2010-01-29 15:03 address.resolve
lrwxrwxrwx 1 root smmsp10 2010-03-10 09:27 aliases - ../aliases
-rw-r- 1 smmta smmsp 12288 2010-03-10 09:30 aliases.db
-rw-r--r-- 1 root root 3281 2010-03-10 09:30 databases
-rw-r- 1 smmta smmsp50 2010-03-10 09:27 default-auth-info
-rw-r--r-- 1 root root 5657 2010-01-29 15:24 helpfile
-rw-r--r-- 1 root smmsp29 2010-03-10 09:27 local-host-names
drwxr-sr-x 2 smmta smmsp 4096 2010-03-10 09:27 m4
-rwxr-xr-- 1 root smmsp 9940 2010-03-10 09:30 Makefile
drwxr-xr-x 2 root root 4096 2010-03-10 09:27 peers
drwxr-xr-x 2 smmta smmsp 4096 2010-03-10 09:27 sasl
-rw-r--r-- 1 root smmsp 64858 2010-03-10 09:30 sendmail.cf
-rw-r--r-- 1 root root 12234 2010-03-10 09:30 sendmail.conf
-rw-r--r-- 1 root smmsp 4204 2010-03-10 09:30 sendmail.mc
-rw-r--r-- 1 root root149 2010-01-29 15:03 service.switch
-rw-r--r-- 1 root root180 2010-01-29 15:03 service.switch-nodns
drwxr-sr-x 2 smmta smmsp 4096 2010-03-10 09:27 smrsh
-rw-r--r-- 1 root smmsp 59382 2010-03-10 09:30 submit.cf
-rw-r--r-- 1 root smmsp 2435 2010-03-10 09:30 submit.mc
drwxr-xr-x 2 smmta smmsp 4096 2010-03-10 09:30 tls
-rw-r--r-- 1 root smmsp 0 2010-03-10 09:27 trusted-users
/etc/mail/m4:
total 8
drwxr-sr-x 2 smmta smmsp 4096 2010-03-10 09:27 .
drwxr-sr-x 7 smmta smmsp 4096 2010-03-10 09:30 ..
-rw-r- 1 root smmsp0 2010-03-10 09:27 dialup.m4
-rw-r- 1 root smmsp0 2010-03-10 09:27 provider.m4
/etc/mail/peers:
total 12
drwxr-xr-x 2 root root 4096 2010-03-10 09:27 .
drwxr-sr-x 7 smmta smmsp 4096 2010-03-10 09:30 ..
-rw-r--r-- 1 root root 328 2010-01-29 15:03 provider
/etc/mail/sasl:
total 16
drwxr-xr-x 2 smmta smmsp 4096 2010-03-10 09:27 .
drwxr-sr-x 7 smmta smmsp 4096 2010-03-10 09:30 ..
-rwxr--r-- 1 root root 3680 2010-03-10 09:30 sasl.m4
-rw-r- 1 smmta smmsp 885 2010-03-10 09:27 Sendmail.conf.2
/etc/mail/smrsh:
total 8
drwxr-sr-x 2 smmta smmsp 4096 2010-03-10 09:27 .
drwxr-sr-x 7 smmta smmsp 4096 2010-03-10 09:30 ..
lrwxrwxrwx 1 root smmsp 26 2010-03-10 09:27 mail.local -
/usr/lib/sm.bin/mail.local
lrwxrwxrwx 1 root smmsp 17 2010-03-10 09:27 procmail - /usr/bin/procmail
/etc/mail/tls:
total 60
drwxr-xr-x 2 smmta smmsp 4096 2010-03-10 09:30 .
drwxr-sr-x 7 smmta smmsp 4096 2010-03-10 09:30 ..
-rw-r--r-- 1 root root 4130 2008-05-15 06:31 mail_sender_crt.pem
-rw-r- 1 root smmsp 1679 2008-05-14 10:53 mail_sender_key.pem
-rw-r--r-- 1 root root 7 2010-03-10 09:27 no_prompt
-rw--- 1 root root 1191 2010-03-10 09:27 sendmail-client.cfg
-rw-r--r-- 1 root smmsp 1241 2010-03-10 09:27 sendmail-client.crt
-rw--- 1 root root 1021 2010-03-10 09:27 sendmail-client.csr
-rw-r- 1 root smmsp 1675 2010-03-10 09:27 sendmail-common.key
-rw-r- 1 root smmsp 1582 2010-03-10 09:27 sendmail-common.prm
-rw--- 1 root root 1191 2010-03-10 09:27 sendmail-server.cfg
-rw-r--r-- 1 root smmsp 1241 2010-03-10 09:27 sendmail-server.crt
-rw--- 1 root root 1021 2010-03-10 09:27 sendmail-server.csr
-rwxr--r-- 1 root root 3252 2010-03-10 09:30 starttls.m4
sendmail.conf:
DAEMON_NETMODE=Static;
DAEMON_NETIF=eth0;
DAEMON_MODE=None;
DAEMON_PARMS=;
DAEMON_HOSTSTATS=No;
DAEMON_MAILSTATS=No;
QUEUE_MODE=${DAEMON_MODE};
QUEUE_INTERVAL=10m;
QUEUE_PARMS=;
MSP_MODE=Cron;
MSP_INTERVAL=20m;
MSP_PARMS=;
MSP_MAILSTATS=${DAEMON_MAILSTATS};
MISC_PARMS=;
CRON_MAILTO=root;
CRON_PARMS=;
LOG_CMDS=No;
HANDS_OFF=No;
AGE_DATA=;
DAEMON_RUNASUSER=No;
DAEMON_STATS=${DAEMON_MAILSTATS};
MSP_STATS=${MSP_MAILSTATS};
sendmail.mc:
divert(-1)dnl
divert(0)dnl
define(`_USE_ETC_MAIL_')dnl
include(`/usr/share/sendmail/cf/m4/cf.m4')dnl
VERSIONID(`$Id: sendmail.mc, v 8.13.8-3 2006-12-08 20:21:10 cowboy Exp $')
OSTYPE(`debian')dnl
DOMAIN(`debian-mta')dnl
undefine(`confHOST_STATUS_DIRECTORY')dnl#DAEMON_HOSTSTATS=
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`Family=inet, Name=MSP-v4, Port=submission, Addr=127.0.0.1')dnl
define(`confPRIVACY_FLAGS',dnl
Bug#539643: [caff] Try to import key from user keyring first
Hi, I am going to have a look at that wishlist bug. Regards -- Franck Joncourt signature.asc Description: Digital signature
Bug#586830: [Debian-med-packaging] Bug#586830: Bug#586830: marked as done (hardcodes Python 2.5)
On 06/30/2010 09:05 AM, Piotr Ożarowski wrote: [Charles Plessy, 2010-06-30] What makes you think that autodocktools works with python 2.6 if upstream hardcoded it for 2.5. Have you tested the package before uploading? I understand that you may be disapointed that we have not answered your bug report, but please consider that people may be busy, and that the absence of answer does not mean that we were not thinking about the question (can autodock run with python = 2.5?). I am still puzzled why a NMU with no consultation with the maintainer was chosen instead of simply removing the package from Testing. yeah, I did some code reviewing and didn't spot anything that doesn't work with 2.6. Could you point me to what is not working so that I can fix it since you're busy? You could do me a great favour if you go for the real thing, i.e. get the packages from upstream CVS of which they know it is compatible with 2.6. It is also my experience from the 2.5 transition that there won't be too many packages affected. But it is not on us to decide that, really, so I think. If you are actively using the autodocktools then I am happy for your contribution and expect you to deal with any problems. If not, then I am too busy to be offended. Many greetings Steffen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515200: Providing an openssl-linked pycurl
On Wed, Jun 30, 2010 at 06:59:01AM +0100, MJ Ray wrote: Hi, According to my understandment: - OpenSSL is released under a license which is GPL incompatible, unless an exception to the GPL is used in the software compiled with it. Debian cannot distribute GPL software released under the unmodified GPL and linked against OpenSSL. - pycurl is released under the LGPL (2.1 or later) or a MIT/X derivative license based on the one of curl itself. Neither of these licenses is incompatible with OpenSSL, and as for curl itself we should be able to provide a version of pycurl which uses openssl. Am I correct up to here? http://packages.debian.org/changelogs/pool/main/p/pycurl/current/copyright suggests so. Thanks. What GNUTLS version? Oh, it looks like that's the current version. The idea I think is to provide both, as curl itself does. As I understand it, if the GPL python software were derived from openssl in some way, then there would be a problem. Otherwise, not. If it worked with a GNUTLS version of pycurl unmodified/interchangably, I think it's unlikely there's a problem. Thanks for the further clue. But then the GNUTLS version must exist to be sure things work, so why not use the GNUTLS version? In the case of bug 515200, the report about www1.banking.first-direct.com has a solution in bug 532752 (which maybe could be used by some setopt call in pycurl?), while the dynamic routing firewall problem awaits more information in bug 532752 since June 2009. If there are bugs in GNUTLS or remote servers, please try to help their maintainers to debug them, rather than rebuilding every single gnutls-using package to use openssl and spread a licensing can of worms which gnutls helps to keep closed. Also, is rebuilding even a proper fix for 515200? It looks like www1.banking.first-direct.com might have a problem and I suspect maybe if/when openssl supports whatever feature is causing connection problems (TLS1.1?), it might fail too then. I'm not aware of any specific bug; I've just been asked if under debian we would have an option of running under pycurl with openssl on Debian by a colleague who is looking at that part of the code for our project and I guess his reasons are not having to make sure the code works with either GNUTLS and OpenSSL, and that we might need to support OpenSSL anyway. I agree with you that it's good to improve GNUTLS, but OpenSSL is still free software and still distributed by Debian, so it's also good to have choice. This might open discussions about how to provide the feature tecnically (different module names in python, conflicting packages, etc) and make sure legality is kept, but in the meantime we'd just like a legal opinion on what would or would not be ok. (also considering it's OK for a user to use GPL+OpenSSL software if he wants, it's just not OK for us to distribute it). To be clear: I do not offer a legal opinion. I am not a lawyer. Ask one if you want legal opinion. If you want the debian project to ask, I think you need to persuade some official (ftp-master or leader seem most likely) to request it. I didn't want a lawyer's opinion, just a look at the issue by -legal people to make sure we weren't missing anything evident. Unless we have specific guidelines that say we should, for this kind of issue, I think that the fact that we looked at it and things seem ok ought to be enough: we would't move very far if we had to ask a lawyer for permission on everything we do. :) Now I guess it's up to the maintainer to see if he's willing to do/accept/support the change, and for us to reach an agreement whether technically it makes sense. That said projects under the GPL without openssl exceptions which wanted to use the pycurl library with OpenSSL can still ask for advice or refrain to do so: this has nothing to do with the library itself anyway. :) Thanks, Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586839: [Debian-med-packaging] Bug#586839: mgltools-gle: depends on python ( 2.6)
On 06/30/2010 09:27 AM, Ralf Treinen wrote: After the recent transition of phython-2.6 to testing, this makes mgltools-gle also uninstallable in testing. Pjotr, can you please address this one and all the other mgltool-* packages that are not autobuilt, too? Many thanks Steffen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586839: [Debian-med-packaging] Bug#586839: mgltools-gle: depends on python ( 2.6)
[Steffen Möller, 2010-06-30] On 06/30/2010 09:27 AM, Ralf Treinen wrote: After the recent transition of phython-2.6 to testing, this makes mgltools-gle also uninstallable in testing. Pjotr, s/j/i/ can you please address this one and all the other mgltool-* packages that are not autobuilt, too? I will take a look, is this related to autodocktools? -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587553: RFP: bluej -- educational environment for java development
On 2010-06-29 21:08, RalfGesellensetter wrote: Package: wnpp Severity: wishlist * Package name: bluej Version : 3.0.0 Upstream Author : Michael Kölling and many others * URL : http://bluej.org/download/files/bluej-300.deb * License : GNU GPL 2.0 Description : Integrated Java Environment for introductory teaching BlueJ is an integrated Java environment specifically designed for introductory teaching. BlueJ was developed at a University specifically for the purpose of teaching object orientation with Java. BlueJ is free! (from their home page). Recently, version 3.0 was released, and license was switched to GPL! The author provides a debian package on his home page, but it has to be checked if this package follows official policy. I have been used BlueJ for years, in many German schools it is kind of compulsary. Hi I had a quick look at it and the GPL is good news, however ... icons/license.txt: Copyright (c) for all BlueJ icons: Michael Kolling. Reproduction of the logos is permitted for non-commercial purposes. Use of the logo for commercial purposes or on items commercially sold is explicitly prohibited without written license. - cannot go into Debian main. Discriminates commercial use and does (as far as I can tell) allow modifications. See the Debian Free Software Guidelines[1]. It depends on junit (not sure what version), svnkit (+ javahl), netbeans cvs client and possibly also some thing called trilead. Other than the junit, I am not sure of the status of those dependencies. For anyone interested in working on this: upstreams bug tracker at [2] and the source is available from [3]. I have been unable to locate a public VCS for this project. Also according to [4], BlueJ does not run with gij/gcj, so it will not be available under some architectures (e.g. the kfreebsd ones). ~Niels NB: I have not done a complete check of the source files in the source zip to see if there some files under a different license than GPL and the icon license (except for the third party libraries). So there may be other problems. [1] http://www.debian.org/social_contract#guidelines [2] http://bugs.bluej.org/trac/bluej/wiki [3] http://www.bluej.org/download/source-download.html [4] http://www.bluej.org/download/install.html see Unix: paragraph 1. signature.asc Description: OpenPGP digital signature
Bug#515200: pycurl and openssl
Hi Guido, thanks for follow this up! On Tue, Jun 29, 2010 at 15:34, Guido Trotter ultrot...@debian.org wrote: Hi Sandro, We stomped into #515200 the other day, while looking for ways to use pycurl to replace some functionality in our code. I'm willing to followup with Debian Legal, but looking at the license of pycurl (which is LGPL or MIT/X) there should definitely be no problem in compiling it with OpenSSL. Great! I saw the thread is having some replies, still I didn't read them carefully (but they seem encouraging). What is forbidden is linking pure GPL programs with OpenSSL, but this wouldn't happen here, as pycurl is not under the GPL. What would be less clear is the status of pure GPL software using pycurl+openssl (rather than pycurl+gnutls), and distributed by Debian. But various packages can continue to depend on the gnutls version to stay compatible, and also I'm not even sure using a python library would qualify as linking. yeah, that's also a point debian-legal would clarify, i think Anyway, would you agree that if debian-legal is not against, we can proceed providing an alternative version? The license seems to be completely allowing this. Yep, the blocker I saw was legal not technical (even if I'll have to find a way to compile one version with gnutls and another with openssl), so once d-legal will give a go we can processed (oh, patches are welcome :P ). Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587603: dbmail: new stable upstream release
Package: dbmail Severity: wishlist Please package the lastest stable upstream release (2.2.16) As fare as I understand it's a bugfix release and it would fix problems like this http://code.google.com/p/k9mail/issues/detail?id=1159 which would be very nice. ;) Thanks! -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686-bigmem (SMP w/4 CPU cores) Locale: lang=de...@euro, lc_ctype=de...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587604: O: cmus -- lightweight ncurses audio player
Package: wnpp Severity: normal The current maintainer of cmus, Carlos Eduardo Sotelo Pinto (krlos) krlos@gmail.com, is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see http://www.debian.org/devel/wnpp/index.html#howto-o for detailed instructions how to adopt a package properly. The package description is: C* Music Player is a modular and very configurable ncurses-based audio player. It has some interesting features like configurable colorscheme, mp3 and ogg streaming, it can be controlled with an UNIX socket, filters, album/artists sorting and a vi-like configuration interface. . It currently supports different input formats: - Ogg Vorbis - MP3 (with libmad) - FLAC - Wav - Modules (with libmodplug) - Musepack - AAC - Windows Media Audio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587606: python2.6-minimal: Package fails to install
Package: python2.6-minimal Version: 2.6.5+20100628-2 Severity: grave Justification: renders package unusable I tried to # apt-get install python-qt4 but python2.6-minimal fails to install: mto...@premium:~$ sudo dpkg --configure -a Setting up python2.6-minimal (2.6.5+20100628-2) ... Linking and byte-compiling packages for runtime python2.6... pycentral: pycentral rtinstall: installed runtime python2.6 not found pycentral rtinstall: installed runtime python2.6 not found dpkg: error processing python2.6-minimal (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of python2.6: python2.6 depends on python2.6-minimal (= 2.6.5+20100628-2); however: Package python2.6-minimal is not configured yet. dpkg: error processing python2.6 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of libpython2.6: libpython2.6 depends on python2.6 (= 2.6.5+20100628-2); however: Package python2.6 is not configured yet. dpkg: error processing libpython2.6 (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of python-qt4: python-qt4 depends on libpython2.6 (= 2.6); however: Package libpython2.6 is not configured yet. dpkg: error processing python-qt4 (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: python2.6-minimal python2.6 libpython2.6 python-qt4 mto...@premium:~$ pycentral showversions 2.4 2.5 pycentral showversions is deprecated, use `pyversions -vs' mto...@premium:~$ pyversions -s python2.4 python2.5 All installed python packages: mto...@premium:~$ dpkg -l python\* | grep -v ^un Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Description +++-===-===-== ii python 2.5.4-2 An interactive high-level object-oriented language (default version) ii python-4suite-xml 1.0.2-7 An open-source platform for XML and RDF processing ii python-all 2.5.4-2 Package depending on all supported Python runtime versions ii python-all-dev 2.5.4-2 Package depending on all supported Python development packages ii python-apt 0.7.13.2Python interface to libapt-pkg ii python-beautifulsoup3.1.0.1-2 error-tolerant HTML parser for Python ii python-brlapi 4.0-8 Python bindings for BrlAPI ii python-bugbuddy 2.26.0-1Python module for bug-buddy ii python-cairo1.8.6-1 Python bindings for the Cairo vector graphics library ii python-central 0.6.11 register and build utility for Python packages ii python-cheetah 2.0.1-2 text-based template engine and Python code generator ii python-crypto 2.0.1+dfsg1-4+b1 cryptographic algorithms and protocols for Python ii python-cups 1.9.31-1.1 Python bindings for CUPS ii python-cupsutils1.0.0-6 Python utility modules around the CUPS printing system ii python-cwiid0.6.00+svn201-2 library to interface with the wiimote ii python-dbus 0.83.0-1simple interprocess messaging system (Python interface) ii python-debian 0.1.14 Python modules to work with Debian-related data formats ii python-dev 2.5.4-2 Header files and a static library for Python (default) ii python-dev-i386-cross 2.5.4-2 Header files and a static library for Python (default) (for cross-compiling) ii python-egenix-mxdatetime3.1.3-2 date and time handling routines for Python ii python-egenix-mxtexttools 3.1.3-1 fast text processing tools for Python ii python-egenix-mxtools 3.1.3-1 collection of additional builtins for Python ii python-eggtrayicon 2.25.3-2Python module to display icons in the system tray ii python-elementtree 1.2.6-14 Light-weight toolkit for XML processing ii python-evince
Bug#587607: joystick and inputattach no longer exist on s390
Package: ltsp-client Version: 5.2.2-1 Hi, ltsp-client depends on inputattach | joystick, unfortunately neither are built on s390 any more. Would it be possible to add a !s390 qualifier to the dependencies? (I don't think ltsp-client on s390 would need inputattach!) Incidentally, I imagine it's really inputattach you're after with this dependency; it might be worth adding ( 20051019-7) to the joystick dependency since versions of joystick from 20051019-7 onwards no longer provide inputattach, and installing joystick without inputattach would satisfy the dependency without actually providing an inputattach binary. Regards, Stephen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587132: bustle: FTBFS: Could not find module `Graphics.UI.Gtk.Pango.Font':
Will Thompson wrote: On 28/06/10 11:50, Chris Lamb wrote: Fancy refreshing the package a little for GHC 6.12 and doing another release? :) Done: http://www.willthompson.co.uk/bustle/releases/bustle-0.2.2.tar.gz and http://www.willthompson.co.uk/bustle/releases/bustle-0.2.2.tar.gz.asc I think this tarball is missing the Bustle/ directory.. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org `- signature.asc Description: PGP signature
Bug#587590: [Pkg-nagios-devel] Bug#587590: nagios-plugins-basic: Please add the attached patch for faster checking of Postfix queues
Hi Russell, On Wednesday 30 June 2010 05:26:53 Russell Coker wrote: The mailq command reads the headers of each message, if there are many thousands of messages that can regularly take long enough to cause a timeout. The following patch (against version 1.4.12-5) adds a new option -M postfix-fast to use find instead of mailq, it usually runs about 1,000 times faster! The same bug appears to be present in 1.4.14-5, I will make and test a patch for that shortly and update this bug report accordingly. thanks for your bugreport. From my side, I wouldn't love to carry this kind of patch over long time, without getting it applied upstream. So we need to get it into there first. I asked Ton about integration and he requests two things as requirements, which sounds reasonable for me: * find/wc needs converted to pure perl (using File::Find which is part of core perl) * postfix paths should be discovered/configurable by ./configure So if the patch fits this, I would happily forward it to upstream and if it gets accepted into SCM, I will apply it to the package asap. Thanks and with kind regards, Jan. -- Never write mail to w...@spamfalle.info, you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part.
Bug#568606: brasero: Total size to burn reported to be -2147483648 MiB
tags 568606 + patch
thanks
Please find the trivial fix from upstream git attached.
- Fabian
From c58f5060eb38293eb5ce166de7c5f7546a77bb7b Mon Sep 17 00:00:00 2001
From: Philippe Rouquier bonfire-...@wanadoo.fr
Date: Fri, 21 May 2010 11:27:33 +
Subject: Do not use int value in a g_signal_emit when a long is expected
---
diff --git a/libbrasero-burn/brasero-burn.c b/libbrasero-burn/brasero-burn.c
index e9b3973..34861a8 100644
--- a/libbrasero-burn/brasero-burn.c
+++ b/libbrasero-burn/brasero-burn.c
@@ -1349,7 +1349,7 @@ start:
0,
1.0,
1.0,
- -1);
+ -1L);
}
return BRASERO_BURN_OK;
}
--
cgit v0.8.3.1
Bug#568606: Info received (Bug#568606: brasero: Total size to burn reported to be -2147483648 MiB)
I have just seen that this patch has also been applied to the gnome-2-30 branch for the brasero 2.30.2 release. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579960: ClamAV daemon still fails to start on 32 bit PowerPC
Hi Michael, i tried the patch you mentioned, and it seems to work fine here! Once Again thank you for your help! Best regards Tom Am 29.06.2010 19:18, schrieb Michael Tautschnig: reopen 579960 tags 579960 + upstream forwarded 579960 https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1921 found 579960 0.96.1+dfsg-1~volatile1 thanks Hi Thomas, Hi Michael and Philipp, first of all than you both, for your immediate action! I immediately updated to the new packages but clamd died with the same symtoms as described by Pete in the very first mail of this thread. Could there be any regression in this update? According to upstream's bugreport it seems that it hasn't been fixed properly in 0.96.1 (see https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1921). There seems to be a new attempt, however: In this upstream bugreport there's a patch attached (https://wwws.clamav.net/bugzilla/attachment.cgi?id=1333) which you may want to try out and see whether it helps. If it does, please report back so we can upload a patched version until there is a new upstream release that finally fixes this issue. Best, Michael -- Thomas Kempf fon + 49 7321 969845 fax + 49 7321 969890 tke...@hueper.de http://www.hueper.de Werbeagentur Hüper GmbH Im Brühl 1 89520 Heidenheim an der Brenz Registergericht Amtsgericht Heidenheim an der Brenz HRB 720441 Geschäftsführer Peter Hüper Bernd Weser -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549020: wodim: Wodim can't wtite CD's on ATAPI: HL-DT-ST DVDRAM GSA-T50N
Hi all, My computer has a x64 processor and use 2.6.32-5-amd64 kernel version. And I am unable to burn a CD or DVD with Wodim. I have the same problem that is signaled on the bugs.debian.org site: bug #549020. In the last message, it says that the problem is solved but not for me. Here are the results of my commands : uname -r 2.6.32-5-amd64 sudo hdparm -I /dev/scd0 /dev/scd0: ATAPI CD-ROM, with removable media Model Number: HL-DT-ST DVDRAM GH41N Serial Number: K5B9AN25125 Firmware Revision: MN01 Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6 Standards: Likely used CD-ROM ATAPI-1 Configuration: DRQ response: 50us. Packet size: 12 bytes cache/buffer size = unknown Capabilities: LBA, IORDY(can be disabled) DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns sudo hdparm -d1 /dev/scd0 /dev/scd0: setting using_dma to 1 (on) HDIO_SET_DMA failed: Inappropriate ioctl for device HDIO_GET_DMA failed: Inappropriate ioctl for device Thanks for your help. best regards DeathSceythe
Bug#587599: [Pkg-acpi-devel] Bug#587599: acpi-support: syntax error in /usr/share/acpi-support/policy-funcs
On Wed, Jun 30, 2010 at 09:39:38AM +0200, Sven Joachim wrote: I noticed the following error message upon boot: ... I wonder how I managed to lose that brace. Sigh... ++ test $XUSER != (pidof dcopserver /dev/null test -x /usr/bin/dcop /usr/bin/dcop --user $XUSER kded kded loadedModules | grep -q klaptopdaemon) || Should be in front of the test command though. Fixed in git. michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584203: acpi-fakekey: fails to start at boot
On Tue, Jun 29, 2010 at 02:40:29PM -0400, Michel wrote: Sorry should have being clearer, like this: 'if ! modprobe -q uinput; then sleep 5' I changed it to: 'if ! modprobe -q uinput; sleep 5; then' What I meant was: if ! modprobe -q uinput; then ... fi sleep 5 With the above it does start at boot now: ... Doesn't mean a lot since you changed the if command. Please put the sleep below the fi. Input Layer: Type: 4 Code: 4 Value: 28 Input Layer: Type: 1 Code: 28 Value: 0 Input Layer: Sync Which key did you press here? Could you please also try one of the volume keys or the mute key with acpi_listen running? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585067: keyboard-configuration: No alt+gr keys working after some time
Dear Sir, Regarding teh bug, since the issue remained, I recently bought a new keyboard because of the non working altgr. So I choosed a PS2, could manage to find one, logitech, for 50 euros. And unfortunatley, the keyboard is not working either... so I am so sorry about it. So the other one didnt work either, this altgr. This means that I have 2 keyboards that arent working for this altgr. I am considering teh fact that it is not the keyboard now itself. Could it be X11 itself ? I mean I am using JWM as windows manager on this computer, and visibly hte altgr works when I am under TTY1,2,... when I press alt ctrl F1 best regards Yellow On Thu, Jun 17, 2010 at 8:58 PM, yellow protoss yellowprot...@gmail.comwrote: I attached the output file. thank you Best regards On Tue, Jun 15, 2010 at 11:33 PM, Julien Cristau jcris...@debian.orgwrote: On Sat, Jun 12, 2010 at 21:53:30 +0200, yellow protoss wrote: cat /etc/default/keyboard # If you change any of the following variables and HAL and X are # configured to use this file, then the changes will become visible to # X only if HAL is restarted. In Debian you need to run # /etc/init.d/hal restart # The following variables describe your keyboard and can have the same # values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options # in /etc/X11/xorg.conf. XKBMODEL=pc105 XKBLAYOUT=de XKBVARIANT=nodeadkeys XKBOPTIONS=lv3:ralt_switch What's the output of 'xkbcomp :0 -'? Cheers, Julien -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJMF/GhAAoJEDEBgAUJBeQMskYP/iWnyZ9MATyfAqTBsKnokJL1 RTvBQEeKmQnVkSDQTzfx37/d5NA78KcaTnUNoqxTB6Fn+43WpDtIWJslNb8Z0TnC aZTuFhKtgCXlYbcvMbrB5kDXYfSYQ/blLxX69jRcGO49jo0dLq6oMIg3fCaA50Qi BywcsEnR1wmtzSBCsjsWd4RmfGVVVKX9Rg9woDAnhQJG7rNekcKL3TDst01bu/Ey FF5y0cCUs0oAHpYlc7YlyGFb55UOeiIFaZcjjnckVs2bMH2MMJ0tVoKjkMS9E2FR P6l2jEQEh5QXiRtTX8MXZQQn8G8O4ekS9lvmcA+Nr8SNyOBJ0dqYMsjI2LopxEK+ O0BW9IH6G0X18y4MtougX8Kw/vD6x/4vFQ3gL7EdzUugz9igpLHhcCkzZVZPBVk6 Q/bGytsmHVuKvoiDgwEEGCcRVHEEuZErvJRsQZeMedtMUf9vLLSo3V5vI36lM3i8 glVW9DIsGJPDBpIeJaeyzFeP0by2G0Hhjd5wsiTNJ+Q94Nd4C2mgMdFMRh/BEVIk ylRBfn64ev60QvGiRvOBZRPnup/tpvPi5C14hhgb1PHLxKpVTUQcPXgvv4O6GmTB yEcvgE+CmBeLxNjHxCKx0zwGyeeb9/Tu2xwMBUMn/1ygT9hougGH2tyZnwQW1XNU vsnuYORQWxwqv3IO6esP =CVvd -END PGP SIGNATURE-
Bug#587608: initrampf doesn't create initrd
Package: initramfs-tool Version: 0.97 When I try to add an official debian new kernel or install a kernel compiled by myself, I receive this error: == I seguenti pacchetti parzialmente installati saranno configurati: initramfs-tools linux-image-2.6.32-5-686 Nessun pacchetto verrà installato, aggiornato o rimosso. 0 pacchetti aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati. È necessario prelevare 0B di archivi. Dopo l'estrazione, verranno occupati 0B. Configurazione di initramfs-tools (0.97)... update-initramfs: deferring update (trigger activated) Configurazione di linux-image-2.6.32-5-686 (2.6.32-15)... Running depmod. Running update-initramfs. update-initramfs: Generating /boot/initrd.img-2.6.32-5-686 update-initramfs: failed for /boot/initrd.img-2.6.32-5-686 update-initramfs failed to create initrd image. Failed to create initrd image. dpkg: errore nell'elaborare linux-image-2.6.32-5-686 (--configure): il sottoprocesso vecchio script di post-installation ha restituito lo stato di errore 1 Elaborazione dei trigger per initramfs-tools... update-initramfs: Generating /boot/initrd.img-2.6.30-2-686 update-initramfs: failed for /boot/initrd.img-2.6.30-2-686 dpkg: errore nell'elaborare initramfs-tools (--configure): il sottoprocesso vecchio script di post-installation ha restituito lo stato di errore 1 Si sono verificati degli errori nell'elaborazione: linux-image-2.6.32-5-686 initramfs-tools E: Sub-process /usr/bin/dpkg returned an error code (1) Errore durante l'installazione di un pacchetto. Tentativo di ripristino: Configurazione di initramfs-tools (0.97)... update-initramfs: deferring update (trigger activated) Configurazione di linux-image-2.6.32-5-686 (2.6.32-15)... Running depmod. Running update-initramfs. update-initramfs: Generating /boot/initrd.img-2.6.32-5-686 update-initramfs: failed for /boot/initrd.img-2.6.32-5-686 update-initramfs failed to create initrd image. Failed to create initrd image. dpkg: errore nell'elaborare linux-image-2.6.32-5-686 (--configure): il sottoprocesso vecchio script di post-installation ha restituito lo stato di errore 1 Elaborazione dei trigger per initramfs-tools... update-initramfs: Generating /boot/initrd.img-2.6.30-2-686 update-initramfs: failed for /boot/initrd.img-2.6.30-2-686 dpkg: errore nell'elaborare initramfs-tools (--configure): il sottoprocesso vecchio script di post-installation ha restituito lo stato di errore 1 Si sono verificati degli errori nell'elaborazione: linux-image-2.6.32-5-686 initramfs-tools Lettura elenco dei pacchetti... Fatto Generazione albero delle dipendenze Lettura informazioni sullo stato... Fatto Lettura delle informazioni sullo stato esteso... Fatto Inizializzazione dello stato dei pacchetti... Fatto Lettura delle descrizioni dei task... Fatto == and the new kernel is installed but not configured: in fact no initrd is created. With my own kernel, which doesn't need an initrd, I have to comment the line: update-initramfs -c -t -k ... in /etx/kernel/postinstall.d/initramfs-tools Thanx MS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572284: cmus: orphaned now
Package: cmus Version: 2.3.1-1 Severity: normal Hi, Orphaned now: http://bugs.debian.org/587604 regards, -- Ricardo Mones http://people.debian.org/~mones «Try to have as good a life as you can under the circumstances.» -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587587: insserv: safe-upgrade fails several loop between service X and Y if started
[Leonidas Spyropoulos] Well since nxserver (for which I am interesting it) is maintained from a company named nomachine it's kinda hard to press them release a new version, or correct this one. Well, I assume they are interested in getting their packages to work also with newer Debian releases, and thus are interested in fixing this even if they are not pressed. Did you try to report the issue to them? Maybe my only way to fix this is provide the LSB headers myself, which I have no idea how :P Here are two draft headers for nxserver and nxsensor. I do not know what they need to start before or after, so I added some default values based on a hunch. More information on the header format is available from URL: http://wiki.debian.org/LSBInitScripts/ . Try to add these to the init.d scripts in question and see if it help. ### BEGIN INIT INFO # Provides: nxserver # Required-Start:$remote_fs # Required-Stop: $remote_fs # Should-Start: $syslog # Should-Stop: $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start or stop nxserver ### END INIT INFO ### BEGIN INIT INFO # Provides: nxsensor # Required-Start:$remote_fs # Required-Stop: $remote_fs # Should-Start: $syslog # Should-Stop: $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start or stop nxserver ### END INIT INFO Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586554: update-initramfs fails to generate initrd.img-2.6.32-5-686 in Debian testing when upgrading from 0.96 to 0.97
Package: initramfs-tools Version: 0.97 Severity: normal Hi. Same problem occured here during upgrade from 0.96 to 0.97. Now, I am not even sure the machine will boot properly next time as apparently rebuilding the initramfs failed. r...@halucigenia:~# sh -x /var/lib/dpkg/info/initramfs-tools.postinst + set -e + [ ! -e /etc/initramfs-tools/modules ] + [ x != xtriggered ] + dpkg --compare-versions ge 1.14.5ubuntu10~~ + DPKG_MAINTSCRIPT_PACKAGE= update-initramfs -u update-initramfs: Generating /boot/initrd.img-2.6.32-5-686 update-initramfs: failed for /boot/initrd.img-2.6.32-5-686 Eventually I found the notice in a previous post of this thread saying iscan was the culprit. I purged iscan, but the problem remained. I purged iscan-data, too. Now, finally, it was possible to upgrade initramfs- tools successfully. I have emailed Epson support to inform them of the interference of their drivers with the Debian system. Regards Andreas -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 8.0M Jun 25 18:23 /boot/initrd.img-2.6.32-5-686 -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=69fd34e6-38c8-4a8b-86b8-581daf85ec5d ro quiet -- resume RESUME=UUID=e9012356-b8c2-473e-9547-fa87854b56b2 -- /proc/filesystems ext3 fuseblk -- lsmod Module Size Used by vboxnetadp 5118 0 vboxnetflt 12579 0 vboxdrv 126509 2 vboxnetadp,vboxnetflt acpi_cpufreq4943 0 cpufreq_userspace 1480 0 cpufreq_stats 1940 0 cpufreq_conservative 4018 0 cpufreq_powersave602 0 ppdev 4058 0 lp 5570 0 parport22554 2 ppdev,lp sco 5857 2 bridge 32987 0 stp 996 1 bridge bnep7444 2 rfcomm 25167 0 l2cap 21705 6 bnep,rfcomm crc16 1027 1 l2cap bluetooth 36327 6 sco,bnep,rfcomm,l2cap binfmt_misc 4907 1 uinput 4796 1 fuse 43758 1 loop9757 0 snd_hda_codec_intelhdmi 9027 1 snd_hda_codec_via 19285 1 snd_hda_intel 16703 4 snd_hda_codec 46002 3 snd_hda_codec_intelhdmi,snd_hda_codec_via,snd_hda_intel snd_hwdep 4054 1 snd_hda_codec snd_pcm_oss28671 0 snd_mixer_oss 10461 2 snd_pcm_oss snd_pcm47214 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss snd_seq_midi3576 0 snd_rawmidi12505 1 snd_seq_midi arc4 974 2 snd_seq_midi_event 3684 1 snd_seq_midi ecb 1405 2 snd_seq35463 3 snd_seq_midi,snd_seq_midi_event ath9k 238333 0 mac80211 123258 1 ath9k ath 6014 1 ath9k snd_timer 12258 2 snd_pcm,snd_seq snd_seq_device 3673 3 snd_seq_midi,snd_rawmidi,snd_seq uvcvideo 45226 0 cfg80211 87601 3 ath9k,mac80211,ath i915 219952 2 drm_kms_helper 18305 1 i915 snd34363 18 snd_hda_codec_intelhdmi,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device soundcore 3450 2 snd rfkill 10264 3 bluetooth,cfg80211 videodev 25545 1 uvcvideo drm 112020 3 i915,drm_kms_helper v4l1_compat10250 2 uvcvideo,videodev snd_page_alloc 5045 2 snd_hda_intel,snd_pcm i2c_algo_bit3497 1 i915 pcspkr 1207 0 asus_laptop11090 0 serio_raw 2916 0 led_class 1757 2 ath9k,asus_laptop i2c_core 12696 5 i915,drm_kms_helper,videodev,drm,i2c_algo_bit tpm_tis 5496 0 video 14605 1 i915 psmouse44653 0 ac 1640 0 battery 3782 0 processor 26599 3 acpi_cpufreq button 3598 1 i915 tpm 8137 1 tpm_tis tpm_bios3569 1 tpm output 1204 1 video evdev 5609 24 ext3 94204 2 jbd32169 1 ext3 mbcache 3762 1 ext3 sg 15968 0 sr_mod 10770 0 cdrom 26487 1 sr_mod sd_mod 25869 4 crc_t10dif 1012 1 sd_mod usbhid 27980 0 hid50629 1 usbhid uhci_hcd 16057 0 ahci 27246 3 thermal 9206 0 libata115665 1 ahci ehci_hcd 27763 0 scsi_mod 101401 4 sg,sr_mod,sd_mod,libata thermal_sys 9378 3 video,processor,thermal atl1e 23144 0 usbcore
Bug#587609: new version breaks virtualbox-ose compilation
Package: iasl Version: 20100528-2 Severity: serious Tags: sid Since upgrading iasl virtualbox-ose doesn't compile anymore: ... kBuild: iasl DevicesR3 - /home/michael/technik/sources/archive/virtualbox-ose/virtualbox-ose/src/VBox/Devices/PC/vbox.dsl /home/michael/technik/sources/archive/virtualbox-ose/virtualbox-ose/src/VBox/Devices/PC/vbox.dsl 998: 0xdfdf, // Range Length (calculated Error4118 - Length is not equal to fixed Min/Max window ^ ASL Input: /home/michael/technik/sources/archive/virtualbox-ose/virtualbox-ose/src/VBox/Devices/PC/vbox.dsl - 1305 lines, 46189 bytes, 288 keywords Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 404 Optimizations ... Please note that I do not know if this is a iasl problem or a virtualbox-ose one, although all older versions up to 20090521-1 worked without a problem. I set this report to serious just in case it's an iasl problem to prevent migration, so we have a working version left in squeeze. Michael -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages iasl depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib iasl recommends no packages. iasl suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585067: keyboard-configuration: No alt+gr keys working after some time
On Thu, Jun 17, 2010 at 20:58:49 +0200, yellow protoss wrote:
I attached the output file.
thank you
Best regards
On Tue, Jun 15, 2010 at 11:33 PM, Julien Cristau jcris...@debian.orgwrote:
On Sat, Jun 12, 2010 at 21:53:30 +0200, yellow protoss wrote:
cat /etc/default/keyboard
# If you change any of the following variables and HAL and X are
# configured to use this file, then the changes will become visible to
# X only if HAL is restarted. In Debian you need to run
# /etc/init.d/hal restart
# The following variables describe your keyboard and can have the same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.
XKBMODEL=pc105
XKBLAYOUT=de
XKBVARIANT=nodeadkeys
XKBOPTIONS=lv3:ralt_switch
What's the output of 'xkbcomp :0 -'?
[...]
xkb_symbols pc+us+inet(evdev)+level3(ralt_switch) {
This reports a us layout, not de with nodeadkeys... Is your session /
desktop resetting the layout maybe?
Cheers,
Julien
signature.asc
Description: Digital signature
Bug#559301: How can I fsck a filesytem after the journal has been destroyed?
Actualy this is even worse than I thought. If an external journal gets destroyed there appears to be no way to fsck the filesystem. I have an ext3 filesystem on /dev/group-a/ums which has a journal on /dev/flash/ums-journal. Some terrible accident causes the destruction of the journal. Now how do I fsck the filesystem? lvremove /dev/flash/ums-journal Do you really want to remove active logical volume ums-journal? [y/n]: y Logical volume ums-journal successfully removed r...@acadia:~/ums-benchmark# fsck /dev/group-a/ums fsck from util-linux-ng 2.16.2 e2fsck 1.41.12 (17-May-2010) Can't find external journal r...@acadia:~/ums-benchmark# tune2fs -f -O ^has_journal /dev/group-a/ums tune2fs 1.41.12 (17-May-2010) r...@acadia:~/ums-benchmark# fsck.ext3 /dev/group-a/ums e2fsck 1.41.12 (17-May-2010) Can't find external journal What with this and bug 587531 external journals look pretty dodgy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587608: initrampf doesn't create initrd
tags 587608 moreinfo stop On Wed, 30 Jun 2010, Mauro Sacchetto wrote: When I try to add an official debian new kernel or install a kernel compiled by myself, I receive this error: == I seguenti pacchetti parzialmente installati saranno configurati: initramfs-tools linux-image-2.6.32-5-686 Nessun pacchetto verrà installato, aggiornato o rimosso. 0 pacchetti aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati. È necessario prelevare 0B di archivi. Dopo l'estrazione, verranno occupati 0B. Configurazione di initramfs-tools (0.97)... update-initramfs: deferring update (trigger activated) Configurazione di linux-image-2.6.32-5-686 (2.6.32-15)... Running depmod. Running update-initramfs. update-initramfs: Generating /boot/initrd.img-2.6.32-5-686 update-initramfs: failed for /boot/initrd.img-2.6.32-5-686 update-initramfs failed to create initrd image. Failed to create initrd image. dpkg: errore nell'elaborare linux-image-2.6.32-5-686 (--configure): il sottoprocesso vecchio script di post-installation ha restituito lo stato di errore 1 Elaborazione dei trigger per initramfs-tools... update-initramfs: Generating /boot/initrd.img-2.6.30-2-686 update-initramfs: failed for /boot/initrd.img-2.6.30-2-686 dpkg: errore nell'elaborare initramfs-tools (--configure): il sottoprocesso vecchio script di post-installation ha restituito lo stato di errore 1 Si sono verificati degli errori nell'elaborazione: linux-image-2.6.32-5-686 initramfs-tools E: Sub-process /usr/bin/dpkg returned an error code (1) Errore durante l'installazione di un pacchetto. Tentativo di ripristino: Configurazione di initramfs-tools (0.97)... update-initramfs: deferring update (trigger activated) Configurazione di linux-image-2.6.32-5-686 (2.6.32-15)... Running depmod. Running update-initramfs. update-initramfs: Generating /boot/initrd.img-2.6.32-5-686 update-initramfs: failed for /boot/initrd.img-2.6.32-5-686 update-initramfs failed to create initrd image. Failed to create initrd image. dpkg: errore nell'elaborare linux-image-2.6.32-5-686 (--configure): il sottoprocesso vecchio script di post-installation ha restituito lo stato di errore 1 Elaborazione dei trigger per initramfs-tools... update-initramfs: Generating /boot/initrd.img-2.6.30-2-686 update-initramfs: failed for /boot/initrd.img-2.6.30-2-686 dpkg: errore nell'elaborare initramfs-tools (--configure): il sottoprocesso vecchio script di post-installation ha restituito lo stato di errore 1 Si sono verificati degli errori nell'elaborazione: linux-image-2.6.32-5-686 initramfs-tools Lettura elenco dei pacchetti... Fatto Generazione albero delle dipendenze Lettura informazioni sullo stato... Fatto Lettura delle informazioni sullo stato esteso... Fatto Inizializzazione dello stato dei pacchetti... Fatto Lettura delle descrizioni dei task... Fatto == and the new kernel is installed but not configured: in fact no initrd is created. With my own kernel, which doesn't need an initrd, I have to comment the line: update-initramfs -c -t -k ... in /etx/kernel/postinstall.d/initramfs-tools your report is useless as it is not reported via reportbug and thus misses important information. please next time use reportbug as it collects that information. you may want to double check if you have iscan installed, please provide the output of dpkg -l iscan* -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586554: update-initramfs fails to generate initrd.img-2.6.32-5-686 in Debian testing when upgrading from 0.96 to 0.97
* Andreas Neudecker zap...@gmx.net [Wed Jun 30, 2010 at 12:05:37PM +0200]: Same problem occured here during upgrade from 0.96 to 0.97. Now, I am not even sure the machine will boot properly next time as apparently rebuilding the initramfs failed. [...] Eventually I found the notice in a previous post of this thread saying iscan was the culprit. I purged iscan, but the problem remained. I purged iscan-data, too. Now, finally, it was possible to upgrade initramfs- tools successfully. We are working on new initramfs-tools version which should display the source of the problem then, I'll be investigating on the iscan issue in more detail as well and report back. regards, -mika- signature.asc Description: Digital signature
Bug#587531: e2fsprogs: e2fsck/tune2fs work badly with lvm, snapshot of fs with external journal
Maybe fsck should refuse to read or modify the journal if it is in use? Also we need a way to be able to fsck a filesystem if the journal is no longer available, or alternativly a way to remove a journal from a filesystem if the journal is not available. (bug #559301 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559301 - tune2fs -f -O ^has_journal does nothing if the journal device can't be found). Maybe the easiest/safest would be: 1. fsck refuses to work if the journal device is open 2. tune2fs -f -O ^has_journal modifies the filesystem but *not* the journal device 3. tune2fs -O ^has_journal refuses to work if the journal is not empty or the filesystem is active or the journal is open by someone. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587588: build on kfreebsd
On 6/30/10, Cyril Brulebois k...@debian.org wrote: Thanks for that. Some comments: - it'd be nice to tag the bug as having a patch. - it'd also be nice to usertag the bug when submitting. - it's not a serious bug, since pwlib never built on kfreebsd-*, that's only important. Ok. Thanks to both of you for the advice, I will follow these guidelines. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576072: Re[2]: [Pkg-xfce-devel] Bug#576072: it is now possible to select textlabel size
On mar., 2010-06-29 at 21:17 +0400, Ibragimov Rinat wrote:
GtkWidget *about;
-const gchar* authors[2] = {
+const gchar* authors[] = {
Alexander Iliev sasoil...@mamul.org,
Gauvain Pocentek gauvainpocen...@gmail.com,
NULL
Does this mean you intend to take over upstream maintainership?
No, I had not added my name to the list, but removed '2' from array size because
there are three elements (including NULL), not two. I'd noticed compiler
warning
about this line and fixed it but forgot to remove this from the patch. My fault.
I can upload patch without this fix if it is important.
---
Rinat
select-font-size-v2.diff
Description: Binary data
Bug#587587: insserv: safe-upgrade fails several loop between service X and Y if started
On Wed, Jun 30, 2010 at 11:08 AM, Petter Reinholdtsen p...@hungry.comwrote: [Leonidas Spyropoulos] Well since nxserver (for which I am interesting it) is maintained from a company named nomachine it's kinda hard to press them release a new version, or correct this one. Well, I assume they are interested in getting their packages to work also with newer Debian releases, and thus are interested in fixing this even if they are not pressed. Did you try to report the issue to them? Only paid customers can report issues on their site :( And after some search I found this: http://www.nomachine.com/fr/view.php?id=FR11G02291 It's a feature Request for version 4.0 (currently 3.4) so I guess I can't do much. Maybe my only way to fix this is provide the LSB headers myself, which I have no idea how :P Here are two draft headers for nxserver and nxsensor. I do not know what they need to start before or after, so I added some default values based on a hunch. More information on the header format is available from URL: http://wiki.debian.org/LSBInitScripts/ . Try to add these to the init.d scripts in question and see if it help. ### BEGIN INIT INFO # Provides: nxserver # Required-Start:$remote_fs # Required-Stop: $remote_fs # Should-Start: $syslog # Should-Stop: $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start or stop nxserver ### END INIT INFO ### BEGIN INIT INFO # Provides: nxsensor # Required-Start:$remote_fs # Required-Stop: $remote_fs # Should-Start: $syslog # Should-Stop: $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start or stop nxserver ### END INIT INFO I wrote the above LSB Headers into the init scripts but cannot test them since I upgraded and I have only encounter these on upgrades. Is there another way to check the init scripts if their LSB headers are correct? Will the make-testsuite show the scripts now correctly? Happy hacking, -- Petter Reinholdtsen -- Caution: breathing may be hazardous to your health.
Bug#587610: dnssec-tools - new upstream version
Package: dnssec-tools Version: 1.5-1 Severity: wishlist The latest upstream version of dnssec-tools is 1.6. Bastian -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587611: dnssec-tools - FHS violation: Errors creating path: /usr/var
Package: dnssec-tools Version: 1.5-1 Severity: serious There exists no /usr/var, and a random tool is the last one that is allowed to create a new one there. | $ zonesigner -genkeys -zone example.org ./zonefile | Errors creating path: /usr/var: | (set DT_STATEDIR to change the location) | /usr/var: Permission denied Bastian -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587613: dnssec-tools - Fails with unreadable files
Package: dnssec-tools Version: 1.5-1 Severity: important | $ chmod 000 zonefile | $ zonesigner -genkeys -zone example.org ./zonefile | Errors creating path: /usr/var: | (set DT_STATEDIR to change the location) | /usr/var: Permission deniedzone example.org/IN: loading from master file ./zonefile failed: permission denied | zone example.org/IN: not loaded due to errors. Bastian -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587614: dnssec-tools - All scripts in /usr/bin, but root-only
Package: dnssec-tools Version: 1.5-1 Severity: important The complete documentation only specifies one config file: /etc/dnssec-tools/dnssec-tools.conf. There is no notion of a user-defined config file and this file specifies root-only directories. Bastian -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587612: d-shlibs: misses the point in checking and listing dependencies of development library packages
Package: d-shlibs Version: 0.44 Severity: normal Dear Jonas, this is the bug report that you asked me for in http://lists.alioth.debian.org/pipermail/pkg-multimedia- maintainers/2010-June/010668.html. To sum up, d-devlibdeps simply prints out the corresponding -dev packages for the libraries that the given shared library is linked against. IMHO this is neither right nor common practice. The dependencies of development library packages are not necessarily the -dev packages of the libraries that the package in question is linked to. I mean, if libfoo0 is linked against liba0, libb0 and libc0, then liba-dev, libb-dev and libc-dev are *not* necessarily dependencies of libfoo-dev! Imagine what this would mean for e.g. libavcodec-dev. Things are different for static libraries, though. To find out hard dependencies for shared libraries development packages, you should (1) check which headers are included by the public API, (2) check which libraries are referenced by the .pc files and (3) check which libraries are referenced by the .la files. - Fabian -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (550, 'unstable'), (400, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages d-shlibs depends on: ii binutils 2.20.1-11 The GNU assembler, linker and bina d-shlibs recommends no packages. d-shlibs suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587615: dnssec-tools - To generic script names
Package: dnssec-tools Version: 1.5-1 Severity: important Many of the scripts in /usr/bin have really generic names, without any notion of the purpose: | /usr/bin/donuts | /usr/bin/cleankrf | /usr/bin/donutsd | /usr/bin/trustman | /usr/bin/timetrans | /usr/bin/rolllog | /usr/bin/rollerd | /usr/bin/keyarch | /usr/bin/blinkenlights -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585624: Info received ([icedove] icedove 3.0.4 doesn't follow network.protocol-handler.app.http* any more)
There had been hope that the upcoming icedove update as of today (squeeze 3.0.5) would fix this, apparently not. I did try the whole thing with a new user=new profile and viola icedove open http[,s] links with the right application namely x-www-browser. This newly created icedove profile didn´t fixed it for my mainuser. After deleting any mime related file i could find w/o success, i created a completely new kde profile. Now icedove behaves right also with it´s original profile! Here i use $ apt-cache policy kdebase-bin kdebase-bin: Installed: 4:4.4.4-1 Candidate: 4:4.4.4-1 Apparently i am not able to trace that down to a specific setting/file but it seems this bug here is caused by the DE and not by icedove. Fabrice cc'ed can you try that also and [,not] confirm? -- bye Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587616: dnssec-tools - zonesigner fails for simple signing: unable to update serial number in ./zonefile
Package: dnssec-tools Version: 1.5-1 Severity: grave zonesigner, the central tool, fails to sign a simple zone. | $ zonesigner -zone waldi.eu.org ./zonefile | Errors creating path: /usr/var: | (set DT_STATEDIR to change the location) | /usr/var: Permission denied | if zonesigner appears hung, strike keys until the program completes | (see the Entropy section in the man page for details) | | unable to update serial number in ./zonefile Bastian -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587617: Typo in package description
Package: glassfish Version: 1:2.1.1-b31-2 Severity: minor Tags: patch Hello. I found a small typo while translating the package description via DDTSS. The long descriptions read Glassfish, it should be GlassFish instead. The patch is included. Erik -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (20, 'experimental'), (20, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- control 2010-05-20 22:39:14.0 +0200 +++ control.new 2010-06-30 13:13:25.0 +0200 @@ -28,7 +28,7 @@ Application Server, the Java EE 5 Reference Implementation, and the Java Persistence API Reference Implementation, TopLink Essentials. . - This package ships only the activation part of Glassfish. + This package ships only the activation part of GlassFish. Package: glassfish-appserv Architecture: all @@ -39,7 +39,7 @@ Application Server, the Java EE 5 Reference Implementation, and the Java Persistence API Reference Implementation, TopLink Essentials. . - This package ships only the Application Server components of Glassfish. + This package ships only the Application Server components of GlassFish. Package: glassfish-jmac-api Architecture: all @@ -50,7 +50,7 @@ Application Server, the Java EE 5 Reference Implementation, and the Java Persistence API Reference Implementation, TopLink Essentials. . - This package ships only the Jmac API components of Glassfish. + This package ships only the Jmac API components of GlassFish. Package: glassfish-mail Architecture: all @@ -84,4 +84,4 @@ Application Server, the Java EE 5 Reference Implementation, and the Java Persistence API Reference Implementation, TopLink Essentials. . - This package ships only the Toplink Essentials components of Glassfish. + This package ships only the Toplink Essentials components of GlassFish.
Bug#587619: ITP: phonon-backend-vlc -- Phonon VLC backend
Package: wnpp Severity: wishlist Owner: Fathi Boudra f...@debian.org * Package name: phonon-backend-vlc Version : 0.0.1~git1+1b1ce593 Upstream Author : VLC Phonon authors * URL : http://gitorious.org/phonon/phonon-vlc * License : LGPL2+ Programming Lang: C++ Description : Phonon VLC backend Phonon is the Qt 4 multimedia API, which provides a task-oriented abstraction layer for capturing, mixing, processing, and playing audio and video content. This package contains VLC backend for Phonon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#266118: unclutter: Blinks pointer and causes 100% CPU usage
Hi there,
I'm also seeing this bug with evince, gimp and amule.
The recommendation (on
https://bugs.launchpad.net/ubuntu/+source/unclutter/+bug/385034)
that unclutter be run with -noevents, stops the blinking and cpu usage,
but also stops fvwm from cycling through windows with Alt-Tab.
The attached patch solves the problem satisfactorily for me,
but, not being an X programmer, i don't really understand what FocusOut is for.
The patch is against unclutter-8
(from
http://ftp.de.debian.org/debian/pool/main/u/unclutter/unclutter_8.orig.tar.gz)
bye
TAO.
--- unclutter/unclutter.c 1994-04-12 01:40:47.0 +1000
+++ unclutter.patched/unclutter.c 2010-06-30 21:23:45.0 +1000
@@ -334,7 +334,9 @@
do{
XNextEvent(display,event);
}while(event.type!=LeaveNotify
- event.type!=FocusOut
+ /* Some gtk applications seem not to like this:
+ * event.type!=FocusOut
+ */
event.type!=UnmapNotify
event.type!=ConfigureNotify
event.type!=CirculateNotify
signature.asc
Description: Digital signature
Bug#586769: Re[2]: Bug#586769: (no subject)
Tue, 29 Jun 2010 16:43:21 -0500 письмо от William Vera bi...@billy.com.mx: Any advance with this issue? Please let me know if you need something Thanks Greetings! added 08-fixbeeping.dpatch to a debian/patches (by dpatch patch-template) added '08-fixbeeping.dpatch' line to 00list then dpkg-buildpackage -b somewhere in log it said something like dpatch apply-all applying patch 01_manpagefix to ./ ... ok. applying patch 02_options.c to ./ ... ok. applying patch 003_descmanpage to ./ ... ok. applying patch 04-focused to ./ ... ok. applying patch 05-addfocusedmanpage to ./ ... ok. applying patch 06_manpagespace to ./ ... ok. applying patch 07_fix-formatstring to ./ ... ok. applying patch 08-fix-beeping to ./ ... ok. and then was built without errors. I compared your and mine versions of main.c (again. Last time I was wrong) and found function `scrot_nice_clip` defined two times in your version. With the same body. May be you applied patches manually and then dpatch had not detected that they were applied and had done it second time? Can you start from orig.tar.gz and post here dpkg-buildpackage log from start until configure script launch, please? (with fix-beeping included as dpatch) --- Rinat -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587620: apt: add an optionnal Why field to suggest entries (in the dependency field)
Package: apt Version: 0.7.25.3 Severity: wishlist Hello, Sometimes, from a user point of view, understanding why a package A recommends or suggests package B1 or B2 is not straightforward. It would be nice to add an optionnal why field to explain what features are enabled in package A when installing package B1. Ideally, this could be displayed when the user calls : apt-cache show or looks at the package data in another front-end for apt. This way, they would know from the start if they want to install package B1 all along, when installing A. Best regards, Alexandre Fournier -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Acquire ; APT::Acquire::Translation environment; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^linux-image.*; APT::NeverAutoRemove:: ^linux-restricted-modules.*; APT::NeverAutoRemove:: ^kfreebsd-image.*; Dir /; Dir::State var/lib/apt/; Dir::State::lists lists/; Dir::State::cdroms cdroms.list; Dir::State::userstatus status.user; Dir::State::status /var/lib/dpkg/status; Dir::Cache var/cache/apt/; Dir::Cache::archives archives/; Dir::Cache::srcpkgcache srcpkgcache.bin; Dir::Cache::pkgcache pkgcache.bin; Dir::Etc etc/apt/; Dir::Etc::sourcelist sources.list; Dir::Etc::sourceparts sources.list.d; Dir::Etc::vendorlist vendors.list; Dir::Etc::vendorparts vendors.list.d; Dir::Etc::main apt.conf; Dir::Etc::netrc auth.conf; Dir::Etc::parts apt.conf.d; Dir::Etc::preferences preferences; Dir::Etc::preferencesparts preferences.d; Dir::Bin ; Dir::Bin::methods /usr/lib/apt/methods; Dir::Bin::dpkg /usr/bin/dpkg; Dir::Media ; Dir::Media::MountPath /media/apt; Dir::Log var/log/apt; Dir::Log::Terminal term.log; DPkg ; DPkg::Pre-Install-Pkgs ; DPkg::Pre-Install-Pkgs:: /usr/sbin/apt-listbugs apt || exit 10; DPkg::Pre-Install-Pkgs:: /usr/sbin/dpkg-preconfigure --apt || true; DPkg::Tools ; DPkg::Tools::Options ; DPkg::Tools::Options::/usr/sbin/apt-listbugs ; DPkg::Tools::Options::/usr/sbin/apt-listbugs::Version 2; -- (no /etc/apt/preferences present) -- -- /etc/apt/sources.list -- # deb http://ftp.fr.debian.org/debian/ lenny main deb http://ftp.debian.org/debian/ testing main non-free contrib deb-src http://ftp.debian.org/debian/ testing main deb http://security.debian.org/ testing/updates main deb-src http://security.debian.org/ testing/updates main #deb http://volatile.debian.org/debian-volatile lenny/volatile main #deb-src http://volatile.debian.org/debian-volatile lenny/volatile main deb http://ftp.debian.org/debian experimental main deb http://condor.infra.s1.p.fti.net/dop sarge ke-preprod deb ftp://ftp.debian-multimedia.org testing main non-free -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apt depends on: ii debian-archive-keyring2009.01.31 GnuPG archive keys of the Debian a ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libgcc1 1:4.5.0-1 GCC support library ii libstdc++64.5.0-1The GNU Standard C++ Library v3 apt recommends no packages. Versions of packages apt suggests: pn apt-doc none (no description available) ii aptitude 0.6.1.5-3 terminal-based package manager (te ii bzip2 1.0.5-4high-quality block-sorting file co pn dpkg-dev none (no description available) ii lzma 4.43-14Compression method of 7z format in ii python-apt0.7.95 Python interface to libapt-pkg ii synaptic 0.63.1 Graphical package manager -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585067: keyboard-configuration: No alt+gr keys working after some time
thanks for the reply.
So I tried alomost everything, namely with :
.startup script : with setxkbmap us
and also
.startup script : without any setxkbmap and .startup script empty.
at the start of JWM.
It seems that it comes from X11 + JWM together ... I would suppose.
On Wed, Jun 30, 2010 at 12:13 PM, Julien Cristau jcris...@debian.orgwrote:
On Thu, Jun 17, 2010 at 20:58:49 +0200, yellow protoss wrote:
I attached the output file.
thank you
Best regards
On Tue, Jun 15, 2010 at 11:33 PM, Julien Cristau jcris...@debian.org
wrote:
On Sat, Jun 12, 2010 at 21:53:30 +0200, yellow protoss wrote:
cat /etc/default/keyboard
# If you change any of the following variables and HAL and X are
# configured to use this file, then the changes will become visible
to
# X only if HAL is restarted. In Debian you need to run
# /etc/init.d/hal restart
# The following variables describe your keyboard and can have the
same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions
options
# in /etc/X11/xorg.conf.
XKBMODEL=pc105
XKBLAYOUT=de
XKBVARIANT=nodeadkeys
XKBOPTIONS=lv3:ralt_switch
What's the output of 'xkbcomp :0 -'?
[...]
xkb_symbols pc+us+inet(evdev)+level3(ralt_switch) {
This reports a us layout, not de with nodeadkeys... Is your session /
desktop resetting the layout maybe?
Cheers,
Julien
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJMKxi2AAoJEDEBgAUJBeQM6VMQAJpIoeZFI+YzqFcifSeSFXz4
g5u1ad8eAB4Yk2opaPo7qV2gUyPFhp8GiqeKJ7XRFecwhXLxJrT01J4Rd8CTm/qI
JFWOskcKmIOjH7u5x1Jyy73XoLAP/J543UJKM+f/yTrgWvZ8tzFsqc6C1hVL34q7
pWi8So3ymPVuOrcqmsv6vWEMasAiAXD6Intb0FrVt3HQhETv0Ycum8KG+YURz+UH
eQOTk1QhZVg3eJssq4MAbOfSeo+mwELcbENBoL4ClbuZhIiv1aZ8B2IuR4go2IO5
xSI6QM5prSAiVw34A8XjQvUHwaJSp7VD/tJU2Kaf6ZvIY+WT+L3X41cXglSt1A1+
rNWeaUwOIPhSv1XfDMsof2xNxQpzToWbMd7od5uJhXeIN5Og6A+MwnSjl7JNyY1K
dN4T41q/SFKtsnlaxXt3+WnC6WAO3URCzOuBbeoYf2Pa2n5NmSGprZxE2PQpfMv8
/pTUjw9EYkwFOz7VEcbP/q3IG+YfdwvGP/UYhZaYFKK3xnPCSS0ByHjKs3eS7Ru7
t605qwVHNFIzessrp4RtHmtVJsC+taDlih+6ouECnoErrSkd3OZ+Fp15iHUTX2LT
jHQ5sAIHMsVhSalAAVgXNiENtxb+xAXrH7mpaMjgOfLI1rElQTd/Y7qk2g15ma9g
vY0jWlUYAQUiQFIpu7BZ
=g/aV
-END PGP SIGNATURE-
Bug#585067: keyboard-configuration: No alt+gr keys working after some time
On Wed, Jun 30, 2010 at 13:39:57 +0200, yellow protoss wrote: thanks for the reply. So I tried alomost everything, namely with : .startup script : with setxkbmap us and also .startup script : without any setxkbmap and .startup script empty. at the start of JWM. It seems that it comes from X11 + JWM together ... I would suppose. Well there doesn't seem to be a bug in X here. If you're using a us layout then there's nothing for altgr to do. If you want to use de(nodeadkeys) then don't set the keymap to us... Cheers, Julien signature.asc Description: Digital signature
Bug#587439: jscal: error getting axis map: Success
On Mon, 28 Jun 2010 10:53:21 -0600, ha...@softhome.net wrote: The jscal that ships with Debian is not remapping my buttons. Here is what happens: $ sudo jscal -u 2,0,1,9,304,305,311,307,308,309,310,306,312 /dev/input/js0 jscal: error getting axis map: Success I built the patched jscal available here: http://ubuntuforums.org/showthread.php?t=761044 This jscal works just fine. This confuses me as it seems to have originated from a debian bug report(444142) which has been closed. So this appears to be a regression. Indeed, the check in get_axmap2() is incorrect (it should say 0). I'm afraid it will take me a couple of weeks to upload a fixed package... Regards, Stephen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587612: d-shlibs: misses the point in checking and listing dependencies of development library packages
Hi Fabian, On Wed, Jun 30, 2010 at 12:56:50PM +0200, Fabian Greffrath wrote: To sum up, d-devlibdeps simply prints out the corresponding -dev packages for the libraries that the given shared library is linked against. IMHO this is neither right nor common practice. The dependencies of development library packages are not necessarily the -dev packages of the libraries that the package in question is linked to. I mean, if libfoo0 is linked against liba0, libb0 and libc0, then liba-dev, libb-dev and libc-dev are *not* necessarily dependencies of libfoo-dev! Imagine what this would mean for e.g. libavcodec-dev. Things are different for static libraries, though. To find out hard dependencies for shared libraries development packages, you should (1) check which headers are included by the public API, (2) check which libraries are referenced by the .pc files and (3) check which libraries are referenced by the .la files. Thanks (again) for your input. I do not understand in what situations -dev packages need not depend on -dev packages corresponding to what packages the library links against. As I see it, this is contained in 1st paragraph of Debian Policy §8.4. Perhaps if you elaborate a bit more on your libavcodec-dev example, I may better understand your point? Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#587622: frozen-bubble: Frozen Bubble's description contains unnecessary details
Package: frozen-bubble Severity: minor Reported at https://bugs.launchpad.net/ubuntu/+source/frozen-bubble/+bug/599809 In Frozen Bubble's description in the Software Center, we find this line: This game is widely rumored to be responsible for delaying the Woody$ I think informations related to rumors or Debian-specific should not be present. The package description also features the Homepage url which should not be there, but in the debian/control Homepage field -- System Information: Debian Release: squeeze/sid APT prefers lucid-updates APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid') Architecture: i386 (i686) Kernel: Linux 2.6.32-22-generic (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587623: xarchiver doesn’t respect $TMP
Package: xarchiver Version: 1:0.5.2+20090319+dfsg-4 Severity: normal Hello xarchiver places its temporary files in /tmp, even if $TMP and $TMPDIR point to another directory. Regards -- System Information: Debian Release: squeeze APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xarchiver depends on: ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra ii libfontconfig12.8.0-2.1 generic font configuration library ii libfreetype6 2.3.11-1 FreeType 2 font engine, shared lib ii libglib2.0-0 2.24.1-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio Versions of packages xarchiver recommends: pn arj none (no description available) ii bzip21.0.5-4 high-quality block-sorting file co pn p7zip-full none (no description available) pn rpm none (no description available) ii unzip6.0-4 De-archiver for .zip files ii xdg-utils1.0.2+cvs20100307-1 desktop integration utilities from ii zip 3.0-3 Archiver for .zip files Versions of packages xarchiver suggests: pn lha none (no description available) pn rar none (no description available) -- no debconf information -- debsums errors found: debsums: missing file /usr/share/locale/de/LC_MESSAGES/xarchiver.mo (from xarchiver package) debsums: missing file /usr/share/locale/en_GB/LC_MESSAGES/xarchiver.mo (from xarchiver package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587621: fretsonfire-game: Frets on Fire description is confusing
Package: fretsonfire-game Severity: minor Reported at https://bugs.launchpad.net/hundredpapercuts/+bug/599525 Here's the Frets on Fire description in the Software Center: Frets on Fire is a game of musical skill and fast fingers. The aim of the game is to play guitar with the keyboard as accurately as possible. This is the package containing the game code. You will need working sound and an open-gl capable graphics card. The last line is unnecessary and confusing for the end-user. -- System Information: Debian Release: squeeze/sid APT prefers lucid-updates APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid') Architecture: i386 (i686) Kernel: Linux 2.6.32-22-generic (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587618: xserver-xorg: Periodically x switches between virual desktops randomly and at speed
On Wed, Jun 30, 2010 at 12:20:16 +0100, Ben Whyte wrote: Package: xserver-xorg Version: 1:7.5+6 Severity: important When using X I frequently get rapid switching of workspaces within fluxbox, on running xev, I see _WIN_workspace and also _net_wn_desktop appear I am running fluxbox if that is relevant. Sounds unlikely to be an X bug. Please provide the output of xinput list and xinput test-xi2 when that happens. Cheers, Julien signature.asc Description: Digital signature
Bug#587318: gforth: Please make Emacs mode auto-add to auto-mode-alist
On 29 June 2010 14:54:36 UTC+1, Peter Pentchev r...@ringlet.net wrote: I've added the attached patch to my Subversion repo; I admit that I'm not very well versed in e-lisp, so any suggestions / reproaches would be welcome :) I think the lines you've added are fine, but need to be added to /etc/emacs.d/site-lisp/50gforth.el, not gforth.el, because as far as I can see, the Debian Emacs routines don't automatically use autoload (though some individual packages do). This solution is used, for example, by inform-mode. However, if you want to really be nice, then you should add the lines to gforth.el, preceded by ;;;###autoload so that they work with autoload, and then also add the lines to 50gforth.el, so they are actually loaded at startup by Debian Emacs. This has two advantages: 1. You can supply the patch to gforth.el to upstream, and it will improve gforth.el for all Emacs users. 2. If Debian ever starts using autoload in all Emacs extension packages, then the necessary change to gforth.el has already been made. BTW, is there some kind of a list of the filename extensions registered by the various Emacs modes in Debian? Meaning, is there a way for me to check if I'm stepping on anybody's toes by grabbing .fs, .4th, and .fth? Not as far as I know; that's a question for the Emacs maintainers. You may in any case want to check whether what I said above is correct. -- http://rrt.sc3d.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586333: [buildd-tools-devel] Bug#586333: Debian desktop support for virtualisation
Roger Leigh rle...@codelibre.net writes: On Sun, Jun 27, 2010 at 10:48:25AM +0200, Josselin Mouette wrote: Le dimanche 27 juin 2010 à 01:40 +0100, Roger Leigh a écrit : On Fri, Jun 25, 2010 at 01:46:41PM +0200, Josselin Mouette wrote: You may also need (but I havenât checked): * /var/run/cups for printing * /var/run/avahi-daemon and some others that Iâm forgetting. Thanks! I think we now have most of these. We don't preserve the environment by default (you have to use the -p option), but we could make that automatic in a future release by adding a new configuration option. You should definitely pass the following environment variables without asking, since GNOME applications wonât work without them: [...] I've added a 'preserve-environment=true|false' option today, which will pass the entire environment through minus some filtering for security (which doesn't cover any of the variables in your list). Passing all of /var/run looks a bit dangerous to me since it could lead some scripts in the chroot believe that a daemon is started in the chroot. Iâm not sure if thatâs a real problem, but you should probably at least print a warning somewhere. Agreed. I'll just limit this to /var/run/gdm3 in the next upload. Unfortunately, because we can't be sure gdm3 is installed, it will need to be commented out by default. Or we need to make schroot-mount less picky about mount failures. I would be somewhat dubious about doing that though, since it would mask a whole set of failures and could have security implications. So it's still not perfect, but I think we can easily document the few minor bits of tweaking required--the major bits are all done at least. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. Don't forget about mail and sound and probably a lot more. The chroot way will allways be a case-by-case option though. Every user can easily create one for their needs but covering all the possible configurations so it works out-of-the-box for everyone will be hellishly complicated. Me I just use ia32-apt-get + dpkg-cross and do apt-get install 32bit only programm apt-get build-dep bla-armel-cross MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576072: [Pkg-xfce-devel] Bug#576072: it is now possible to select textlabel size
On 30/06/2010 12:41, Ibragimov Rinat wrote:
On mar., 2010-06-29 at 21:17 +0400, Ibragimov Rinat wrote:
GtkWidget *about;
-const gchar* authors[2] = {
+const gchar* authors[] = {
Alexander Iliev sasoil...@mamul.org,
Gauvain Pocentek gauvainpocen...@gmail.com,
NULL
Does this mean you intend to take over upstream maintainership?
No, I had not added my name to the list, but removed '2' from array size
because
there are three elements (including NULL), not two. I'd noticed compiler
warning
about this line and fixed it but forgot to remove this from the patch. My
fault.
I can upload patch without this fix if it is important.
Nah, don't bother, it was just my secret hope :) Did you open a bug on
upstream bugfzilla about this issue? And keep bugging the maintainer, we
never know :/
--
Yves-Alexis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587624: Update config for University of Toronto
package: krb5-config
severity: wishlist
From a mail from Peter St. Onge:
The complete config data (used internally) would be as follows:
-
[libdefaults]
default_realm = UTORONTO.CA
[realms]
UTORONTO.CA = {
kdc = kerberos1.utoronto.ca
kdc = kerberos2.utoronto.ca
kdc = kerberos3.utoronto.ca
admin_server = kerberos1.utoronto.ca
default_domain = utoronto.ca
[domain_realm]
.toronto.edu = UTORONTO.CA
.utoronto.ca = UTORONTO.CA
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584819: gcc-4.5: FTBFS on hurd-i386
reopen 584819 thanks Oops, sorry, it looks like my patch toold is quite laxist and accepted a not so exact patch, but buildds such don't accept that. The attached patch should fix the hooks content. It also moves hurd-changes to after the snapshot barrier, now that it only contains long-term changes. Thanks, Samuel Index: debian/patches/hurd-pthread.diff === --- debian/patches/hurd-pthread.diff(révision 4569) +++ debian/patches/hurd-pthread.diff(copie de travail) @@ -58,7 +58,7 @@ # if defined(GC_FREEBSD_THREADS) --- a/src/boehm-gc/configure.ac.orig 2009-02-07 22:30:12.0 + +++ b/src/boehm-gc/configure.ac2009-02-07 22:35:31.717091000 + -@@ -172,6 +172,11 @@ +@@ -180,6 +180,11 @@ AM_CPPFLAGS=$AM_CPPFLAGS -pthread THREADLIBS=-pthread ;; @@ -67,12 +67,12 @@ + AC_DEFINE(_REENTRANT) + AC_DEFINE(THREAD_LOCAL_ALLOC) + ;; - *-*-solaris*) + *-*-solaris2.8*) AC_DEFINE(GC_SOLARIS_PTHREADS,1,[support for Solaris pthreads]) # Need to use alternate thread library, otherwise gctest hangs --- a/src/boehm-gc/configure.orig 2009-02-07 22:32:34.0 + +++ b/src/boehm-gc/configure 2009-02-07 22:35:28.06565 + -@@ -5489,6 +5489,20 @@ +@@ -14893,6 +14893,20 @@ AM_CPPFLAGS=$AM_CPPFLAGS -pthread THREADLIBS=-pthread ;; @@ -90,9 +90,9 @@ +_ACEOF + + ;; - *-*-solaris*) + *-*-solaris2.8*) - cat confdefs.h \_ACEOF + $as_echo #define GC_SOLARIS_PTHREADS 1 confdefs.h --- a/src/boehm-gc/os_dep.c.orig 2009-02-07 22:37:20.0 + +++ b/src/boehm-gc/os_dep.c2009-02-07 22:37:40.0 + @@ -312,7 +312,7 @@ Index: debian/rules.patch === --- debian/rules.patch (révision 4569) +++ debian/rules.patch (copie de travail) @@ -126,7 +126,7 @@ endif ifeq ($(DEB_TARGET_ARCH_OS),hurd) - debian_patches += hurd-changes hurd-pthread + debian_patches += hurd-pthread endif ifeq ($(DEB_TARGET_ARCH),alpha) @@ -174,6 +174,10 @@ debian_patches = endif +ifeq ($(DEB_TARGET_ARCH_OS),hurd) + debian_patches += hurd-changes +endif + ifeq ($(PKGSOURCE),gcc-snapshot) debian_patches += gcc-ice-hack-trunk gcc-ice-apport-trunk else
Bug#585067: keyboard-configuration: No alt+gr keys working after some time
I assume that it is not coming from the layout but really a but in itself of X11. I tried all kind of layouts, and the TTY work flawless (no X). I guess it has something to do with X. On Wed, Jun 30, 2010 at 1:44 PM, Julien Cristau jcris...@debian.org wrote: On Wed, Jun 30, 2010 at 13:39:57 +0200, yellow protoss wrote: thanks for the reply. So I tried alomost everything, namely with : .startup script : with setxkbmap us and also .startup script : without any setxkbmap and .startup script empty. at the start of JWM. It seems that it comes from X11 + JWM together ... I would suppose. Well there doesn't seem to be a bug in X here. If you're using a us layout then there's nothing for altgr to do. If you want to use de(nodeadkeys) then don't set the keymap to us... Cheers, Julien -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJMKy4HAAoJEDEBgAUJBeQMWJAQAJ4zz/ns7YC7eNi8+lrW8y/R 0VuHQrOlLyOU+b/1pQyCept8pVVRy+3QXJMRSak8XJXPIE2FKweHYkivAryL5U5K NKjSEKZ2cCt8Q9DGe3DcZ/cdlqLTpjjOHf6eHolHLv1H+LfuZcZ3IteERZnwl4Cw ENRk8miZow/nTey63jS5742jzFC8/+bXBRRCdoFSFLVlwKdkhXibl4XNpIuHlHd9 ns29e6zj5eQ5n7yKS9SrmDIBY1SqCN64zP/le8WnhSkG2fbfPighHWoFSM/8I1jo eniD4YoBWu3IfXmcun6mRNV3bo1qK4gFeA0nSSxxpPwt80TThXLiQ5WExoCFTZZy 7XmhZ+UMQHtOTBM+dh11d7aDIflvJC6ROIpLmfF/RHGco/W5tXdNDuDvFMEoGyn7 Xa8GXmeD+4h01LrNnnzFw4onHFQdG5WddnR9aZMKDL1UeDjILKxdzcGEZqy8kWyZ wJrftw+ujTo7ESat+s073r4f41VmTwXBfszC+sk+XJEUehX3EBUsdIHEl54T9Kqt 6pDI+jV+hce3KdstJKzvzz+aLSwbjWibo+dsys43omPn0BvR2RfCATy2EMafUGki 0T268S4mMOtFG9OmjLra5G2HQrWIrHFHEHWBMH/hN0ZTRhduuTz9hN7z+Fwxo746 4GRwG5vHWLYAAaOETYyY =TAis -END PGP SIGNATURE-
Bug#587373: [Build-common-hackers] Bug#587373: cdbs: python-distutils.mk: Installs scripts with a versioned shebang
tag 587373 - patch thanks Would you happen to know if that option is new or we can safely use this also for e.g. backports? I don't know. I need to do some more historical research. Would it perhaps be better to always pass this option, also for specific versions of Python? The problem isn't with versions of python, but the different libraries that setup.py may be using. It looks like I need to do some more testing, I've found some packages that would FTBFS with this. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585067: keyboard-configuration: No alt+gr keys working after some time
On Wed, Jun 30, 2010 at 14:04:33 +0200, yellow protoss wrote: I assume that it is not coming from the layout but really a but in itself of X11. I tried all kind of layouts, and the TTY work flawless (no X). I guess it has something to do with X. The layout (xkbcomp output) you attached in this bug looked just fine, it just wasn't a german layout. There's no evidence of a bug here, so unless you can provide more details and something that makes some sense, I'll close this bug. I don't know what you tried, I don't know your desktop environment, and you don't seem to have even tried to provide coherent explanations. Cheers, Julien signature.asc Description: Digital signature
Bug#587440: sbcl-doc: Package doesn't install
Package: sbcl-doc Version: 1:1.0.34.0-1.1 Severity: serious -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (700, 'testing'), (650, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.33.1maxwell (PREEMPT) Locale: LANG=pt_PT.UTF-8, LC_CTYPE=pt_PT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages sbcl-doc depends on: ii dpkg 1.15.7.2 Debian package management system ii install-info 4.13a.dfsg.1-5 Manage installed documentation in sbcl-doc recommends no packages. sbcl-doc suggests no packages. -- no debconf information The installation process aborts with the error below: dpkg: erro ao processar /var/cache/apt/archives/sbcl-doc_1%3a1.0.39.0-1_all.deb (--unpack): não foi possível efectuar uma limpeza à volta de `./usr/share/doc/sbcl-doc/html/sbcl/Method-sb_002dbsd_002dsockets_003asocket_002dmake_002dstream-_0028_0028socket-socket_0029-_0026key-input-output-_0028element_002dtype-_0027character_0029-_0028buffering-full_0029-_0028external_002dformat-default_0029-tim' antes de instalar outra versão: Nome de arquivo muito longo dpkg-deb: subprocesso paste morto pelo sinal (Pipe quebrado) Note that this is in portuguese. It aborts due to too long a filename; no removal of the previously installed file was done. Thank you, --- appa -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587625: beid-tools: Daemon fails to start
Package: beid-tools Version: 3.5.2.dfsg-10 Severity: important Hello. All the latest packages related to beid card reader being installed, no application is working: * beidgui reports ---CUT--- No card readers are detected. Please check the card readers are connected and/or verify the pcsc daemon is running. ---CUT--- * Doing /etc/init.d/beid start seems to have no effect and does not report anything * Manually starting the daemon: /usr/bin/beidpcscd -v reports ---CUT--- The service eID Privacy Service /usr/bin/beidpcscd is not installed and not running ---CUT--- * In iceape and iceweasel, attempting to connect to the government web site results in a page being displayed that contains: ---CUT--- Secure Connection Failed An error occurred during a connection to ccff02.minfin.fgov.be. SSL peer was unable to negotiate an acceptable set of security parameters. (Error code: ssl_error_handshake_failure_alert) ---CUT--- * I noticed that there are 2 config file in /etc: beidbase.conf beid.conf but I have no clue whether I should change something there: none of the beid packages contains any user documentation (there is only a changelog file). Regards, Gilles -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-3-vserver-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages beid-tools depends on: ii libbeid2 3.5.2.dfsg-10 library to read identity informati ii libbeidlibopensc2 3.5.2.dfsg-10 belgian eID PKCS11 library ii libc6 2.11.2-1 Embedded GNU C Library: Shared lib ii libgcc11:4.4.3-9 GCC support library ii libqt3-mt 3:3.3.8b-6Qt GUI Library (Threaded runtime v ii libssl0.9.80.9.8n-1 SSL shared libraries ii libstdc++6 4.4.3-9 The GNU Standard C++ Library v3 beid-tools recommends no packages. beid-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587626: should use default enctype configuration
package: krb5-config In 1.8, MIT Kerberos added support for the default tag for enctype configuration. So you can do something like default_tgs_enctypes = default -des-cbc-crc I think we should use this style in the commented out entries in krb5.conf. This would of course mean that krb5-config would break libkrb53, although that's probably just fine. Depending on how we resolve the bugs against krb5, we may want to delay pushing a change here until after squeeze. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570350: pid_ns child_reaper fixes for 2.6.26
On 06/29, Ben Hutchings wrote: On Tue, 2010-06-29 at 17:23 +0200, Oleg Nesterov wrote: @@ -182,9 +182,12 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns) rc = sys_wait4(-1, NULL, __WALL, NULL); } while (rc != -ECHILD); - - /* Child reaper for the pid namespace is going away */ - pid_ns-child_reaper = NULL; + /* + * We can not clear -child_reaper or leave it alone. + * There may by stealth EXIT_DEAD tasks on -children, + * forget_original_parent() must move them somewhere. + */ + pid_ns-child_reaper = init_pid_ns.child_reaper; This is correct, but the second patch @@ -182,12 +182,6 @@ void zap_pid_ns_processes(struct pid_namespace *pid_ns) rc = sys_wait4(-1, NULL, __WALL, NULL); } while (rc != -ECHILD); - /* - * We can not clear -child_reaper or leave it alone. - * There may by stealth EXIT_DEAD tasks on -children, - * forget_original_parent() must move them somewhere. - */ - pid_ns-child_reaper = init_pid_ns.child_reaper; Removes this code? That's what your commit 950bbabb5a804690a0201190de5c22837f72f83f did. This commit moves this pid_ns-child_reaper = init_pid_ns.child_reaper, to find_new_reaper(). Like the new patch below does, this is correct. Probably I misread your previous patch as if it just kills this assignment. I think you are right, you need these 2 commits 950bbabb5a804690a0201190de5c22837f72f83f add0d4dfd660e9e4fd0af3eac3cad23583c9558f (in that order). That is the opposite of the order in which they were originally applied! Indeed, I confused the order ;) Sorry. The combined diff is: Looks correct to me. Oleg. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585067: keyboard-configuration: No alt+gr keys working after some time
Well, I am not expert ni LINUX nor coder. So If you can be specific what you require, I can surely provide it, and would be pleased to contribute. Unfortunately I am not developer or coder, so if you inquire a command and an output to be reported, I would surely do my best to do so. I am sorry On Wed, Jun 30, 2010 at 2:11 PM, Julien Cristau jcris...@debian.org wrote: On Wed, Jun 30, 2010 at 14:04:33 +0200, yellow protoss wrote: I assume that it is not coming from the layout but really a but in itself of X11. I tried all kind of layouts, and the TTY work flawless (no X). I guess it has something to do with X. The layout (xkbcomp output) you attached in this bug looked just fine, it just wasn't a german layout. There's no evidence of a bug here, so unless you can provide more details and something that makes some sense, I'll close this bug. I don't know what you tried, I don't know your desktop environment, and you don't seem to have even tried to provide coherent explanations. Cheers, Julien -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJMKzSMAAoJEDEBgAUJBeQMANAP/iLIBVh5HfUzn7cr45H9Fv9g h37ZsvGaSE7sZGx2+RVAkNkB1Nf+kZ43jcqEaCFrewo7F0r+Z0e9/ofwxnx1LrSc bFu23B8RMEoAzuU9RntTaC0ClwTEZjeJLMb2pgCObtEqP4KgK4E/UnFI3eTAwLaH cixd3PFVYShg7jm54mqhAHEPfk/E/kIIQmrtKrl3yAEV+bAiVBmau6xm4xi9pCf7 QJBdXuoffIgvAhlXmkjA4kPufI+njAX2ALYdx+SEHA27LiVcjd0Msp4Ge2mAphCr RcBPPPEPhL7/y5twN/HRqc7JaRITU28sFeqMcueBJEgqaui3kJmieuI9vxCAacRR SMI+K+L6co6W+//rt33+/XTGVDIlXlcd9GkAManxFyF/MI11lhKL9NT1zwMeeMAW 8fY3Gw6Myw84C5ZD3mULSYiAPFEtY3NGH+/Hsvc9iq3R+U3JkNg0FTLif3GZ4UPT TS2VnjqoY7JatiSBOFviIIQgCjPFQDGGl9ydYNYzaGdAbKqBRg/lG8pstrCEit1f mtukpUILkRma1tR8b9LNcjK2sXqME+Lb7eNJRLYVjmbiIGdUe3OiqhEDA0gNRpa+ s6iYNh2zByB6vvcxmnslRGKelEew0AGQ0wFdUFBvx34r1GQVG4VapLR4DHHBLKK8 CM6efJB076GBsSe7SVeI =BcyJ -END PGP SIGNATURE-
Bug#587373: [Build-common-hackers] Bug#587373: cdbs: python-distutils.mk: Installs scripts with a versioned shebang
On Wed, Jun 30, 2010 at 02:12:18PM +0200, Stefano Rivera wrote: Would you happen to know if that option is new or we can safely use this also for e.g. backports? I don't know. I need to do some more historical research. ok. Would it perhaps be better to always pass this option, also for specific versions of Python? The problem isn't with versions of python, but the different libraries that setup.py may be using. It seems we are talking about different things: I proposed that (in the cases where your proposed option works) not only the unversioned python path is ensured when using the default Python, but also the versioned python path is used when using a non-default Python (e.g. for a project where Python 2.6 is not supported, built for a system where Python 2.6 is the default compiler). It looks like I need to do some more testing, I've found some packages that would FTBFS with this. Too bad. Even if you cannot solve it, please do post more details about it, in case others reading this might have ideas. Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#587622: frozen-bubble: Frozen Bubble's description contains unnecessary details
Le mercredi 30 juin 2010 à 12:44 +0100, Andrew Higginson a écrit : Package: frozen-bubble Severity: minor Reported at https://bugs.launchpad.net/ubuntu/+source/frozen-bubble/+bug/599809 In Frozen Bubble's description in the Software Center, we find this line: This game is widely rumored to be responsible for delaying the Woody$ I think informations related to rumors or Debian-specific should not be present. Maybe they are not relevant for Ubuntu, but they are for Debian. Anyway this is just a joke indicating that the game is very addictive, it had of course no real relation with the delays in the woody release. The package description also features the Homepage url which should not be there, but in the debian/control Homepage field Indeed, the packaging needs a lifting. -- .''`. : :' : “Fuck you sir, don’t be suprised when you die if `. `' you burn in Hell, because I am a solid Christian `-and I am praying for you.” -- Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551373: warzone2100: Segmentation fault when trying to run game
On 29.6.2010 16:59, Julien Cristau wrote: On Sat, Oct 17, 2009 at 22:10:36 +0200, Tomas Safarik wrote: when I try to run the game Single player - New game it segfaults. $ warzone2100 Failed to free bo[0x12014278] at 5000 ret = Operation not permitted info|10:02:47: [seq_Play] unable to open 'sequences/cam1/c001.ogg' for playback info|10:02:47: [rebuildSearchPath] * Failed to remove path /usr/data/ again info|10:02:47: [rebuildSearchPath] * Failed to remove path /usr/share/warzone2100/ again info|10:02:47: [rebuildSearchPath] * Failed to remove path /usr/share/games/warzone2100/ again [driAllocateTexture:635] unable to allocate texture Saved dump file to '/tmp/warzone2100.gdmp-NVojET' If you create a bugreport regardings this crash, please include this file. Segmentation fault I'll be happy to provide more information if needed. Is this still reproducible with mesa 7.7 or 7.8? If so please install libgl1-mesa-dri-dbg and libgl1-mesa-glx-dbg, get a stacktrace from gdb, and file a bug at bugs.freedesktop.org against mesa, component Drivers/DRI/r300. Thanks. Cheers, Julien Hello Julien, unfortunately I no longer use powerpc computer so I am not able to test it. -- Tomas Safarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587132: bustle: FTBFS: Could not find module `Graphics.UI.Gtk.Pango.Font':
On 30/06/10 10:23, Chris Lamb wrote: I think this tarball is missing the Bustle/ directory.. :) Blah. I wish cabal had a distcheck-alike. New tarball uploaded. -- Will -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587612: d-shlibs: misses the point in checking and listing dependencies of development library packages
Am 30.06.2010 13:49, schrieb Jonas Smedegaard: I do not understand in what situations -dev packages need not depend on -dev packages corresponding to what packages the library links I'll try, although my knowlegde in this subject is also rather limited (i.e. whose isn't?). ;) against. As I see it, this is contained in 1st paragraph of Debian Policy §8.4. Perhaps if you elaborate a bit more on your libavcodec-dev example, I may better understand your point? The section of Debian Policy that you quote deals with shared libraries. I'll try to explain my concern in an example a bit less complex than libavcodec-dev: A shared library libfoo0 makes use of symbols of another library liba0 and is thus linked against it. However, in our case libfoo0 does not export (parts of) liba's symbols via its own interface (i.e. it does not reference liba's headers in its own exported headers). That is, if an application bar uses symbols from libfoo0 that in turn make use of symbols from liba0 - but bar does not use the symbols from liba0 directly - then there is no need to link bar against liba0. It is sufficient to link bar against libfoo0 which in turn is linked against liba0. As a consequence, the application does not need to build-depend on the liba-dev package. For static linking, however, the situation is a bit different: Since you build the whole of libfoo.a into the bar object, instead of only making bar link against libfoo0, you also have to build the whole of the libraries that libfoo.a uses symbols from into the bar object. In this case you need access to all the static variants of the libraries that libfoo references (in our example liba.a) and thus have to install the corresponding -dev packages, e.g. liba-dev. Back to the libavcodec example: If you want to use libavcodec for en- or decoding of multimedia material, you simply use some of the functions it exports in its header files in the libavcodec-dev package and link your application against the shared libavcodec52.so library. The libavcodec52 library package will pull in all the required codec libraries that libavcodec uses internally, but as an application developer you do not have to care which library libavcodec uses to de- or encode certain types of media. That's why the libavcodec-dev package has no further *dependencies* except for libavutil-dev, of which it uses some symbols in its exported interface, i.e. in its own header files. On the other hand, libavcodec-dev *suggests* some other -dev packages that are/were usefull for static linking, i.e. that need to be built into your application alongside libavdcodec.a in order to work. However, the packages in this list once were hard dependencies until we (i.e. Sam and Loic IIRC) decided to not support static linking in this form anymore and demote them to suggests a few years ago. The list has not been updated since then, though, and nobody has complained so far. ;) The difference between both scenarios is also well displayed by the different fields Libs and Libs.private in .pc files. I don't know if .la files also do this distinction, but there is a similar field in them called dependency_libs. I hope I was able to bring some light into this subject. However, I will not claim that everything I wrote here is perfectly corrent. ;) - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587627: linux-image-2.6.32-5-686: Unable to use 1600x1200 resolution on external screen, screen not syncing
Package: linux-2.6 Version: 2.6.32-15 Severity: normal Tags: upstream When booting, after the grub menu, the external screen starts being unable to sync as soon as KMS sets the mode for the screen (1600x1200, which is the native resolution). Display on the laptop screen at 800x480 is ok. When Xorg starts, the screen syncs again because it sets another resolution. All resolutions work fine, except the native one (1600x1200), even after disabling the laptop screen. Upgrading to kernel 2.6.34-1 still gives the same results. Note that the problem also occurs with kms disabled. This screen works fine with a different computer with an intel chipset (G31 express). Here is the get-edid | parse-edid result : -- get-edid: get-edid version 2.0.0 Performing real mode VBE call Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0 Function supported Call successful VBE version 300 VBE string at 0x2110 Intel(r)915GM/910ML/915MS Graphics Chip Accelerated VGA BIOS VBE/DDC service about to be called Report DDC capabilities Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0 Function supported Call successful Monitor and video card combination does not support DDC1 transfers Monitor and video card combination supports DDC2 transfers 0 seconds per 128 byte EDID block transfer Screen is not blanked during DDC transfer Reading next EDID block VBE/DDC service about to be called Read EDID Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0 Function supported Call successful parse-edid: EDID checksum passed. # EDID version 1 revision 3 Section Monitor # Block type: 2:0 3:fd # Block type: 2:0 3:fc Identifier 20.1'' VendorName TVT ModelName 20.1'' # Block type: 2:0 3:fd HorizSync 24-82 VertRefresh 56-87 # Max dot clock (video bandwidth) 170 MHz # Block type: 2:0 3:fc # Block type: 2:0 3:fc # DPMS capabilities: Active off:yes Suspend:yes Standby:yes Mode1600x1200 # vfreq 60.000Hz, hfreq 75.000kHz DotClock162.00 HTimings1600 1664 1856 2160 VTimings1200 1201 1204 1250 Flags +HSync +VSync EndMode # Block type: 2:0 3:fd # Block type: 2:0 3:fc # Block type: 2:0 3:fc - And the modelines from Xorg.0.log (II) intel(0): Printing probed modes for output VGA1 (II) intel(0): Modeline 1600x1200x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) (II) intel(0): Modeline 1280x1024x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) intel(0): Modeline 1280x1024x70.0 128.95 1280 1368 1504 1728 1024 1025 1028 1066 -hsync +vsync (74.6 kHz) (II) intel(0): Modeline 1280x1024x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) intel(0): Modeline 1280x960x60.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) (II) intel(0): Modeline 1152x864x85.1 119.74 1152 1224 1352 1552 864 865 868 907 -hsync +vsync (77.2 kHz) (II) intel(0): Modeline 1152x864x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) intel(0): Modeline 1024x768x75.1 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.1 kHz) (II) intel(0): Modeline 1024x768x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) intel(0): Modeline 1024x768x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) intel(0): Modeline 832x624x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) intel(0): Modeline 800x600x85.1 56.25 800 832 896 1048 600 601 604 631 +hsync +vsync (53.7 kHz) (II) intel(0): Modeline 800x600x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) intel(0): Modeline 800x600x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) intel(0): Modeline 800x600x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) intel(0): Modeline 800x600x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) intel(0): Modeline 640x480x85.0 36.00 640 696 752 832 480 481 484 509 -hsync -vsync (43.3 kHz) (II) intel(0): Modeline 640x480x72.8 31.50 640 664 704 832 480 489 491 520 -hsync -vsync (37.9 kHz) (II) intel(0): Modeline 640x480x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) intel(0): Modeline 640x480x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) intel(0): Modeline 640x480x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) intel(0): Modeline 720x400x87.8 35.50 720 738 846 900 400
Bug#585812: zsh: xsltproc completion doesn't include --nodtdattr option
On Mon, Jun 14, 2010 at 02:54:10AM +0200, Vincent Lefevre wrote: xsltproc --help contains: [...] --nodtdattr do not default attributes from the DTD [...] but this option isn't listed in the completion for xsltproc. The attached patch fixes this problem. Index: Completion/Unix/Command/_xmlsoft === RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_xmlsoft,v retrieving revision 1.7 diff -u -r1.7 _xmlsoft --- Completion/Unix/Command/_xmlsoft21 Oct 2005 14:45:01 - 1.7 +++ Completion/Unix/Command/_xmlsoft30 Jun 2010 12:51:56 - @@ -14,6 +14,7 @@ '--debug[dump the tree of the result instead]' \ '--dumpextensions[dump registered extension elements and functions]' \ '--novalid[skip the DTD loading phase]' \ + '--nodtdattr[do not default attributes from the DTD]' \ '--noout[do not dump the result]' \ '--maxdepth[increase the maximum depth]:depth' \ '--maxparsedepth[increase the maximum parser depth]:depth' \ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587628: ImportError: No module named logging
Package: python2.6-minimal Version: 2.6.5+20100616-1 Severity: grave I have python 2.5.4-9. I think I saw something about logging in changelog.Debian. Can't find that. Setting up python2.6-minimal (2.6.5+20100616-1) ...^M Linking and byte-compiling packages for runtime python2.6...^M Traceback (most recent call last):^M File /usr/bin/pycentral, line 3, in module^M import glob, logging, os, re, string, sys, time, cStringIO^M ImportError: No module named logging^M dpkg: error processing python2.6-minimal (--configure):^M subprocess installed post-installation script returned error exit status 1^M dpkg: dependency problems prevent configuration of python-minimal:^M python-minimal depends on python2.6-minimal (= 2.6.5+20100616-1~); however:^M Package python2.6-minimal is not configured yet.^M dpkg: error processing python-minimal (--configure):^M dependency problems - leaving unconfigured^M Errors were encountered while processing:^M python2.6-minimal^M python-minimal^M _ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969
