Bug#725022: confirmed in Debian wheezy
Control: reopen -1 Reopening the bug since it seems to affect other people. Le vendredi 27 décembre 2013 à 12:10 +0100, Ralf Paaschen a écrit : How to reproduce the bug: - start gnucash in an clean user account - Tools - Online Banking Setup... ; button forward ; button Start AqBanking Wizard ; button Create user - CRASH I have followed these steps on a Wheezy machine and I do not get a crash. Something must be specific to your setup, and at this stage I still do not know what. In order to move forward, I need more debugging information. Can you please provide a gdb backtrace of the crash (after having installed the gnucash-dbg and libaqbanking34-dbg) ? Can you please also attach a tracefile? (obtained by running gnucash --debug; the file will be created under /tmp/gnucash.trace). Thanks, -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Bug#733454: more info
The installation could be done with Rls 7 CD when the boot command was : boot: install vga=normal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733480: bash 4.3~rc1-1 gcc-4.8 compiler very slow
Package:bash Version: 4.3~rc1-1 (experimental) Severity: important After upgrading bash 4.2+dfsg-1 (unstable) to version 4.3~rc1-1 (experimental) compiling with gcc-4.8 (4.8.2-10) has become very slow. For example: using bash/4.2, make xf86-input-evdev takes 5 seconds, using bash/4.3~rc1 the same compilation takes about 60 seconds! Both compilations started after make distclear and autogen in konsole (4:4.11.3-1). Reverting to bash version 4.2 fixes this issue. --- System Information: Debian Release: jessie/sid Architecture: amd64 (x86_64) Kernel: linux-image-3.12-6-amd64 Libc6: 2.18-0 experimental -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart and upgrading from sysvinit scripts
On Sat, Dec 28, 2013 at 10:31:32PM -0800, Russ Allbery wrote: Uoti Urpala uoti.urp...@pp1.inet.fi writes: Adding the mentioned Requires=lbcd.socket line should ensure that the service is never started without the socket running. I'm quite sure that daemons intended to run under systemd should have no need to implement any socket-opening code themselves (unless they do something special like opening a socket in the middle of operation); anything which would contradict that should be a misunderstanding or a bug. Oh, good point, yes. That's pretty clear from daemon(7), now that you mention it in that light. Okay, I'll take this approach in the next upload, after I get a chance to do some more experimentation with what that does with start and stop (probably tomorrow). Thank you for the review. This was really helpful. However, I think this gets to the heart of why upstart upstream has avoided ever recommending the use of socket-based activation. There are some fairly fundamental problems that basically halted development of socket-based activation in upstart (beyond merging of Scott's original implementation, which is rudimentary, as has been noted), and a look at systemd usage on Fedora led me to believe that systemd had not overcome these problems at all. If I'm not mistaken (no references to hand - sorry), systemd upstream has claimed in the course of discussions on debian-devel that lazy activation is not the purpose of socket-based activation, and that using socket-based activation does not require you to pay the service startup penalty at the time of first connection. However, this is not borne out by my experiments with systemd on Fedora (which I would presume to be the go-to source for best practices of systemd service activation). On Fedora 20, after enabling the sshd and rsync service+socket units (both installed but disabled by default on Fedora per their policies on running services out-of-the-box) and rebooting, I find that both port 22 and port 873 are bound by pid 1. Only upon connecting to the socket does systemd actually spawn the server (in the case of sshd, it spawns it as 'sshd -i', so has to start up the server anew on each connection; in the case of rsyncd, the .service definition is completely incompatible with socket-based activation and any attempt to connect results in the rsyncd.socket unit landing in a 'failed' state). If what one is trying to accomplish here is to provide a replacement for inetd, then this is perfectly sufficient. But if one is trying to use socket-based activation for the claimed purpose of ensuring service startup ordering without the need to declare explicit dependencies, then you must accept the penalty of lazy activation - which is almost never acceptable in a server context (where the purpose of the machine is to run the services that you have configured, and they should therefore not be started lazily), and suboptimal even in a client context (since not starting services that are on the critical path for boot until the client requests them will potentially lead to a significant boot-time slowdown, if all the services are doing this). As far as I've been able to tell, the only solutions that would allow non-lazy socket-based-activation of services in systemd all introduce significant boot-time races, whereby it is no longer assured that systemd will bind to the socket (and passing the socket information via the environemnt) before starting the service. Indeed, when I looked at this problem on an earlier version of Fedora, I found what I believe to be a latent security problem in the cups units, because it was nondeterministic whether the service would start with sockets passed from systemd, or a different set of sockets as defined in the cups config! When I mentioned this to Lennart at DebConf this year, his response was that cups was special. Well, after further investigation, I don't think it's true that cups is special. I think systemd socket-based activation is snake oil, that does not do what was promised without introducing hidden trade-offs which no one has been forced to acknowledge because too few developers are making use of this feature today to expose the integration problems. Of course, it's entirely possible that I've misunderstood something here, so I welcome your investigations with lbcd. I'm very interested to see if your understanding of systemd socket-based activation best practices matches my own, and to have an opportunity to experiment with socket-based activation in the more relevant environment of Debian unstable rather than Fedora. FWIW, if indeed socket-based activation in systemd can't actually be used for anything besides a glorified inetd, I think that has implications for the discussion about daemon readiness protocols. The argument for systemd seems to be use sd_notify, or if you don't like having a library dependency then just use socket-based activation which is better anyway. But
Bug#727708: upstart and upgrading from sysvinit scripts
On Sat, Dec 28, 2013 at 05:24:57PM -0800, Russ Allbery wrote: I'll have more to say about the relative merits of the two init systems later, but one thing I wanted to not briefly: this exercise was extremely valuable in helping me get a more realistic picture of both init systems. I had gone into this exercise with the vague impression that they were roughly at feature parity, and now realize that is not the case. My impression now is that systemd's init and service management component is a substantially more mature piece of software. That's an odd thing to say given that upstart is older, but systemd has the feel of software that's been tested against a wide variety of different situations and has had the necessary adaptations and configuration added to meet those needs. In some cases, that's simply additional features; in some cases, that's more comprehensive and more scalable design. The socket activation system in particular is night and day between the two systems. So to respond specifically to this point about the night and day difference between the socket-based activation systems: yes, upstart upstream has not invested in fleshing out its socket-based activation support, because earlier investigations led us to believe that socket-based activation is a red herring that will never deliver the promised benefits. The feature was made available for those who might prefer to start their services without the need for writing socket-handling code; but in my estimation, the flaws wrt system startup (which as far as I can see also affect the systemd implementation) make it altogether unsuitable for any services you're expecting to have started at boot, and we have deliberately avoided its use in Ubuntu. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#733452: init system daemon readiness protocol
]] Ian Jackson I conclude therefore that we should design another simple protocol - preferably, a variation on one of the existing ones - and have (at least) both Debian's systemd and Debian's upstart implement it. I think you're into ever-multiplying power socket standards territory here. I am not going to carry patches in systemd in Debian for a Debian-only notification protocol because you don't want to use the upstream protocol. As I've said in other messages, feel free to talk to upstream, but I'm not going to pass on suggestions which I'm not going to support. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system other points, and conclusion
Hi, On Sat, 28 Dec 2013, Ian Jackson wrote: It does, however, have a number of missing features. Those I have in mind are: - ability to log daemon output to syslog - multiple socket activation (systemd socket activation protocol) - socket activation for IPv6 (and datagram sockets) Of these Russ rightly points out that lack of IPv6 support is rather poor; it is arguably not suitable for release in jessie without this. However, crucially, these are all simple matters of programming, without difficult design decisions. They IMO don't reveal structural problems with upstart's approach to things. This is pretty much in opposition with the way that the tech-ctte has approached problems in the past. In used to only decide based on existing code that was ready to be deployed. This is troublesome because, in my eyes, you now look very much like the systemd fanboys that you criticize, except that you are in the upstart camp. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart and upgrading from sysvinit scripts
On Sat, Dec 28, 2013 at 04:45:38PM -0800, Russ Allbery wrote:
After some more experimentation (the documentation doesn't say clearly
whether pre-start can expose environment variables to exec or not), it
looks like a better approach is:
expect stop
pre-start script
test -x /usr/sbin/lbcd || { stop; exit 0; }
if [ -f /etc/default/lbcd ] ; then
. /etc/default/lbcd
fi
end script
# To change the default lbcd service, specify a command to run for the
# weight and interval, or do round-robin (-R), set the desired flags
# in DAEMON_OPTS in /etc/default/lbcd.
exec /usr/sbin/lbcd -f -l -Z $DAEMON_OPTS
This seems to work and is what I will be uploading.
Hmm, It seems to not be what you uploaded in practice... which stands to
reason, since in fact no, the pre-start script cannot export environment
variables to the main process (for standard unixy reasons - upstart doesn't
do anything magical here to try to tie the process environments together, so
when the pre-start script exits, its environment goes with it. This could
be documented better). I guess you figured this out after having written
this mail?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Bug#732039: installation-reports: success on Lenovo Thinkpad X201 using Jessie current ISO copies to USB stick
On 29.12.2013 04:20, Buck Huppmann wrote: Agreed; i was mostly just dutifully filing a success report, not looking for any sort of resolution, since my system is working fine It's good to know, that it sometimes even works. ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733349: ITP: kbdlight -- simple application that changes MacBooks' keyboard backlight level
Guus Sliepen g...@debian.org wrote: First of all, this application is so simple, it can easily be written as a architecture independent shell script. Furthermore, the package name is very generic, it would be nice if it worked for other brands of laptops as well. My Samsung for example has the same interface to change the backlight, except the sysfs file is called /sys/class/leds/samsung::kbd_backlight instead of smc::kbd_backlight. And I think the FTP masters will ask you if it wouldn't be possible to have the functionality merged with an existing Debian package that has to do with backlight or ACPI. This is true. And actually someone else did it also as a shell script, with a similar name as well: https://github.com/mkouhei/scripts/blob/master/kbdlight.sh However, the point is that somebody put effort on doing this is a small C application and somebody thought it was also useful. I don't see why it should not be included in Debian, maybe it'll be useful for even more people. signature.asc Description: Digital signature
Bug#727708: systemd and upstart, a view from a daemon Debian maintainer
On Sat, Dec 28, 2013 at 03:56:49PM -0800, Russ Allbery wrote: Also, the approach to the systemd integration introduces a new runtime package dependency on init-system-helpers, which despite its generic-sounding name actually contains only helpers for systemd and is maintained in Debian by the systemd maintainers. The maintainers of the package have openly offered any other useful helpers for any other init systems a home in that package. I think it's more due to an accident of history and existing usage that the bit of necessary supporting glue for upstart ended up in lsb-base instead of init-system-helpers. I acknowledge the maintainers' offer in the spirit it was intended, but I see no reason at all that upstart needs to add any glue code to the init-system-helpers package. The only outstanding integrations we would want to make are to have upstart automatically divert init scripts without the need for maintainers to edit each init script individually; and that's a change that should be made in the upstart package itself, not in a generic helper package. I also think that the extensive maintainer script changes required for any upstart-using package are quite deplorable (whether or not they're wrapped in a helper script + debhelper snippet). I understand the reasons why a trigger is unsuitable given that the systemd package may not be installed, but I am of the firm opinion (having had it beaten into me by years of dealing with the resulting bugs) that the best maintainer script is the non-existent one, and I think this added maintainer script complexity is a move in the wrong direction. If Debian adopts systemd as the default, I would hope to see these maintainer script snippets disappear in favor of a trigger, or rolled into the update-rc.d script which is already being called. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#733481: RM: fim -- RoQA; unmaintained, buggy
Package: ftp.debian.org Severity: normal Hi, please remove fim. I've sponsored the uploads in the past, but the maintainer seems MIA (no followups and bugs) and the package has already been dropped from testing for a while. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733482: ELinks not built with lua support
Package: elinks Version: 0.12~pre6-4 The patch 09-Switch-to-use-lua-5.1.diff only updates configure.in, but doesn't update or rebuild the configure script. This means that lua5.1 is not detected by the configure script and elinks is therefore built without lua support. Also compare the lua configuration sections in http://sources.debian.net/src/elinks/0.12~pre6-4/configure.in#L818 http://sources.debian.net/src/elinks/0.12~pre6-4/configure#L18802 which shows that these files are out of sync. Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart and upgrading from sysvinit scripts
Le dimanche 29 décembre 2013 à 01:10 -0800, Steve Langasek a écrit : If I'm not mistaken (no references to hand - sorry), systemd upstream has claimed in the course of discussions on debian-devel that lazy activation is not the purpose of socket-based activation, and that using socket-based activation does not require you to pay the service startup penalty at the time of first connection. However, this is not borne out by my experiments with systemd on Fedora (which I would presume to be the go-to source for best practices of systemd service activation). On Fedora 20, after enabling the sshd and rsync service+socket units (both installed but disabled by default on Fedora per their policies on running services out-of-the-box) and rebooting, I find that both port 22 and port 873 are bound by pid 1. Only upon connecting to the socket does systemd actually spawn the server (in the case of sshd, it spawns it as 'sshd -i', so has to start up the server anew on each connection; in the case of rsyncd, the .service definition is completely incompatible with socket-based activation and any attempt to connect results in the rsyncd.socket unit landing in a 'failed' state). I’m not sure you can conclude that socket activation is broken from such investigations. It looks to me that: * Fedora deliberately used an inetd-like sshd setup, which is more suitable for a workstation to which you don’t ssh much, but not for a production server. * You found a bug in Fedora’s rsyncd unit files. If you don’t want lazy activation, you just need to add a WantedBy=multi-user.target. This way, sockets will be bound by systemd at the earliest possible time, and passed to the daemon as it is started, but it will be started regardless of an incoming connection. This is described in more detailed in the “systemd for administrators” series: http://0pointer.de/blog/projects/socket-activation2.html -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733483: kterm: please remove the dependency on libxp6
Source: kterm Version: 6.2.0-46 Hi maintainer Your package has a dependency on libxp6, but only for the i386 architecture. It seems that the package links libxp6 when libxp-dev is installed, which is why the dependency is present in your uploaded package but not in the buildd's packages. I believe that a binNMU will solve the problem for kterm, but the cause of the problem lies in templates from the xutils-dev package, see bug #731441 [1]. Regards Graham [1] http://bugs.debian.org/731441 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733484: Perl module RefDB::SRUserver is required for some scripts
Package: refdb Version: 1.0.0~pre2-3 Still an issue with SRUserver: checking for Perl module Text::Iconv... Text::Iconv checking for Perl module RefDB::Makestyle... RefDB::Makestyle checking for Perl module RefDB::Prefs... RefDB::Prefs checking for Perl module RefDB::SRU... RefDB::SRU configure: WARNING: Perl module RefDB::SRUserver is required for some scripts checking for Perl module RefDB::SRUserver... checking for Perl module XML::Parser... XML::Parser checking for Perl module MARC::Record... MARC::Record checking for Perl module MARC::Charset... MARC::Charset ref: https://buildd.debian.org/status/fetch.php?pkg=refdbarch=i386ver=1.0.0~pre2-3stamp=1388246865 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689055: luarocks: Please add support for parallel 5.1 5.2 trees
Package: luarocks Version: 2.0.9-1 Followup-For: Bug #689055 Dear Maintainer, I'm interested in seeing this existing issue fixed, or reassigned to a more urgent status. I'm willing to help out if time is thin, so please let me know. Naturally I prefer to install as much software as possible from the Debian repos, and as I develop against Lua5.2 I consider this a blocker for using luarocks on Debian. * What led up to the situation? Installing luarocks from within Synaptic forces installation of liblua5.1-dev, lua5.1. * What exactly did you do (or not do) that was effective (or ineffective)? Nothing. The package's DEBIAN/control file specifies the following: 'Depends: liblua5.1-dev, lua5.1 ...Therefore the only solution (for me) to this problem is to buildand install luarocks from the upstream source. * What was the outcome of this action? -Installation of lua5.1 and liblua5.1-dev is forced on a system with a sane lua5.2 development environment. -Calling require 'luarocks.loader' from within a Lua5.2 interpreter fails. -Calling require 'luarocks.loader' from within a Lua5.1 interpreter succeeds. * What outcome did you expect instead? I expect luarocks to work with both major versions of Lua. Since Lua5.2 is different enough from Lua 5.1 in language features, falling back to Lua 5.1 is not feasible. Best Luke -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages luarocks depends on: ii liblua5.1-0-dev [liblua5.1-dev] 5.1.5-5 ii lua5.1 5.1.5-5 ii wget 1.14-5 ii zip 3.0-8 luarocks recommends no packages. luarocks 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#733485: RM: python-drizzle -- ROM; dead upstream; no reverse deps
Package: ftp.debian.org Severity: normal Hallo, on behalf of the former maintainer, Monty Taylor I request removal of python-drizzle. I orphaned python-drizzle (#724231) a while ago, and as there was no response I think it is time to remove it finally. Thanks, -- coldtobi For reference, here is the original mail: On 09/20/2013 02:16 PM, Tobias Frost wrote: Dear Monty Taylor, How are you? I hope that you are fine. All is quite well, thanks! I was wondering about your packages python-drizzle and plywood, which has a few important bugs pending and only being NMUed the last two years. Also your other packages did not receive an upload the past years. Please let me know if you are still active, because your packages are missing you. Please tell me a little bit about your plans regarding your packages, what you are going to do and when you think you are going to do so. I have, in fact, lost interest in these packages. I was packaging them because I was also upstream for them - and then I stopped working on them as an upstream, so I stopped working on them as a packager too. If you aren't interested in your packages anymore, just tell us as well and we'll try to find new maintainers. In case your packages are co-maintained, you may have lost interest in them so you (or we) can ask not to be mentioned in maintainer fields. Yes please - I think a new maintainer would be great. That said - both are essentially abandoned upstream, so it might be worthwhile looking to see if it makes sense for them to remain in debian at all. Thank you for all your contributions and regards, Thank you! Monty -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733486: RM: plywood -- ROM; dead upstream, no reverse deps
Package: ftp.debian.org Severity: normal Hallo, on behalf of the former maintainer, Monty Taylor I request removal of plywood I orphaned plywood (#724269) a while ago, and as there was no response I think it is time to remove it finally. Thanks, -- coldtobi For reference, here is the original mail: On 09/20/2013 02:16 PM, Tobias Frost wrote: Dear Monty Taylor, How are you? I hope that you are fine. All is quite well, thanks! I was wondering about your packages python-drizzle and plywood, which has a few important bugs pending and only being NMUed the last two years. Also your other packages did not receive an upload the past years. Please let me know if you are still active, because your packages are missing you. Please tell me a little bit about your plans regarding your packages, what you are going to do and when you think you are going to do so. I have, in fact, lost interest in these packages. I was packaging them because I was also upstream for them - and then I stopped working on them as an upstream, so I stopped working on them as a packager too. If you aren't interested in your packages anymore, just tell us as well and we'll try to find new maintainers. In case your packages are co-maintained, you may have lost interest in them so you (or we) can ask not to be mentioned in maintainer fields. Yes please - I think a new maintainer would be great. That said - both are essentially abandoned upstream, so it might be worthwhile looking to see if it makes sense for them to remain in debian at all. Thank you for all your contributions and regards, Thank you! Monty -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733273: Acknowledgement (uscan: Using options causes it to check the status multiple times)
On Sat, Dec 28, 2013 at 10:46:00PM -0500, James McCoy wrote: On Sat, Dec 28, 2013 at 12:36:38AM +0100, Kurt Roeckx wrote: So this might be just my misunderstanding of the watch file syntax and really be the same as #733272 Could you provide the watch file you're using? It said: version=3 ftp://ftp.openssl.org/source/openssl-(\d+\.\d+\.\d+[a-z]?)\.tar\.gz opts=pgpsigurlmangle=s/$/.asc/ ftp://ftp.openssl.org/source/openssl-(\d+\.\d+\.\d+[a-z]?)\.tar\.gz But I've changed it to: version=3 opts=pgpsigurlmangle=s/$/.asc/ ftp://ftp.openssl.org/source/openssl-(\d+\.\d+\.\d+[a-z]?)\.tar\.gz I have to guess that that is the correct way to do it, but as said in #733272 things aren't clear for me. kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724231: O: python-drizzle -- python binding to libdrizzle
Package: wnpp Followup-For: Bug #724231 For your reference, I just requested removal of this package See #724231 -- coldtobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724269: O: plywood -- playwriting typing and typesetting help
Package: wnpp Followup-For: Bug #724269 For reference, I just requested removal of this package. See #733486 -- coldtobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733487: (no subject)
Package: libbonoboui Severity: serious User: alteh...@debian.org Usertags: ftp X-Debbugs-CC: ftpmas...@ftp-master.debian.org thanks Dear Maintainer, according to debian/copyright all files are licensed under LGPL2+. The file samples/bonoboui/hello.c and several files in tools/browser/ are licensed under GPL2+ and are not mentioned in debian/copyright. nitpick mode Most of the language files have a line saying something like This file is distributed under the same license as the libbonoboui package., which is fine. Some files like az.po, bg.po ... don't have such a line. How do you know their license? Maybe this has been discussed before, but I couldn't find anything in the archive. The file bonobo/bonobo-ally.c and .h are copyrighted by Sun Microsystems. Are you sure they publish something under the LGPL? I would rather expect SPL or CDDL ... /nitpick mode Thanks! Thorsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733488: libjna-java: Update the jna library to a current upstream version
Package: libjna-java Version: 3.2.7-4 Severity: important Dear Maintainer, is it possible to update the libjna-java package to a current (or at least newer than 3.4.0) version of the JNA library? Version 3.2.7 has the following bug which makes the package more or less unusable for my code: https://java.net/jira/browse/JNA-185 Thanks in advance! Jonas Wolz -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-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 libjna-java depends on: ii libc62.13-38 ii libffi5 3.0.10-3 libjna-java recommends no packages. Versions of packages libjna-java suggests: pn libjna-java-doc none -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731441: Templates in xutils-dev cause build-depends on libxp-dev
I believe the templates in xutils-dev are also responsible for the libxp6 dependency in kterm, see bug #733483 [1]. Building kterm locally with libxp-dev installed and my patched version of xutils-dev causes the following lines to disappear from kterm's generated Makefile: XPLIBSRC = $(LIBSRC)/Xp SOXPREV = 6.2 DEPXPLIB = XPLIB = -lXp LINTXP = $(LINTLIBDIR)/llib-lXp.ln [1] http://bugs.debian.org/733483 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies
Package: python-apt Version: 0.9.2 Severity: wishlist Tags: patch From 0d295006a98769cd6151c78b3a078ad92d8047ee Mon Sep 17 00:00:00 2001 From: Michael Wisheu mich...@5challer.de Date: Sun, 29 Dec 2013 11:57:19 +0100 Subject: [PATCH] * apt/cache.py: - Fixed PEP8 linter and pyflakes issues - Added 'InstalledFilter' to get a filtered cache that only contains the currently installed packages. * apt/packages.py: - Fixed PEP8 linter issues - Removed special handling of 'collections' import as all supported distributions have Python 2.6 or newer by now. - Replaced faulty 'BaseDependency.__dstr' with easier to read compat code. - Added new properties to 'Dependency' and 'BaseDependency' to get the target package versions that could satisfy a dependency. --- apt/cache.py | 52 ++- apt/package.py | 279 --- debian/changelog | 16 +++- 3 files changed, 268 insertions(+), 79 deletions(-) diff --git a/apt/cache.py b/apt/cache.py index 43fb55d..897c2be 100644 --- a/apt/cache.py +++ b/apt/cache.py @@ -40,6 +40,7 @@ class FetchFailedException(IOError): class LockFailedException(IOError): Exception that is thrown when locking fails. + class CacheClosedException(Exception): Exception that is thrown when the cache is used after close(). @@ -53,7 +54,7 @@ class Cache(object): list of available packages. The cache can be used like a mapping from package names to Package -objects (although only getting items is supported). +objects (although only getting items is supported). Keyword arguments: progress -- a OpProgress object @@ -74,7 +75,7 @@ class Cache(object): self._fullnameset = set() self._changes_count = -1 self._sorted_set = None - + self.connect(cache_post_open, self._inc_changes_count) self.connect(cache_post_change, self._inc_changes_count) if memonly: @@ -86,17 +87,17 @@ class Cache(object): apt_pkg.config.clear(APT) apt_pkg.config.set(Dir, rootdir) apt_pkg.init_config() -if os.path.exists(rootdir+/etc/apt/apt.conf): +if os.path.exists(rootdir + /etc/apt/apt.conf): apt_pkg.read_config_file(apt_pkg.config, rootdir + /etc/apt/apt.conf) -if os.path.isdir(rootdir+/etc/apt/apt.conf.d): +if os.path.isdir(rootdir + /etc/apt/apt.conf.d): apt_pkg.read_config_dir(apt_pkg.config, rootdir + /etc/apt/apt.conf.d) apt_pkg.config.set(Dir::State::status, rootdir + /var/lib/dpkg/status) # also set dpkg to the rootdir path so that its called for the # --print-foreign-architectures call -apt_pkg.config.set(Dir::bin::dpkg, +apt_pkg.config.set(Dir::bin::dpkg, os.path.join(rootdir, usr, bin, dpkg)) # create required dirs/files when run with special rootdir # automatically @@ -105,7 +106,6 @@ class Cache(object): # recognized (LP: #320665) apt_pkg.init_system() self.open(progress) - def _inc_changes_count(self): Increase the number of changes @@ -165,8 +165,8 @@ class Cache(object): i = last = 0 size = len(self._cache.packages) for pkg in self._cache.packages: -if progress is not None and last+100 i: -progress.update(i/float(size)*100) +if progress is not None and last + 100 i: +progress.update(i / float(size) * 100) last = i # drop stuff with no versions (cruft) if pkg.has_versions: @@ -289,16 +289,14 @@ class Cache(object): # now check the result (this is the code from apt-get.cc) failed = False -transient = False err_msg = for item in fetcher.items: if item.status == item.STAT_DONE: continue if item.STAT_IDLE: -transient = True continue err_msg += Failed to fetch %s %s\n % (item.desc_uri, - item.error_text) +item.error_text) failed = True # we raise a exception if the download failed or it was cancelt @@ -349,7 +347,6 @@ class Cache(object): if fetcher is None: fetcher = apt_pkg.Acquire(progress) - return self._fetch_archives(fetcher, apt_pkg.PackageManager(self._depcache)) @@ -362,12 +359,12 @@ class Cache(object): else: return bool(pkg.has_provides and not pkg.has_versions) -def get_providing_packages(self, pkgname, candidate_only=True, +def
Bug#664501: Please enable hardened build flags
On Sun, Mar 18, 2012 at 12:47:57PM +0100, Moritz Muehlenhoff wrote: Package: pmount Version: 0.9.23-2 Severity: important Tags: patch Please enable hardened build flags for your package. Since your package has already been converted to dh, setting debian/compat to 9 is all you need to do. I've tested in a local build that this is sufficient to enable hardened build flags. What's the status? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733471: Bug#733465: debian-goodies: debget can't find systemd-sysv
On 2013-12-29 05:10:33 +0100, Axel Beckert wrote: Actually, I'd consider dropping debget (or at least its implementation) completely in favour of dget which does the same, but * faster (pro), * more reliable (pro), * more featureful (also works with source packages), * is written in Perl instead of /bin/sh (con), and * is part of devscripts (con). Indeed, dget is OK. If you drop debget entirely (as a command name), don't forget to update the other scripts that depend on it, such as debman. Actually I likely would have done that now if dget wouldn't be in devscripts. But devscripts is a rather package-development centric package while debian-goodies is a more admin-centric package. So I'm not sure what's the best way to handle tools for both groups. Perhaps devscripts could be split into a package-development centric package and a more admin-centric package. Some other tools from devscripts are not just used for package development, e.g.: * bts, to update information in bug reports. * rc-alert, to check for some security bugs (needs filtering). * debuild, to rebuild a package (or perhaps its dependencies makes this one too close to package development? I don't know.) -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733490: RM: unicon -- RoQA; orphaned, unused, dead upstream
Package: ftp.debian.org Severity: normal Hi, please remove unicon. It's orphaned for more than a year, dead upstream and popcon is very low. It's also affected by several of the bugs found by the Mayhem project. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653506: Please enable hardened build flags
On Mon, Apr 09, 2012 at 11:54:32AM -0400, Sam Hartman wrote: Moritz == Moritz Mühlenhoff j...@inutil.org writes: Moritz On Thu, Dec 29, 2011 at 01:03:51AM +0100, Moritz Muehlenhoff wrote: Package: barnowl Version: 1.6.2-1.1 Severity: important Tags: patch Please enable hardened build flags for barnowl. dh does inject them automatically, when building in compat level 9: jmm@pisco:~$ hardening-check /usr/bin/barnowl /usr/bin/barnowl: (..) Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Moritz What's the status? Do you plan an upload in the next weeks Moritz or shall I upload a NMU? The issue is that I'm not sure I like the patch. I'm not sure I'm comfortable depending on a new debhelper compatibility level for barnowl. It tends to get backported for a number of environments. You can NMU if you like, although I don't promise not to revert your patch. my recommendation is that you NMU what you proposed as I don't have a lot of time and krb5 (which I maintain) is needing attention and far more important than barnowl. If I revert I'll fix things another way (presumably adding an explicit call to dpkg-buildflags to an override in the debian/rules) Can you reconsider, now that debhelper compat level is available in stable? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733491: g2ipmsg: Can not setup lock file:/tmp/g2ipmsg.lock
Package: g2ipmsg Version: 0.9.6+dfsg-1.1 Severity: important Dear Maintainer, on startup I got the error message: Can not setup lock file:/tmp/g2ipmsg.lock errno : -11 -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/4 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 g2ipmsg depends on: ii gconf2 3.2.6-1 ii libart-2.0-22.3.21-2 ii libatk1.0-0 2.10.0-2 ii libbonobo2-02.32.1-3 ii libbonoboui2-0 2.24.3-1 ii libc6 2.17-97 ii libcairo2 1.12.16-2 ii libfontconfig1 2.11.0-2 ii libfreetype62.5.1-1 ii libgconf2-4 3.2.6-1 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-02.36.4-1 ii libgnome2-0 2.32.1-4 ii libgnomecanvas2-0 2.30.3-1.2 ii libgnomeui-02.24.5-2 ii libgnomevfs2-0 1:2.24.4-4 ii libgstreamer0.10-0 0.10.36-1.2 ii libgtk2.0-0 2.24.22-1 ii libice6 2:1.0.8-2 ii liborbit2 1:2.14.19-0.3 ii libpango1.0-0 1.36.0-1+b1 ii libpopt01.16-8 ii libsm6 2:1.2.1-2 ii libssl1.0.0 1.0.1e-6 ii libxml2 2.9.1+dfsg1-3 g2ipmsg recommends no packages. g2ipmsg 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#733492: /usr/bin/evince-previewer: No search option available
Package: evince Version: 3.10.0-1+b1 Severity: important File: /usr/bin/evince-previewer Hello, evince-previewer is the program registered for opening PDF documents. While evince ha s a search option it is not available in the previewer. Please fix the previewer or register the working PDF viewer. Thanks -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (990, 'stable'), (171, 'unstable'), (151, 'experimental'), (121, 'precise-updates'), (121, 'precise-security'), (121, 'precise'), (101, 'stable'), (101, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages evince depends on: ii evince-common 3.10.0-1 ii gnome-icon-theme-symbolic 3.10.1-1 ii libatk1.0-02.10.0-2 ii libc6 2.17-97 ii libcairo-gobject2 1.12.16-2 ii libcairo2 1.12.16-2 ii libevdocument3-4 3.10.0-1+b1 ii libevview3-3 3.10.0-1+b1 ii libgail-3-03.8.6-1 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-0 2.38.2-1 ii libgtk-3-0 3.8.6-1 ii libice62:1.0.8-2 ii libnautilus-extension1a3.4.2-1+build1 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-01.36.0-1+b1 ii libsecret-1-0 0.15-2 ii libsm6 2:1.2.1-2 ii libx11-6 2:1.5.0-1+deb7u1 ii libxml22.8.0+dfsg1-7+nmu2 ii shared-mime-info 1.0-1+b1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages evince recommends: ii dbus-x11 1.6.8-1+deb7u1 ii gvfs 1.12.3-4 Versions of packages evince suggests: ii nautilus 3.8.2-2 ii poppler-data 0.4.5-10 ii unrar 1:4.1.4-1 -- 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#733493: evince menus have no names and cannot be activated by keyboard
Package: evince Version: 3.10.0-1+b1 Severity: important Hello, the menus in evince are no longer intelligible. There is some 'spiky wheel' menu, 'wrench wrapped in paper' menu, 'looking glass' menu, and a completely hidden menu which pops up when you click the zoom factor. There is no way to describe which menu you activated since they are unnamed. The icons can change with icon theme, presumably. There is no way to activate them with keyboard, either. Given there is no name the looking glass could be search? zoom? The other two both look like something you would assign to settings - two settings menus? Please dump this abomination and re-import the standard menubar. It's fine if it contains the icons *in addition* to the menu text but the icons alone are quite useless. Thanks Michal -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (990, 'stable'), (171, 'unstable'), (151, 'experimental'), (121, 'precise-updates'), (121, 'precise-security'), (121, 'precise'), (101, 'stable'), (101, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages evince depends on: ii evince-common 3.10.0-1 ii gnome-icon-theme-symbolic 3.10.1-1 ii libatk1.0-02.10.0-2 ii libc6 2.17-97 ii libcairo-gobject2 1.12.16-2 ii libcairo2 1.12.16-2 ii libevdocument3-4 3.10.0-1+b1 ii libevview3-3 3.10.0-1+b1 ii libgail-3-03.8.6-1 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-0 2.38.2-1 ii libgtk-3-0 3.8.6-1 ii libice62:1.0.8-2 ii libnautilus-extension1a3.4.2-1+build1 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-01.36.0-1+b1 ii libsecret-1-0 0.15-2 ii libsm6 2:1.2.1-2 ii libx11-6 2:1.5.0-1+deb7u1 ii libxml22.8.0+dfsg1-7+nmu2 ii shared-mime-info 1.0-1+b1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages evince recommends: ii dbus-x11 1.6.8-1+deb7u1 ii gvfs 1.12.3-4 Versions of packages evince suggests: ii nautilus 3.8.2-2 ii poppler-data 0.4.5-10 ii unrar 1:4.1.4-1 -- 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#733494: OptParse exception during [dist-]upgrade
Package: apt-cudf Version: 3.1.3-7 Severity: normal Dear maintainer, I have used apt-cudf happily for a while now, but recently it started to show the following behaviour: $ sudo apt-get --solver aspcud dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Fatal error: exception OptParse.Opt.No_value Execute external solver... Done Done Fatal error: exception OptParse.Opt.No_value Execute external solver... Done The following packages have been kept back: aspcud automake cups-filters e2fslibs e2fsprogs fonts-inconsolata gringo icedtea-6-jre-cacao icedtea-6-jre-jamvm libcomerr2 libcomerr2:i386 libestr0 libfontconfig1 libfontconfig1:i386 libfontconfig1-dev libfreetype6-dev libpodofo0.9.0 librdf0 libss2 openjdk-6-jdk openjdk-6-jre openjdk-6-jre-headless openjdk-6-jre-lib 0 upgraded, 0 newly installed, 0 to remove and 23 not upgraded. In particular the OptParse.Opt.No_value exception seems to be problematic and also seem to prevent aspcud from calculating a proper solution. I include some additional information as the problem might be related to this: $ cat /etc/apt/preferences Explanation: Pinned by apt-listbugs at 2013-12-08 10:44:04 + Explanation: #730361: fontconfig-config: unowned files after purge (policy 6.8, 10.8): /etc/fonts/conf.d/70-no-bitmaps.conf - /usr/share/fontconfig/conf.avail/70-no-bitmaps.conf Package: fontconfig-config Pin: version 2.11.0-1 Pin-Priority: 1000 Explanation: Pinned by apt-listbugs at 2013-12-08 10:44:04 + Explanation: #711343: PILCompat is broken Package: python-imaging Pin: version 1.1.7-4 Pin-Priority: 1000 Explanation: Pinned by apt-listbugs at 2013-12-08 10:44:04 + Explanation: #730742: Font rendering fuzzy (straight lines smeared across subpixels) since upgrade to 2.5.1 Package: libfreetype6:i386 Pin: version 2.4.9-1.1 Pin-Priority: 1000 Explanation: Pinned by apt-listbugs at 2013-12-08 10:44:04 + Explanation: #730742: Font rendering fuzzy (straight lines smeared across subpixels) since upgrade to 2.5.1 Package: libfreetype6 Pin: version 2.4.9-1.1 Pin-Priority: 1000 Explanation: Pinned by apt-listbugs at 2013-12-08 10:44:04 + Explanation: #730599: makeinfo -D 'var value' doesn't work Package: texinfo Pin: version 5.2.0.dfsg.1-1 Pin-Priority: 1000 Explanation: Pinned by apt-listbugs at 2013-12-08 10:44:04 + Explanation: #728440: python-pil has circular Depends on python-pil.imagetk Package: python-pil Pin: version * Pin-Priority: -3 Explanation: Pinned by apt-listbugs at 2013-12-08 10:44:04 + Explanation: #731040: python-nose fails to install on sid Package: python-nose Pin: version 1.3.0-2 Pin-Priority: 1000 $ aptitude search ~U -F'%v%p' 2012.10.24-5 aspcud 1:1.14.1-1automake 1.0.34-3+b1 cups-filters 1.42.8-1 e2fslibs 1.42.8-1 e2fsprogs 001.010-4 fonts-inconsolata 4.2.1-2 gringo 6b27-1.12.7-2 icedtea-6-jre-cacao 6b27-1.12.7-2 icedtea-6-jre-jamvm 1.42.8-1 libcomerr2 1.42.8-1 libcomerr2:i386 0.1.5-2 libestr0 2.11.0-1 libfontconfig1 2.11.0-1 libfontconfig1:i386 2.11.0-1 libfontconfig1-dev 2.4.9-1.1 libfreetype6-dev 0.9.0-1.1+b1 libpodofo0.9.0 1.0.16-3 librdf0 1.42.8-1 libss2 6b27-1.12.7-2 openjdk-6-jdk 6b27-1.12.7-2 openjdk-6-jre 6b27-1.12.7-2 openjdk-6-jre-headless 6b27-1.12.7-2 openjdk-6-jre-lib Please let me know if you require additional information or how I can debug this problem further. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf-8, LC_CTYPE=en_GB.utf-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apt-cudf depends on: ii aspcud [cudf-solver] 2012.10.24-5 ii libbz2-1.01.0.6-5 ii libc6 2.17-97 ii libpcre3 1:8.31-2 ii perl 5.18.1-5 ii zlib1g1:1.2.8.dfsg-1 apt-cudf recommends no packages. apt-cudf 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#705859: blueman: diff for NMU version 1.23+update1-2.1
tag 705859 + patch pending tag 719747 + patch pending thanks Dear maintainer, I've prepared an NMU for blueman (versioned as 1.23+update1-2.1) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. Regards. diff -Nru blueman-1.23+update1/debian/changelog blueman-1.23+update1/debian/changelog --- blueman-1.23+update1/debian/changelog 2013-07-27 00:08:52.0 +0200 +++ blueman-1.23+update1/debian/changelog 2013-12-29 12:35:53.0 +0100 @@ -1,3 +1,11 @@ +blueman (1.23+update1-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Include missing icons from upstream. +Closes: #705859, #719747 + + -- Evgeni Golov evg...@debian.org Sun, 29 Dec 2013 12:35:48 +0100 + blueman (1.23+update1-2) unstable; urgency=low * Add libpulse-mainloop-glib0 to dependencies (Closes: #706121) diff -Nru blueman-1.23+update1/debian/patches/missing_icons blueman-1.23+update1/debian/patches/missing_icons --- blueman-1.23+update1/debian/patches/missing_icons 1970-01-01 01:00:00.0 +0100 +++ blueman-1.23+update1/debian/patches/missing_icons 2013-12-29 10:54:41.0 +0100 @@ -0,0 +1,565 @@ +From 9863fb99aa384e42b8349d505af77c071f8cb6e6 Mon Sep 17 00:00:00 2001 +From: Christopher Schramm cschr...@shakaweb.org +Date: Sun, 13 Oct 2013 10:01:32 +0200 +Subject: [PATCH] Add missing icons (fixes #2) + +--- + data/icons/hicolor/scalable/status/Makefile.am | 2 +- + .../scalable/status/blueman-tray-disabled.svg | 291 + + .../icons/hicolor/scalable/status/blueman-tray.svg | 234 + + 3 files changed, 526 insertions(+), 1 deletion(-) + create mode 100644 data/icons/hicolor/scalable/status/blueman-tray-disabled.svg + create mode 100644 data/icons/hicolor/scalable/status/blueman-tray.svg + +diff --git a/data/icons/hicolor/scalable/status/Makefile.am b/data/icons/hicolor/scalable/status/Makefile.am +index f0ddd52..2082dfc 100644 +--- a/data/icons/hicolor/scalable/status/Makefile.am b/data/icons/hicolor/scalable/status/Makefile.am +@@ -4,6 +4,6 @@ context = status + + iconsdir = $(themedir)/$(size)/$(context) + +-icons_DATA = blueman-tray-active.svg ++icons_DATA = blueman-tray-active.svg blueman-tray-disabled.svg blueman-tray.svg + + EXTRA_DIST = $(icons_DATA) +diff --git a/data/icons/hicolor/scalable/status/blueman-tray-disabled.svg b/data/icons/hicolor/scalable/status/blueman-tray-disabled.svg +new file mode 100644 +index 000..8ee5fe0 +--- /dev/null b/data/icons/hicolor/scalable/status/blueman-tray-disabled.svg +@@ -0,0 +1,291 @@ ++?xml version=1.0 encoding=UTF-8 standalone=no? ++!-- Created with Inkscape (http://www.inkscape.org/) -- ++ ++svg ++ xmlns:dc=http://purl.org/dc/elements/1.1/; ++ xmlns:cc=http://creativecommons.org/ns#; ++ xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; ++ xmlns:svg=http://www.w3.org/2000/svg; ++ xmlns=http://www.w3.org/2000/svg; ++ xmlns:xlink=http://www.w3.org/1999/xlink; ++ xmlns:sodipodi=http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd; ++ xmlns:inkscape=http://www.inkscape.org/namespaces/inkscape; ++ width=48 ++ height=48 ++ id=svg2160 ++ sodipodi:version=0.32 ++ inkscape:version=0.48.4 r9939 ++ version=1.0 ++ sodipodi:docname=blueman-tray-disabled.svg ++ inkscape:output_extension=org.inkscape.output.svg.inkscape ++ inkscape:export-filename=/home/andreas/Desktop/bluetooth/bluetooth-applet-16.png ++ inkscape:export-xdpi=90 ++ inkscape:export-ydpi=90 ++ defs ++ id=defs2162 ++linearGradient ++ inkscape:collect=always ++ id=linearGradient3393 ++ stop ++ style=stop-color:#729fcf;stop-opacity:1; ++ offset=0 ++ id=stop3395 / ++ stop ++ style=stop-color:#729fcf;stop-opacity:0; ++ offset=1 ++ id=stop3397 / ++/linearGradient ++linearGradient ++ inkscape:collect=always ++ id=linearGradient3383 ++ stop ++ style=stop-color:#729fcf;stop-opacity:1 ++ offset=0 ++ id=stop3385 / ++ stop ++ style=stop-color:#3465a4;stop-opacity:1 ++ offset=1 ++ id=stop3387 / ++/linearGradient ++linearGradient ++ id=linearGradient4140 ++ inkscape:collect=always ++ stop ++ id=stop4142 ++ offset=0 ++ style=stop-color:#ff;stop-opacity:1 / ++ stop ++ id=stop4144 ++ offset=1 ++ style=stop-color:#ff;stop-opacity:0 / ++/linearGradient ++linearGradient ++ id=linearGradient8692 ++ inkscape:collect=always ++ stop ++ id=stop8694 ++ offset=0 ++ style=stop-color:#00;stop-opacity:1; / ++ stop ++ id=stop8696 ++ offset=1 ++ style=stop-color:#00;stop-opacity:0; / ++/linearGradient ++filter ++ inkscape:collect=always ++ id=filter3274 ++ feGaussianBlur ++ inkscape:collect=always ++ stdDeviation=0.511583 ++
Bug#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies
Hi everyone, This is a feature request bug to improve the 'apt.package.Dependency' and 'apt.package.BaseDependency' classes in 'python-apt'. The current implementation of both classes is rather scarce and so I've refactored them to to include better properties. Most notably the information from 'apt_pkg.Dependency.all_targets()' is now available as a property on both classes. While I was at it I've fixed PEP8 and pyflakes issues, fixed bugs and got rid of obsolete code. Please review the patch carefully and let me know what you think. Best, Michael Schaller
Bug#732709: itk / tiff 5
Control: tags -1 patch I have prepared a patch at: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/insighttoolkit/branches/3.20.1/debian/patches/tiff5.patch?view=markup As mentionned above this is a (partial) import from upstream git commit: 563abcab25aeff7099de0712a8735c58d14602fb I would appreciate if someone would double check this patch (1). Or the other solution (2) is to use the embedded TIFF lib. Since ITK 3.x is pretty much a branch dead-upstream, I think this would be easier to have a lintian overrides... Steve, what would you go with (1) or (2) ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733238: xserver-xorg-input-evdev: ioctl EVIOCGBIT for bitmask in EvdevOpenMTDev failed: Inappropriate ioctl for device
On Sat, Dec 28, 2013 at 08:32:32PM +0100, Julien Cristau wrote:
On Fri, Dec 27, 2013 at 16:22:21 +, ael wrote:
Package: xserver-xorg-input-evdev
Version: 1:2.8.2-1
Severity: normal
From Xorg.0.log:
(EE) evdev: PS2++ Logitech TrackMan: ioctl EVIOCGBIT for bitmask in
EvdevOpenMTDev failed: Inappropriate ioctl for device
[ 1052.675] (EE) PS2++ Logitech TrackMan: Couldn't open mtdev device
The trackball is not multi-touch. I have a custom rule for these devices
under /etc/udev/rules.d/ which perhaps is no longer used?
# Logitech Marble Mice PN 804377-, PN 810-000767 or
# PN 804251- connected via USB or PS/2
# Marble FX or Marble Mouse (ael)
ACTION!=add|change, GOTO=xorg_marble_end
KERNEL!=event*, GOTO=xorg_marble_end
#ENV{ID_PATH}!=platform-i8042-serio-1, GOTO=xorg_marble_end
# Above for PS/2, misses USB. name below seems to be enough
ATTRS{name}==ImExPS/2 Logitech Explorer Mouse, GOTO=marbles
ATTRS{name}==Logitech USB Trackball, GOTO=marbles
ATTRS{name}==PS2++ Logitech Mouse, GOTO=marble_FX
ATTRS{name}==PS2++ Logitech TrackMan , GOTO=marble_FX
GOTO=xorg_marble_end
LABEL=marbles
ENV{x11_options.ButtonMapping}=1 9 3 4 5 6 7 8 2
LABEL=marble_FX
#ENV{x11_options.Protocol}=ExplorerPS/2
ENV{x11_options.EmulateWheel}=true
ENV{x11_options.EmulateWheelButton}=8
ENV{x11_options.YAxisMapping}=4 5
ENV{x11_options.XAxisMapping}=6 7
ENV{x11_options.ZAxisMapping}=4 5
#ENV{x11_options.Emulate3Buttons}=0
I don't think the above (X options in udev rules) can ever have worked.
They did for a while, but I suspect a long time ago.
But now I have the equivalent in xorg.conf as in the original bug
report. This has been working for several years, but after a recent
upgrade, is now failing with the EVIOCGBIT. Any help with that?
I guess that I should remove the udev rule just in case: I think that I
had just forgotten about it. I will remove that rule and report back
just in case it was somehow triggering the problem.
Thanks for the reply and any further help,
ael
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719382: node-stringprep: FTBFS: /bin/sh: 1: node-waf: not found
Package: node-stringprep Version: 0.1.5-1 Followup-For: Bug #719382 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu trusty ubuntu-patch In Ubuntu, the attached patch was applied to achieve the following: * Switch from node-waf to node-gyp to fix FTBFS (Closes: #719382) I'm not a particularly node-friendly person, and have no ideal how to test this, but this naive patch seems to end up building and installing the right files, at any rate. ... Adam -- System Information: Debian Release: wheezy/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (500, 'saucy-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-0-generic (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Nru node-stringprep-0.1.5/debian/changelog node-stringprep-0.1.5/debian/changelog diff -Nru node-stringprep-0.1.5/debian/control node-stringprep-0.1.5/debian/control --- node-stringprep-0.1.5/debian/control 2013-03-05 16:56:44.0 -0700 +++ node-stringprep-0.1.5/debian/control 2013-12-29 04:55:42.0 -0700 @@ -7,6 +7,7 @@ debhelper, dh-buildinfo, nodejs-dev (= 0.2.6), + node-gyp, libicu-dev Standards-Version: 3.9.4 Homepage: https://github.com/astro/node-stringprep diff -Nru node-stringprep-0.1.5/debian/rules node-stringprep-0.1.5/debian/rules --- node-stringprep-0.1.5/debian/rules 2013-03-05 16:54:22.0 -0700 +++ node-stringprep-0.1.5/debian/rules 2013-12-29 04:51:12.0 -0700 @@ -22,7 +22,7 @@ libpkgname = node-node-stringprep -CDBS_BUILD_DEPENDS += , nodejs-dev (= 0.2.6), libicu-dev +CDBS_BUILD_DEPENDS += , nodejs-dev (= 0.2.6), node-gyp, libicu-dev # suppress optional build-dependencies CDBS_BUILD_DEPENDS_rules_upstream-tarball = @@ -35,13 +35,14 @@ DEB_INSTALL_DOCS_$(libpkgname) += README.markdown configure/$(libpkgname):: - NODE_PATH=$(cdbs_curdestdir)/usr/lib/nodejs node-waf configure + NODE_PATH=$(cdbs_curdestdir)/usr/lib/nodejs node-gyp configure build/$(libpkgname):: - NODE_PATH=$(cdbs_curdestdir)/usr/lib/nodejs node-waf build + NODE_PATH=$(cdbs_curdestdir)/usr/lib/nodejs node-gyp build install/$(libpkgname):: - NODE_PATH=$(cdbs_curdestdir)/usr/lib/nodejs node-waf install + install -m 644 -D build/Release/node-stringprep.node \ + $(cdbs_curdestdir)/usr/lib/nodejs/node-stringprep.node # Node modules have an uncommon extension preventing autodetection by # dh_shlibdeps, so we do it manually
Bug#733495: [INTL:es] Spanish translation of debconf messages
Package: squid-deb-proxy Severity: wishlist Tags: l10n patch Greetings, -- Camaleón # squid-deb-proxy po-debconf translation to Spanish # Copyright (C) 2013 Software in the Public Interest # This file is distributed under the same license as the squid-deb-proxy package. # Changes: # - Initial translation # Camaleón noela...@gmail.com, 2013 # - Updates # Traductores, si no conocen el formato PO, merece la pena leer la # documentación de gettext, especialmente las secciones dedicadas a este # formato, por ejemplo ejecutando: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # Equipo de traducción al español, por favor lean antes de traducir # los siguientes documentos: # - El proyecto de traducción de Debian al español # http://www.debian.org/intl/spanish/ # especialmente las notas y normas de traducción en # http://www.debian.org/intl/spanish/notas # - La guía de traducción de po's de debconf: # /usr/share/doc/po-debconf/README-trans # o http://www.debian.org/intl/l10n/po-debconf/README-trans msgid msgstr Project-Id-Version: squid-deb-proxy 0.8.5\n Report-Msgid-Bugs-To: squid-deb-pr...@packages.debian.org\n POT-Creation-Date: 2011-06-30 12:07+0100\n PO-Revision-Date: 2013-12-14 12:05+0200\n Last-Translator: Camaleón noela...@gmail.com\n Language-Team: Debian Spanish debian-l10n-span...@lists.debian.org\n Language: es\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=2; plural=(n != 1);\n X-Generator: Virtaal 0.7.1\n #. Type: boolean #. Description #: ../squid-deb-proxy.templates:1001 msgid Allow PPA (Personal Package Archive) access? msgstr ¿Desea permitir el acceso a los PPA (Personal Package Archive o «Archivo de Paquetes Personal»)? #. Type: boolean #. Description #: ../squid-deb-proxy.templates:1001 msgid Squid-deb-proxy by default will not allow PPA repositories from launchpad. Selecting Y in this option will activate PPA repo access. msgstr De manera predeterminada, squid-deb-proxy no permite los repositorios PPA de Launchpad. Si selecciona Y («sí») en esta opción se activará el acceso a los repositorios PPA. #. Type: boolean #. Description #: ../squid-deb-proxy.templates:2001 msgid Allow unrestricted network access? msgstr ¿Desea permitir el acceso a la red sin restricciones? #. Type: boolean #. Description #: ../squid-deb-proxy.templates:2001 msgid Squid-deb-proxy restricts access to the cache to private networks only by default. Selecting Y in this option will allow unrestricted access of all IPs to access the cache. Selecting N will only allow private networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to access the cache. msgstr De manera predeterminada, squid-deb-proxy sólo permite acceder al caché a las redes privadas. Si selecciona Y («sí») en esta opción se permitirá el acceso sin restricciones a todas las direcciones IP. Si selecciona N («no») sólo se permitirá el acceso al caché a las redes privadas (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
Bug#733496: Code copy of older Mozilla code
Package: mozjs17 Severity: serious This package forks a local copy of the Iceweasel Javascript engine which is no longer supported with security updates (currently only the ESR24 series is maintained) What's the strategy here? Do you plan to backport/triage all Javascript related security issues from current Mozilla releases to your version? Why do we need a copy of the old version anyway? What are the expected applications using it and why can't they be migrated to the mozjs provided by the iceweasel source package. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705409: RFP: CDemu - program for emulating optical drives
Package: wnpp Followup-For: Bug #705409 I wish to maintain that package -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733497: [INTL:es] Spanish translation of debconf messages
Package: pybit Severity: wishlist Tags: l10n patch Greetings, -- Camaleón # pybit po-debconf translation to Spanish # Copyright (C) 2013 Software in the Public Interest # This file is distributed under the same license as the pybit package. # Changes: # - Initial translation # Camaleón noela...@gmail.com, 2013 # - Updates # Traductores, si no conocen el formato PO, merece la pena leer la # documentación de gettext, especialmente las secciones dedicadas a este # formato, por ejemplo ejecutando: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # Equipo de traducción al español, por favor lean antes de traducir # los siguientes documentos: # - El proyecto de traducción de Debian al español # http://www.debian.org/intl/spanish/ # especialmente las notas y normas de traducción en # http://www.debian.org/intl/spanish/notas # - La guía de traducción de po's de debconf: # /usr/share/doc/po-debconf/README-trans # o http://www.debian.org/intl/l10n/po-debconf/README-trans msgid msgstr Project-Id-Version: pybit 1.0.0-2\n Report-Msgid-Bugs-To: py...@packages.debian.org\n POT-Creation-Date: 2012-12-15 22:13+\n PO-Revision-Date: 2013-12-16 17:35+0200\n Last-Translator: Camaleón noela...@gmail.com\n Language-Team: Debian Spanish debian-l10n-span...@lists.debian.org\n Language: es\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=2; plural=(n != 1);\n X-Generator: Virtaal 0.7.1\n #. Type: string #. Description #: ../pybit-client.templates:1001 msgid PyBit client-ID string: msgstr Cadena del identificador de cliente (client-ID) pyBit: #. Type: string #. Description #: ../pybit-client.templates:1001 msgid Please specify a unique string that can be used to identify this client within the job list and queues. msgstr Indique una cadena de texto única que se pueda usar para identificar este cliente en la lista de trabajos y las colas. #. Type: boolean #. Description #: ../pybit-client.templates:2001 msgid Use LVM snapshots on this client? msgstr ¿Desea utilizar instantáneas LVM en este cliente? #. Type: boolean #. Description #: ../pybit-client.templates:2001 msgid If the sbuild configuration uses LVM snapshots, pybit-client can ensure that your snapshot APT cache data is kept up-to-date whilst keeping the snapshot clean. msgstr Si la configuración de sbuild usa instantáneas LVM, pybit-client puede asegurarse de que los datos del caché de APT de su instantánea se mantengan actualizados mientras se mantiene la instantánea limpia. #. Type: string #. Description #: ../pybit-client.templates:3001 msgid Buildd location: msgstr Ubicación de buildd: #. Type: string #. Description #: ../pybit-client.templates:3001 msgid Please specify a writeable directory where the version control handler and the upload task can write files. msgstr Indique un directorio con permisos de escritura donde el manejador de control de versiones y la tarea de envíos pueden guardar los archivos. #. Type: string #. Description #: ../pybit-client.templates:3001 msgid If this is left blank, the default /home/buildd/pybit will be used. msgstr Si deja este campo en blanco se usará el directorio predeterminado («/home/buildd/pybit»). #. Type: string #. Description #: ../pybit-client.templates:4001 ../pybit-web.templates:1001 msgid Host machine running RabbitMQ: msgstr Servidor donde se ejecuta RabbitMQ: #. Type: string #. Description #: ../pybit-client.templates:4001 msgid Please specify the server running RabbitMQ that this buildd client will communicate with, receiving details of the jobs it needs to attempt to build. msgstr Indique el servidor donde se ejecuta RabbitMQ con el que se comunicará este cliente buildd y desde donde recibirá los detalles de los trabajos que necesita intentar construir. #. Type: string #. Description #: ../pybit-client.templates:5001 msgid Destination for dput package uploads: msgstr Destino donde dput enviará paquetes: #. Type: string #. Description #: ../pybit-client.templates:5001 msgid Please specify the machine that this client will use as upload host. This destination will be stored in its dput configuration. msgstr Indique el equipo que usará este cliente como servidor de envíos. Este destino se almacenará en su configuración dput. #. Type: string #. Description #: ../pybit-client.templates:5001 msgid This entry must not be empty. msgstr Este campo no puede estar en blanco. #. Type: note #. Description #: ../pybit-client.templates:6001 msgid Client-ID string cannot be empty! msgstr ¡La cadena del identificador de cliente (client-ID) no puede estar en blanco! #. Type: note #. Description #: ../pybit-client.templates:6001 msgid This client will fail to start until it receives a unique client-ID. msgstr El cliente no se iniciará hasta que reciba un identificador de cliente (client-ID) único. #. Type: note #. Description #: ../pybit-client.templates:7001 ../pybit-web.templates:4001 msgid Missing
Bug#733498: [INTL:es] Spanish translation of debconf messages
Package: wims-moodle Severity: wishlist Tags: l10n patch Greetings, -- Camaleón # wims-moodle po-debconf translation to Spanish # Copyright (C) 2013 Software in the Public Interest # This file is distributed under the same license as the wims-moodle package. # # Changes: # - Initial translation # Camaleón noela...@gmail.com, 2013 # # - Updates # # # Traductores, si no conocen el formato PO, merece la pena leer la # documentación de gettext, especialmente las secciones dedicadas a este # formato, por ejemplo ejecutando: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # # Equipo de traducción al español, por favor lean antes de traducir # los siguientes documentos: # # - El proyecto de traducción de Debian al español # http://www.debian.org/intl/spanish/ # especialmente las notas y normas de traducción en # http://www.debian.org/intl/spanish/notas # # - La guía de traducción de po's de debconf: # /usr/share/doc/po-debconf/README-trans # o http://www.debian.org/intl/l10n/po-debconf/README-trans # msgid msgstr Project-Id-Version: wims-moodle 4.0-9\n Report-Msgid-Bugs-To: wims-moo...@packages.debian.org\n POT-Creation-Date: 2009-09-06 20:39+0200\n PO-Revision-Date: 2013-12-14 13:36+0200\n Last-Translator: Camaleón noela...@gmail.com\n Language-Team: Debian Spanish debian-l10n-span...@lists.debian.org\n Language: es\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=2; plural=(n != 1);\n X-Generator: Virtaal 0.7.1\n #. Type: string #. Description #: ../templates:1001 msgid Please type the base address to access Wims from remote machines: msgstr Introduzca la dirección base para acceder a Wims desde equipos remotos: #. Type: string #. Description #: ../templates:1001 msgid The base address to access Wims will be needed to enable users to access their Wims assignments from Moodle. msgstr Necesita la dirección base de Wims para permitir a los usuarios acceder a sus tareas Wims desde Moodle. #. Type: string #. Description #: ../templates:1001 msgid If you can access Wims at https://wims.mycollege.uk/wims/, you should answer https://wims.mycollege.uk; msgstr Si puede acceder a Wims desde «https://wims.mycollege.uk/wims/» debería responder «https://wims.mycollege.uk»; #. Type: string #. Description #: ../templates:1001 msgid Please notice that the protocol should be https. Apache must be configured to be able to answer https requests. msgstr Tenga en cuenta que el protocolo debe ser https. Apache debe estar configurado para responder a solicitudes https.
Bug#733499: network-manager-gnome: Recommend or suggest libpam-systemd
Package: network-manager-gnome Version: 0.9.8.4-1 Severity: normal I'm using network-manager-gnome in XFCE, and libpam-systemd was not installed. When using the Create new WIFI network on the Network Manager systray applet, I got the following error message popup: Failed to add/activate connection (32) No session found for uid 1000 (unknown) After reading http://qubes-os.org/trac/ticket/626 I decided to install libpam-systemd, and then it worked. So perhaps network-manager-gnome should recommend or suggest libpam-systemd? I don't think it should be a depends, since I'd imagine that only a small fraction of users will try to create a WIFI hotspot. Best regards Torquil Sørensen -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages network-manager-gnome depends on: ii dbus-x11 1.6.18-2 ii dconf-gsettings-backend [gsettings-backend] 0.18.0-1 ii gconf-service3.2.6-1 pn gnome-icon-theme none ii libatk1.0-0 2.10.0-2 ii libc62.17-97 ii libcairo-gobject21.12.16-2 ii libcairo21.12.16-2 ii libdbus-1-3 1.6.18-2 ii libdbus-glib-1-2 0.100.2-1 ii libgconf-2-4 3.2.6-1 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-0 2.36.4-1 ii libgnome-bluetooth11 3.8.1-2 ii libgnome-keyring03.8.0-2 ii libgtk-3-0 3.8.6-1 ii libnm-glib-vpn1 0.9.8.0-5 ii libnm-glib4 0.9.8.0-5 ii libnm-gtk0 0.9.8.4-1 ii libnm-util2 0.9.8.0-5 ii libnotify4 0.7.6-1 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-0 1.36.0-1+b1 ii libsecret-1-00.15-2 ii network-manager 0.9.8.8-1 ii policykit-1-gnome0.105-2 Versions of packages network-manager-gnome recommends: pn gnome-bluetooth none ii gnome-keyring 3.8.2-2 ii iso-codes 3.49-1 ii mobile-broadband-provider-info 20130915-1 ii notification-daemon 0.7.6-1 Versions of packages network-manager-gnome suggests: pn network-manager-openconnect-gnome none pn network-manager-openvpn-gnome none pn network-manager-pptp-gnome none ii network-manager-vpnc-gnome 0.9.8.6-1 -- 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#733238: Removing udev rule does not modify bug
xorg.conf includes:- Section InputClass Identifier marble_FX Driver evdev MatchProductImExPS/2 Logitech Explorer Mouse|Logitech USB Trackball|PS2++ Logitech Mouse|PS2++ Logitech TrackMan MatchIsPointer true # Option Protocol ExplorerPS/2 Option EmulateWheel true Option EmulateWheelButton8 # Option EmulateWheelTimeout 300 Option XAxisMapping 6 7 Option YAxisMapping 4 5 Option ZAxisMapping 4 5 EndSection Section InputClass Identifier marble Driver evdev MatchProductImExPS/2 Logitech Explorer Mouse|Logitech USB Trackball MatchIsPointer true Option ButtonMapping 1 9 3 4 5 6 7 8 2 EndSection -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733500: nmu: haskell-comonad_4.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu haskell-comonad_4.0-1 . amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc sparc . -m Rebuild against new libghc-contravariant-dev (Joachim doesn't seem to be around to run his usual script for Haskell packages, and I don't have direct w-b access, so hopefully somebody can help with this since I need it to be able to upload a fix for one of the outstanding Haskell problems ...) Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542236: hyphen-ml packaging status
Can this bug get some love? I filed this in 2009 along with hyphen packages for many other Indian languages, this alone is remaining to be packaged for last 4 years :( Thanks Santhosh
Bug#733344: Wine unable to start any programs
wine exits non-zero on any operation on a previously working amd64 install of 1.6.1-6. Downgrading to wine from testing (although awkward due to the changes in dependencies) does restore a working Wine installation. Downgrading to 1.6.1-6 from -7 via snapshots just gave a lot of broken dependencies and I couldn't see a simple way to get the /usr/bin/wine executable back, hence going back to testing. No output is shown with the packages in sid, the only clue is the exit code seen with echo $? Working install achievable with these packages from testing: ii libwine 1.4.1-4i386 ii libwine-bin:i386 1.4.1-4i386 ii libwine-gecko-1.4 1.4+dfsg1-3all ii wine-bin 1.4.1-4i386 and these support packages: sudo apt-get install -t jessie libice6:i386 libsm6:i386 libssl1.0.0:i386 libtiff4:i386 -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Bug#677730: policycoreutils: sepolgen-ifgen doesn't work if policy utils are newer than the kernel
Hi, I maybe doesn't understand the problem properly or the problem has been fixed. On my machine here (up-to-date sid): cat /sys/fs/selinux/policyvers = 28 and the loaded policy is: /etc/selinux/default/policy/policy.29 sepolgen-ifgen is running fine (except a warning) with the current refpolicy package in unstable. Are you still able to reproduce this? Cheers Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730352: libisl-dev: /usr/include/isl/union_map.h:114:45: error: unknown type name 'isl_multi_aff'
Hi, On 24/11/13 18:34, Matthias Klose wrote: Control: reassign -1 src:llvm-toolchain-3.2 then please fix llvm-3.2. Consider the minimal example I gave when reporting the bug. It triggers the issue even without llvm being involved. How can this possibly be solved in llvm-3.2? As far as I can see, the issue can be reduced to isl. Any hint? Thanks in advance, Roland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730352: libisl-dev: /usr/include/isl/union_map.h:114:45: error: unknown type name 'isl_multi_aff'
On 29/12/13 14:44, Roland Stigge wrote: Consider the minimal example I gave when reporting the bug. It triggers the issue even without llvm being involved. To be more precise: With llvm being used neither as a compiler nor when building llvm. (I compiled the example program with gcc.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733502: busybox: FTBFS when built with bash as the default shell
Package: busybox
Version: 1:1.21.0-6exp
Severity: important
Tags: upstream
Busybox fails to build when the default shell is bash and busybox is
*not* installed on the system. In this condition the
which-uses-default-path test fails as in this build log [1]:
| FAIL: which-uses-default-path
| ++ command -pv busybox
| + BUSYBOX=
Looking at the test, it does:
| BUSYBOX=$(command -pv busybox)
| SAVED_PATH=$PATH
| unset PATH
| $BUSYBOX which ls
It is launched with PATH set to ${busybox-build-dir}:$PATH
On a POSIX compliant shell like bash, the '-p' passed to 'command' means
ignore the PATH environment variable and use the default one [1]. If
busybox is not in the standard path (which is supposed to be the case on
a clean chroot on a buildd), this command will return nothing, and a
exit value different of 0, and the test will fail, as seen on the build
log.
When dash is used, it ignores the '-p' argument passed to 'command'
contrary to what POSIX mandates. The just built busybox is therefore
correctly found the in the PATH, and the test succeed. I have reported
the dash issue as bug #733501.
On the busybox side, it looks like what is really wanted here is
'command -v busybox' instead of 'command -pv busybox. That way the
testsuite passes.
[1]
https://buildd.debian.org/status/fetch.php?pkg=busyboxarch=mipsver=1%3A1.21.0-6expstamp=1387284512
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages busybox depends on:
ii libc6 2.18-0experimental0
busybox recommends no packages.
busybox 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#731221: vsftpd do not show files to anonymous user
close 731221 thanks This is already documented in README.Debian. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640789: Crash on folder name with spaces
Control: tags -1 patch
Hello,
Trečiadienis 07 Rugsėjis 2011 11:57:14 rašė:
It seems that an unescaped $dir in debian/iso-scan.postinst makes
iso-scan exit while searching for iso images, if a folder name
contains spaces.
line 165:
isolist=$(find $dir $opt -name *.iso -o -name *.ISO 2/dev/null)
The patch is attached. I have been hit by this today and have spent hours
trying to understand what was going on.
--
Modestas Vainius mo...@debian.orgFrom 650fb20f67028f92c0a36acd2a95fc45bc8ae361 Mon Sep 17 00:00:00 2001
From: Modestas Vainius mo...@debian.org
Date: Sun, 29 Dec 2013 15:47:31 +0200
Subject: [PATCH] Escape directory path when invoking `find`.
Closes: #640789.
---
debian/changelog | 7 +++
debian/iso-scan.postinst | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index fbdd6b7..eecbdcf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+iso-scan (1.52) UNRELEASED; urgency=medium
+
+ * Do not crash when searching in folders with shell-special characters in
+their name. (Closes: #640789)
+
+ -- Modestas Vainius mo...@debian.org Sun, 29 Dec 2013 15:49:15 +0200
+
iso-scan (1.51) unstable; urgency=low
[ Updated translations ]
diff --git a/debian/iso-scan.postinst b/debian/iso-scan.postinst
index 1255214..a21ed85 100755
--- a/debian/iso-scan.postinst
+++ b/debian/iso-scan.postinst
@@ -162,7 +162,7 @@ scan_device_for_isos() {
elif [ $look_subdirs = 1 ]; then
opt=-type f
fi
- isolist=$(find $dir $opt -name *.iso -o -name *.ISO 2/dev/null)
+ isolist=$(find $dir $opt -name *.iso -o -name *.ISO 2/dev/null)
TOPLEVEL_DIRS_COUNT=$(($TOPLEVEL_DIRS_COUNT + 1))
for iso in $isolist; do
--
1.8.5.2
signature.asc
Description: This is a digitally signed message part.
Bug#727708: systemd vs. binfmt-support
On Sun, Dec 29, 2013 at 05:56:30AM +0200, Uoti Urpala wrote: On Thu, 2013-12-26 at 21:42 +, Colin Watson wrote: The first reason is, I suppose, rather selfish: I've been working on this on and off for fourteen years and it seems a bit rude for systemd to turn up and declare that it's now the standard on the strength of an underpowered implementation, without even mentioning it to me (I'll accept that this is irrational since the systemd authors probably weren't aware of the prior art, but it's certainly my gut reaction). I I don't think systemd authors have made any declarations about binfmt in particular. The only thing they've actually done is add a very simple implementation (src/binfmt/binfmt.c, less than 200 lines of code, much of it argument parsing). I consider having a basic implementation to be a useful batteries included feature: systemd supports lots of different setups from embedded to desktop, and it's useful to have at least a basic implementation ready when building a system. It's easy enough to override if you want something different. I agree with this part. My comments above were imprecisely phrased, sorry (though I did flag them as a gut reaction); I'm mainly referring to the end result for Debian. Thus I consider any opinions saying systemd should not include a tool for setting binfmt, or that adding it was somehow objectionable behavior, to be wrong. I was referring more to Tollef's position, really. Debian systemd maintenance ought to take into account matters of Debian integration, which includes whether it fits well into best-of-breed Debian practice. If it's easy enough to override, then given that we have a better implementation in Debian then we should simply continue to use it. I think this has been proven false by experience - systemd has innovated a lot in things where smaller projects were stagnant. And there's a fairly clear reason why this would be so: something like binfmt-support is too small a unit for independent development, both to design independently and to sell to every user individually. It's simply not true that it's too small a unit for independent development (what on earth gives you the authority to pronounce on this, please, given that I've been independently developing it and working with the people who consume it directly for much longer than systemd's been around?). Besides, this is a red herring; there's no need to sell it to every user individually, only to distributions complex enough for it to be worth it, maybe half a dozen conversations. Typical users get it by way of dependencies or similar. Binfmt support is not that complex a task in itself. In practice, a lot of the usability will depend on consistency with other system parts. Designing APIs for it only is too narrow a view; you need to consider other tools, and if you can do better, then it's quite likely you should change the other tools too (things like adding udev rules etc). However, I've been thinking about this for rather a long time, and I'm actually quite familiar with the design issues. binfmt-support is specifically designed to be suitable for distributions (not just Debian) shipping binfmt integration; in particular I have put much more effort than systemd has into how it fits into packaging. Convincing every distro builder out there individually that your binfmt support code is best wastes effort, both yours and theirs. It's more efficient to have systemd upstream decide what is a reasonable default implementation, and then have only people with specific needs or opinions change it. This sounds very much like an argument from authority, and I'm afraid I don't subscribe to it. I don't consider my effort wasted, and I don't consider it wasted effort for other distributions to take improved code either; nor do I think that something really not particularly tied to the init system needs to be developed under the systemd umbrella. Cheers, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732623: possible explanation and patch proposal
control: reassign -1 lightdm-gtk-greeter control: retitle -1 no hardware actions after first logout on systemd/logind systems On Sat, Dec 28, 2013 at 03:45:45PM +0100, Pascal Dormeau wrote: Hi Yves-Alexis, Please find hereafter an explanation of the problem based on my personal interpretation. Vincent has been very much involved in debugging so I CC him too. * What is going on : This happens when logind is running. Before logout, we have at least one logind user session and one logind lightdm session (implies that libpam-systemd is installed). At logout, lightdm immediately starts a new session (and runs a new lightdm-gtk-greeter process), then the former lightdm session is removed, and only then the user session is removed. So when the new lightdm-gtk-greeter process is launched, more than one logind session exists. lightdm-gtk-greeter checks if suspend, hibernate, restart, shutdown are allowed using the lightdm_get_can_suspend/hibernate/restart/shutdown() functions. If one of those actions is not allowed, it is hidden from the power menu, from beginning to end of the lightdm-gtk-greeter process. If logind is running, power actions are allowed according to /usr/share/polkit-1/actions/org.freedesktop.login1.policy. For multiple-sessions, restart and hibernate are allow_active auth_admin_keep. So at logout we have temporary a multi-sessions configuration implying that hibernate and restart are not allowed. Because the power menu is static inside a given lightdm-gtk-greeter process, hibernate and restart remain forbidden even after only one lightdm session remains. The bug could be in the way the different logind sessions are removed and created at logout, but still, lightdm-gtk-greeter is unable to track session changes (for instance, if someone else logs into a VT). * proposal The proposal is to check whether hibernate, restart, shutdown are allowed, only when the power menu is opened. The patch in attachment is doing this. But BIG WARNING: I spend only a couple of days digging into the GTK documentation available on the web, it's all new for me. It might be dirty. Check needed. Help also welcome for improvement (I guess there is a smarter way to avoid those 5 new GtkWidget objects). I run lightdm and lightdm-gtk-greteer with it, so far they behave as expected (in particular, if I log in a VT resulting into a multiple session situation, I can see the change in the menu). Ok so in the end it's more like a race condition in the GTK+ greeter (which might happen in other greeters though). I'm reassigning to the correct package and will forward upstream. Thanks for the investigation. Regards, -- Yves-Alexis Perez signature.asc Description: Digital signature
Bug#727085: Now we don't depend on the weird libevent patch
On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote: Not really, in my opinion. I think it's a valid rejection reason for anything that is not the reference PHP implementation published and copyrighted by the PHP Group. Personally, I consider the PHP License non-free even for PHP itself, but that's another story: https://lists.debian.org/debian-legal/2005/11/msg00272.html Just to clarify, since Paul may not be accustomed with Debian's structure or your involvement: this is your opinion but you're not a member of the Debian project and you're certainly not the decision maker for DFSG-freeness. The maintainer (and, possibly, sponsoring Debian Developer) is the first line of defense, and ultimately the decision is up to the ftp-master team[1] as part of the power of processing the NEW queue and accepting packages into Debian, a power that is delegated from the project leader. PHP is in the archive and is licensed under the PHP License to my knowledge, so the current ftp-masters' stance is that it's a perfectly acceptable license for inclusion into Debian. There is zero evidence suggesting that HHVM is not going to be accepted in Debian for the licensing reasons that you stated and there is, in fact, evidence to the contrary. Please avoid suggesting so -or if you do, explain that you're not part of the decision process- and possibly frightening perfectly good upstreams, or asking them to do more work, especially when they've proved themselves to be very willing to collaborate with us. Regards, Faidon 1: https://wiki.debian.org/Teams/FTPMaster -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Sun, Dec 29, 2013 at 2:46 PM, Faidon Liambotis parav...@debian.org wrote: On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote: Personally, I consider the PHP License non-free even for PHP itself, but that's another story: https://lists.debian.org/debian-legal/2005/11/msg00272.html That's seems to be an old email, things may changed a bit since then. Just to clarify, since Paul may not be accustomed with Debian's structure or your involvement: this is your opinion but you're not a member of the Debian project and you're certainly not the decision maker for DFSG-freeness. It seems he _is_ connected with Debian. At least apt-listbugs[1] developed and maintained by him. PHP is in the archive and is licensed under the PHP License to my knowledge, so the current ftp-masters' stance is that it's a perfectly acceptable license for inclusion into Debian. I think he meant PHP License is not free for _other_ software than PHP itself. But I'm neither a legal person and will let the FTP Masters decide on this. I know one of them personally, may ask him in advance for a legal standpoint. I'm still interested about HHVM, will retry its packaging next year. Regards, Laszlo/GCS [1] http://packages.qa.debian.org/a/apt-listbugs.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733503: RFS: commbug/1.0.3-0~experimental0 [ITP] -- Hello, I want request sponsorship
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package commbug * Package name: commbug Version : 1.0.3-0~experimental0 Upstream Author : Huang Rui vows...@gmail.com * URL : http://code.google.com/p/commbug/ * License : GNU GPL v3 Section : utils It builds those binary packages: commbug- Serial Ports Debugging Assistant To access further information about this package, please visit the following URL: http://mentors.debian.net/package/commbug Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/commbug/commbug_1.0.3-0~experimental0.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: Fix GUI display incomplete or dislocation bug in gnome3 desktop environment. Regards, Huang Rui -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640651: please set default FIRST_SYSTEM_UID=1 and FIRST_SYSTEM_GID=1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 You mean policy is more important than compatibility? Compatibility is a quality criteria. But policy? I see your issue, but that would better be solved with a possibility to tell the installer to change these variables. Some debconf menu for adduser to be run before the first dynamic UID/GID package is installed would be fine. Since all packages adding UIDs/GIDs should depend upon adduser this could actually work. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBCAAGBQJSwDIgAAoJEAqeKp5m04HLi7AH/36+ht0iYe3asyRPOQ9b4xt9 nS6FZN3A8HdZgHmdaCYn6HB4++z6Ft5g6Gr2vxTJW8kGe+gkQ1PhQVBvvzij+Dyu +ksDW5AYbfyySvEg4152Sa3OYcJ30gxluvCB4SPYtJPktxXsVqB4N5gxudoUuUl1 9TCEr5RkZNwtRQ8j9BvqFWOvLIOw4EeO2Pbue8H4ET2Ap0/AlUjmECuBixqq90y4 UYI3fLEUwrQ9LG34RxewpOiPNgPKmEysHNPNaMwO5ep8Ec8bsF6FNM/OWLhGcG4L G0kF4/1MlkzeIi8uZUpWUGcjlcQNOxpGutpl3zC9mkx0R9lUpPKSU59M6LynS2A= =9ZqA -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#733504: quilt: please sort order of files in diffs ASCIIbetically
Package: quilt Version: 0.60-2 Severity: important Hi, this is the companion bug for the same problem in dpkg-source --commit reported as: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689193 The severity in quilt is higher because this is quilt’s primary objective (managing diffs) and the impact of unsorted patches on maintainer and reviewer time is nōn-neglegible. Please sort the order of files in diffs (on “quilt refresh”) by ascending order of the pathnames involved (do make sure to *not* use the collation but only the octet values). I can probably cobble up a patch, should that be needed, but did not yet do so as I’d have to get familiar with quilt’s internals first. Thanks! -- System Information: Debian Release: 7.3 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'stable-updates'), (500, 'stable'), (490, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: m68k i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Versions of packages quilt depends on: ii bsdmainutils 9.0.3 ii bzip2 1.0.6-4 ii diffstat 1.55-3 ii gettext 0.18.1.1-9 ii patch 2.6.1-3 ii perl 5.14.2-21+deb7u1 quilt recommends no packages. Versions of packages quilt suggests: ii graphviz2.26.3-14 ii postfix [mail-transport-agent] 2.9.6-2 pn procmailnone -- 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#542236: hyphen-ml packaging status
Santhosh Thottingal santhosh.thottin...@gmail.com writes:
Can this bug get some love? I filed this in 2009 along with hyphen
packages for many other Indian languages, this alone is remaining to
be packaged for last 4 years :(
Sorry I totally forgot about this package is ready a long time ago and
is in our repo on debian-in. I had pinged Kartik on IRC for upload but
looks like he lost track of it.
Now I'm ccing 2 DD's hoping atleast one of them will upload it. Once I
get a DD status this should not be a problem
Cheers,
--
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4 C96B 6C8F 74AE 8770 0B7E
signature.asc
Description: PGP signature
Bug#699049: libfarstream-0.1-0: seems farstream not detecting audiocodecs
Hi, I guess this bug should be reassign to some other package (or even closed?) Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733505: rush: Allows reading arbitrary files
Package: rush Version: 1.7+dfsg-1 Severity: important From the package description: GNU Rush is a restricted shell designed for sites providing only limited access to resources for remote users. Much like sudo the shell allows a configuration file to limit the commands the user(s) are allowed to execute, and again like sudo the main binary (/usr/sbin/rush) is installed setuid root. Unfortunately the program suffers from the grave flaw that a configuration file may be tested via the --lint option, and this occurs prior to dropping any privileges. As the program is setuid(root) any file on the system may be read. Sample exploit: shelob ~ $ rush --lint /etc/shadow 21| head -n 2 rush: Info: /etc/shadow:1: unknown statement: root:$6$zwJQWKVo$../Wg.rwXXitSyS8/.../:15884:0:9:7::: rush: Info: /etc/shadow:2: unknown statement: daemon:*:15884:0:9:7::: As you can see the unrecognized content is shown to the user, allowing the local user access to the file they otherwise couldn't read. In this case setting up the system for a dictionary attack against the password hashes. Mitigating factors: Only the first whitespace-separated token is shown to the user. The identifier CVE-2013-6889 has been assigned to help track this security problem across distributions and releases. Please mention it when uploading a fixed package. -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.11.2 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rush depends on: ii libc6 2.13-38 rush recommends no packages. Versions of packages rush suggests: pn xinetd | inetutils-inetd none -- 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#727085: Now we don't depend on the weird libevent patch
On Sun, 29 Dec 2013 14:46:50 +0100 Faidon Liambotis wrote: On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote: Not really, in my opinion. I think it's a valid rejection reason for anything that is not the reference PHP implementation published and copyrighted by the PHP Group. Personally, I consider the PHP License non-free even for PHP itself, but that's another story: https://lists.debian.org/debian-legal/2005/11/msg00272.html Just to clarify, since Paul may not be accustomed with Debian's structure or your involvement: this is your opinion Sure, that's why I said personally. I also added but that's another story, meaning that my side-note talked about a fact that will probably have *no* effect on Debian decision-making process. but you're not a member of the Debian project True: I could have said that more explicitly, even though I have never claimed otherwise. I apologize if the lack of explicit clarification caused any confusion about this. and you're certainly not the decision maker for DFSG-freeness. Once again true: I just pointed out a well known rejection reason that, *in my own personal opinion*, could apply to the present case. The maintainer (and, possibly, sponsoring Debian Developer) is the first line of defense, and ultimately the decision is up to the ftp-master team[...] as part of the power of processing the NEW queue and accepting packages into Debian, a power that is delegated from the project leader. That's my understanding of Debian procedures, too. PHP is in the archive and is licensed under the PHP License to my knowledge, so the current ftp-masters' stance is that it's a perfectly acceptable license for inclusion into Debian. Yes, ftp-masters clearly think that the reference PHP implementation copyrighted by the PHP Group is acceptable for Debian main. I personally disagree, but, as I said, that's another story... There is zero evidence suggesting that HHVM is not going to be accepted in Debian for the licensing reasons that you stated and there is, in fact, evidence to the contrary. Please avoid suggesting so -or if you do, explain that you're not part of the decision process- and possibly frightening perfectly good upstreams, or asking them to do more work, especially when they've proved themselves to be very willing to collaborate with us. I am not sure I agree with you on this. In my *own personal* opinion, there's a possibility that something which is not the reference implementation of the PHP language (the implementation developed and copyrighted by the PHP Group) could be rejected, if licensed under the terms of the PHP License. It's true that the cited reject FAQ talks about PHP add-on packages, but then explains that the problem is that this license talks only about PHP, the PHP Group, and includes Zend Engine, so its not applicable to anything else. See again https://ftp-master.debian.org/REJECT-FAQ.html Hence, I expressed my concern about this *possible* rejection reason. That fact that the parts licensed under the terms of the PHP License are derived from PHP itself may mitigate the issue or even eliminate it, from the ftp-masters' point of view. But please note that this fact surfaced *after* I had expressed my concern. Frankly speaking, I don't see any clear evidence that this issue is non-existent. I was concerned about it, so I thought I could warn people upfront and see whether it could be (more or less easily) solved or worked around. Once again, I apologize if anything I said was not crystal clear and generated any confusion. I reiterate my gratitude to the friendly and helpful upstream developers. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpuwo1bVi3RL.pgp Description: PGP signature
Bug#733506: fex: Getting update notice every day
Package: fex Version: 20130805-1 Severity: normal Dear Maintainer, since I installed fex, I get a message every night, that there is a new version of fex available. This is not true. The version available at uni-stuttgart.de has the same version number as the debian package. Checking the code, I discovered, that the problem is a missing directory $HOME/doc. With the following two commands I could solve the problem on my system: mkdir /usr/share/fex/doc chown fex:fex /usr/share/fex/doc I get the message one more time, and then everything was fine. It seems to me, that this directory should get created automatically on installation of the fex package. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.11-2-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 fex depends on: ii adduser 3.113+nmu3 ii courier-mta [mail-transport-agent] 0.68.2-1+b1 ii debconf [debconf-2.0] 1.5.52 ii libdigest-md5-file-perl 0.08-1 ii libjs-jquery1.7.2+dfsg-3 ii perl5.18.1-5 ii ucf 3.0027+nmu1 ii xinetd [inet-superserver] 1:2.3.15-3 Versions of packages fex recommends: ii fex-utils20130805-1 ii libnet-dns-perl 0.68-1.2 ii perl-modules 5.18.1-5 fex suggests no packages. -- Configuration Files: /etc/cron.d/fex changed [not included] only changed to tests every five minutes for better debugging /etc/fex/fup.pl [Errno 13] Keine Berechtigung: u'/etc/fex/fup.pl' -- debconf information: fex/lastver: 0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733507: linux-image-3.11-2-amd64: Qualcomm Atheros AR9462 Bluetooth module on an Asus Z87I-PRO motherboard
Package: src:linux Version: 3.11.10-1 Severity: normal Tags: upstream Dear Maintainer, I'm having difficulties in getting the Bluetooth module on the Asus Z87i-PRO motherboard, which very probably is a AR9462 to work in combination with the 3.11 kernel. I also tried a newer 3.12 kernel, but this does not make any difference. The Bluetooth module is not recognized by Bluez or in Gnome Shell: $ sudo hcitool dev Devices: Dmesg shows: [1.430255] usb 1-11: new full-speed USB device number 4 using xhci_hcd [1.447651] usb 1-11: string descriptor 0 malformed (err = -61), defaulting to 0x0409 [1.449542] usb 1-11: New USB device found, idVendor=0b05, idProduct=17d0 [1.449543] usb 1-11: New USB device strings: Mfr=1, Product=2, SerialNumber=3 The usb-devices command shows: T: Bus=01 Lev=01 Prnt=01 Port=10 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0b05 ProdID=17d0 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb And lsusb -v shows: Bus 001 Device 004: ID 0b05:17d0 ASUSTek Computer, Inc. Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 1 Bluetooth bMaxPacketSize064 idVendor 0x0b05 ASUSTek Computer, Inc. idProduct 0x17d0 bcdDevice0.01 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 177 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 4 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint
Bug#733508: Unsets LD_LIBRARY_PATH from child processes
Package: rxvt-unicode-256color Version: 9.19-1 Severity: minor Hi, I got git builds of various libraries laying around (xcb, Xlib, cairo, ...) and want all my program to use these versions of the libraries so that I notice new problems early. To do this, I set LD_LIBRARY_PATH in ~/.xsession which is inherited by all processes in the X session. However, urxvt not unsets LD_LIBRARY_PATH. To test this I ran this command and checked for LD_LIBRARY_PATH in its output: env -i sh -c 'LD_LIBRARY_PATH=foo urxvt -hold -e /usr/bin/env' This happens because the urxvt binary is g+s, thanks to bug #500230. If I remove the setgid bit, LD_LIBRARY_PATH is passed on to the shell that urxvt starts. I know that this is not really urxvt's fault, but I have this problem due to a change in urxvt. It would be nice if urxvt used my local Xlib and xcb builds, but more importantly everything else should do so. Cheers, Uli -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (50, 'experimental'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/2 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 rxvt-unicode-256color depends on: ii base-passwd 3.5.28 ii libc6 2.17-97 ii libfontconfig12.11.0-2 ii libfreetype6 2.5.1-1 ii libgcc1 1:4.8.2-10 ii libgdk-pixbuf2.0-02.28.2-1+b1 ii libglib2.0-0 2.38.0-1 ii libperl5.18 5.18.1-5 ii libstartup-notification0 0.12-3 ii libx11-6 2:1.6.2-1 ii libxft2 2.3.1-1 ii libxrender1 1:0.9.8-1 ii ncurses-term 5.9+20130608-1 Versions of packages rxvt-unicode-256color recommends: pn fonts-vlgothic | fonts-japanese-gothic none ii ttf-dejavu 2.33+svn2514-3 rxvt-unicode-256color 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#733509: RFP: lubuntu-software-center -- Utility for browsing, installing, removing applications.
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org --- Please fill out the fields below. --- Package name: lubuntu-software-center Version: 0.0.8 Upstream Author: [Stephen Smally (not sure)] URL: [https://launchpad.net/lubuntu-software-center] License: [GNU GPL v3] Description: [The Lubuntu Software Center lets you browse and install thousands of applications available. You can view available applications by category, or search quickly by name or description. You can also examine the applications already installed, and remove those you no longer need.] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system other points, and conclusion
]] Ian Jackson This is exacerbated by the fact that systemd's Debian maintainers are (IMO) much too deferential to upstream. That's because the bits of systemd you've asked to change isn't just a piece of software. It's a standardised API, and you're effectively asking us to change that API. I think it's pretty clear why that is a bad idea. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Sun, 29 Dec 2013 15:22:09 +0100 László Böszörményi (GCS) wrote: On Sun, Dec 29, 2013 at 2:46 PM, Faidon Liambotis parav...@debian.org wrote: On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote: Personally, I consider the PHP License non-free even for PHP itself, but that's another story: https://lists.debian.org/debian-legal/2005/11/msg00272.html That's seems to be an old email, things may changed a bit since then. Not much, as far as I know. The current version of the PHP License is still 3.01 and I am not aware of any other licensing exception or additional permission granted by the PHP Group over their PHP reference implementation. I think that my old license analysis still holds. Just to clarify, since Paul may not be accustomed with Debian's structure or your involvement: this is your opinion but you're not a member of the Debian project and you're certainly not the decision maker for DFSG-freeness. It seems he _is_ connected with Debian. At least apt-listbugs[...] developed and maintained by him. Yes, I am the current maintainer and developer of apt-listbugs, but I am *not* a Debian Project member: I am an external contributor. PHP is in the archive and is licensed under the PHP License to my knowledge, so the current ftp-masters' stance is that it's a perfectly acceptable license for inclusion into Debian. I think he meant PHP License is not free for _other_ software than PHP itself. Actually, I personally think even PHP itself is non-free. But, as previously mentioned, ftp-masters disagree with me: they think the reference PHP implementation is acceptable for Debian main. But I'm neither a legal person and will let the FTP Masters decide on this. I know one of them personally, may ask him in advance for a legal standpoint. I'm still interested about HHVM, will retry its packaging next year. Good, thanks again. Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpvWXkolaTEG.pgp Description: PGP signature
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
]] Ian Jackson As the upstream author of a daemon I'm - not willing to add a library dependency for this - not willing to write a 50-100 lines of tiresome socket code for this - not willing to copy the library file into my source tree so the result is that userv upstream won't support systemd's readiness protocol. Lennart provided http://fpaste.org/64821/32737713/ as a pretty minimal example of sd_notify which implements it in 18 lines of code. It lacks a little bit of error handling, but even with that, it's hardly 50-100 lines of tiresome socket code. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733429: libcatalyst-modules-perl: FTBFS: Tests failed
On Sat, 28 Dec 2013 22:30:01 +0100, Salvatore Bonaccorso wrote: From HTML:FormFu Changes: - HTML::FormFu::MultiForm moved out to separate distribution. HTML::FormFu::MultiForm, but we don't have it packaged in Debian. Looks like we should change this :) There is also [1] relevant: 1.00 2013-12-16 - Updated for HTML-FormFu v1.00 - Only require MultiForm at runtime when needed [1] https://metacpan.org/changes/distribution/Catalyst-Controller-HTML-FormFu And that's enough to pass the tests and fix this RC bug. Nice. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Pink Floyd: One Slip signature.asc Description: Digital signature
Bug#733429: Pending fixes for bugs in the libcatalyst-modules-perl package
tag 733429 + pending thanks Some bugs in the libcatalyst-modules-perl package are closed in revision 735b49dcdde8d8630c72713776e727e74cf3315b in branch 'master' by gregor herrmann The full diff can be seen at http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libcatalyst-modules-perl.git;a=commitdiff;h=735b49d Commit message: Update Catalyst-Controller-HTML-FormFu. Closes: #733429 Thanks: David Suárez for the bug report. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733512: Error updating mate-polkit-common
Package: mate-polkit-common Version: 1.6.0-1 Severity: critical Tags: upstream Justification: aborts update Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? Updating via apt-get * What was the outcome of this action? dpkg error -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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#695398: libnet-dns-perl: New upstream version available
On Dec 07, Sebastian Schmidt y...@yath.de wrote: there is version 0.70 available for Net::DNS on CPAN, including Net::DNS::ZoneFile. Please update the Debian package. Are there any news? Recent releases should be stable now. -- ciao, Marco signature.asc Description: Digital signature
Bug#733513: [calibre] RuntimeError: Failed to load unrar module with error: No module named unrar
Package: calibre
Version: 1.14.0+dfsg-1
Severity: normal
--- Please enter the report below this line. ---
I can not convert a cbr-File to EPUB with Calibre
Error Message from Calibre:
calibre, version 1.14.0 (linux2, isfrozen: False)
Konvertierungsfehler: Fehlgeschlagen: Konvertiere Buch 1 von 1 (Comic001)
Konvertiere Buch 1 von 1 (Comic001)
Resolved conversion options
calibre version: 1.14.0
{'asciiize': False,
'author_sort': None,
'authors': None,
'base_font_size': 0.0,
'book_producer': None,
'change_justification': 'left',
'chapter': None,
'chapter_mark': u'pagebreak',
'colors': 256,
'comic_image_size': None,
'comments': None,
'cover': u'/tmp/calibre_1.14.0_tmp_fOZ5nC/UY2l0o.jpeg',
'debug_pipeline': None,
'dehyphenate': True,
'delete_blank_paragraphs': True,
'despeckle': True,
'disable_font_rescaling': True,
'disable_trim': True,
'dont_add_comic_pages_to_toc': False,
'dont_grayscale': True,
'dont_normalize': False,
'dont_sharpen': False,
'dont_split_on_page_breaks': False,
'duplicate_links_in_toc': False,
'embed_all_fonts': False,
'embed_font_family': None,
'enable_heuristics': True,
'epub_flatten': False,
'epub_inline_toc': False,
'epub_toc_at_end': False,
'expand_css': False,
'extra_css': None,
'extract_to': None,
'filter_css': u'',
'fix_indents': True,
'flow_size': 260,
'font_size_mapping': None,
'format_scene_breaks': True,
'html_unwrap_factor': 0.4,
'input_encoding': None,
'input_profile': calibre.customize.profiles.InputProfile object at
0x3594f90,
'insert_blank_line': False,
'insert_blank_line_size': 0.5,
'insert_metadata': False,
'isbn': None,
'italicize_common_cases': True,
'keep_aspect_ratio': True,
'keep_ligatures': False,
'landscape': False,
'language': None,
'level1_toc': u'//h:h1',
'level2_toc': u'//h:h2',
'level3_toc': u'//h:h3',
'line_height': 0.0,
'linearize_tables': False,
'margin_bottom': 0,
'margin_left': 0,
'margin_right': 0,
'margin_top': 0,
'markup_chapter_headings': True,
'max_toc_links': 50,
'minimum_line_height': 120.0,
'no_chapters_in_toc': False,
'no_default_epub_cover': False,
'no_inline_navbars': False,
'no_process': False,
'no_sort': False,
'no_svg_cover': False,
'output_format': u'png',
'output_profile': calibre.customize.profiles.OutputProfile object at
0x334a390,
'page_breaks_before': None,
'prefer_metadata_cover': False,
'preserve_cover_aspect_ratio': False,
'pretty_print': True,
'pubdate': None,
'publisher': None,
'rating': None,
'read_metadata_from_opf': u'/tmp/calibre_1.14.0_tmp_fOZ5nC/E53_QX.opf',
'remove_fake_margins': True,
'remove_first_image': True,
'remove_paragraph_spacing': False,
'remove_paragraph_spacing_indent_size': 1.5,
'renumber_headings': True,
'replace_scene_breaks': u'',
'right2left': False,
'search_replace': '[]',
'series': None,
'series_index': None,
'smarten_punctuation': False,
'sr1_replace': None,
'sr1_search': None,
'sr2_replace': None,
'sr2_search': None,
'sr3_replace': None,
'sr3_search': None,
'start_reading_at': None,
'subset_embedded_fonts': False,
'tags': None,
'timestamp': None,
'title': None,
'title_sort': None,
'toc_filter': None,
'toc_threshold': 6,
'toc_title': None,
'unsmarten_punctuation': False,
'unwrap_lines': True,
'use_auto_toc': False,
'verbose': 2,
'wide': False}
InputFormatPlugin: Comic Input running
on /tmp/calibre_1.14.0_tmp_fOZ5nC/AA1AQc.cbr
Traceback (most recent call last):
File /usr/bin/calibre-parallel, line 20, in module
sys.exit(main())
File /usr/lib/calibre/calibre/utils/ipc/worker.py, line 192, in main
result = func(*args, **kwargs)
File /usr/lib/calibre/calibre/gui2/convert/gui_conversion.py, line
31, in gui_convert_override
override_input_metadata=True)
File /usr/lib/calibre/calibre/gui2/convert/gui_conversion.py, line
25, in gui_convert
plumber.run()
File /usr/lib/calibre/calibre/ebooks/conversion/plumber.py, line
1035, in run
accelerators, tdir)
File /usr/lib/calibre/calibre/customize/conversion.py, line 241, in
__call__
log, accelerators)
File
/usr/lib/calibre/calibre/ebooks/conversion/plugins/comic_input.py,
line 180, in convert
pages = self.get_pages(fname, cdir)
File
/usr/lib/calibre/calibre/ebooks/conversion/plugins/comic_input.py,
line 129, in get_pages
tdir = extract_comic(comic)
File /usr/lib/calibre/calibre/ebooks/comic/input.py, line 32, in
extract_comic
extract(path_to_comic_file, tdir)
File /usr/lib/calibre/calibre/__init__.py, line 283, in extract
extractor(path, dir)
File /usr/lib/calibre/calibre/utils/unrar.py, line 150, in extract
stream_extract(stream, location)
File /usr/lib/calibre/calibre/utils/unrar.py, line 124, in
stream_extract
f = RARFile(stream)
File /usr/lib/calibre/calibre/utils/unrar.py, line 92, in RARFile
%err)
RuntimeError: Failed to load unrar module with error: No module named unrar
--- System information. ---
Architecture: amd64
Kernel: Linux 3.11-2-amd64
Debian
Bug#733323: rxvt-unicode-256color: urxvt spawns an extra process.
Hi Ryan, Thank you for the information. It was new to me. I can understand people wanting that utmp functionality, and I guess spawning the extra process is the way to handle this. However, on a system of which I am the only user, I am not really interested in that functionality. Is it not possible to configure the package so that the end user may choose if he wants that functionality or not? I am the kind of person that, when having several options available, I go for the solution that: i. gives me all the functionality I want/use ii. allows me to opt out of the functionality I do not want, without adding extra 'bloat'. Until I find a better solution, I get rid of the extra process by running the commands chgrp root /usr/bin/urxvt chmod g-s /usr/bin/urxvt Which, of course, I will have to repeat every time after installing a new version of the package. Regards, Jean-Pierre
Bug#733512: Error updating mate-polkit-common
On 12/29/2013 05:13 PM, Frank McCormick wrote: * What led up to the situation? Updating via apt-get * What was the outcome of this action? dpkg error That happens when trying to update the package when using the MATE Debian repository at the same time and is hard to avoid since the MATE repositories contain mate-polkit while Debian has split the package into mate-polkit and mate-polkit-common. We could maybe add a Breaks here, but mixing different repositories is problematic anyways. As a hotfix, you can run: apt-get -o Dpkg::Options::=--force-overwrite -f install which will allow mate-polkit-common to overwrite files from the existing mate-polkit package installed through MATE's Debian repository. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700945: xbmc-standalone: dummy transitional package does not depend on package(s) that replace it
fixed 700945 2:12.2+dfsg1-1 thanks On 02/19/2013 04:27 PM, Michael Deegan wrote: Package: xbmc-standalone Version: 2:11.0~git20120510.82388d5-1 Severity: normal Dear Maintainer, Transitional packages work better when they actively facilitate the transition to their replacements. :) True. The xbmc package has moved to the simpler method of handling the transition. From https://wiki.debian.org/Renaming_a_Package: ... Method 1 (only useful in very easy cases) One method is to just have the new package provide, replace and conflict the old package. This has disadvantages: If there are versioned depends on the old package, they will break. Most package managers (including APT, as of 2011-02-21) do not know to replace the old with the new one and will only use the new package if it is installed for some other reason. ... I'm not sure if APT caught up since then. I think if it has not, it may, thus IMO staying with the new method is future-proof. Cheers, Balint signature.asc Description: OpenPGP digital signature
Bug#733452: init system daemon readiness protocol
]] Tollef Fog Heen ]] Ian Jackson I conclude therefore that we should design another simple protocol - preferably, a variation on one of the existing ones - and have (at least) both Debian's systemd and Debian's upstart implement it. I think you're into ever-multiplying power socket standards territory here. I am not going to carry patches in systemd in Debian for a Debian-only notification protocol because you don't want to use the upstream protocol. As I've said in other messages, feel free to talk to upstream, but I'm not going to pass on suggestions which I'm not going to support. It seems Lennart read the proposal and responded in https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/37AWJLE3XcJ -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733514: RFP: golang-sqlite3-dev -- trivial sqlite3 binding for the go language
Package: wnpp Severity: wishlist Control: block 706060 by -1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: golang-sqlite3-dev Version : ? Upstream Author : Russ Cox r...@golang.org * URL : http://code.google.com/p/gosqlite * License : New BSD License Programming Lang: Go Description : trivial sqlite3 binding for the go language [...] golang-sqlite3-dev is a dependency for lxc-docker (#706060). I'm filling this RFP so that I can subscribe to it. :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJSwE3RAAoJEAf8SJEEK6ZasbUP/i8T0T7+6bqbs9TZSg2+7m4i mteY2UJGUWtveLOFOAQGmJ4XLZBJFaRU/Vr3NHTmxcZbHaa4O+297g2NX14Js5Os BSZPdEdtTN5jBImgqekzoX/3vJqtGxfV+jpV9k9XiHb7AtiBHgjUlxlCsLAKAMYO NeXhqT4TivZ4Xc1lvX4+pZa2EhvxK6/DwuftPxWYJKKTfPCl6/4VvIp7jF+9sVUn Nzj63dBgtmNAZqsJ0CWp0RQogA/F6sd1/Wr/sil6HYrE1E9hyu5IQGZVQU/BsPJd PAUKZ/8TfVOv/RN7qVWmlmRW2De25hTxJycovak2nPGyAZQRTWdXv5FeZMB32xuf 1NM8Xl9/aTEL0510ZdkQ0HsMAFZIYaLaJEYdGzLpF+1JB+jC3do3lrNiKbKRVfyy 1fuKmRijq2quRo+WkmkJoDkVewrRlGWE17ShtyeETMC+Axoj7KRpwNMV0Mpuhh87 VSmR75pESAsd4qgeOoMpclxP+iQTXJyyIFLk+xQRsKjUTuPXRcNBcUBHqQrL31oh OJyWGXAXDJWhgnEPH5l4QKDV7TPkXVD3LJktfoiG9GI/dHfyUOrOhrMTK2j0wW/1 xDYrcN9Ngjbk2Vvm8h3dxnl+4Z7KM7MOR4v0ODjapc7nmQJsuk+uhktn+2AKZjOY L6+e2GGNv5jYTbIUnM8Z =H/tT -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#721618: schleuder and ruby1.9
According to upstream, http://schleuder2.nadir.org/featurerequests/ruby1.9-compatiblity.html schleuder should be ok with Ruby1.9 if tmail is replaced by ruby-actionmailer, which should be a transparent replacement. I wonder which version of actionmailer is supposed to be used for this. actionmailer 2.3 depends on tmail, 3.2 has replaced the dependency with mail, and I see no code in actionmailer 3.2 or 4.0 that would provide a compatibility layer for tmail. -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- signature.asc Description: Digital signature
Bug#733061: Info
With 2.0.5 installed, I did not have /var/lib/emacsen-common/state/package/installed/emacsen-common. It got created only after I dpkg-reconfigure'd emacsen-common. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733515: cpl-plugin-xsh: arch-dependent files in Multi-Arch: same package
Package: cpl-plugin-xsh Version: 2.3.0+dfsg-1 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch cpl-plugin-xsh is marked as Multi-Arch: same, but the following files are architecture-dependent: /usr/share/doc/cpl-plugin-xsh/html/_static/basic.css /usr/share/doc/cpl-plugin-xsh/html/_static/sphinxdoc.css /usr/share/doc/cpl-plugin-xsh/html/genindex.html /usr/share/doc/cpl-plugin-xsh/html/index.html /usr/share/doc/cpl-plugin-xsh/html/search.html /usr/share/doc/cpl-plugin-xsh/html/searchindex.js /usr/share/doc/cpl-plugin-xsh/html/xsh_*.html /usr/share/doc/cpl-plugin-xsh/html/objects.inv An example diff between i386 and amd64 is attached. -- Jakub Wilk cpl-plugin-xsh_2.3.0+dfsg-1.archdiff.xz Description: Binary data
Bug#733516: request-tracker4: please update to 4.2
package: request-tracker4 severity: wishlist Hi, Upstream releases 4.2.1, so please consider to upgrade your package. (or just update to 4.0.18). And 4.2.x is major update as upstream says - do you release it as request-tracker4.2, or just update its version? -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732699: Info
tag 732699 + confirmed thanks This is actually caused by #733061; I will add a Conflicts: emacsen-common ( 2.0.0) in org-mode's control file, because it needs to be there, but this change alone won't fix much: per my comment on #733061, I had to dpkg-reconfigure emacsen-common to get /var/lib/emacsen-common/state/package/installed/emacsen-common created. Cheers, --Seb -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733512: Error updating mate-polkit-common
On 29/12/13 11:19 AM, John Paul Adrian Glaubitz wrote: On 12/29/2013 05:13 PM, Frank McCormick wrote: * What led up to the situation? Updating via apt-get * What was the outcome of this action? dpkg error That happens when trying to update the package when using the MATE Debian repository at the same time and is hard to avoid since the MATE repositories contain mate-polkit while Debian has split the package into mate-polkit and mate-polkit-common. We could maybe add a Breaks here, but mixing different repositories is problematic anyways. Strange because AFAIK my MATE desktop came from the Debian repositories. A second problem I am having is two MATE packages which won't update: Calculating upgrade... Done The following packages have been kept back: libmateweather-common libmatewnck-common 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. frank@frank-debian:~$ This has been the situation for months. As a hotfix, you can run: apt-get -o Dpkg::Options::=--force-overwrite -f install Yes that is basically what I did. Thanks Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695398: libnet-dns-perl: New upstream version available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 29.12.13 17:11, schrieb Marco d'Itri: On Dec 07, Sebastian Schmidt y...@yath.de wrote: there is version 0.70 available for Net::DNS on CPAN, including Net::DNS::ZoneFile. Please update the Debian package. Are there any news? Recent releases should be stable now. Time to get active again. Give me some days within the new year. Or, if you want to start work, please coordinate work with me and/or use delayed upload queue. Regards Florian - -- Florian Roscher private: m...@florian-roscher.de Debian: f...@debian.org PGP Key / ID: 1024D/B4071A65 Fingerprint : F9AB 00C1 3E3A 8125 DD3F DF1C DF79 A374 B407 1A65 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLAT/cACgkQDFrm3Brt5EOyKwCggp1v44xcwnm2afVe5F2oGJ6W vRoAnA5gGXa61yg+TqHfwlMYYnkiaNwx =xC4b -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#733517: FTBFS on Sparc and S390x
Package: python-cffi Version: 0.7.2-2 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi! python-cffi unit tests are failing on sparc and s390x arch. You can find a patch to fix some of the problems here: https://bitbucket.org/cffi/cffi/commits/f3dabd52fbeb54e814e14120cb27ceae3ad266ce There is another problem on sparc that makes the build fail but it succeeds on s390x. I still have to figure out the remaining bug on sparc but it seems quite complex (and related to libffi). - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-cffi depends on: ii libc6 2.17-97 ii libffi6 3.0.13-10 ii python2.7.5-5 ii python-pycparser 2.10+dfsg-1 python-cffi recommends no packages. Versions of packages python-cffi suggests: ii python-dev 2.7.5-5 - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSwFIyAAoJEJWkL+g1NSX5O8cP/2+w+EzHHpwyU9D3R0lJ/GeR Ey1KXJIboCcbu0/9+M5FLmZA2V+XodmsX3dTTOoqkyLsoC0GkGwa6yG+nZuUjbvd P7qZELFlmIZ7IRETa/9dqCOC3fzVwWtE/I8EHPAcFdzll0QHgHx6pry+QXbpm1Pr wzLUNbtjtbBpgL8YPaVrRB7YUfIKpPOUdYc5U4a8LLaIZLhaNeIdj49AM6gRZpEd lyDA4b0jDEVBzOdcbADaw7rfLGXdodwucPAYRMiaNZB7pcYfdT3Yf/R/weavW6ml jeXyVlhv9vseRppGB7kNbGnoS8P6yFBJSwheBdPAQNxJn1kIjBp+Iz05Izs40NqI pM0j3XYJUwt09/yID2tDVYwNad9kOhBiQe8q8IFfDViILmkovAf103ZE2uQgw3kg Lsk6JNv1fhIwC4YZr7Y5ezt2Wk3GOFOv5HQHXDHHJYZy/i/tCkGHCIera//rn6WQ Vsm6l1bqEmD6WnPGz7LCQ9dGIakbT8iIUMAzFLLGYMqwlsJ5sWJK3pc8SoiQ7Fdx CUbFbR6emqgr8gh68KThN9r9chU4Y2DtwKyj/0UnAKWiYUq2vQsYEdQQbiFSmByB 9IrWXNDADMEREqNPTuE7HwuG95RfgrqED+Hbeoz4YRX4md+O1BqRCPhrUf2KQGs8 +DJtqcxrT4+L0HyIm67m =VUbA -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#733512: Error updating mate-polkit-common
(Note: Please keep the bug tracker in CC, I just bounced your mail) On 12/29/2013 05:29 PM, Franklin McCormick wrote: Strange because AFAIK my MATE desktop came from the Debian repositories. This doesn't contract my previous statement at all. The current problem with MATE in Debian is that the whole upload is work-in-progress and many packages are yet missing. MATE consists of over 50 separate packages and it's not possible to upload all packages simultaneously to Debian since the FTP masters have to manually acknowledge every new package manually. As a result, users are dealing with having to mix packages from the official Debian archives with the packages from the MATE Debian repositories which can result in conflicts like the one you reported. These conflicts will always occur from time to time while MATE hasn't been fully uploaded to the Debian archives and users therefore have to deal with these, unfortunately. However, such problems are normal and to be expected when using Debian unstable which is why it's not recommended to use Debian unstable unless you can resolve these problems yourself. A second problem I am having is two MATE packages which won't update: Calculating upgrade... Done The following packages have been kept back: libmateweather-common libmatewnck-common 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. frank@frank-debian:~$ This has been the situation for months. Yes, and the origin of this problem is the same as mentioned above. I am sorry for the breakage, but we can't avoid it at the moment. It might have been smarter to upload everything to experimental first, but we have started with unstable now and have to get this whole process done. Please be patient :). PS: I am considering closing or downgrading the severity of this bug report as we can't really address it at the moment and setting it to critical will just prevent the package from migrating to testing. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart and upgrading from sysvinit scripts
On Sun, 2013-12-29 at 01:10 -0800, Steve Langasek wrote: However, I think this gets to the heart of why upstart upstream has avoided ever recommending the use of socket-based activation. There are some fairly fundamental problems that basically halted development of socket-based activation in upstart (beyond merging of Scott's original implementation, which is rudimentary, as has been noted), and a look at systemd usage on Fedora led me to believe that systemd had not overcome these problems at all. As far as I can see, what you're saying here is 100% based on misconceptions only, and has no connection to any real issues whatsoever. If I'm not mistaken (no references to hand - sorry), systemd upstream has claimed in the course of discussions on debian-devel that lazy activation is not the purpose of socket-based activation, and that using socket-based activation does not require you to pay the service startup penalty at the time of first connection. Yes, this is true. If you have a daemon configured to always start, and then add a .socket unit for socket activation, this does not in any way STOP the daemon from starting! Any mechanism that directly starts a .service will continue to do so regardless of the existence of a .socket. What a .socket adds is that you can have the socket active while the service is inactive, and in this state an incoming connection to the active socket will trigger start of the service. Other services which make requests through the socket can depend on the .socket only (as opposed to directly depending on the .service) to allow this state. On Fedora 20, after enabling the sshd and rsync service+socket units (both installed but disabled by default on Fedora per their policies on running services out-of-the-box) and rebooting, I find that both port 22 and port 873 are bound by pid 1. Only upon connecting to the socket does systemd actually spawn the server (in the case of sshd, it spawns it as 'sshd -i', so has to start up the server anew on each connection; in the case of rsyncd, the .service definition is completely incompatible with socket-based activation and any attempt to connect results in the rsyncd.socket unit landing in a 'failed' state). Assuming this is an accurate description, it sounds like an intentional decision for ssh and a bug in rsyncd (as Josselin already said). If what one is trying to accomplish here is to provide a replacement for inetd, then this is perfectly sufficient. But if one is trying to use socket-based activation for the claimed purpose of ensuring service startup ordering without the need to declare explicit dependencies, then you must accept the penalty of lazy activation - which is almost never acceptable in a server context (where the purpose of the machine is to run the services that you have configured, and they should therefore not be started lazily), and suboptimal even in a client context (since not starting services that are on the critical path for boot until the client requests them will potentially lead to a significant boot-time slowdown, if all the services are doing this). As above, your belief that systemd would force lazy activation has no basis in reality that I can see. As far as I've been able to tell, the only solutions that would allow non-lazy socket-based-activation of services in systemd all introduce significant boot-time races, whereby it is no longer assured that systemd will bind to the socket (and passing the socket information via the environemnt) before starting the service. Indeed, when I looked at this problem on an earlier version of Fedora, I found what I believe to be a latent security problem in the cups units, because it was nondeterministic whether the service would start with sockets passed from systemd, or a different set of sockets as defined in the cups config! When I mentioned this to Lennart at DebConf this year, his response was that cups was special. Well, after further investigation, I don't think it's true that cups is special. I think systemd socket-based activation is snake oil, that does not do what was promised without introducing hidden trade-offs which no one has been forced to acknowledge because too few developers are making use of this feature today to expose the integration problems. If foo.service has Requires=foo.socket, then on general principles it would sound like a very obvious bug if the service ever starts without foo.socket active. I'd like to hear of some evidence of such a bug before taking it seriously. And even if such a bug somehow existed, fixing it should be a straightforward bugfix. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730456: lintian: Implementation buggy
Package: lintian Followup-For: Bug #730456 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just saw this lintian error popping up at drizzle, but its postinst already uses --home: # creating drizzle user if it isn't already there if ! getent passwd drizzle /dev/null; then # Adding system user: drizzle. adduser \ --system \ --disabled-login \ --ingroup drizzle \ --home $DATADIR \ --gecos Drizzle Server \ --shell /bin/false \ drizzle /dev/null fi Or is this error meant differently? coldtobi - -- System Information: Debian Release: jessie/sid APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.23.52.20130722-1 ii bzip2 1.0.6-4 ii diffstat 1.55-3 ii file 1:5.14-2 ii gettext0.18.3-1 ii hardening-includes 2.3 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.29 ii libarchive-zip-perl1.30-7 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.34-1 ii libdpkg-perl 1.16.12 ii libemail-valid-perl0.190-1 ii libfile-basedir-perl 0.03-1 ii libipc-run-perl0.92-1 ii liblist-moreutils-perl 0.33-1+b1 ii libparse-debianchangelog-perl 1.2.0-1 ii libtext-levenshtein-perl 0.06~01-2 ii libtimedate-perl 1.2000-1 ii liburi-perl1.60-1 ii man-db 2.6.5-2 ii patchutils 0.3.2-2 ii perl [libdigest-sha-perl] 5.14.2-21+deb7u1 ii t1utils1.37-2 Versions of packages lintian recommends: ii libautodie-perl 2.20-1 ii libperlio-gzip-perl 0.18-1+b2 ii perl-modules [libautodie-perl] 5.14.2-21+deb7u1 Versions of packages lintian suggests: pn binutils-multiarch none ii dpkg-dev 1.16.12 ii libhtml-parser-perl3.71-1 ii libtext-template-perl 1.45-2 ii xz-utils 5.1.1alpha+20120614-2 - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLAVQMACgkQvyUNygvkuQKu5QCfedwrP7I8fXnfoatqBFGLma/O GuoAoLjQgdxsGblIpoc0gVWDeCQ6uJvR =9CEU -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#733518: ITP: libfixbuf -- Implementation of the IPFIX protocol
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: libfixbuf Version : 1.4.0 Upstream Author : Brian Trammell * URL : http://tools.netsa.cert.org/fixbuf/index.html * License : LGPL2 Programming Lang: C Description : Implementation of the IPFIX protocol libfixbuf is a compliant implementation of the IPFIX Protocol, as defined in RFC 5101. It supports the information model defined in RFC 5102, extended as proposed by RFC 5103 to support information elements for representing biflows. libfixbuf supports UDP, TCP, SCTP, TLS over TCP, and Spread as transport protocols. It also supports operation as an IPFIX File Writer or IPFIX File Reader. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702817: xbmc: [INTL:de] German translation of cpluff
Hi Chris, On 12/28/2013 03:09 PM, Chris Leick wrote: Hi Balint, but there are po files. Please remove them. Otherwise other translators may waste their time too. You are right. Upstream is discussing exactly that in the linked pull request. Since clpluff is a 3rd party lib for them I think adding notes for translators would be a better approach and I suggested this there. Thanks, Balint Kind regards, Chris Balint Reczey: tags 702817 wontfix tags 700726 wonfix thanks Chris Leick wrote: Package: xbmc Version: 12.0 Severity: wishlist Tags: l10n patch please find attached the initial German translation of cpluff. (xbmc/lib/cpluff/po/de.po) Sorry, upstream did not like the idea of translating log messages because doing so would make debugging harder for every developer not speaking German. signature.asc Description: OpenPGP digital signature
Bug#733512: Error updating mate-polkit-common
Am 29.12.2013 um 17:19 schrieb John Paul Adrian Glaubitz: On 12/29/2013 05:13 PM, Frank McCormick wrote: * What led up to the situation? Updating via apt-get * What was the outcome of this action? dpkg error That happens when trying to update the package when using the MATE Debian repository at the same time and is hard to avoid since the MATE repositories contain mate-polkit while Debian has split the package into mate-polkit and mate-polkit-common. We could maybe add a Breaks here, Breaks wouldn't help here, Replaces is what's needed. Considering that over 2000 people have the packages from the MATE repositories installed[1], adding that might be a good idea. but mixing different repositories is problematic anyways. Indeed, if a newer version gets uploaded to the MATE repositories people tracking it will likely experience the same problem again. Cheers, Sven 1. http://qa.debian.org/popcon.php?package=mate-polkit -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733512: Error updating mate-polkit-common
On 12/29/2013 06:05 PM, Sven Joachim wrote: Breaks wouldn't help here, Replaces is what's needed. Considering that over 2000 people have the packages from the MATE repositories installed[1], adding that might be a good idea. Oh, yes, you're right. I completely forgot about Replaces. but mixing different repositories is problematic anyways. Indeed, if a newer version gets uploaded to the MATE repositories people tracking it will likely experience the same problem again. This actually shouldn't happen as the same people who create the MATE Debian packages are also involved with the Debian packages and will perform all further updates to the packages in Debian only, leaving the MATE Debian packages in their old versions. I will talk to Stefano regarding this issue and ask him not to update the packages in MATE's repositories anymore. Thanks for the feedback everyone! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733292: Don't build depends on systemtap-sdt-dev for mips64(el) and mipsn32el
Package: drizzle Severity: wishlist Followup-For: Bug #733292 Fix just commited to the repository. Thanks for reporting, -- coldtobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733519: Cannot use -B to get binary only packages
Package: git-buildpackage Version: 0.6.8 Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi! When using `gbp buildpackage -B`, I get the following error: #+begin_example Building with cowbuilder for distribution wheezy-backports, architecture i386 W: /home/bernat/.pbuilderrc does not exist I: using cowbuilder as pbuilder dpkg-buildpackage: cannot combine -B and -S Use --help for program usage information. gbp:error: Couldn't run 'git-pbuilder -v1.5~dev19-2~bpo70+1 -B': git-pbuilder returned 2 #+end_example I suppose that `-B` should be filtered outwhen trying to build the package source. I am unsure if the problem is in git-buildpackage or in cowbuilder/pbuilder. - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages git-buildpackage depends on: ii devscripts2.13.9 ii git 1:1.8.5.2-1 ii man-db2.6.5-2 ii python2.7.5-5 ii python-dateutil 1.5+dfsg-0.1 ii python-pkg-resources 2.0.1-2 Versions of packages git-buildpackage recommends: ii cowbuilder0.73 ii pristine-tar 1.30 Versions of packages git-buildpackage suggests: ii python-notify 0.1.1-3 ii unzip 6.0-10 - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSwF3zAAoJEJWkL+g1NSX5eiQP/A7dWjdqZ5pYrHLKB4cGZOxI XilU2LGwV2uipvpfTL/bhKXJan8HmBUjAQsNsQW3pmnHD7Jb0i0Z2Hq7QpFgyBqY nkAeHoQfoYSSSyl25tGQ/ZjTiKv8VQgP3DQRF0U+QUnmB5+b7WiTVOktz9B3H6TJ NfwyO99O/qRLDWU5Wl6QOKDbcqEqNjDZF4dLjrzcMb2nSA7yoIXdKITqAJnNIpEU CAOAGVwOHNjO5wub/Kh3nVDCRGsaQNIs8Ur2QPmHPBQEY+WdeaogcRDj3Vz0K9Kc 3gJ25DWuLXBy01rAb9yFA04bpFuXOobUjJuTiXbhLIXHo/DJylo8YLIjUD3ysQle HFmw8yKxOKmiTa/p3uZshyH0WtIBQBuCFaeV5NbkUrKRSms+3Zuj0HSKwRxKHnbp cYOai9fJ6M4BMPx4e5yseY6ElaY7Z1uExYLktkgyEhe42y1bFeoZNZhVD3mcnVop Eijy7mss+kf2aYwW+zD5r2NN+Ta/3fLL3FSL9iURNx4zxclx7CUygVgp5lM2B6Tg 1pIQE1tWw9aUOwHl7gq/l4F/DEu767ZnF/AMblTP7/WF6HFiRiiesb6y902IvzOA XPb8CvNg4n48BOXcQA+1BWVx13LIsQEVLig5D3LSp/aJw51hB+FQeCNPhhHtvLzn PvlxX6/xHS3oxNf8DfTX =Rrhy -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
