Bug#725022: confirmed in Debian wheezy

[Sébastien Villemot]

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

[PhDm]

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

[Jos van Wolput]

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

[Steve Langasek]

On Sat, Dec 28, 2013 at 10:31:32PM -0800, Russ Allbery wrote:
> Uoti Urpala  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 I'

Bug#727708: upstart and upgrading from sysvinit scripts

[Steve Langasek]

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

[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.

-- 
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

[Raphael Hertzog]

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

[Steve Langasek]

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

[Andreas Cadhalpun]

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

[David Moreno]

Guus Sliepen  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

[Steve Langasek]

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

[Moritz Muehlenhoff]

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

[Christof Meerwald]

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

[Josselin Mouette]

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

[Graham Inggs]

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

[Mathieu Malaterre]

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=refdb&arch=i386&ver=1.0.0~pre2-3&stamp=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

[luke]

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

[Tobias Frost]

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

[Tobias Frost]

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)

[Kurt Roeckx]

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

[Tobias Frost]

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

[Tobias Frost]

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)

[Thorsten Alteholz]

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.



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 ...




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

[Jonas Wolz]

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  


-- 
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

[Graham Inggs]

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

[Michael Schaller]

Package: python-apt
Version: 0.9.2
Severity: wishlist
Tags: patch
>From 0d295006a98769cd6151c78b3a078ad92d8047ee Mon Sep 17 00:00:00 2001
From: Michael Wisheu 
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

Bug#664501: Please enable hardened build flags

[Moritz Mühlenhoff]

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

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - 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

[Moritz Muehlenhoff]

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

[Moritz Mühlenhoff]

On Mon, Apr 09, 2012 at 11:54:32AM -0400, Sam Hartman wrote:
> > "Moritz" == Moritz Mühlenhoff  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

[Jörg Frings-Fürst]

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

[Michal Suchanek]

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

[Michal Suchanek]

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

[Wolodja Wentland]

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

[Evgeni Golov]

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   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 
+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 @@
++
++
++
++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">
++  
++
++  
++  
++
++
++  
++  
++
++
++  
++  
++
++
++  
++  
++
++
++  
++
++
++
++
++
++  
++  
++
++  
++  
++
++  
++image/svg+xml
++http://purl.org/dc/dcmitype/StillImage"; />
++http://creativecommons.org/licenses/GPL/2.0/"; />
++
++  
++  http://creativecommons.org/licenses/GPL/2.0/";>
++http://web.resource.org/cc/Reproduction"; />
++http://web.resource.org/cc/Distribution"; />
++http://web.resource.org/cc/Notice"; />
++http://web.resource.org/cc/DerivativeWorks"; />
++http://web.resource.org/cc/ShareAlike"; />
++http://web.resource.org/cc/SourceCode"; />
++  
++
++  
++  
++
++  
++  
++  
++  
++  
++  
++
++
++  
++
++  
++  
++  
++  
++
++  
++
++  
++
+diff --git a/data/icons/hicolor/scalable/status/blueman-tray.svg b/data/icons/hicolor/scalable/status/blueman-tray.svg
+new file mode 100644
+index 000..3624a88
+--- /dev/null
 b/data/icons/hicolor/scalable/status/blueman-tray.svg
+@@ -0,0 +1,234 @@
++
++
++http://purl.org/dc/elements/1.1/";
++   xmlns:cc="http://web.resource.org/cc/";
++   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.o

Bug#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies

[michael]

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

[Mathieu Malaterre]

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

[ael]

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

[Adam Conrad]

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

[Camaleón]

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 , 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 \n"
"Language-Team: Debian Spanish \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

[Moritz Muehlenhoff]

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

[Galym Kerimbekov]

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

[Camaleón]

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 , 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 \n"
"Language-Team: Debian Spanish \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
#: ../p

Bug#733498: [INTL:es] Spanish translation of debconf messages

[Camaleón]

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 , 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 \n"
"Language-Team: Debian Spanish \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

[Torquil Macdonald Sørensen]

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 
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 
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  
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
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

[ael]

xorg.conf includes:-


Section "InputClass"
Identifier  "marble_FX"
Driver  "evdev"
MatchProduct"ImExPS/2 Logitech Explorer Mouse|Logitech USB 
Trackball|PS2++ Logitech Mouse|PS2++ Logitech TrackMan"
MatchIsPointer  "true"
#   Option  "Protocol"  "ExplorerPS/2"
Option  "EmulateWheel"  "true"
Option  "EmulateWheelButton""8"
#   Option  "EmulateWheelTimeout"   "300"
Option  "XAxisMapping"  "6 7"
Option  "YAxisMapping"  "4 5"
Option  "ZAxisMapping"  "4 5"

EndSection

Section "InputClass"
Identifier  "marble"
Driver  "evdev"
MatchProduct"ImExPS/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

[Colin Watson]

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

[Santhosh Thottingal]

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

[Neil Williams]

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

[Laurent Bigonville]

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'

[Roland Stigge]

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'

[Roland Stigge]

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

[Aurelien Jarno]

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=busybox&arch=mips&ver=1%3A1.21.0-6exp&stamp=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

[Daniel Baumann]

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

[Modestas Vainius]

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 >From 650fb20f67028f92c0a36acd2a95fc45bc8ae361 Mon Sep 17 00:00:00 2001
From: Modestas Vainius 
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   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

[Colin Watson]

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

[Yves-Alexis Perez]

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

[Faidon Liambotis]

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

[GCS]

On Sun, Dec 29, 2013 at 2:46 PM, Faidon Liambotis  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 
 * 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

[Harald Dunkel]

-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

[Thorsten Glaser]

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  procmail

-- 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

[Vasudev Kamath]

Santhosh Thottingal  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

[Laurent Bigonville]

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

[Steve Kemp]

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 2>&1| 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  

-- 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

[Francesco Poli]

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

[Matthias Wimmer]

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

[Matthias Pronk]

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 Descripto

Bug#733508: Unsets LD_LIBRARY_PATH from child processes

[Uli Schlachter]

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  
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.

[slawomir_1992]

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

[Tollef Fog Heen]

]] 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

[Francesco Poli]

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  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]

[Tollef Fog Heen]

]] 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

[gregor herrmann]

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

[pkg-perl-maintainers]

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

[Frank McCormick]

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

[Marco d'Itri]

On Dec 07, Sebastian Schmidt  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

[Leo]

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': 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': 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 
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 Release: jessie/sid
500 wheezy-backports mozilla.debian.net
500 wheezy linux.drop

Bug#733323: rxvt-unicode-256color: urxvt spawns an extra process.

[Jean-Pierre De Schacht]

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

[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, 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

[Balint Reczey]

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]

]] 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

[Thomas Koch]

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 
* 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

[Christian Hofstaedtler]

> 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 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



signature.asc
Description: Digital signature

Bug#733061: Info

[Sébastien Delafond]

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

[Jakub Wilk]

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

[Hideki Yamane]

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

[Sébastien Delafond]

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

[Franklin McCormick]

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

[Florian Roscher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 29.12.13 17:11, schrieb Marco d'Itri:
> On Dec 07, Sebastian Schmidt  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

[Vincent Bernat]

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

[John Paul Adrian Glaubitz]

(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

[Uoti Urpala]

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

[coldtobi]

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 
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

[Johannes Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer 

* 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

[Balint Reczey]

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

[Sven Joachim]

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

[John Paul Adrian Glaubitz]

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

[Tobias Frost]

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

[Vincent Bernat]

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