Bug#738950: selinux-policy-default: mailman qrunner starting in initrc_t

[Devin Carraway]

Package: selinux-policy-default
Version: 2:2.20140206-1
Severity: normal

mailman's qrunner and friends aren't being properly labelled and so aren't
transitioning properly on startup:

system_u:system_r:initrc_t:s03523 ?S  0:00 /usr/bin/python 
/var/lib/mailman/bin/qrunner --runner=ArchRunner:0:1 -s
system_u:system_r:initrc_t:s03524 ?S  0:00 /usr/bin/python 
/var/lib/mailman/bin/qrunner --runner=BounceRunner:0:1 -s
system_u:system_r:initrc_t:s03525 ?S  0:00 /usr/bin/python 
/var/lib/mailman/bin/qrunner --runner=CommandRunner:0:1 -s
system_u:system_r:initrc_t:s03526 ?S  0:00 /usr/bin/python 
/var/lib/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s
system_u:system_r:initrc_t:s03527 ?S  0:00 /usr/bin/python 
/var/lib/mailman/bin/qrunner --runner=NewsRunner:0:1 -s
system_u:system_r:initrc_t:s03528 ?S  0:00 /usr/bin/python 
/var/lib/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s
system_u:system_r:initrc_t:s03529 ?S  0:00 /usr/bin/python 
/var/lib/mailman/bin/qrunner --runner=VirginRunner:0:1 -s
system_u:system_r:initrc_t:s03530 ?S  0:00 /usr/bin/python 
/var/lib/mailman/bin/qrunner --runner=RetryRunner:0:1 -s

These are actually started via /usr/lib/mailman/bin/mailmanctl.  FC rules say 
to label that as mailman_mail_exec_t and qrunner as mailman_queue_exec_t, but 
neither is labelled that way with
the mailman module 1.10.0 installed:

-rwxr-xr-x. 1 root list system_u:object_r:bin_t:SystemLow 21412 Feb  3 05:30 
/usr/lib/mailman/bin/mailmanctl
-rwxr-xr-x. 1 root list system_u:object_r:bin_t:SystemLow  9612 Feb  3 05:30 
/usr/lib/mailman/bin/qrunner

The reason may be that they're losing a specificity contest with a conflicting 
FC rule; if the .* is removed from the path in the .fc for those files, it gets 
labelled correctly:

/usr/lib/mailman.*/bin/qrunner  --  
gen_context(system_u:object_r:mailman_queue_exec_t,s0)


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.12-1-amd64 (SMP w/8 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 selinux-policy-default depends on:
ii  libpam-modules   1.1.3-9
ii  libselinux1  2.2.2-1
ii  libsepol12.2-1
ii  policycoreutils  2.2.5-1
ii  python   2.7.5-5
ii  selinux-utils2.2.2-1

Versions of packages selinux-policy-default recommends:
ii  checkpolicy  2.2-1
ii  setools  3.3.8-3

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

-- Configuration Files:
/etc/selinux/default/modules/active/file_contexts.local [Errno 13] Permission 
denied: u'/etc/selinux/default/modules/active/file_contexts.local'

-- 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#737594: kiten: Kiten still leaks memory

[Daniel Palmer]

Sorry for not replying sooner. The mail went in my spam...

I will test your patched version. If its useful I can give a list of
Japanese words etc that you can use to try to trigger leaks?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#736394: [BTS#736394] templates://chef/{chef.templates} : Final update for English review

[Christian PERRIER]

Dear Debian maintainer,

On Monday, January 27, 2014, I notified you of the beginning of a review process
concerning debconf templates for chef.

The debian-l10n-english contributors have now reviewed these templates,
and the final proposed changes are attached to this update to the
original bug report.

Please review the suggested changes, and if you have any
objections, let me know in the next 3 days.

However, please try to avoid uploading chef with these changes
right now.

The second phase of this process will begin on Monday, February 17, 2014, when 
I will
coordinate updates to translations of debconf templates.

The existing translators will be notified of the changes: they will
receive an updated PO file for their language.

Simultaneously, a general call for new translations will be sent to
the debian-i18n mailing list.

Both these calls for translations will request updates to be sent as
individual bug reports. That will probably trigger a lot of bug
reports against your package, but these should be easier to deal with.

The call for translation updates and new translations will run until
about Monday, March 10, 2014. Please avoid uploading a package with fixed or 
changed
debconf templates and/or translation updates in the meantime. Of
course, other changes are safe.

Please note that this is an approximative delay, which depends on my
own availability to process this work and is influenced by the fact
that I simultaneously work on many packages.

Around Tuesday, March 11, 2014, I will contact you again and will send a final 
patch
summarizing all the updates (changes to debconf templates,
updates to debconf translations and new debconf translations).

Again, thanks for your attention and cooperation.


-- 


# These templates have been reviewed by the debian-l10n-english
# team
#
# If modifications/additions/rewording are needed, please ask
# debian-l10n-engl...@lists.debian.org for advice.
#
# Even minor modifications require translation updates and such
# changes should be coordinated with translators and reviewers.

Template: chef/chef_server_url
Type: string
_Description: URL of Chef server
 Please choose the full URI that clients will use to connect to the
 server (for instance: http://chef.example.com:4000).
 .
 This setting will be stored in /etc/chef/client.rb as
 "chef_server_url".
Source: chef
Section: ruby
Priority: optional
Maintainer: Debian Ruby Extras Maintainers 

Uploaders: Tollef Fog Heen 
Build-Depends: debhelper (>= 8.2), gem2deb (>= 0.2.13~), po-debconf
Standards-Version: 3.9.5
Vcs-Git: git://anonscm.debian.org/pkg-ruby-extras/chef.git
Vcs-Browser: 
http://anonscm.debian.org/gitweb?p=pkg-ruby-extras/chef.git;a=summary
Homepage: http://wiki.opscode.com/display/chef
XS-Ruby-Versions: all

Package: chef
Architecture: all
XB-Ruby-Versions: ${ruby:Versions}
Depends:
 chef-zero (>= 1.6.2),
 erubis (>= 2.7),
 ohai (>= 6),
 ruby | ruby-interpreter,
 ruby-diff-lcs (>= 1.2.4),
 ruby-highline (>= 1.6.9),
 ruby-json (>= 1.4.4),
 ruby-mixlib-authentication (>= 1.3),
 ruby-mixlib-cli (>= 1.3),
 ruby-mixlib-config (>= 2),
 ruby-mixlib-log (>= 1.3),
 ruby-mixlib-shellout (>= 1.2),
 ruby-net-ssh (>= 1:2.6),
 ruby-net-ssh-multi (>= 1.1),
 ruby-rest-client (<< 1.7.0),
 ruby-rest-client (>= 1.0.4),
 ruby-yajl (>= 1.1),
 ucf,
 ${misc:Depends},
 ${shlibs:Depends}
Provides: libchef-ruby, libchef-ruby1.8
Conflicts: libchef-ruby (<< 0.10.10-1~), libchef-ruby1.8 (<< 0.10.10-1~)
Replaces: libchef-ruby (<< 0.10.10-1~), libchef-ruby1.8 (<< 0.10.10-1~)
Breaks: chef-solr (<< 11)
Description: Chef systems integration framework - clients
 Chef is a systems integration framework and configuration management library
 written in Ruby. Chef provides a Ruby library and API that can be used to
 bring the benefits of configuration management to an entire infrastructure.
 .
 Chef can be run as a client (chef-client) to a server, or run as a standalone
 tool (chef-solo). Configuration recipes are written in a pure Ruby DSL.
 .
 This package provides the chef-client, chef-solo, and knife binaries as well
 as the Chef library.
--- chef.old/debian/chef.templates  2014-01-23 08:57:23.092735010 +0100
+++ chef/debian/chef.templates  2014-02-14 07:10:55.300561519 +0100
@@ -1,7 +1,17 @@
+# These templates have been reviewed by the debian-l10n-english
+# team
+#
+# If modifications/additions/rewording are needed, please ask
+# debian-l10n-engl...@lists.debian.org for advice.
+#
+# Even minor modifications require translation updates and such
+# changes should be coordinated with translators and reviewers.
+
 Template: chef/chef_server_url
 Type: string
-_Description: URL of Chef Server (e.g., http://chef.example.com:4000):
-  This is the full URI that clients will use to connect to the
-  server.
-  .
-  This will be used in /etc/chef/client.rb as 'chef_server_url'.
+_Description: URL of Chef server
+ Please choose the full URI that clients will use to connect to the
+ server (for instance: http://chef.example.com:4000

Bug#733087: apt-cacher-ng: General update after the debconf review process

[Christian PERRIER]

Dear Debian maintainer,

On Wednesday, January 01, 2014, I sent you a notification about the beginning 
of a review
action on debconf templates for apt-cacher-ng.

Then, I sent you a bug report with rewritten templates and announcing
the beginning of the second phase of this action: call for translation
updates.

Translators have been working hard and here is now the result of their efforts.

Please consider using it EVEN if you committed files to your
development tree as long as they were reported.

The attached tarball contains:

- debian/changelog with the list of changes
- debian/control with rewrites of packages' descriptions
- debian/ with all the rewritten templates file(s)
- debian/po/*.po with all PO files (existing ones and new ones)

As said, please use *at least* the PO files as provided here,
preferrably over those sent by translators in their bug reports. All
of them have been checked and reformatted. In some cases, formatting
errors have been corrected.

The patch.rfr file contains a patch for the templates and control
file(s) alone.

Please note that this patch applies to the templates and control
file(s) of your package as of Wednesday, January 01, 2014. If your package was 
updated
in the meantime, I may have updated my reference copybut I also
may have missed that. This is indeed why I suggested you do not
modified such files while the review process was running,
remember..:-)

It is now safe to upload a new package version with these changes.

Please notify me of your intents with regards to this. 

There is of course no hurry to update your package but feel free to
contact me in case you would need sponsoring or any other action to
fix this.



-- 




patch.tar.gz
Description: Binary data
--- apt-cacher-ng.old/debian/apt-cacher-ng.templates2013-12-21 
08:43:11.800788971 +0100
+++ apt-cacher-ng/debian/apt-cacher-ng.templates2014-01-21 
08:12:15.850720163 +0100
@@ -15,11 +15,12 @@
  Apt-Cacher NG can download packages from repositories other than those
  requested by the clients. This allows it to cache content effectively,
  and makes it easy for an administrator to switch to another mirror later.
+ The URL remapping can be set up automatically, using a configuration
+ based on the current state of /etc/apt/sources.list.
  .
- This remapping of URLs can be configured now in an automated way based on the
- current state of /etc/apt/sources.list. Optionally, this process can be
- repeated on every package update (modifying the configuration files each
- time).
+ Please specify whether the remapping should be configured once now, or
+ reconfigured on every update of Apt-Cacher NG (modifying the
+ configuration files each time), or left unconfigured.
  .
  Selecting "No automated setup" will leave the existing configuration
  unchanged. It will need to be updated manually.
@@ -27,12 +28,16 @@
 Template: apt-cacher-ng/bindaddress
 Type: string
 Default: keep
-_Description: Bind Address(es):
- Addresses or hostnames to listen on, multiple entries must be separated
- by spaces. Each entry must be an exact address (IP or hostname) which is
- associated with a local network interface. Generic protocol specific addresses
- are supported, like 0.0.0.0 for listening on all IPv4 enabled interfaces.
- Leaving this empty (the default setting) means listening on all interfaces 
and protocols.
+_Description: Listening address(es) for Apt-Cacher NG:
+ Please specify the local addresses that Apt-Cacher NG should listen on
+ (multiple entries must be separated by spaces).
+ .
+ Each entry must be an IP address or hostname associated with a local
+ network interface. Generic protocol-specific addresses are also
+ supported, such as 0.0.0.0 for listening on all IPv4-enabled interfaces.
+ .
+ If this field is left empty, Apt-Cacher NG will listen on all
+ interfaces, with all supported protocols.
  .
  The special word "keep" keeps the value from the current (or default)
  configuration unchanged.
@@ -41,30 +46,34 @@
 Type: string
 Default: keep
 _Description: Listening TCP port:
- Configure at which TCP port should Apt-Cacher NG listen for incoming HTTP
- (proxy) requests. Default is port 3142, and it can be set to  to emulate
- apt-proxy.
+ Please specify the TCP port that Apt-Cacher NG should listen on for
+ incoming HTTP (proxy) requests. The default value is port 3142, but it
+ can be set to  to emulate apt-proxy.
  .
- If left empty, the value from the current configuration remains unchanged.
+ If this field is left empty, the value from the current configuration
+ remains unchanged.
 
 Template: apt-cacher-ng/cachedir
 Type: string
 Default: keep
-_Description: Top level directory for package cache:
+_Description: Top-level directory for package cache:
  The main cache storage directory should be located on a file system without
  file name restrictions.
  .
- If left empty, the value from the current configuration remains unchanged or
- is set to default directory /var/cache/a

Bug#737594: kiten: Kiten still leaks memory

[Maximiliano Curia]

¡Hola Daniel!

El 2014-02-14 a las 16:59 +0900, Daniel Palmer escribió:
> I will test your patched version. If its useful I can give a list of
> Japanese words etc that you can use to try to trigger leaks?

Yes, sure, also if you can send a detailed list of steps to trigger a major
memory leak I can try to patch it.


-- 
"A computer program does what you tell it to do, not what you want it to do."
-- Greer's Law
Saludos /\/\ /\ >< `/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738951: sa-compile: post-installation script fails: Only one of PREFIX or INSTALL_BASE can be given

[Vincent Lefevre]

Package: sa-compile
Version: 3.3.2-8
Severity: grave
Justification: renders package unusable

I get the following error:

Setting up sa-compile (3.3.2-8) ...
Running sa-compile (may take a long time)
Only one of PREFIX or INSTALL_BASE can be given.  Not both.
command '/usr/bin/perl Makefile.PL 
PREFIX=/tmp/.spamassassin25665jgQStqtmp/ignored 
INSTALLSITEARCH=/var/lib/spamassassin/compiled/5.018/3.003002 
>>/tmp/.spamassassin25665jgQStqtmp/log' failed: exit 255
dpkg: error processing package sa-compile (--configure):
 subprocess installed post-installation script returned error exit status 25

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sa-compile depends on:
ii  gcc   4:4.8.2-2
ii  libc6-dev 2.17-97
ii  make  3.81-8.3
ii  re2c  0.13.5-1
ii  spamassassin  3.3.2-8

sa-compile recommends no packages.

sa-compile 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#738855: initscripts: Skip killing root-owned process starting with @

[Helmut Grohne]

On Fri, Feb 14, 2014 at 12:28:52AM +, Dimitri John Ledkov wrote:
> Thanks a lot for the review!

Hmm. Maybe you can hold this patch off for a little longer?

Pulling in oss-sec, because I am no longer sure that the remedy
addresses all relevant aspects. Summary of previous discussion follows
for oss-sec:

Dimitri Ledkov asked for the initscripts package to exempt root-owned
processes whose process name starts with an '@' from being killed in the
sendsigs script during shutdown. This support would make initscripts a
little more compatible with systemd, which is a good thing! The relevant
systemd documentation can be found at:
http://www.freedesktop.org/wiki/Software/systemd/RootStorageDaemons/

However, I doubt that the proposed restriction (effective UID of process
equals 0) is sufficient. For example in a SELinux context being root may
mean significantly less. Russel Coker runs a machine where you can log
into as root remotely, see http://www.coker.com.au/selinux/play.html. In
this context allowing user processes to not be killed merely by changing
their name could cause data loss during shutdown by blocking umount. I
do not understand the consequences of the above technique in other
security extension contexts, so I am asking here for help.

The alternative mechanism currently used by initscripts is to allow
daemons to write their PID to /run/sendsigs.omit.d/$daemon. Being a
file-based approach, it can be easily controlled in the SELinux context
using restorecon.

Another aspect of interest could be processes running as root with their
capability bounding set cleared or reduced.

So dear oss-sec readers, do you think that allowing processes whose
effective UID is 0 to not being killed during shutdown is a good idea?

If the answer is no, then please assign a CVE identifier for systemd
(version 38+, src/core/killall.c).

Helmut


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#735898: pavucontrol segmentation fault

[Vincent Lefevre]

On 2014-02-14 02:40:36 -0500, John M. wrote:
> By creating a new user account, I'm able to open pavucontrol from that
> account, but only until I log out and in again. Then it's back to
> segmentation fault.
> 
> So it seems like the problem is related to a setting in some other
> program (gconf? dconf? gstreamer? jack?).

You can try to see with strace.

-- 
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#738952: tahoe-lafs: Incorrect dependency python-pycryptopp (>= 0.5.29) version (>= 0.6.0 required)

[Roger Pueyo Centelles]

Package: tahoe-lafs
Version: 1.10.0-1
Severity: important

Dear Maintainer,

I've just tried to upgrade to tahoe-lafs 1.10-1 in Sid from the previous 
1.9.2-1 in Wheezy. Apparently, all
the dependencies were met, and the package installed without trouble.

However, when trying to create an introducer/storage/client, it seems like 
python-pycryptopp version required
is at least 0.6.0 (instead of 0.5.29 as stated). Please check this error 
message:

Traceback (most recent call last):
  File "/usr/bin/tahoe", line 3, in 
from allmydata.scripts import runner
  File "/usr/lib/python2.7/dist-packages/allmydata/__init__.py", line 380, in 

check_all_requirements()
  File "/usr/lib/python2.7/dist-packages/allmydata/__init__.py", line 378, in 
check_all_requirements
raise PackagingError(get_error_string(errors, debug=True))
allmydata.PackagingError: 
PackagingError: We require pycryptopp >= 0.6.0, but could only find version 
0.5.29.
The version we found is from '/usr/lib/python2.7/dist-packages'.
To resolve this problem, uninstall that version, either using your
operating system's package manager or by moving aside the directory.

For debugging purposes, the PYTHONPATH was
  None
install_requires was
  ['setuptools >= 0.6c6', 'zfec >= 1.1.0', 'simplejson >= 1.4', 'zope.interface 
== 3.6.0, == 3.6.1, == 3.6.2, >= 3.6.5', 'Twisted >= 11.0.0', 'foolscap >= 
0.6.3', 'pyOpenSSL', 'Nevow >= 0.6.0', 'pycrypto == 2.1.0, == 2.3, >= 2.4.1', 
'pyasn1 >= 0.0.8a', 'mock >= 0.8.0', 'pycryptopp >= 0.6.0']
sys.path after importing pkg_resources was
  /usr/bin:
  /usr/lib/python2.7:
  /usr/lib/python2.7/plat-linux2:
  /usr/lib/python2.7/lib-tk:
  /usr/lib/python2.7/lib-old:
  /usr/lib/python2.7/lib-dynload:
  /usr/local/lib/python2.7/dist-packages:
  /usr/lib/python2.7/dist-packages:
  /usr/lib/pymodules/python2.7


Regards,

Roger


-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages tahoe-lafs depends on:
ii  net-tools  1.60-24.2
ii  python 2.7.3-4+deb7u1
ii  python-crypto  2.6-4+deb7u3
ii  python-foolscap0.6.4-1
ii  python-mock0.8.0-3
ii  python-nevow   0.10.0-4
ii  python-openssl 0.13-2+deb7u1
ii  python-pkg-resources   0.6.24-1
ii  python-pyasn1  0.1.3-1
ii  python-pycryptopp  0.5.29-1
ii  python-setuptools  0.6.24-1
ii  python-simplejson  2.5.2-1
ii  python-twisted 12.0.0-1
ii  python-zfec1.4.5-2
ii  python-zope.interface  3.6.1-3

tahoe-lafs recommends no packages.

tahoe-lafs 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#738835: "Satellite" config vs null client config

[Daniel Pocock]

The Debian package of Postfix offers a "Satellite system" configuration
(a list of all the Debian configs at the bottom of this email)

I'm not sure if this is meant to emulate the null client configuration
or be something else

Anyway, I opened an issue for it in the Debian bug tracker

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738835

One particular thing I notice about all the configurations offered in Debian is 
that they all set mydestination using the hostname, e.g.

   mydestination = host1.example.org, localhost.example.org, host1, localhost

instead of leaving mydestination blank.

Is there any compelling reason to have these entries in mydestination?

Are there other common applications (either in Debian or elsewhere) that are 
explicitly sending mail to root@$HOSTNAME or root@localhost rather than just 
the unqualified recipient name root for example?



No configuration:  
  Should be chosen to leave the current configuration unchanged.
Internet site: 
  Mail is sent and received directly using SMTP.
Internet with smarthost:   
  Mail is received directly using SMTP or by running a utility such 
  as fetchmail. Outgoing mail is sent using a smarthost.
Satellite system:  
  All mail is sent to another machine, called a 'smarthost', for
  delivery.   
Local only:
  The only delivered mail is the mail for local users. There is no  
  network.   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#735600: ekiga: Segmentation fault after libpt2.10.10 upgrade

[Eugen Dedu]

On 10/02/14 23:49, Sylvain BOILARD wrote:

notfixed 735600 2.10.10~dfsg-4
thanks


Hi,

I still encounter crashes seemingly caused by libpt with Ekiga.

Here is the backtrace I get when Ekiga crashes after the program has
ran for a while:


We plan to use a newer version of ptlib very soon, which had many fixes. 
 I am pretty sure this bug is fixed, since I remember some changes on 
Contacts.


I suggest to wait until this new release appears.

Your crash is not related to ptlib upgrade, as far as I see.  Are you 
sure that you did not have the crash before, and now you have it?


--
Eugen


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#538655: asciidoc: unstable conversion rule for ' (2009) ==> worth working on that?

[Osamu Aoki]

Hi,

On Thu, Feb 13, 2014 at 03:12:53PM +0100, Joseph Herlant wrote:
> Hi Osamu,
> 
> Sure I can keep the bug opened, but could you provide an example to
> reproduce the issue please?
> Just to verify there's not a built-in solution that could avoid the
> need of cleaning all doc.

I did digging several years ago.  So my memory is vague.

Issue is related to the one documented in changelog for Version 8.3.0 
(2008-11-29):
...
  25.1. Compatibility issues

   Version 8.3.0 has a number of backward incompatibilities with respect
   to the previous 8.2.7 release:
 ...
 * The introduction of single-quote quoting requires that double-quote
   quoting is escaped with two backslashes.


Something between ` ... ` are now not required to be escaped even for
some characters like * now but we needed escape for such characters.

When I find time, I will chack it.

Osamu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738953: maint-guide: Address dh_bugfiles and reportbug documrentation

[Osamu Aoki]

Package: maint-guide
Version: 1.2.32
Severity: normal

Some hints for:
 * /usr/share/bugs//{script,presubj,control}
 * dh_bugfiles
 * README.developers.gz (repoortbug)

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (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

maint-guide depends on no packages.

maint-guide recommends no packages.

Versions of packages maint-guide suggests:
ii  debian-policy 3.9.5.0
ii  developers-reference  3.4.11
ii  devscripts2.14.1
ii  dh-make   0.63
ii  doc-base  0.10.5
ii  dput  0.9.6.4
ii  fakeroot  1.20-3
ii  lintian   2.5.21
ii  pbuilder  0.215
ii  quilt 0.61-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#738954: salt-minion: file.find crashes on dangling symlinks

[Avinash Sultanpur]

Package: salt-minion
Version: 0.16.4-2~bpo70+1
Severity: important

salt-call throws up an error when it encounters a dangling
symlink. The bug was fixed upstream:

 https://github.com/saltstack/salt/issues/2830

$ sudo salt-call -l quiet --local file.find /tmp type=d
Traceback (most recent call last):
  File "/usr/bin/salt-call", line 11, in 
salt_call()
  File "/usr/lib/python2.7/dist-packages/salt/scripts.py", line 76, in salt_call
client.run()
  File "/usr/lib/python2.7/dist-packages/salt/cli/__init__.py", line 265, in run
caller.run()
  File "/usr/lib/python2.7/dist-packages/salt/cli/caller.py", line 132, in run
ret = self.call()
  File "/usr/lib/python2.7/dist-packages/salt/cli/caller.py", line 73, in call
ret['return'] = func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/salt/modules/file.py", line 480, in 
find
ret = [p for p in finder.find(path)]
  File "/usr/lib/python2.7/dist-packages/salt/utils/find.py", line 555, in find
fstat = os.stat(fullpath)
OSError: [Errno 13] Permission denied: '/tmp/link'

Please include the fix in the deb.


-- System Information:
Debian Release: 7.2
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'stable-updates')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages salt-minion depends on:
ii  dctrl-tools   2.22.2
ii  python2.7.3-4+deb7u1
ii  python-pkg-resources  0.6.24-1
ii  salt-common   0.16.4-2~bpo70+1

Versions of packages salt-minion recommends:
ii  dmidecode  2.11-9

Versions of packages salt-minion suggests:
pn  python-augeas  

-- 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#738955: goldendict: Goldendict works incorrectly after dictd dictionary update

[Nikolay Shaplov]

Package: goldendict
Version: 1.5.0~git20131003-1
Severity: normal

Goldendict works incorrectly after dictd dictionary update

1. remove ~/.goldendict

2. install dict-freedict-eng-rus package from stable 
http://ftp.us.debian.org/debian/pool/main/f/freedict/dict-freedict-eng-rus_1.3-4_all.deb

3. run goldendict, configure it to use dict-freedict-eng-rus, try to open 
"free" article, you should success.

4. Close goldendict (and remove it from tray, make shure that ps aux |grep 
goldendict does now show any goldendict process)

5. Install dict-freedict-eng-rus from unstable
http://ftp.us.debian.org/debian/pool/main/f/freedict/dict-freedict-eng-rus_2013.11.30-1_all.deb

6. Run goldendict and try to see "free" article now. It will show you article
===
fragrant /frəgrənt/
 ароматически; ароматичны
===
inside "free" tab.

And this is a BUG! Goldendict should work properly even after dist-upgrade.

7. If I delete ~/.goldendict and reconfigure it again, package from 
unstable would work well.


I think it should either check file creation dates and sizes on startup, and 
if it is changed do indexes rescan (this preferable) or goldendict package 
should somehow provide something like "on dict updated" hook, so freedict 
package can inform it, that dict were updated and goldendict should reindex 
it.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages goldendict depends on:
ii  libao4   1.1.0-2
ii  libavcodec-extra-54  6:9.10-2
ic  libavcodec54 6:9.10-2
ii  libavformat546:9.10-2
ii  libavutil52  6:9.10-2
ii  libbz2-1.0   1.0.6-5
ii  libc62.17-97
ii  libgcc1  1:4.8.2-10
ii  libhunspell-1.3-01.3.2-6
ii  liblzo2-22.06-1.2
ii  libogg0  1.3.1-1
ii  libqt4-network   4:4.8.5+git192-g085f851+dfsg-2
ii  libqt4-svg   4:4.8.5+git192-g085f851+dfsg-2
ii  libqt4-xml   4:4.8.5+git192-g085f851+dfsg-2
ii  libqtcore4   4:4.8.5+git192-g085f851+dfsg-2
ii  libqtgui44:4.8.5+git192-g085f851+dfsg-2
ii  libqtwebkit4 2.2.1-7
ii  libstdc++6   4.8.2-10
ii  libvorbis0a  1.3.2-1.3
ii  libvorbisfile3   1.3.2-1.3
ii  libx11-6 2:1.6.2-1
ii  libxtst6 2:1.2.2-1
ii  zlib1g   1:1.2.8.dfsg-1

goldendict recommends no packages.

Versions of packages goldendict suggests:
pn  goldendict-wordnet  

-- 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#738957: dpkg-maintscript-helper: prepare_dir_to_symlink can never succeed

[Richard Levitte]

Package: dpkg
Version: 1.17.6
Severity: important
Tags: patch

Dear Maintainer,

This is a problem that I encountered when trying to upgrade php-aws-sdk from
1.5.6.2-1 to 2.5.2-1, I would get these messages (the first repeats a large
number of times):

Preparing to unpack .../php-aws-sdk_2.5.2-1_all.deb ...
check-files-ownership: line 6: return: can only `return' from a function or
sourced script
[ ... the previous line repeats over 30 times ... ]
dpkg-maintscript-helper: error: directory '/usr/share/php/AWSSDKforPHP'
contains files not owned by package php-aws-sdk:all, cannot switch to symlink
dpkg: error processing archive /var/cache/apt/archives/php-aws-
sdk_2.5.2-1_all.deb (--unpack):
 subprocess new pre-installation script returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/php-aws-sdk_2.5.2-1_all.deb

I went looking in /usr/bin/dpkg-maintscript-helper, and found this snippet of
code in prepare_dir_to_symlink:

find "$PATHNAME" -print0 | xargs -0 -n1 sh -c '
package="$1"
file="$2"
if ! dpkg-query -L "$package" | grep -q -x "$file"; then
return 1
fi
return 0
' check-files-ownership "$PACKAGE" || \
error "directory '$PATHNAME' contains files not owned by" \
  "package $PACKAGE, cannot switch to symlink"

The code performed with sh -c will never be able to succeed, easily
demonstrated as follows:

: ; sh -c 'return 0'
sh: line 0: return: can only `return' from a function or sourced script
: ; echo $?
1

However, using exit works, as expected:

: ; sh -c 'exit 0'
: ; echo $?
0

After changing /usr/bin/dpkg-maintscript-helper to use exit instead of return
in the code shown above, php-aws-sdk upgraded with no problems.

Patch included



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=sv_SE.utf8, LC_CTYPE=sv_SE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-5
ii  libc62.17-97
ii  liblzma5 5.1.1alpha+20120614-2
ii  libselinux1  2.2.2-1
ii  tar  1.27.1-1
ii  zlib1g   1:1.2.8.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  0.9.15.2

-- no debconf information
--- /usr/bin/dpkg-maintscript-helper.orig	2014-02-14 09:49:53.0 +0100
+++ /usr/bin/dpkg-maintscript-helper	2014-02-14 09:51:47.0 +0100
@@ -394,9 +394,9 @@
 		package="$1"
 		file="$2"
 		if ! dpkg-query -L "$package" | grep -q -x "$file"; then
-			return 1
+			exit 1
 		fi
-		return 0
+		exit 0
 	' check-files-ownership "$PACKAGE" || \
 		error "directory '$PATHNAME' contains files not owned by" \
 		  "package $PACKAGE, cannot switch to symlink"

Bug#738956: debconf: Specifying `Frontend` in `debconf.conf` fails

[Paul Menzel]

Package: debconf
Version: 1.5.49
Severity: normal

Dear Debian folks,


from the manual page of `debconf.conf` (`man 5 debconf.conf`).

   Additional fields that can be used include:

  Frontend
 The frontend Debconf should use, overriding any frontend 
set in the debconf database.

After `echo "Frontend: Teletype" >> /etc/debconf.conf` running any DPKG
related thinks an error is thrown.

If I am doing anything wrong, it would be great if an example could be
added to the manual page.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part

Bug#727708: init system coupling etc.

[Josselin Mouette]

Le jeudi 13 février 2014 à 23:47 -0800, Russ Allbery a écrit : 
> > (B) Someone writes a GUI for accessing journald files on the hard drive.
> 
> Depending on how this is written, it may depend on the package providing
> journalctl or it may depend on some shared library that implements the
> journal reading code, or it might even have no dependencies at all if it
> implements the journal reading code itself.

This is not a hypothetical case. It exists, and it uses journald
directly. The software will not start if systemd is not PID 1. Note that
this is part of what we’d like to put in the gnome metapackage, so
forbidding this has real impact on real packages for jessie.

> > (E) GNOME depends on logind interfaces and there is not working
> > alternative logind (>=205) implementation available.
> 
> (I don't know of any reason why GNOME would specifically need to depend on
> a post-205 logind at this point, so I'm replying to this without the
> parenthetical.)

This will certainly happen one day or another, but probably not for
jessie.

This (not isolated) case raises the point of package-level management of
non-library interfaces, with versions. We might need to set a policy on
this kind of cases. For example, should we generalize situations such
as:
* systemd-sysv Provides: systemd204, systemd207, … 
* foo Depends: systemd-sysv (>= 204) | systemd204

> > (F) GNOME depends on logind interfaces and somebody stepped up and
> > created a logind implementation for other init systems.
> 
> In this case, I think GNOME should allow either implementation to satisfy
> its dependency.  I think that's uncontroversial across the board,
> including with the GNOME maintainers.

This is indeed uncontroversial, except for the part that the non-systemd
case would be unsupported from the GNOME side.

I’m just not seeing this happening (see at the bottom).

> It's possible that, in the long, long run, GNOME will want to depend on
> systemd to use systemd for session management, but it's already been clear
> on this thread that this won't happen for jessie, and it's not at all
> clear whether this will ever be necessary or whether there will always be
> a fallback available.  It is obvious, at least as I understand it, that
> this won't be necessary or something anyone is considering for jessie.

It has already been made clear that this WILL happen for jessie, but
that a fallback (either in the same package or another one) can be made
available.

> We have one specific issue around logind that is likely to affect GNOME
> and KDE and possibly others, and we've talked about the solutions in
> detail and Steve is confident that we can solve this issue for sysvinit
> for jessie.

The only available solution so far involves keeping a systemd 204
package, which will not happen. With systemd as the default init system,
the systemd maintainers will try to have the latest version integrated.

So either Steve and his cronies commit to maintain a separate systemd204
package (with all the switching issues that scenario involves), or they
deliver their so-far vaporware to work over systemd >= 205. Or it just
doesn’t work, which is what will probably happen.

In all cases, it is unacceptable to put the burden of implementing
logind on non-systemd systems on maintainers of packages that just need
the logind interfaces. If it is not available, software such as gdm3
will depend, directly or indirectly, on systemd as PID 1, and that will
be all.

(For non-Linux ports, the old ConsoleKit code will be enabled instead,
but users should not expect this to work at all.)

-- 
 .''`.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#738958: mutt: should split Mail-Followup-To into To and Cc while replying

[Adam Lee]

Package: mutt
Version: 1.5.21-6.4
Severity: normal
Tags: upstream

Hi,

When the honor_followup_to option is set, mutt will use all addresses in
Mail-Followup-To as To while replying. I think mutt should recognize
which addresses are To and which are Cc, or lots of Cc addresses will be
noticed unnecessarily.

Like this:

1, recognize addresses in &in->mail_followup_to but not in &in->cc, append to 
&out->to
2, if &out->to is not empty now, recognize addresses in &in->mail_followup_to 
but not in &out->to, append to &out->cc
3, else if &out->to is empty now, append addresses in &in->mail_followup_to to 
&out->to


-- Package-specific info:
Mutt 1.5.21 (2010-09-15)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 3.12-1-amd64 (x86_64)
ncurses: ncurses 5.9.20140118 (compiled with 5.9)
libidn: 1.28 (compiled with 1.28)
hcache backend: tokyocabinet 1.4.48
Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"
To contact the developers, please mail to .
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode
misc/autoconf-remove-am-c-prototypes.patch
features/ifdef
features/xtitles
features/trash-folder
features/purge-message
features/imap_fast_trash
features/sensible_browser_position
features-old/patch-1.5.4.vk.pgp_verbose_mime
features/compressed-folders
features/compressed-folders.debian
debian-specific/Muttrc
debian-specific/Md.etc_mailname_gethostbyname.diff
debian-specific/use_usr_bin_editor.diff
debian-specific/correct_docdir_in_man_page.diff
debian-specific/dont_document_not_present_features.diff
debian-specific/document_debian_defaults
debian-specific/assumed_charset-compat
debian-specific/467432-write_bcc.patch
debian-specific/566076-build_doc_adjustments.patch
misc/define-pgp_getkeys_command.diff
misc/gpg.rc-paths
misc/smime.rc
upstream/531430-imapuser.patch
upstream/537818-emptycharset.patch
upstream/543467-thread-segfault.patch
upstream/542817-smimekeys-tmpdir.patch
upstream/548577-gpgme-1.2.patch
upstream/553321-ansi-escape-segfault.patch
upstream/568295-references.patch
upstream/547980-smime_keys-chaining.patch
upstream/528233-readonly-open.patch
upstream/228671-pipe-mime.patch
upstream/383769-score-match.patch
upstream/578087-header-strchr.patch
upstream/603288-split-fetches.patch
upstream/537061-dont-recode-saved-attachments.patch
upstream/608706-fix-spelling-errors.patch
upstream/620854-pop3-segfault.patch
upstream/611412-bts-regexp.patch
upstream/624058-gnutls-deprecated-set-priority.patch
upstream/624085-gnutls-deprecated-verify-peers.patch
upstream/584138-mx_update_context-segfault.patch
upstream/619216-gnutls-CN-validation.patch
upstream/611410-no-implicit_autoview-for-text-html.patch
upstream/path_max
misc/579967-fixes-german-translation.patch
mutt.org

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (2, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mutt depends on:
ii  libassuan02.1.1-1
ii  libc6 2.17-97
ii  libcomerr21.42.9-3
ii  libgnutls26   2.12.23-11
ii  libgpg-error0 1.12-0.2
ii  libgpgme111.4.3-0.1
ii  libgssapi-krb5-2  1.12+dfsg-2
ii  libidn11  1.28-1
ii  libk5crypto3  1.12+dfsg-2
ii  libkrb5-3 1.12+dfsg-2
ii  libncursesw5  5.9+20140118-1
ii  libsasl2-22.1.26.dfsg1-8
ii  libtinfo5 5.9+20140118-1
ii  libtokyocabinet9  1.4.48-2

Versions of packages mutt recommends:
pn  default-mta | mail-transport-agent  
ii  libsasl2-modules2.1.26.dfsg1-8
ii  locales 2.17-97
ii  mime-support3.54

Versions of packages mutt suggests:
ii  aspell   0.60.7~20110707-1
ii  ca-certificates  20130906
ii  gnupg1.4.16-1
pn  mixmaster
ii  openssl  1.0.1f-1
ii  urlview  0.9-19

Versions of packages mutt 

Bug#738959: Should protect apache php5.conf file with IfModule directives, and use version 2.4 allow directives

[Julian Gilbey]

Package: libapache2-mod-php5
Version: 5.5.9+dfsg-1
Severity: normal
Tags: patch

It is wise to surround the apache config file with an  directive, just in case for some bizarre reason the config
script is still enabled even after the module is disabled or the
package removed.  Its presence won't harm but might protect.  The
attached patch includes this.

More significantly, the config file still uses the apache 2.2
Allow/Deny directives; the attached patch converts these into the
equivalent apache 2.4 directives.

   Julian
--- php5.conf.dpkg-dist	2014-02-14 09:08:07.952582773 +
+++ php5.conf	2014-02-14 09:09:13.331228344 +
@@ -1,3 +1,4 @@
+
 
 SetHandler application/x-httpd-php
 
@@ -6,13 +7,11 @@
 # Deny access to raw php sources by default
 # To re-enable it's recommended to enable access to the files
 # only in specific virtual host or directory
-Order Deny,Allow
-Deny from all
+Require all denied
 
 # Deny access to files without filename (e.g. '.php')
 
-Order Deny,Allow
-Deny from all
+Require all denied
 
 
 # Running PHP scripts in user directories is disabled by default
@@ -25,3 +24,4 @@
 php_admin_flag engine Off
 
 
+ # mod_php5.c

Bug#733740: ping... Re: Processed: bug 733740 is forwarded to https://release.debian.org/transitions/html/libdotconf0.html

[Paul Gevers]

Hi,

I am sure I would have received an confirmed message, but he

On 13-02-14 21:24, Debian Bug Tracking System wrote:
>> forwarded 733740 https://release.debian.org/transitions/html/libdotconf0.html

So now dotconf has a transition tracker. What is the estimated time that
this transition can start? If it can not start soon [no hard feelings],
I am going to temporarily work around the dotconf version dependency in
speech-dispatcher, but clearly I like to avoid that.

Paul
ps: on a completely unrelated thing: would I be helping the release team
if I would/could take care of setting up these transition trackers. (I
mean making sure the ben files are created properly and some such.)
Unless I am mistaken, it already helps to have the transition trackers
in place before the acknowledgement of the team to start the actual
transition. IIUC it helps to detect the intermixing of transitions, right?




signature.asc
Description: OpenPGP digital signature

Bug#738715: [debian-freedict] Bug#738715: Bug#738715: Bug#738715: dict-freedict-eng-rus: GoldenDict does not show requested article (at least for dict-freedict-eng-rus 2013.11.30-1)

[Nikolay Shaplov]

On Thursday 13 February 2014 11:34:20 Sebastian Humenda wrote:
> Hello again,
> 
> sorry, I've used the wrong dict-freedict-eng-rus database, due to problems
> on my unstable system.
> 
> When installing eng-rus, dictd even stops working. So it seems to be indeed
> something serious. I'll have a look.

While answering your out-of-list mail, I've found the origin of this bug:
Goldendict somehow does not notice that dictionary were changed (It does not 
use dictd, it uses files directly) and continue to use it's old index from 
~/.goldendict. If one remove this dir and run goldendict again, if will 
properly use new dictionary.

That's goldendict's bug, and I've reported it:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738955

This bug can be closed.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#717239: Bug #717239: partman-ufs: depends on obsolete package

[Cyril Brulebois]

Steven Chamberlain  (2013-08-16):
> The dependency should be still satisfied on kFreeBSD and Hurd.  On
> kFreeBSD it's even our default filesystem.
> 
> Since the package is arch: all, is this an actionable bug?  It seems to
> me no different than say, partman-zfs dependencies not being satisfied
> on GNU/Linux.

I've just switched partman-ufs from all to kfreebsd-any, and uploaded it
from amd64 using -akfreebsd-amd64 since it has no arch-dep code to
build, hoping it won't break anything. -bsd@: please yell if something
breaks.

uninstallability will go away once partman-ufs is decrufted on
non-kfreebsd architectures (fixing monolithic image building on these
architectures).

For the record, partman-zfs was moved back to kfreebsd-any a while ago,
and decrufted lately.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#738960: command-not-found suggests wrong package, says gdk-pixbuf-query-loaders is in libgtk2.0-bin

[Vlad Orlov]

Package: command-not-found
Version: 0.2.38-1
Severity: normal

# gdk-pixbuf-query-loaders > 
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
The program 'gdk-pixbuf-query-loaders' is currently not installed.  You can 
install it by typing:
apt-get install libgtk2.0-bin
gdk-pixbuf-query-loaders: command not found

This is wrong because gdk-pixbuf-query-loaders is not in libgtk2.0-bin, it's in 
libgdk-pixbuf2.0-dev.

Bug#738826: how-can-i-help: modify control a bit to allow use in stable (wheezy)

[igor80]

Hi Lucas,

You can find the local backport there
http://igor80.free.fr/how-can-i-help/

Diff with original gives

diff -r how-can-i-help-4/debian/changelog 
how-can-i-help-4~bpolocal/debian/changelog
0a1,6
> how-can-i-help (4~bpolocal) stable-backports; urgency=medium
> 
>   * wheezy-backports build
> 
>  -- No Body   Mon, 10 Feb 2014 22:16:08 +0100
> 
diff -r how-can-i-help-4/debian/control how-can-i-help-4~bpolocal/debian/control
14c14
< Depends: ${shlibs:Depends}, ${misc:Depends}, ruby (>= 1:1.9.3), ruby-debian 
(>= 0.3.8+b2), ruby-json (>= 1.8.0-1)
---
> Depends: ${shlibs:Depends}, ${misc:Depends}, ruby (>= 1:1.9.3), ruby-debian 
> (>= 0.3.8+b1), ruby-json (>= 1.7.3-3)

how-can-i-help --all returns

==  How can you help?  (doc: http://wiki.debian.org/how-can-i-help ) ==
Packages where help is needed, including orphaned ones (from WNPP):
 - at - http://bugs.debian.org/675322 - ITA (Someone working on adoption)
 - gnupg - http://bugs.debian.org/660685 - RFH (Maintainer looking for help)
 - grub2 - http://bugs.debian.org/248397 - RFH (Maintainer looking for help)
 - iproute - http://bugs.debian.org/705169 - RFH (Maintainer looking for help)
 - libept - http://bugs.debian.org/678382 - RFH (Maintainer looking for help)
 - openssl - http://bugs.debian.org/332498 - RFH (Maintainer looking for help)
 - xml-core - http://bugs.debian.org/660687 - RFH (Maintainer looking for help)
Bugs suitable for new contributors (tagged 'gift'):
 - apt - http://bugs.debian.org/80123 - Pre-Download hook
 - apt - http://bugs.debian.org/711456 - apt-cdrom: MultiArch support with a 
single CD-ROM drive
 - aptitude - http://bugs.debian.org/174820 - aptitude: I hit '+' on a virtual 
package, and nothing happens
 - aptitude - http://bugs.debian.org/492432 - aptitude: fetch and display 
copyright (like changelog)
 - aptitude - http://bugs.debian.org/497137 - "download" command ignores cache 
and directly goes to HTTP!
 - aptitude - http://bugs.debian.org/498239 - warnings, status printed twice
 - aptitude - http://bugs.debian.org/693847 - aptitude: Repeated "Downloaded" 
lines w/ http.debian.net
 - dput - http://bugs.debian.org/271575 - Please provide possibility to 
continue even if current file is broken
 - dput - http://bugs.debian.org/348908 - dput: guess location of package 
?*.changes? file

The build was done in a minimal wheezy system
That may explain this short list

If you need more info/test, let me know.

igor

hcih.test
Description: Binary data
diff -r how-can-i-help-4/debian/changelog how-can-i-help-4~bpolocal/debian/changelog
0a1,6
> how-can-i-help (4~bpolocal) stable-backports; urgency=medium
> 
>   * wheezy-backports build
> 
>  -- No Body   Mon, 10 Feb 2014 22:16:08 +0100
> 
diff -r how-can-i-help-4/debian/control how-can-i-help-4~bpolocal/debian/control
14c14
< Depends: ${shlibs:Depends}, ${misc:Depends}, ruby (>= 1:1.9.3), ruby-debian (>= 0.3.8+b2), ruby-json (>= 1.8.0-1)
---
> Depends: ${shlibs:Depends}, ${misc:Depends}, ruby (>= 1:1.9.3), ruby-debian (>= 0.3.8+b1), ruby-json (>= 1.7.3-3)

Bug#738893: O: cwidget -- high-level terminal interface library for C++ (runtime files)

[Manuel A. Fernandez Montecelo]

Control: owner -1 m...@debian.org
Control: retitle -1 ITA: cwidget -- terminal interface library for C++

-- 
Manuel A. Fernandez Montecelo 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738961: synaptic: Application is closing at the moment that any key is pressed

[AndresBurbano]

Package: synaptic
Version: 0.75.13
Severity: grave
Tags: d-i
Justification: causes non-serious data loss

Dear Maintainer,

   * What led up to the situation?
I always develop in Debian, so I got a New PC, then I installed the latest
version and when I use the synaptec for install some packages, I realized that
every time pressed I key it was automatically closing the app.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I Open the application, Accept the  Quick Introduction dialog, I put the cursor
in the Quick filter and write the app name. At the first key that I press it
get close. I tried several different keys(a, b, z, t..). However if I select
the package with the mouse it install normally.


   * What was the outcome of this action?

Application is close

   * What outcome did you expect instead?

A list filter by the written name

cordialement,



-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-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 synaptic depends on:
ii  hicolor-icon-theme  0.12-1
ii  libapt-inst1.5  0.9.7.9+deb7u1
ii  libapt-pkg4.12  0.9.7.9+deb7u1
ii  libatk1.0-0 2.4.0-2
ii  libc6   2.13-38+deb7u1
ii  libcairo2   1.12.2-3
ii  libept1.4.121.0.9
ii  libfontconfig1  2.9.0-7.1
ii  libfreetype62.4.9-1.1
ii  libgcc1 1:4.7.2-5
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libgtk2.0-0 2.24.10-2
ii  libpango1.0-0   1.30.0-1
ii  libstdc++6  4.7.2-5
ii  libvte9 1:0.28.2-5
ii  libx11-62:1.5.0-1+deb7u1
ii  libxapian22 1.2.12-2
ii  zlib1g  1:1.2.7.dfsg-13

Versions of packages synaptic recommends:
ii  gksu 2.0.2-6
ii  libgtk2-perl 2:1.244-1
ii  policykit-1  0.105-3
ii  rarian-compat0.8.1-5
ii  software-properties-gtk  0.82.7.1debian1

Versions of packages synaptic suggests:
ii  apt-xapian-index  0.45
pn  deborphan 
pn  dwww  
ii  menu  2.1.46

-- 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#738893: O: cwidget -- high-level terminal interface library for C++ (runtime files)

[Manuel A. Fernandez Montecelo]

For the record, I tried to contact Daniel Burrows several times for
more than 2 years about this project and other abandoned projects,
specially aptitude.

Luckily we got to salvage aptitude a while ago already, but I was
going to ask again about this because cwidget is used by aptitude, and
needs some love.

-- 
Manuel A. Fernandez Montecelo 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#732652: testing changed Icedove package

[Carsten Schoenert]

Hello Ximin,

On Wed, Feb 12, 2014 at 04:00:47PM +, Ximin Luo wrote:
> All extensions are from the Debian repos. Actually I have disabled
> everything except moz-g-k and the bug is still present. I'm not sure
> how another extension could interfere with where icedove loads its
> libs from.

O.k. just want to be sure that no other installed software will causes
some trouble.

> I repeat, setting LD_LIBRARY_PATH=/usr/lib/icedove makes things work.
> Perhaps you just forgot a -Wl,rpath during the build process?

Mozilla has changed the starting wrapper for Thunderbird in version 14
or so. They use some kind of "intelligent" mechanism to detect the used
librarys and set a LD_LIBRARY_PATH if needed.
But this covers just a included directory 'plugins/' and not
/usr/lib/icedove.

So you propably right with the linker flag '-Wl,rpath". I rebuild
yesterday the current version 24.3.0 with this additional declaration to
LDFLAGS.
I uploaded the packages with this little change to

  http://openmct.org/misc/icedove24-test/

I checked the builded binary 'icedove' with readelf. The binarys now
uses RUNPATH.

> (pbuilder)root@jessie:~/icedove-24.3.0/debian/tmp/usr/lib/icedove# readelf 
> --dynamic icedove | grep PATH
>  0x001d (RUNPATH)Library runpath:  [/usr/lib/icedove]

So I'd like to ask you if you please can test once again the Icedove
package with mozilla-gnome-keyring?
Unfortunately I never have used m-g-k and I'm having currently not much
time and testing installations to play with m-g-k. I think you know your
package much better then me and will find much quicker if it works
correctly with this changes while the build process.

> Here are the messages from icedove console:
> 
> Could not read chrome manifest 
> 'file:///usr/lib/icedove/components/components.manifest'.

This should be also fixed in the packages from above. We have forgotten
to change the install declarations for this directory. Mozilla has added
the manifest file between version 17 and 24.

> Failed to load native module at path 
> '/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{6f9d85e0-794d-11dd-ad8b-0800200c9a66}/platform/Linux_x86_64-gcc3/components/libgnomekeyring-icedove.so':
>  (80004005) libldif60.so: cannot open shared object file: No such file or 
> directory
> Could not read chrome manifest 
> 'file:///usr/lib/icedove/extensions/%7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D/chrome.manifest'.
> While creating services from category 'profile-after-change', could not 
> create service for entry 'Disk Space Watcher Service', contract ID 
> '@mozilla.org/toolkit/disk-space-watcher;1'
> 
> Feel free to install xul-ext-gnome-keyring and play with it yourself.

Thanks for your interaction.

Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#669171: Acknowledgement (git-buildpackage: Create changelog if it does not exist)

[Guido Günther]

On Thu, Feb 13, 2014 at 06:10:52PM +0100, Daniel Dehennin wrote:
> Daniel Dehennin  writes:
> 
> Hello,
> 
> > I rebased my patch[1] against latest master to use the new
> > “get_dch_default_urgency()” function in my tests.
> 
> Is there anything I can do to have this patch merged?

It's basically waiting on me having more time to review this again and
possibly merge this.
 -- Guido


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738881: invoke-rc.d: unknown initscript, /etc/init.d/dictd not found.

[Andreas Beckmann]

Control: severity -1 serious

On Thursday, 13. February 2014 21:22:36 Sebastian Humenda wrote:
> am I right that you haven't installed dictd or dicod when the error occurs?
> If so, I'm going to fix that with the next upload.

If that is not in Depends: ... it's not installed during the piuparts tests 
and they are failing now for *all* dict-freedict-*-* packages.


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738962: python-csb: More issues with the tests

[Dmitry Shachnev]

Source: python-csb
Version: 1.2.2+dfsg-2
Severity: important

Dear Maintainer,

I have tried to fix the python-csb autopkgtest and noticed the following things:

1) python-csb should depend on python-numpy and python-scipy (and python3-csb
   should depend on python3-numpy and python3-scipy). These dependencies are
   specified in REQUIRES field in setup.py and, as I understand, the package
   is mostly useless without these dependencies. The tests also need numpy
   to succeed.

2) In debian/tests/build, Makefile-style variables are used. I think that was
   blindly copied from debian/rules, and not really needed.

   Also, you use python instead of $python, so in fact the test is ran
   three times for python2.7.

   I would write the command like this:

 for py in $(pyversions -i) $(py3versions -i); do
 PYTHONWARNINGS=d $py test/app.py --generated-resources /tmp 
--verbosity 2
 done

   Note that I also increased verbosity to get the more understandable output
   in case of failures.

3) One of the tests fails (at least with Python 2.7):

 FAIL: testWHAM 
(usr/lib/python2-7/dist-packages/csb/test/cases/statmech/wham.TestWHAM)

 Traceback (most recent call last):
   File "/usr/lib/python2.7/dist-packages/csb/test/cases/statmech/wham.py", 
line 80, in testWHAM
 self.log_z, delta=0.5)
   File "/usr/lib/python2.7/dist-packages/csb/test/__init__.py", line 415, 
in assertAlmostEqual
 raise self.failureException(msg)
 AssertionError: nan != -14.7726232844 within 0.5 delta

4) The tests failures are ignored. When the test fails for python2.7, the next
   tests are run.

5) Some test is printed into stderr, for example the deprecation warnings and
   names of the tests. Autopkgtest considers that as a failure by default, to
   allow stderr you need to add this line to debian/tests/control:

 Restrictions: allow-stderr

Please contact me or debian-pyt...@lists.debian.org if you have any questions.

Hope my investigation helps,

--
Dmitry Shachnev

signature.asc
Description: OpenPGP digital signature

Bug#738963: spamassassin: New upstream version 3.4.0 available

[Adrian Knoth]

Package: spamassassin
Version: 3.3.1-1.1
Severity: wishlist
Tags: upstream

Hi!

There's a new upstream version 3.4.0 available. I'd be nice to see
it rather soon in Debian.


Cheers

-- System Information:
Debian Release: 6.0.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages spamassassin depends on:
pn  libarchive-tar-perl(no description available)
ii  libdigest-sha1-perl2.13-1NIST SHA-1 message digest algorith
ii  libhtml-parser-perl3.66-1collection of modules that parse H
ii  libnet-dns-perl0.66-2Perform DNS queries from a Perl sc
ii  libnetaddr-ip-perl 4.028+dfsg-1  IP address manipulation module
ii  libsocket6-perl0.23-1Perl extensions for IPv6
ii  libsys-hostname-long-p 1.4-2 Figure out the long (fully-qualifi
ii  libwww-perl5.836-1   Perl HTTP/WWW client/server librar
ii  perl   5.10.1-17squeeze6 Larry Wall's Practical Extraction 
ii  perl-modules [libio-zl 5.10.1-17squeeze6 Core Perl modules

Versions of packages spamassassin recommends:
ii  gcc4:4.4.5-1 The GNU C compiler
ii  gnupg  1.4.10-4+squeeze3 GNU privacy guard - a free PGP rep
ii  libc6-dev  2.11.3-4  Embedded GNU C Library: Developmen
ii  libio-socket-inet6-per 2.65-1.1  Object interface for AF_INET6 doma
ii  libmail-spf-perl   2.007-1   Perl implementation of Sender Poli
ii  make   3.81-8An utility for Directing compilati
ii  perl [libsys-syslog-pe 5.10.1-17squeeze6 Larry Wall's Practical Extraction 
ii  re2c   0.13.5-1  tool for generating fast C-based r
ii  spamc  3.3.1-1.1 Client for SpamAssassin spam filte

Versions of packages spamassassin suggests:
ii  libdbi-perl1.612-1   Perl Database Interface (DBI)
pn  libio-socket-ssl-perl  (no description available)
ii  libmail-dkim-perl  0.38-1cryptographically identify the sen
pn  libnet-ident-perl  (no description available)
ii  perl [libcompress-zlib 5.10.1-17squeeze6 Larry Wall's Practical Extraction 
pn  pyzor  (no description available)
pn  razor  (no description available)

-- Configuration Files:
/etc/default/spamassassin changed [not included]
/etc/spamassassin/local.cf changed [not included]

-- 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#738964: dh_virtualenv: error: no such option: -a - dh_virtualenv doesn't honor dh's -a option

[Michael Prokop]

Package: dh-virtualenv
Version: 0.6-1
Severity: normal


dh_virtualenv doesn't honor dh's -a option:

, [ simple demo ]
| % dpkg-buildpackage -B
| [...]
| dh binary-arch --with=python-virtualenv
|dh_testroot -a
|dh_prep -a
|dh_installdocs -a
|dh_installchangelogs -a
|dh_perl -a
|dh_virtualenv -a
| Usage: dh_virtualenv [options]
|
| dh_virtualenv: error: no such option: -a
| make: *** [binary-arch] Error 2
`

Any dh script should accept -a and -i, quoting from debhelper's source:

, [ debhelper-9.20131227/doc/PROGRAMMING ]
| Debhelper programs should accept all options listed in the "SHARED
| DEBHELPER OPTIONS" section of debhelper(7), including any long forms of
| these options, like --verbose . If necessary, the options may be ignored.
`

Quoting according section of debhelper(7):

, [ man 7 debhelper ]
| SHARED DEBHELPER OPTIONS
| [...]
|-a, --arch
|Act on architecture dependent packages that should be built for 
the build architecture.
|
|-i, --indep
|Act on all architecture independent packages.
`

regards,
-mika-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2014-02-14t11-07...@devnull.michael-prokop.at

Bug#724471: smokeping: FTBFS: configure.ac:24: error: required file 'conftools/compile' not found

[Niko Tyni]

On Tue, Sep 24, 2013 at 08:50:59AM +0300, Damyan Ivanov wrote:
> Package: src:smokeping
> Version: 2.6.8-2
> Severity: serious
> Justification: FTBFS
> 
> smokeping fails to build in a clean current sid pbuilder chroot:
> 
> make[1]: Entering directory `/tmp/buildd/smokeping-2.6.9'
> aclocal
> autoconf
> automake
> configure.ac:24: error: required file 'conftools/compile' not found
> configure.ac:24:   'automake --add-missing' can install 'compile'
> make[1]: *** [override_dh_auto_configure] Error 1
> make[1]: Leaving directory `/tmp/buildd/smokeping-2.6.9'
> make: *** [build] Error 2

Antoine, are you still maintaining smokeping? It's been RC buggy for
half a year and was removed from testing three months ago.
-- 
Niko Tyni   nt...@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#738712: kid3-core, kid3-cli: fails to upgrade from 'testing' - trying to overwrite /usr/share/kid3/translations/*

[Andreas Beckmann]

On 2014-02-12 11:37, Patrick Matthäi wrote:
> tag #738712 + pending
> thanks
> 
> Patch (see below) comitted, but I have to wait to fix another bug.

That's only Breaks, it needs a matching Replaces, too.

> 
> Index: debian/control
> ===
> --- debian/control  (Revision 19859)
> +++ debian/control  (Arbeitskopie)
> @@ -29,6 +29,7 @@
>  Architecture: any
>  Depends: ${shlibs:Depends},
>   ${misc:Depends}
> +Breaks: kid3 (<< 3.0.2-2)
>  Description: Audio tag editor core libraries and data
>   An application to edit the ID3v1 and ID3v2 tags in MP3 files in an
> efficient
>   way. These tags can be edited by most MP3 players, but not in a very

Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738966: gnome-shell-timer: version 20140214: no icon shows in gnome-shell 3.8

[Klaus]

Package: gnome-shell-timer
Version: 0.0.20140211-1
Severity: normal

Dear Maintainer,

This version of gnome-shell-timer does not start fully in 
gnome-shell 3.8.4-5
Its icon doesn't appear in the top panel, and in tweak-tool on the
extensions list the entry is greyed out and shows a warning sign.
However, the timer-applet-configurator can still be called up and
appears to behave normally.

Downgrading to the previous version 0.0.20130422-1 restores function.
So far I've been unable to find any related error messages in the log files.

Kind regards
Klaus

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnome-shell-timer depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.18.0-1
ii  gnome-shell  3.8.4-5
pn  python:any   

gnome-shell-timer recommends no packages.

gnome-shell-timer 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#738967: missing license in debian/copyright

[Thorsten Alteholz]

Package: libical
Severity: serious
User: alteh...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks

Dear Maintainer,

please add the Perl license of
  libical-1.0/src/Net-ICal-Libical/lib/Net/ICal/Libical/*
to debian/copyright
Further please add the licenses of
  libical-1.0/src/libicalvcal/*
to debian/copyright as well.

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#738968: dict-freedict-eng-rus: GoldenDict seems to use 00-database-short as dictionary name, and it is missing

[Nikolay Shaplov]

Package: dict-freedict-eng-rus
Version: 2013.11.30-1
Severity: normal

GoldenDict does not properly show Dictionary Name in it's interface. As far as 
I can get, it uses 00-database-short "header" from dict file. In 
dict-freedict-eng-rus_1.3-4 this header exists, and name is shown well, but in 
dict-freedict-eng-rus_2013.11.30 "header" is missing, and dictionary name is 
empty.

Also it would be good to fill /usr/share/opendict/dictionaries/plain/freedict-
eng-rus.dict.dz/conf/config.xml with actual values. I do not know where it is 
used, but it might also cause some problems


Here is /usr/share/opendict/dictionaries/plain/freedict-eng-
rus.dict.dz/conf/config.xml from dict-freedict-eng-rus_1.3-4 :

===


  dict
  Freedict English-Russian
  1.3-4
  

  
  freedict-eng-rus.dict.dz
  UTF-8
  
  
  This plugin fetches translations from freedict-eng-rus.dict 
dictionary.



And here is the same file from dict-freedict-eng-rus_2013.11.30-1




  dict
  Freedict 
  
  

  
  freedict-eng-rus.dict.dz
  UTF-8
  
  
  This plugin fetches translations from freedict-eng-rus.dict 
dictionary.




-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

dict-freedict-eng-rus depends on no packages.

dict-freedict-eng-rus recommends no packages.

Versions of packages dict-freedict-eng-rus suggests:
pn  dict | opendict | kdict | gnome-dictionary  
pn  dictd | serpento

-- 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#738188: VESA Newcons is awfully slow

[Aleksandr Rybalko]

On Fri, 14 Feb 2014 00:01:56 +
Robert Millan  wrote:

> On 12/02/2014 18:36, Ed Maste wrote:
> > On 12 February 2014 09:05, Robert Millan  wrote:
> >> There's a small glitch during VT switch: immediately after pressing the
> >> keys, screen is redrawn, but where you'd normally see the login prompt,
> >> blurry characers are drawn. After a fraction of a second, these are 
> >> replaced
> >> with proper glyphs. Smells like a font related problem. Would you like to
> >> see a video capture?
> > 
> > That sounds quite odd.  Sure, if you can easily obtain a video capture
> > please do.
> 
> Strange. What I get now is black screen during 3 seconds every time I switch 
> VT.

3 seconds is for VirtualBox, right?

> 
> This happens only with VGA mode, and even after disabling debugging flags.
> 
> -- 
> Robert Millan


-- 
Aleksandr Rybalko 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738970: Add support to "dev-master" version in composer

[Javier Barroso]

package: pkg-php-tools
version: 1.11
severity: minor

Hello,

There are packages [1] using "dev-master" [2] as version of requisites
/ suggestion.

I patched /usr/share/pkg-php-tools/scripts/phppkginfo to consider this
string like "*"

Surely there is a better fix, but for the moment it work. Please if
there is a better method, add a note in readme file.

Thank you very much

[1] https://github.com/juanmf/RedmineIssueImporter
[2] https://getcomposer.org/doc/articles/aliases.md#why-aliases-
--- phppkginfo.orig	2014-02-14 12:10:43.148301336 +0100
+++ phppkginfo	2014-02-14 12:13:42.339430983 +0100
@@ -361,6 +361,11 @@
 		return implode(' | ', $pkg);
 	}
 	$version = trim($version);
+	if ($version == "dev-master")
+	{
+	   printLog('Workaround, changing version from '.$version.' to "*"');
+	   $version = "*";
+	}
 	if (preg_match('/^'.
 			'(>|>=|<|<=|!=|~)?'. # Operator
 			'\s*'. # Optional spaces

Bug#738969: how-can-i-help: bad line ending in case of dpkg error

[Vincent Lefevre]

Package: how-can-i-help
Version: 4
Severity: normal

It seems that in case of dpkg error, how-can-i-help has bad line ending:

# apt-get install -f
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up sa-compile (3.3.2-8) ...
Running sa-compile (may take a long time)
Only one of PREFIX or INSTALL_BASE can be given.  Not both.
command '/usr/bin/perl Makefile.PL 
PREFIX=/tmp/.spamassassin3946JHmS3Gtmp/ignored 
INSTALLSITEARCH=/var/lib/spamassassin/compiled/5.018/3.003002 
>>/tmp/.spamassassin3946JHmS3Gtmp/log' failed: exit 255
dpkg: error processing package sa-compile (--configure):
 subprocess installed post-installation script returned error exit status 25
Errors were encountered while processing:
 sa-compile
==  How can you help?  (doc: http://wiki.debian.org/how-can-i-help ) ==
   
--  Show all opportunities, not just new ones: how-can-i-help --all  --
  
E: Sub-process /usr/bin/dpkg returned an error code (1)

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages how-can-i-help depends on:
ii  ruby 1:1.9.3.4
ii  ruby-debian  0.3.8+b2
ii  ruby-json1.8.0-1+b1

how-can-i-help recommends no packages.

how-can-i-help 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#717125: [Piuparts-devel] Bug#717125: Bug#717125: piuparts: New test: upgrade from directly to command line package file

[Holger Levsen]

tags 717125 + gift
retitle 717125 document how to test upgrades from wheezy to sid using local 
pacḱages
thanks

Hi,

On Donnerstag, 18. Juli 2013, Norbert Preining wrote:
> On Mi, 17 Jul 2013, Andreas Beckmann wrote:
> > put debs into a local repository, e.g. /tmp/repo, run
> > 
> >   dpkg-scanpackages > Packages
> > 
> > there and add this to piuparts:
> > 
> > --bindmount /tmp/repo
> > --testdebs-repo /tmp/repo
> > --distupgrade-to-testdebs
> 
> Yes, thanks, that is what I was searching for.
[...]
> > Maybe we need to upgrade the documentation to make this more obvious.
> Please, yes.

It would be great if someone could update the documentation to explain this use 
case better. This is *your* chance to become part of the small circle of 
piuparts 
contributors! :-)


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#737153: OpenCVModules.cmake not installed, causing visp FTBFS

[Fabien Spindler]

The proposed fix 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737153 lead to an 
other error during ViSP package configuration:


CMake Error at /usr/share/OpenCV/OpenCVModules.cmake:117 (message) :
  The imported target "opencv_java" references the file

"/usr/share/OpenCV/java/libopencv_java248.so"

  but this file does not exist.

Fabien

Bug#737347: xboard: wish for pre-4.8 snapshot for experimental to get new features more exposure

[h . g . muller]

Op Wo, 12 februari, 2014 10:38 pm schreef Yann Dirson:

Hi Yann,

I will move GNU SHogi to the top of my priorities list this weekend, as
otherwise I just don't get to it. I went sort of manic on XBoard the past
few weeks, as I finally figured out how to do one of the features that was
still on the wish list for the GTK version (ICS output not in the x-term
but in its own dialog window, where it can have appropriate callbacks).
And then I got distracted by another pet-project of mine, on-the-fly
tablebase generation.

Let me first comment on (some of) your remaks on XBoard-experimental:

>
> * games defaulting to hachu (@chu and @sho) look OK
> * games defaulting to gnu(mini)shogi require xboard support, I'll
> upload a gnushogi master snapshot into experimental as well; they work well
> with the correct binaries in $PATH
> * @mini should I think default to japanese theme
Mini-Shogi is not an officially-defined variant of XBoard, and thus needs
some user configuration to be played. In cases like that, it seemed best
to separate the theme config file from the rules config file. (I guess the
same in principle holds for Sho Shogi, but I probably figured that there
would be no interest outside the traditional Shogi community for that
anyway. While for mini-Shogi I see a good future, provided that people get
the opportunity to play it in a 'kanji-free version'.)

The need for user rule configuration would disappear completely if GNU
miniShogi would use the engine-defined-variants feature of XBoard-exp,
however, and I think this is the way to go. I should simply announce

feature variants="mini,5x5+5_shogi"

and respond to the "variant mini" command with

setup (P.BR.S...G.+.++.+Kp.br.s...g.+.++.+k) 5x5+5_shogi
rbsgk/4p/5/P4/KGSBR w 0 1

Then it could be played by simply selecting "mini" from the New Variant
menu, and no rule configuration would be needed anymore. The 5x5+5_shogi
would only be mentioned in the variants feature for compatibility with
older interfaces and older engines. (E.g. if you want to play engine vs
engine, and the opponent engine would not support 'variant mini'.) Then
only theme configuration would remain, and you could use @shogi for that:

xboard @shogi -fcp gnuminishogi

would overrule gnushogi as default engine specified in @shogi.

> * @xq board drawing is messed with large window sizes here,
> although OK with smaller window sizes (see http://imagebin.org/292981),
> otherwise seems OK

That is a matter of the size of the bitmap provided for the Xiangqi board.
XBoard cuts tiles the size of a square from this bitmap. For a square grid
of NxN squares that would in principle allow cutting 2Nx2N squares out of
it before you start to see the next grid line, but with the diagonal lines
in the Palace you already see artifacts when the square size gets >N.
These are not very annoying, however. My attitude was pertty much that if
people would think the board is too messy, they should simply switch to
smaller square size. In older XBoard (before it used Cairo) the only sizes
for which there were built-in westernized Xiangqi piece bitmaps were 33,
49 and 72 anyway, and the bitmap of teh Xiangqi board was made with 49x49
grid.

> * I feel .desktop files for shipped confs would be
> needed to make them more visible to users

Indeed, the confs are only useful from the command line. OTOH, confs can
be combined on the command line, which is useful when they configure
different aspects (game rules, board theme, engine). It would be hard to
provide desktops for every possible combination of those. But if there are
a few obvious combinations of theme + rules + engine (e.g. because GNU
also features an engine, such as with GNU Shogi), we could make desktop
files for those.

>
> * Tried Mighty Lion by starting "xboard -fcp hachu -scp hachu" and
> selecting that variant, looks like hachu crashed (xboard -debug output
> attached for comment by HGM, hachu is current master, ie version
> 0.17-3-g3460d0c).  The same technique is OK with Sho and Chu.

OK, I will have a look at that.

> * Trying to switch to Dai or Tenjiku is refuse with "Engine did not send
> setup for non-standard variant" * Maybe a @hachu conf would be useful for
> easy access to those games ? Maybe better shipped by hachu itself ?

The current XBoard does not support Dai or Tenjiku, and could not be made
to support them even through user configuring. The number of piece types
needed for thos games exceeds XBoard's current maximum (44 piece types,
which was already doubled compared to 4.7.x in order to support Chu
Shogi). Only the WinBoard 'Alien Edition' fork currently supports those
variants (as well as Dai Dai, Maka Dai Dai and Tai), but the piece images
are constructed from scratch in the WinBoard front-end in the 'mnemonic'
theme, so this does not work for XBoard.

In addition, Tenjiku is not fully implemented in HaChu yet. The move
generator still doesn't do 'area moves'. My original plan was to first
finish the move generator for all v

Bug#738971: /usr/sbin/exim4: On rules file from package debconf-updatepo fails wo argument

[Corcodel Marian]

Package: exim4-daemon-light
Version: 4.80-7
Severity: normal
File: /usr/sbin/exim4
Tags: patch

--- a/debian/rules
+++ b/debian/rules
@@ -267,7 +267,11 @@
dh_testdir
dh_testroot

-   debconf-updatepo
+   if debconf-updatepo || echo $? ; then \
+   debconf-updatepo --skip-pot; \
+   else \
+   debconf-updatepo; \
+   fi

rm -f build-stamp configure-stamp installbase-stamp test-stamp
 I added this patch because  "debconf-updatepo " fail when not have  file
templates.pot-update
On directory exim4-4.80 run :
#:~/Debian/exim4/exim4-4.80$ debconf-updatepo
None of the files in POTFILES.in contain strings marked for translation.
file templates.pot-update does not exist at /usr/share/intltool-debian
/intltool-update line 783.




-- Package-specific info:
Exim version 4.80 #3 built 13-Feb-2014 22:01:00
Copyright (c) University of Cambridge, 1995 - 2012
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2012
Berkeley DB: Berkeley DB 5.1.29: (October 25, 2011)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='internet'
dc_other_hostnames=''
dc_local_interfaces='127.0.0.1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
mailname:marian1000.go.ro

-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-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 exim4-daemon-light depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  exim4-base 4.80-7
ii  libc6  2.13-38+deb7u1
ii  libdb5.1   5.1.29-5
ii  libgnutls262.12.20-7
ii  libpcre3   1:8.30-5

exim4-daemon-light recommends no packages.

exim4-daemon-light suggests no packages.

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#684503: simple fix

[Robert Lemmen]

hi everyone,

please note that the "fix" discussed above could be as simple as this,
which doesn't even look any worse:

--- gnome-pkg-tools-0.19.3.prepatch/control.header  2014-02-14 
11:35:27.0 +
+++ gnome-pkg-tools-0.19.3/control.header   2014-02-14 11:35:44.0 
+
@@ -2,4 +2,4 @@
 # 
 # Modifications should be made to debian/control.in instead.
 # This file is regenerated automatically in the clean target.
-
+#

regards  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Bug#683195: gnome-terminal: "Open Link" on an URL doesn't work anymore

[althaser]

Hey Adam,

Could you please try to reproduce this bug with newer version of
gnome-terminal like 3.4.1.1-2 or 3.10.1-1 ?

here everything works fine with 3.10.1-1.

Please let us know if open link and copy link address already works.

thanks
regards
althaser

Bug#738972: linux - Support for AACRAID series 7/8/9 controllers

[Bastian Blank]

Source: linux
Version: 3.2.54-2
Severity: important

Please add support for AACRAID series 7/8/9 controllers.

Preliminary list of commits:
- 116046127d1a3bad2853d02781ad9fee33f05e5a
- 715525057423eeb6308d2c605ae9ec8325e43858
- maybe 2b4df6ea53d05625e9ca2dd73bc0e831976e009d

Bastian

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.13-trunk-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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738951: sa-compile: post-installation script fails: Only one of PREFIX or INSTALL_BASE can be given

[Vincent Lefevre]

Control: tags -1 patch

On 2014-02-14 09:18:10 +0100, Vincent Lefevre wrote:
> I get the following error:
> 
> Setting up sa-compile (3.3.2-8) ...
> Running sa-compile (may take a long time)
> Only one of PREFIX or INSTALL_BASE can be given.  Not both.
> command '/usr/bin/perl Makefile.PL 
> PREFIX=/tmp/.spamassassin25665jgQStqtmp/ignored 
> INSTALLSITEARCH=/var/lib/spamassassin/compiled/5.018/3.003002 
> >>/tmp/.spamassassin25665jgQStqtmp/log' failed: exit 255
> dpkg: error processing package sa-compile (--configure):
>  subprocess installed post-installation script returned error exit status 25

The problem is that the environment (inherited from the user's shell)
isn't cleaned up in the post-installation script, as needed by perl.
Replacing "su debian-spamd" by "su - debian-spamd" fixes the problem
(see attached patch).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--- debian/sa-compile.postinst~ 2014-02-10 00:56:29.0 +0100
+++ debian/sa-compile.postinst  2014-02-14 12:58:44.328309414 +0100
@@ -6,7 +6,7 @@
 # Compile, if rules have previously been compiled, and it's possible
 if [ -x /usr/bin/re2c -a -x /usr/bin/sa-compile ]; then
 echo "Running sa-compile (may take a long time)"
-su debian-spamd -c "sa-compile --quiet"
+su - debian-spamd -c "sa-compile --quiet"
 invoke-rc.d spamassassin restart
 fi
 }

Bug#720275: Still not working?

[Sven Herzberg]

I have been trying the version of wheezy-backports (as the wheezy version 
exposes this bug).

I think this bug is still not solved. Executing the update call like this (just 
like /etc/cron.d/munin-node does, except for more debugging here):
> $ sudo munin-run -d apt_all update 7200 12; echo $?
> # Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
> # Setting /rgid/ruid/ to /111/65534/
> # Setting /egid/euid/ to /111 111/65534/
> # Setting up environment
> # About to run '/etc/munin/plugins/apt_all update'
> apt update   -- update apt databases randomly
> 
>  maxinterval:
>   Enforce the updating of the apt database if it has
>   been more than (maxinterval many seconds since the last update.
> 
>  probability:
>   There's a 1 in (probability) chance that the database
>   will be updated.
> 1

It looks like munin-run forwards the first argument only, causing silent errors 
(because of the pipe in the crontab file).

Package information:
> $ LC_ALL=C dpkg -l munin-{node,plugin*}
>Desired=Unknown/Install/Remove/Purge/Hold
>| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>||/ NameVersionArchitecture
>   Description
>+++-===-==-==-
>ii  munin-node  2.0.19-2~bpo70+1   all 
>   network-wide graphing framework (node)
>un  munin-plugins
>   (no description available)
>ii  munin-plugins-core  2.0.19-2~bpo70+1   all 
>   network-wide graphing framework (plugins for node)
>ii  munin-plugins-extra 2.0.19-2~bpo70+1   all 
>   network-wide graphing framework (user contributed plugins for node)
>un  munin-plugins-java   
>   (no description available)

If there is any way to move on with this ticket, I'd love to help.

-- 
Sven Herzberg

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738602: debian-installer: Alternative desktop choices do not reflect change to XFCE as default

[Cyril Brulebois]

Control: tag -1 patch pending
Control: found -1 20131211

erusan  (2014-02-10):
> Package: debian-installer
> Severity: important
> 
> Dear Maintainer,
> 
>The recent switch to XFCE as the default desktop for Debian is not
>reflected in the Debian installer's Alternative desktop list. That
>is, GNOME is not an option anywhere, and XFCE remains in the list
>of "alternatives".

That's correct, thanks for reporting this. I believe it should be fixed
by the following commit:
  
http://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=commitdiff;h=aa27246c9291f56620fb86b3f5eff20db4ccdff6

I have only checked the presence of desktop=... in /proc/cmdline for the
booted environment, and navigated a bit in the menus to make sure they
look OK, but didn't complete any full installation.

The F8 boot screen looks OK too, I believe, even if we're almost running
out of characters on the desktop line.

>There is also no indication of what the installer is actually going
>to install, leaving users with a rude realization when they boot
>into their fresh install.

I'm not sure we want, or need, to be explicit about what's getting
installed (be it the desktop or anything else).

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#737153: OpenCVModules.cmake not installed, causing visp FTBFS

[Rebecca N. Palmer]

Debian doesn't have a /usr/share/OpenCV/java/libopencv_java248.so, but 
it does have a /usr/lib/libopencv_java248.so in libopencv2.4-jni; does 
build-depending on that help?



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738973: invoke-rc.d: unknown initscript, /etc/init.d/dictd not found.

[arne]

Package: dict-freedict-nld-deu
Version: 2014.02.02-1
Severity: grave

Preparing to unpack .../dict-freedict-nld-deu_2014.02.02-1_all.deb ...
Unpacking dict-freedict-nld-deu (2014.02.02-1) ...
Setting up dict-freedict-nld-deu (2014.02.02-1) ...
invoke-rc.d: unknown initscript, /etc/init.d/dictd not found.
dpkg: error processing package dict-freedict-nld-deu (--configure):
 subprocess installed post-installation script returned error exit status 100
Errors were encountered while processing:
 dict-freedict-nld-deu


Other dict-freedict-packages also.




-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

dict-freedict-nld-deu depends on no packages.

dict-freedict-nld-deu recommends no packages.

Versions of packages dict-freedict-nld-deu suggests:
pn  dict | opendict | kdict | gnome-dictionary  
pn  dictd | serpento

-- 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#738974: sa-compile installation fails if directory isn't debian-spamd:debian-spamd

[Iain Lane]

Package: spamassassin
Version: 3.3.2-8
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Hey,

Full disclosure: I'm running Ubuntu.

Somehow my /var/lib/spamassassin hadn't been chowned to
debian-spamd:debian-spamd. I'm not sure why; tracing back the upgrade
path didn't give me any clues. When I got sa-compile with -8, the script
couldn't run because debian-spamd (the user sa-compile is run as)
couldn't write to the directory. This failed the postinst, which bombs
out dpkg and apt (if used).

So I've modified the postinst to always chown in the following cases

  - There's no statoverride specified by the local admin.
  - The owner isn't the target (debian-spamd:debian-spamd) already.

...and to run programs under the user who owns the directory. I used the
following changelog.

  * Always chown /var/lib/spamassassin if necessary; some upgrade paths might
have left it as root:root, in which case sa-compile's postinst will not
run successfully.

I guess you might want something like this in Debian too.

Thanks for considering the patch.

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]
diff -Nru spamassassin-3.3.2/debian/sa-compile.postinst spamassassin-3.3.2/debian/sa-compile.postinst
--- spamassassin-3.3.2/debian/sa-compile.postinst	2014-02-09 23:56:29.0 +
+++ spamassassin-3.3.2/debian/sa-compile.postinst	2014-02-14 11:43:12.0 +
@@ -3,10 +3,11 @@
 set -e
 
 sa_compile() {
+OWNER=$(stat -c '%U' /var/lib/spamassassin)
 # Compile, if rules have previously been compiled, and it's possible
 if [ -x /usr/bin/re2c -a -x /usr/bin/sa-compile ]; then
 echo "Running sa-compile (may take a long time)"
-su debian-spamd -c "sa-compile --quiet"
+su $OWNER -c "sa-compile --quiet"
 invoke-rc.d spamassassin restart
 fi
 }
diff -Nru spamassassin-3.3.2/debian/spamassassin.postinst spamassassin-3.3.2/debian/spamassassin.postinst
--- spamassassin-3.3.2/debian/spamassassin.postinst	2014-02-13 16:13:11.0 +
+++ spamassassin-3.3.2/debian/spamassassin.postinst	2014-02-14 11:43:10.0 +
@@ -3,23 +3,29 @@
 set -e
 
 if [ "$1" = "configure" ]; then
-# If a new install, or an upgrade from before 3.3.2-3 ...
-if dpkg --compare-versions "$2" "le" "3.3.2-2"; then
-if ! getent passwd debian-spamd > /dev/null ; then
-adduser --system --group --shell /bin/sh --disabled-password \
---home /var/lib/spamassassin debian-spamd
-else
-mkdir -p /var/lib/spamassassin
-fi
-# Fix permissions of spamassassin; A no-op on new installs, lets 
-# debian-spamd claim ownership of spamassassin updates on upgrades.
+if ! getent passwd debian-spamd > /dev/null ; then
+adduser --system --group --shell /bin/sh --disabled-password \
+--home /var/lib/spamassassin debian-spamd
+else
+mkdir -p /var/lib/spamassassin
+fi
+
+OWNER=$(stat -c '%U' /var/lib/spamassassin)
+GROUP=$(stat -c '%G' /var/lib/spamassassin)
+
+# Lets debian-spamd claim ownership of spamassassin updates on upgrades,
+# unless the user has overridden.
+if ! dpkg-statoverride --list /var/lib/spamassassin/* >/dev/null && \
+[ "$OWNER:$GROUP" != "debian-spamd:debian-spamd" ]; then
 chown -R debian-spamd:debian-spamd /var/lib/spamassassin
+OWNER=debian-spamd
+GROUP=debian-spamd
 fi
 
 test -d /var/lib/spamassassin/sa-update-keys ||
-install -d -o debian-spamd -g debian-spamd -m 700 /var/lib/spamassassin/sa-update-keys
+install -d -o $OWNER -g $GROUP -m 700 /var/lib/spamassassin/sa-update-keys
 
-su debian-spamd -c "sa-update --gpghomedir /var/lib/spamassassin/sa-update-keys \
+su $OWNER -c "sa-update --gpghomedir /var/lib/spamassassin/sa-update-keys \
 --import /usr/share/spamassassin/GPG.KEY"
 fi
 

Bug#698935: gnome-terminal: right-to-left text is displayed incorrectly (as left-to-right)

[althaser]

Hey Axel,

Could you please try to reproduce this bug with newer version of
gnome-terminal like 3.4.1.1-2 or 3.10.1-1 ?

thanks
althaser

Bug#738975: libconfig-model-dpkg-perl: FTBFS with libev-perl and libtest-harness-perl

[Niko Tyni]

Package: libconfig-model-dpkg-perl
Version: 2.044
Severity: important

The test suite of libconfig-model-dpkg-perl fails when libev-perl and
libtest-harness-perl are installed.

Test Summary Report
---
t/dependency-check.t  (Wstat: 256 Tests: 90 Failed: 1)
  Failed test:  2
  Non-zero exit status: 1
t/model_tests.t   (Wstat: 256 Tests: 570 Failed: 1)
  Failed test:  3
  Non-zero exit status: 1
Files=5, Tests=696, 73 wallclock secs ( 0.16 usr  0.01 sys + 73.44 cusr  0.18 
csys = 73.79 CPU)
Result: FAIL

The failure reason (at least the first one) seems to be this warning
from EV.pm, as used by AnyEvent when installed:

#   Failed test 'test BDI warn on unittest instance'
#   at t/dependency-check.t line 132.
# found warning: Too late to run CHECK block at /usr/lib/perl5/EV.pm line 123.

It looks like the newer Test::Harness in libtest-harness-perl (3.30)
enables warnings where the older one (version 3.26 bundled with perl)
doesn't. The old case has $^W==0 during t/dependency-check.t execution
while the new one has $^W==1.

The relevant change in Test-Harness is probably

3.272013-04-30
[...]
- restore "always add -w to switches" behavior

-- 
Niko Tyni   nt...@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#738188: VESA Newcons is awfully slow

[Robert Millan]

On 14/02/2014 11:00, Aleksandr Rybalko wrote:
>> > Strange. What I get now is black screen during 3 seconds every time I 
>> > switch VT.
> 3 seconds is for VirtualBox, right?

No, real hardware (Radeon HD 2400 PRO).

This black screen is not just black pixels, it looks a lot like the usual "mode 
switch" effect
between X and text console.

-- 
Robert Millan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738957: dpkg-maintscript-helper: prepare_dir_to_symlink can never succeed

[Guillem Jover]

Hi!

On Fri, 2014-02-14 at 10:10:52 +0100, Richard Levitte wrote:
> Package: dpkg
> Version: 1.17.6
> Severity: important
> Tags: patch

> This is a problem that I encountered when trying to upgrade php-aws-sdk from
> 1.5.6.2-1 to 2.5.2-1, I would get these messages (the first repeats a large
> number of times):
[…]
> The code performed with sh -c will never be able to succeed, easily
> demonstrated as follows:
> 
> : ; sh -c 'return 0'
> sh: line 0: return: can only `return' from a function or sourced script
> : ; echo $?
> 1
> 
> However, using exit works, as expected:
> 
> : ; sh -c 'exit 0'
> : ; echo $?
> 0

Hmm, I guess you are using bash instead of dash as /bin/sh.

> Patch included

Thanks, merged locally, will be in my next push targetting 1.17.7.

Regards,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#712796: +1

[Salvo Tomaselli]

I agree that such a feature would be needed.


-- 

Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738976: abi-compliance-checker: and multiarch

[Maximiliano Curia]

Package: abi-compliance-checker
Version: 1.99.9-1
Severity: normal
Tags: upstream

Hi,

In a multi-arch system, as Debian aims to be, having to change the  part
of the acc in each architecture its quite troublesome, specially if you are
trying to use a tool like dh_acc.

There a couple of possible solutions to this problem:
 Make the non absolute path libs not found in the current directory to be
 searched in the default system directories, which should include the m-a
 path.

 Add file globs processing in th  tags to be able to write:
 /usr/lib/*/libfoo.so (sadly, this will fail if the user is actually using a
 m-a system).

 Add environment variables support in the .acc files, so we can use:
 
/usr/lib/${DEB_HOST_MULTIARCH}/libfoo.so
 

Please, if possible, provide one of the solutions.

Thank you.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages abi-compliance-checker depends on:
ii  build-essential  11.6
ii  perl 5.18.2-2

Versions of packages abi-compliance-checker recommends:
ii  exuberant-ctags [ctags]  1:5.9~svn20110310-6

Versions of packages abi-compliance-checker suggests:
pn  doc-base  
pn  icheck

-- 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#738757: new version available: 1.0.4

[chrysn]

hello bernd, hello python modules team,

On Wed, Feb 12, 2014 at 07:41:12PM +0100, chrysn wrote:
> * python3 is now supported

as i prefer to use python3 these days, i've added a python3-wtforms
package in the patches attached. things didn't work out of the box with
--buildsystem=python_distutils with my limited understanding thereof,
but --buildsystem=pybuild just did the trick, so that's a major change
in 0001-pybuild-working-with-python3.patch. (also, bumped debhelper
compat to 9 -- at least 8 would have been required for pybuild).

until bug #736878 is fixed, python3-django is not mentioned. the
'Disabled test' issue persists.

the documentation i split out into a -doc package in a second patch
(0002-split-documentation-out-into-dedicated-package.patch). i tried
adding ,sphinxdoc to --with, but dh_sphinxdoc did not recognize the
generated documentation. i did not investigate much further, as i don't
know how sphinx documentation is usually built.

please consider including python3 support when uploading an updated
version.

best regards
chrysn

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom
From dd460b124d7a3951f00138557e08b944b51641e2 Mon Sep 17 00:00:00 2001
From: chrysn 
Date: Fri, 14 Feb 2014 12:14:32 +0100
Subject: [PATCH 1/2] pybuild working with python3

---
 debian/compat  |  2 +-
 debian/control | 20 ++--
 debian/python-wtforms.install  |  1 +
 debian/python3-wtforms.install |  1 +
 debian/rules   |  6 +++---
 5 files changed, 24 insertions(+), 6 deletions(-)
 create mode 100644 debian/python-wtforms.install
 create mode 100644 debian/python3-wtforms.install

diff --git a/debian/compat b/debian/compat
index 7f8f011..ec63514 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-7
+9
diff --git a/debian/control b/debian/control
index c2becea..7532dd5 100644
--- a/debian/control
+++ b/debian/control
@@ -3,11 +3,14 @@ Maintainer: Debian Python Modules Team 
 Section: python
 Priority: optional
-Build-Depends: debhelper (>= 7.0.50~), python-all (>= 2.6.6-3~)
+Build-Depends: debhelper (>= 9), python-all (>= 2.6.6-3~), python3-all, dh-python, python-setuptools
 Build-Depends-Indep: python-sqlalchemy (>= 0.5), python-django, python-dateutil,
- python-sphinx (>= 0.6), python (>= 2.6.6-3~) | python-pysqlite2
+ python-sphinx (>= 0.6), python (>= 2.6.6-3~) | python-pysqlite2,
+ python3-sqlalchemy (>= 0.5), python3-dateutil,
+ python3-sphinx (>= 0.6)
 Standards-Version: 3.9.1
 X-Python-Version: >= 2.4
+X-Python3-Version: >= 3.0
 Homepage: http://wtforms.simplecodes.com/
 Vcs-Svn: svn://anonscm.debian.org/python-modules/packages/wtforms/trunk/
 Vcs-Browser: http://anonscm.debian.org/viewvc/python-modules/packages/wtforms/trunk/
@@ -22,3 +25,16 @@ Description: flexible forms validation and rendering library for Python
  with templates, using the template engine of your choice. It also allows
  to create forms based on ORM models from Django, SqlAlchemy and the
  Google Appengine.
+
+Package: python3-wtforms
+Architecture: all
+Depends: ${misc:Depends}, ${python3:Depends}
+Suggests: python3-sqlalchemy  (>= 0.5)
+Recommends: python3-dateutil, libjs-jquery, libjs-underscore
+Description: flexible forms validation and rendering library for Python 3
+ WTForms is a HTML form field generator which allows full customization
+ with templates, using the template engine of your choice. It also allows
+ to create forms based on ORM models from Django, SqlAlchemy and the
+ Google Appengine.
+ .
+ This is the Python 3 version of the package.
diff --git a/debian/python-wtforms.install b/debian/python-wtforms.install
new file mode 100644
index 000..b2cc136
--- /dev/null
+++ b/debian/python-wtforms.install
@@ -0,0 +1 @@
+usr/lib/python2*
diff --git a/debian/python3-wtforms.install b/debian/python3-wtforms.install
new file mode 100644
index 000..4606faa
--- /dev/null
+++ b/debian/python3-wtforms.install
@@ -0,0 +1 @@
+usr/lib/python3*
diff --git a/debian/rules b/debian/rules
index 6c564d0..42a1fc1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,10 +1,10 @@
 #!/usr/bin/make -f
 
 %:
-	dh --buildsystem=python_distutils --with=python2 $@
+	dh $@ --buildsystem=pybuild --with=python2,python3
 
 build:
-	dh --buildsystem=python_distutils --with=python2 $@
+	dh $@ --buildsystem=pybuild --with=python2,python3
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 	-cd tests ;\
 	for python in $(shell pyversions -vr); do \
@@ -17,7 +17,7 @@ endif
 	rm docs/_build/html/_static/jquery.js
 
 clean:
-	dh --buildsystem=python_distutils --with=python2 $@
+	dh $@ --buildsystem=pybuild --with=python2,python3
 	rm -rf docs/_build
 
 
-- 
1.9.0.rc3

From 1c6b1df641920eb55f01ac96e699beffd6c513e4 Mon Sep 17 00:00:00 2001
From: chrysn 
Date: Fri, 14 Feb 2014 12:40:52 +0100
Subject: [PATCH 2/2] split documentation out into dedicated package

---
 debian/control  | 19 ---
 debian/d

Bug#646020: Ping: CVE-2011-3624

[Arne Wichmann]

begin  quotation  from Antonio Terceiro (in <20140212131039.ga2...@debian.org>):
> On Mon, Feb 10, 2014 at 03:49:31PM +0100, Arne Wichmann wrote:
> > There has been no action on this bug for over a year now. Is there any plan
> > to do something about this?
> 
> not quite
> 
> - there is no patch for this anywhere
> - webrick is hardly something that anyone with a little bit of sanity
>   would use in production

I see. Maybe there should just be a clear warning against using this (for
example by syslogging a warning) and then it could be marked as unimportant
in the security tracker...

cu

AW
-- 
[...] If you don't want to be restricted, don't agree to it. If you are
coerced, comply as much as you must to protect yourself, just don't support
it. Noone can free you but yourself. (crag, on Debian Planet)
Arne Wichmann (a...@linux.de)


signature.asc
Description: Digital signature

Bug#733974: Please tell upstream bugreport for Minetest crashes when selecting Client->"Public Serverlist" and Mods->"Online mod repository"

[Baltix Linux]

Hi Martin,

Sun, 2 Feb 2014 21:35 Martin Quinson wrote:
> Actually, I reported the bug to upstream, seeking for help.
> I'm myself useless and clueless here.

I can't find your bugreport in upstream BTS:
https://github.com/minetest/minetest/issues
Please tell upstream bugreport URL for Minetest crashes when selecting
Client->"Public  Serverlist" and Mods->"Online mod repository"

Thanks,
-- 
Prekyba kompiuteriais su Linux OS - http://tinklas.eu/prekyba
Naudokite laisvą Linux operacinę sistemą savo kompiuteryje -
http://baltix.akl.lt
Use Baltix GNU/Linux OS !


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738188: VESA Newcons is awfully slow

[Aleksandr Rybalko]

On 14 лютого 2014 р. 14:31:45 GMT+02:00, Robert Millan  wrote:
>On 14/02/2014 11:00, Aleksandr Rybalko wrote:
>>> > Strange. What I get now is black screen during 3 seconds every
>time I switch VT.
>> 3 seconds is for VirtualBox, right?
>
>No, real hardware (Radeon HD 2400 PRO).
>
>This black screen is not just black pixels, it looks a lot like the
>usual "mode switch" effect
>between X and text console.

Aha, so it is mode switch, so display done that job a bit long.
Ok, I will try to modify mode restore, to check old mode before forcing new one.

Thanks!
WBW
--
Aleksandr Rybalko 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#516394: [security]: Rapid DNS Poisoning in dnscache

[sa9k063]

Hello,

On 02/13/2014 08:30 PM, coldtobi wrote:
> Source: djbdns
> Followup-For: Bug #516394
> 
> Hi, 
> 
> regarding this bug: It seems that the the German Chaos Computer Clubs' DNS 
> got be owned due to this bug. [1]

no. It is not debians fault when users do not install security updates.

hth


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738977: [uscan] How to use OpenPGP verification with a download from alioth.debian.org?

[Ludovic Rousseau]

Package: devscripts
Version: 2.14.1
Severity: normal

Hello,

I want to use the OpenPGP feature of uscan on a project hosted on
alioth.debian.org.

The download page is at https://alioth.debian.org/frs/?group_id=30105

The problem is that alioth generates strange URL.
For the version 1.4.15 of ccid the binary is at:
https://alioth.debian.org/frs/download.php/file/3989/ccid-1.4.15.tar.bz2
the signature is at:
https://alioth.debian.org/frs/download.php/file/3990/ccid-1.4.15.tar.bz2.asc

The name at the end of the URL is not meaningfull, only the number 3989
or 3990 is.

The URL https://alioth.debian.org/frs/download.php/file/3989/foobar will
also download the archive.


My question: how to write the pgpsigurlmangle rule in such a case?

My debian/watch file is:
version=3
opts=pgpsigurlmangle=s/$/.asc/ \
https://alioth.debian.org/frs/?group_id=30105 \
.*/ccid-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz))

But that does not work as the signature will be downloaded using the URL
https://alioth.debian.org/frs/download.php/file/3989/ccid-1.4.15.tar.bz2.asc
This URL is not correct.

$ uscan --verbose --debug
[...]
uscan debug: matching pattern(s) 
(?:(?:https://alioth.debian.org)?\/frs\/\?group_id\=30105)?.*/ccid-(\d.*)\.(?:tgz|tar\.(?:gz|bz2|xz))
-- Found the following matching hrefs:
 /frs/download.php/file/3989/ccid-1.4.15.tar.bz2 (1.4.15)
 /frs/download.php/latestfile/112/ccid-1.4.15.tar.bz2 (1.4.15)
 /frs/download.php/file/3971/ccid-1.4.14.tar.bz2 (1.4.14)
 /frs/download.php/latestfile/112/ccid-1.4.14.tar.bz2 (1.4.14)
 /frs/download.php/file/3959/ccid-1.4.13.tar.bz2 (1.4.13)
 /frs/download.php/latestfile/112/ccid-1.4.13.tar.bz2 (1.4.13)
 /frs/download.php/file/3937/ccid-1.4.12.tar.bz2 (1.4.12)
 /frs/download.php/latestfile/112/ccid-1.4.12.tar.bz2 (1.4.12)
 /frs/download.php/file/3920/ccid-1.4.11.tar.bz2 (1.4.11)
 /frs/download.php/latestfile/112/ccid-1.4.11.tar.bz2 (1.4.11)
 /frs/download.php/file/3897/ccid-1.4.10.tar.bz2 (1.4.10)
 /frs/download.php/latestfile/112/ccid-1.4.10.tar.bz2 (1.4.10)
 /frs/download.php/file/3866/ccid-1.4.9.tar.bz2 (1.4.9)
 /frs/download.php/latestfile/112/ccid-1.4.9.tar.bz2 (1.4.9)
 /frs/download.php/file/3768/ccid-1.4.8.tar.bz2 (1.4.8)
 /frs/download.php/latestfile/112/ccid-1.4.8.tar.bz2 (1.4.8)
 /frs/download.php/file/3730/ccid-1.4.7.tar.bz2 (1.4.7)
 /frs/download.php/latestfile/112/ccid-1.4.7.tar.bz2 (1.4.7)
 /frs/download.php/file/3711/ccid-1.4.6.tar.bz2 (1.4.6)
 /frs/download.php/latestfile/112/ccid-1.4.6.tar.bz2 (1.4.6)
 /frs/download.php/file/3672/ccid-1.4.5.tar.bz2 (1.4.5)
 /frs/download.php/latestfile/112/ccid-1.4.5.tar.bz2 (1.4.5)
 /frs/download.php/file/3579/ccid-1.4.4.tar.bz2 (1.4.4)
 /frs/download.php/latestfile/112/ccid-1.4.4.tar.bz2 (1.4.4)
 /frs/download.php/file/3535/ccid-1.4.3.tar.bz2 (1.4.3)
 /frs/download.php/latestfile/112/ccid-1.4.3.tar.bz2 (1.4.3)
 /frs/download.php/file/3518/ccid-1.4.2.tar.bz2 (1.4.2)
 /frs/download.php/latestfile/112/ccid-1.4.2.tar.bz2 (1.4.2)
 /frs/download.php/file/3475/ccid-1.4.1.tar.bz2 (1.4.1)
 /frs/download.php/latestfile/112/ccid-1.4.1.tar.bz2 (1.4.1)
 /frs/download.php/file//ccid-1.4.0.tar.bz2 (1.4.0)
 /frs/download.php/latestfile/112/ccid-1.4.0.tar.bz2 (1.4.0)
 /frs/download.php/file/3300/ccid-1.3.13.tar.bz2 (1.3.13)
 /frs/download.php/latestfile/112/ccid-1.3.13.tar.bz2 (1.3.13)
 /frs/download.php/file/3281/ccid-1.3.12.tar.bz2 (1.3.12)
 /frs/download.php/latestfile/112/ccid-1.3.12.tar.bz2 (1.3.12)
 /frs/download.php/file/3080/ccid-1.3.11.tar.bz2 (1.3.11)
 /frs/download.php/latestfile/112/ccid-1.3.11.tar.bz2 (1.3.11)
Newest version on remote site is 1.4.15, local version is 1.4.14
 => Newer version available from
https://alioth.debian.org/frs/download.php/file/3989/ccid-1.4.15.tar.bz2
-- Downloading updated package ccid-1.4.15.tar.bz2
uscan debug: requesting URL 
https://alioth.debian.org/frs/download.php/file/3989/ccid-1.4.15.tar.bz2
-- Downloading OpenPGP signature for package as ccid-1.4.15.tar.bz2.pgp
uscan debug: requesting URL 
https://alioth.debian.org/frs/download.php/file/3989/ccid-1.4.15.tar.bz2.asc
-- Verifying OpenPGP signature ccid-1.4.15.tar.bz2.pgp for ccid-1.4.15.tar.bz2
gpgv: no valid OpenPGP data found.
gpgv: the signature could not be verified.
Please remember that the signature file (.sig or .asc)
should be the first file given on the command line.
uscan warning: OpenPGP signature did not verify.

$ md5sum ../ccid-1.4.15.tar.bz2*
c195333c953f5530bc04a194b5ac1b71  ../ccid-1.4.15.tar.bz2
c195333c953f5530bc04a194b5ac1b71  ../ccid-1.4.15.tar.bz2.pgp


uscan would have to add ".asc" to the filename and parse again the html
page to find the URL for this file, not just add ".asc" at the end of
the URL for the archive.
Is that possible with uscan?

It would be a bad news if uscan OpenPGP signature check can't be used
with Debian own forge :-)


-- Package-speci

Bug#738978: transition: x264

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I've prepared a new upstream release of libx264, and we need to rebuild
all applications that link against it. AFAIUI, this transition should be
rather smooth because it affects only a few packages.

Thanks

Ben file:

title = "x264";
is_affected = .depends ~ "libx264-133" | .depends ~ "libx264-142";
is_good = .depends ~ "libx264-142";
is_bad = .depends ~ "libx264-133";


-- System Information:
Debian Release: 7.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.11.0-15-generic (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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738188: VESA Newcons is awfully slow

[Robert Millan]

On 14/02/2014 13:04, Aleksandr Rybalko wrote:
> On 14 лютого 2014 р. 14:31:45 GMT+02:00, Robert Millan  
> wrote:
>> On 14/02/2014 11:00, Aleksandr Rybalko wrote:
> Strange. What I get now is black screen during 3 seconds every
>> time I switch VT.
>>> 3 seconds is for VirtualBox, right?
>>
>> No, real hardware (Radeon HD 2400 PRO).
>>
>> This black screen is not just black pixels, it looks a lot like the
>> usual "mode switch" effect
>> between X and text console.
> 
> Aha, so it is mode switch, so display done that job a bit long.
> Ok, I will try to modify mode restore, to check old mode before forcing new 
> one.

Excellent. Please let me know if you need some change tested.

-- 
Robert Millan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#725579: lldpad: FTBFS: automake errors

[Hideki Yamane]

On Thu, 13 Feb 2014 01:14:02 +0530
Ritesh Raj Sarraf  wrote:
> Had you verified it on sparc ?

 No, I just eliminated RC bugs in BTS.


-- 
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#738965: systemd: Circular dependencies caused by Debian specific handling of runlevel S sysv init scripts.

[Michael Biebl]

Hi Jon,

Am 14.02.2014 11:31, schrieb Jon Severinsson:
> The debian/patches/debian-changes patch add, amongst other things,
> code to make any sysv init script with Default-Start: S gain
> WantedBy=sysinit.target and Before=sysinit.target.
> 
> However, upstream systemd already contains code to map any
> Required-Start: $network into After=network.target and any
> Required-Start: $remote_fs into After=remote-fs.target.
> Unfortunately, both network.target and remote-fs.target are
> typically started after sysinit.target, and in many cases
> (indirectly) Require=sysinit.target.


It's correct that the handling of rcS style init scripts is a Debian
specific patch. Upstream has removed this functionality under the
assumption that the early boot stage should be handled by native service
files only. We aren't quite there yet in Debian, there are still 100+
packages shipping SysV init scripts in rcS.

> This causes a cyclic dependency, which systemd tries to resolve
> by removing, essentially at random, or more of the involved units
> from the transaction. On one particular system of mine, this
> reliably turns out to be dbus.socket, without which the system
> becomes more-or-less unusable.

I assume you have a SysV init script in rcS which has
Required-Start: $remote_fs
and the network.target is enabled and active (most likely pulled in by
NetworkManager)?


> To solve this problem, while still making sure runlevel S sysv init
> scripts are run before runlevel 2, 3, 4 and 5 sysv init scripts, I
> would recommend changeing sysinit.target to basic.target. This would
> not completely solve the problem, as network.target might (indirectly)
> Require=basic.target as well, but it would mitigate it significantly
> (as dbus.socket is no longer involved in the cycle), and makes it
> possible to completely eliminate the cycle by changeing the network
> providers (in this case NetworkManager.service) to not depend on
> basic.target. (Note that it is not possible to change NetworkManger
> to not depend on sysinit.target, as it requires dbus.socket for basic
> operatation, and dbus.socket Requires=sysinit.target).
> 
> Attaching a one-line patch that would solve the systemd part of this
> problem by replacing SPECIAL_SYSINIT_TARGET with SPECIAL_BASIC_TARGET
> at line 4072 in debian/patches/debian-changes. I will follow up with
> a patch to NetworkManager as a separate bug report later.

I vaguely remember that we discussed this issue a while ago and I'm not
convinced your patch actually addresses the issue properly.

In an ideal world, we'd simply convert all rcS SysV init scripts to
native .service files. This will take time though.

My proposal for the meantime would be to replace the $remote_fs
dependency for rcS style SysV init scripts with $local_fs.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#732368: iceweasel: FTBFS on powerpcspe: AltiVec and E500 instructions cannot coexist

[Sylvestre Ledru]

Hello Roland,

Are you going to push your patch upstream or do you want me to do it ?

Do you patch make ff work under powerpcspe ?

thanks,
S


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#713203: g-wrap: FTBFS: /bin/sh: 1: aclocal-1.11: not found

[Hideki Yamane]

Hi,

On Fri, 14 Feb 2014 02:16:01 +
peter green  wrote:
> I notice your patch is based on the experimental version of the package. 

 Ooh, I've not noticed it, thanks.

> Afaict (note: i'm not the maintainer of this package) uploading a 
> package based on the experimental version to unstable would be a bad 
> idea without further coordination/planning as it would cause a 
> build-dependency conflict in guile-gnome-platform (I found this out the 
> hard way in raspbian).

 Yes, but as the patch suggested it would be put to experimental.
 And guile maintainer Rob suggested(*) those guile-depends-packages should
 move to guile 2.0 if we can.

 *) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707901 etc.

 Probably maintainer put it to experimental once because Debian was 
 around freeze time(*) (yes, just wild guess).

 *) https://lists.debian.org/debian-devel-announce/2012/06/msg9.html



-- 
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#738965: [Pkg-systemd-maintainers] Bug#738965: systemd: Circular dependencies caused by Debian specific handling of runlevel S sysv init scripts.

[Michael Biebl]

Am 14.02.2014 14:39, schrieb Michael Biebl:
> In an ideal world, we'd simply convert all rcS SysV init scripts to
> native .service files. This will take time though.
> 
> My proposal for the meantime would be to replace the $remote_fs
> dependency for rcS style SysV init scripts with $local_fs.

Jon, do you want to work on such a patch?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#698258: ITP: python-charade -- universal encoding detector for Python 2 and Python 3

[Etienne Millon]

Hi,

According to pypi, charade has been merged into chardet.
Is packaging charade still relevant?

* https://pypi.python.org/pypi/chardet:
> This is a continuation of Mark Pilgrim's excellent chardet.
> Previously, two versions needed to be maintained: one that supported
> python 2.x and one that supported python 3.x. We've recently merged
> with Ian Corduscano's charade fork, so now we have one coherent
> version that works for Python 2.6+.

-- 
Etienne Millon


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

[Ian Jackson]

Josselin Mouette writes ("Bug#727708: init system coupling etc."):
> In all cases, it is unacceptable to put the burden of implementing
> logind on non-systemd systems on maintainers of packages that just need
> the logind interfaces. If it is not available, software such as gdm3
> will depend, directly or indirectly, on systemd as PID 1, and that will
> be all.

Firstly, I think the scenario where the required integration work is
not done is unlikely.  But in that scenario, we have two choices:
 (a) Effectively, drop all init systems other than systemd
 (b) Effectively, drop GNOME

Of these, (b) is IMO clearly preferable.  Our downstreams can
straightforwardly provide a more specific Debian derivative which runs
GNOME and (only) systemd.  Asking our downstreams to reintroduce
support for a non-systemd init system is not feasible.

With (a) the only option for people who didn't want systemd would be
to either fork the whole of the Debian project and declare themselves
a new upstream for all of what Debian now does, or to abandon Debian
and its derivatives altogether.

With (b) people who want GNOME and systemd can do that work as a
Debian derivative; it is not necessary to fork the whole project.

The doomsday scenario of choosing between (a) and (b) becomes less
likely if we make it clear how bad it would be.  We need to provide
appropriate backpressure to encourage upstream decisions that support
the continued freedom of our users.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738414: testrepository: FTBFS: Can't locate Debian/Debhelper/Buildsystem/pybuild.pm in @INC

[Hideki Yamane]

Control: tags -1 +patch +pending

Hi,

 Just adding dependency would fix this FTBFS, please check 
 and consider to apply attached patch.


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane
diff -Nru testrepository-0.0.18/debian/changelog testrepository-0.0.18/debian/changelog
--- testrepository-0.0.18/debian/changelog	2014-01-16 05:16:48.0 +0900
+++ testrepository-0.0.18/debian/changelog	2014-02-14 22:47:01.0 +0900
@@ -1,3 +1,11 @@
+testrepository (0.0.18-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control
+- add "Build-Depends: dh-python" to eliminate FTBFS (Closes: #738414)
+
+ -- Hideki Yamane   Fri, 14 Feb 2014 22:47:00 +0900
+
 testrepository (0.0.18-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru testrepository-0.0.18/debian/control testrepository-0.0.18/debian/control
--- testrepository-0.0.18/debian/control	2014-01-16 05:14:08.0 +0900
+++ testrepository-0.0.18/debian/control	2014-02-14 22:46:23.0 +0900
@@ -6,6 +6,7 @@
 Section: python
 Priority: optional
 Build-Depends: debhelper (>= 9),
+   dh-python,
python-all (>= 2.6.6-3~),
python-fixtures,
python-setuptools,

Bug#720516: reaver: wash failing to produce any output

[Przemyslaw Kochanski]

Wouldn't just adding 'mkdir /etc/reaver' to postinst script fix the problem?

Bug#698258: ITP: python-charade -- universal encoding detector for Python 2 and Python 3

[Daniele Tricoli]

retitle 698258 RFP: python-charade -- universal encoding detector for Python 2 
and Python 3
noowner 698258
thanks

Hello Etienne,

On Friday 14 February 2014 14:49:41 Etienne Millon wrote:
> According to pypi, charade has been merged into chardet.
> Is packaging charade still relevant?

Thanks for reminding that I had to close this bug.
Yes, I talked to Piotr after the discovery of the merge, and
packaging charade make no sense anymore:
closing this bug was in my TODO list, thanks for the reminder!

Piotr, I can help updating python-chardet if you agree.

Kind regards,

-- 
 Daniele Tricoli 'Eriol'
 http://mornie.org

signature.asc
Description: This is a digitally signed message part.

Bug#738962: python-csb: More issues with the tests

[Tomas Di Domenico]

Dear Dmitry,

thank you very much for your feedback. Please bear with me and my
probably basic questions. This is my first packaging effort in Debian.

On 14/02/14 11:18, Dmitry Shachnev wrote:
> 1) python-csb should depend on python-numpy and python-scipy (and
> python3-csb should depend on python3-numpy and python3-scipy).
> These dependencies are specified in REQUIRES field in setup.py and,
> as I understand, the package is mostly useless without these
> dependencies. The tests also need numpy to succeed.

I see your point. Right now, build-depends is set to:

  debhelper (>=
9),python-all,python3-all,python-epydoc,python-numpy,python-scipy,python-matplotlib

And the test dependencies
  python-csb,python3-csb,python-unittest2,python-numpy

I'm a bit confused about the dependencies and referencing to the
source or binary packages, and whether they're missing from only the
tests or also from the main package. Where should the references to
the binary package python3-numpy and -scipy be added?

> 2) In debian/tests/build, Makefile-style variables are used. I
> think that was blindly copied from debian/rules, and not really
> needed.
> 
> Also, you use python instead of $python, so in fact the test is
> ran three times for python2.7.
> 
> I would write the command like this:
> 
> for py in $(pyversions -i) $(py3versions -i); do PYTHONWARNINGS=d
> $py test/app.py --generated-resources /tmp --verbosity 2 done
> 
> Note that I also increased verbosity to get the more understandable
> output in case of failures.

Thank you very much for your suggestion. I've updated the code
accordingly.

> 3) One of the tests fails (at least with Python 2.7): 4) The tests
> failures are ignored. When the test fails for python2.7, the next 
> tests are run.

After I figure out the correct setup for the tests I'll try to
reproduce 3) and  4), and will probably get back to you with more
questions ;)

> 5) Some test is printed into stderr, for example the deprecation
> warnings and names of the tests. Autopkgtest considers that as a
> failure by default, to allow stderr you need to add this line to
> debian/tests/control:
> 
> Restrictions: allow-stderr

Is the addition of this restriction a good idea, or should I rather
try to get upstream to change the behaviour?

Once again, thank you for your detailed observations. They are
extremely helpful.

Cheers,
Tomás


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

[Ansgar Burchardt]

Ian Jackson  writes:
> Firstly, I think the scenario where the required integration work is
> not done is unlikely.  But in that scenario, we have two choices:
>  (a) Effectively, drop all init systems other than systemd
>  (b) Effectively, drop GNOME
>
> Of these, (b) is IMO clearly preferable.

Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
plans to depend on logind... And it sounds like a really brillant idea
to drop all of them to keep ChaosEsque Team happy with Debian.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#707851: [call for seconds] Re: Bug#707851: Let's remove the Debian menu from the Debian Policy ?

[Markus Koschany]

Hello Charles,

On 14.02.2014 00:46, Charles Plessy wrote:
[...]
> In his original wording, Josselin proposed to add at the end of section 9.6 
> one
> sentence pointing to the Debian menu as an option.  Here it is, rephrased to
> replace “legacy window managers” by “window managers that do not support the
> FreeDesktop standard”, which is more techically precise.
> 
> 
>   Packages can, to be compatible with Debian additions to some window
>   managers that do not support the FreeDesktop standard, also provide 
> a
>   Debian menu file, following the Debian menu 
> policy,
>   which can be found in the menu-policy files in the
>   debian-policy package.  It is also available from the 
> Debian
>   web mirrors atid="http://www.debian.org/doc/packaging-manuals/menu-policy/";>.
> 
> 
> With the addition above, I call for seconds (patch attached).  Markus, please
> raise your hand if I was wrong to think that this addition correctly addresses
> your comments.

Seconded.

Thank you for keeping me in the loop. I think the above wording is
sensible and addresses my concerns and those of others here in this
thread. Thanks for your work on the Policy.

Sune Vuoela wrote:
> I do think a paragraph like that still makes the changes better than 'status 
> quo', but I do also think that it would be better to 1) not ship this 
> paragraph and 2) apologize to Markus and the games team for having wasted 
> their time with menu files.  This ensures that we in a year don't have to 3) 
> apologize to the rest of the Debian community for having wasted their time 
> with menu files.
> 
> But still. Better than status quo.

I can understand, from the point of view of GNOME, KDE and Xfce users,
that menu files are not useful anymore because they are de facto
superseded by desktop files and the synergy effects with other
distributions are now far greater. However one should keep in mind that
menu files predate desktop files and that they have been widely adopted
because they are a grown and mature alternative.

I think there is no need to apologize since a significant amount of work
has already been done to support menu and desktop files in the past. We
are in a very fortunate situation, in which it is easier to reach the
goal to support both menu systems for games, than it is to get rid of
menu files completely.

I think this gradual approach of the Debian Policy by making
intermediate steps, instead of recommending something and then not even
mentioning it in the next revision, serves users and the Debian
community as a whole better. Now everybody knows that the xdg standard
should be supported by desktop applications but on the other hand,
everybody is free to include a proven menu system which is still useful
for lightweight desktop environments.

What develops from this change, the future will tell.

Regards,

Markus







signature.asc
Description: OpenPGP digital signature

Bug#738980: should optionally(?) trigger suspend or hibernate action

[Holger Levsen]

package: fdpowermon
severity: wishlist

Hi Wouter,

thanks for fdpowermon, I like it. I would like it even more if it could, maybe 
optionally, also trigger supspend or hibernate actions if the battery is below 
threshold, eg 3% or whatever.


cheers,
Holger



signature.asc
Description: This is a digitally signed message part.

Bug#738981: please switch arm to use generic_fpu

[Riku Voipio]

Package: mpg123
Version: 1.16.0-1
Severity: normal
Tags: patch

Hi,

As discussed at 

https://bugs.launchpad.net/ubuntu/+source/mpg123/+bug/1072696

mpg123 and audacious fail to work together on arm with current
cpu setting of mpg123. Not providing float output could be
considered and abi difference.

The better solution would of course be to upstream to runtime cpu
detection. 

But for the time being, it seems the best solution is to pass
--with-cpu=generic_fpu for generic codepath.

--- mpg123-1.16.0/debian/rules  2013-10-07 13:16:59.0 +0300
+++ mpg123-1.16.0/debian/rules  2014-02-14 09:17:02.0 +0200
@@ -22,6 +22,7 @@
--with-module-suffix=.so
 
 CONF_i486:=--with-cpu=x86_dither
+CONF_arm:=--with-cpu=generic_fpu
 
 SOVERSION:=0
 LIB_PKG:=libmpg123-$(SOVERSION)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738923: parted3 preparations

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/14/2014 12:09 AM, Cyril Brulebois wrote:
> The parted3 transition is about transitioning from libparted0 to 
> libparted2? Anyway, why is the -dev package versioned at all?
> Unless you keep several source packages in the archive for a while,
> there's no use for having a versioned -dev package.

I believe the reason is that for a long time, upstream did not manage
their soname versioning correctly, leaving it at zero despite breaking
ABI, and finally with parted 3.0, jumped to 2 since they removed the
filesystem apis.  So debian packaged the library as -0debian1.  I'm
not sure why they put the 0 in the -dev package as well.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS/iZ5AAoJEI5FoCIzSKrwdCgIAKRiJuOjrCgCGJu/QdoR1b1G
YjVhjkU73NxR7KT74jnCEMGDncYPdf3qQyUSqbSdijUT6tkUB2bP5mQooqic96kH
OAAFPcMzM3pxYdzElusC1IHEOV4Y4kPCL8Kq0xutNu05nDMOgx1zZY+Iu0BRGkqF
WkQ2df9VkOL/r/f68iXU9jC68iHdTv6Cj5xsNJ+D/MK/QksYg15ST+V3praFhsAo
MSWoN2ArGz0db7MqM/QrNHFn2L1c5VgOq8R+EnViB7Q1J9/RW0/y9W1TPsbCBE+5
AJGhdAkcvqpCrlu1Y/w1MrAXcekKlhwJtFe0FGXss4oA7kKeBRCKZrUaaidyik0=
=ayLd
-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#738982: (no subject)

[Chris M]

Subject: catfish: 1.0.0-1 Not Launching in Testing
Package: catfish
Version: 1.0.0-1


Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

1.0.0-1 has come into Testing, even though 0.8.2-1 still shows in Packages.

All dependencies are met. It just won't execute - on XFCE.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.12-1-amd64 (SMP w/4 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 catfish depends on:
ii  gir1.2-gdkpixbuf-2.0  2.28.2-1+b1
ii  gir1.2-glib-2.0   1.36.0-2+b1
ii  gir1.2-gtk-3.03.8.6-1
ii  gir1.2-pango-1.0  1.36.0-1+b1
pn  python:any

Versions of packages catfish recommends:
ii  locate   4.4.2-7
ii  mlocate  0.26-1

Versions of packages catfish suggests:
pn  python-zeitgeist  
pn  zeitgeist 

-- 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#733974: Please tell upstream bugreport for Minetest crashes when selecting Client->"Public Serverlist" and Mods->"Online mod repository"

[Martin Quinson]

On Fri, Feb 14, 2014 at 02:58:42PM +0200, Baltix Linux wrote:
> Hi Martin,
> 
> Sun, 2 Feb 2014 21:35 Martin Quinson wrote:
> > Actually, I reported the bug to upstream, seeking for help.
> > I'm myself useless and clueless here.
> 
> I can't find your bugreport in upstream BTS:
> https://github.com/minetest/minetest/issues
> Please tell upstream bugreport URL for Minetest crashes when selecting
> Client->"Public  Serverlist" and Mods->"Online mod repository"

I used the IRC for that so far, but I just opened
https://github.com/minetest/minetest/issues/1147

Thanks for the reminder,
Mt

http://irc.minetest.ru/minetest-dev/2014-02-02



-- 
The nice thing about standards is that there are so many to choose from.  And 
if you
really don't like all the standards you just have to wait another year until 
the one
arises you are looking for. -- Tannenbaum, 'Introduction to Computer 
Networks'


signature.asc
Description: Digital signature

Bug#665342: closed by Phillip Susi (please skip mounts with mount point "none" in /etc/fstab)

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/14/2014 2:02 AM, Harald Dunkel wrote:
> Of course I know noauto, but a mount point "none" would be more
> easy to parse, generate and change, and it would be more intuitive
> to use.
> 
> Currently using "none" give me just a warning at boot time. AFAICS
> there are no negative side effect. It was just a suggestion, trying
> to make things better.

The problem with that is that "none" is a perfectly valid device for
some filesystems, and not for others.  This means the latter could not
use it if they wanted to, and the former would be upset at suddenly
not having their filesystems mounted.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS/ieHAAoJEI5FoCIzSKrwepwH/iQqX5gFXq5xc+wQGqOCiUbC
rrt6kkwUL6lKvCchgvg1fC7WY4MVHPgSGP5lRAbVWI4kQQVi59WD4bXkohI1Y+H3
gQ9ltCoDYex2BbliI3QlhxeBXwcCzwts7OhqCfRQ1MjkeTPaRjWhNVW1yVHypVQk
iKSWI/CsplmYY44ci2dn5/niQt/OJIh8hJqKj4pTpiT+ZxFokqpWXFCKeXDCBbc5
6x+wbcNKT2eZ4/GRawxxoU2IR1wV30x3Qq57BVS5rIe5h6pkt9ocAj30FkPStMEz
bJlSoNd3CmTwnYtp0XDnCv2m35gZWZwWSLIq5m/sF4TN95pPis9HUYonSWURZVo=
=BjNn
-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#738984: dpkg-buildflags overrides CFLAGS amendments

[Robie Basak]

Source: php5
Version: 5.5.9+dfsg-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu trusty ubuntu-patch

Downstream bug: https://launchpad.net/bugs/1280044

Currently, debian/rules makes some additions to CFLAGS, including the
use of `getconf LFS_CFLAGS` for large file support on i386.

However, it then includes /usr/share/dpkg/buildflags.mk, which wipes out
these changes. This causes all previous CFLAGS changes to be wiped out,
including large file support. I can see the consequence of this in the
build log when I build i386, where CFLAGS is missing
"-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64".

If I understand your intent correctly, simply moving the buildflags.mk
include to the top fixes this. Proposed patch:

diff -Nru php5-5.5.9+dfsg/debian/rules php5-5.5.9+dfsg/debian/rules
--- php5-5.5.9+dfsg/debian/rules2014-01-11 22:49:54.0 +
+++ php5-5.5.9+dfsg/debian/rules2014-02-14 14:26:44.0 +
@@ -16,6 +16,10 @@
 # compatibility to upstream
 PHP5_COMPAT=no
 
+# enable dpkg build flags
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
+
 DEB_HOST_GNU_TYPE?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_BUILD_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_HOST_ARCH?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
@@ -109,10 +113,6 @@
 MAKEFLAGS += -j$(NUMJOBS)
 endif
 
-# enable dpkg build flags
-DPKG_EXPORT_BUILDFLAGS = 1
-include /usr/share/dpkg/buildflags.mk
-
 COMMON_CONFIG=--build=$(DEB_BUILD_GNU_TYPE) \
--host=$(DEB_HOST_GNU_TYPE) \
--sysconfdir=/etc \



signature.asc
Description: Digital signature

Bug#727708: init system coupling etc.

[Josselin Mouette]

Le vendredi 14 février 2014 à 13:50 +, Ian Jackson a écrit : 
> Josselin Mouette writes ("Bug#727708: init system coupling etc."):
> > In all cases, it is unacceptable to put the burden of implementing
> > logind on non-systemd systems on maintainers of packages that just need
> > the logind interfaces. If it is not available, software such as gdm3
> > will depend, directly or indirectly, on systemd as PID 1, and that will
> > be all.
> 
> Firstly, I think the scenario where the required integration work is
> not done is unlikely.  But in that scenario, we have two choices:
>  (a) Effectively, drop all init systems other than systemd
>  (b) Effectively, drop GNOME

This looks very much like a false dichotomy to me.

You can have (c) GNOME depends on systemd.
Same for KDE and Xfce, BTW, since they are going in the same direction.

Desktop environments are not the only pieces of software in Debian.
Having them depend on systemd doesn’t prevent you from using other init
systems on machines that don’t have them installed.

> The doomsday scenario of choosing between (a) and (b) becomes less
> likely if we make it clear how bad it would be.  We need to provide
> appropriate backpressure to encourage upstream decisions that support
> the continued freedom of our users.

I don’t see how (c) looks bad. What’s the problem of limiting the scope
of non-default init systems? It’s not as if we will want the same level
of support for them than we want for the default init system.

In all cases, this situation happening or not is the result of the work
of people not interested in logind nor in desktop environments. Having
the decision to keep packages in Debian depend on the work of unrelated
people is preposterous.

Cheers,
-- 
 .''`.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#738983: fdpowermon: document how to use scripted themes

[Holger Levsen]

package: fdpowermon
severity: wishlist

Hi Wouter,

please document how to use scripted themes as introduced by fixing #694751. 
Gregors example from this bug,

action = 80:sudo pm-suspend

doesnt seem to work, as grepping for "action" in the source code revealed. 
Documentation is nice anyway.


cheers,
Holger



signature.asc
Description: This is a digitally signed message part.

Bug#738985: fdpowermon: fails to work if libgtk2-notify-perl is not installed

[Holger Levsen]

package: fdpowermon

Hi Wouter,

if libgtk2-notify-perl is not installed, fdpowerman fails to work and doesnt 
fallback to pre libgtk2-notify-perl behaviour:

$ fdpowermon
Can't locate Gtk2/Notify.pm in @INC (@INC contains: /etc/perl 
/usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 
/usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 
/usr/local/lib/site_perl .) at /usr/bin/fdpowermon line 113.
BEGIN failed--compilation aborted at /usr/bin/fdpowermon line 113.

So it seems the recommends you introduced in 1.9 is not good enough.


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#709846: synaptic: Download status column vanishes when downloads begin

[Julian Rüger]

Just wanted to confirm all of Alex' observations :)
(synaptic 0.80.4, libgtk-3-* 3.8.4-1)

Thanks to anyone looking into fixing this!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#648579: closed by Phillip Susi (/bin/mount should create missing mount point)

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/14/2014 2:35 AM, Harald Dunkel wrote:
> Hi Phillip,
> 
> How comes you are closing bug reports for foreign packages? When
> you say "I'm going to have to reject this request", are you
> speaking on behalf of the package maintainer or of upstream? Any
> further explanation _why_ it is rejected?

I am in the process of becoming the package maintainer.

> IMHO creating the missing mount point as necessary would be
> reasonable. It reduces the probability to run into an error, esp.
> for nested mounts using tmpfs and other "dynamic" file system
> types.

You are looking at it backwards.  It increases the probability of
running into an *undiagnosed* error, which is much worse than running
into an error because you made a simple mistake.  In other words, if
you specify the wrong mount point by accident, you want mount to tell
you that you messed up.

It would be wrong of mount to assume that the mistake you made was not
simply a typeo or some other error, but that you just forgot to create
the directory.  For instance, you forgot to mount /foo first, then
tried to mount /foo/bar.  You don't want /foo/bar created in the root
fs, you want to be reminded that you forgot to mount /foo, which
already has the expected bar in it.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS/is5AAoJEI5FoCIzSKrwg08H/2GsqaGhSY5WDVZcXHu33Vn0
8SXKdjM6ObofOUm5edKoLCxsl+y71Chv9gab4MI6IR572AVu3a+b+HkAY5jxJ+Ql
TykID5k1t22BLFyJ5/JfVBcLXRfuzWKoEyPKdQkToK/Yg4Ro7650Jak+5G1vEw1b
dnHKun8KiNw5aptCE3uoyioz1cXMyO9NUBLsjBQtDKZqGDZ5I9tsx3Kg77imWABo
2a0e4xZfZ/OFQDA2l2dbr6GYEuv7AsVujUcBU0KvOqTO2CbX2/ERg386nB6F1f8u
sgX3x1ozgNDxsmcQtv4rHK2eZikHMeo7FSzMkc4JSjrI9p4Dhd9IC2F680fHTRw=
=tIoJ
-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#698258: ITP: python-charade -- universal encoding detector for Python 2 and Python 3

[Piotr Ożarowski]

[Daniele Tricoli, 2014-02-14]
> On Friday 14 February 2014 14:49:41 Etienne Millon wrote:
> > According to pypi, charade has been merged into chardet.
> > Is packaging charade still relevant?
> 
> Thanks for reminding that I had to close this bug.
> Yes, I talked to Piotr after the discovery of the merge, and
> packaging charade make no sense anymore:
> closing this bug was in my TODO list, thanks for the reminder!
> 
> Piotr, I can help updating python-chardet if you agree.

https://pypi.python.org/pypi/chardet is the current one, right?

I will try to update it this weekend, feel free add yourself to
Uploaders if you beat me to it


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#714213: gnome-terminal-server crashed with signal 5 in g_settings_set_property()

[althaser]

Hey Mykola,

Could you please try to reproduce this bug with newer gnome-terminal
version like 3.10.1-1 ?

Or how can we reproduce the issue ?

thanks
althaser

Bug#671526: rudeconfig: FTBFS on *-i386: old libtool breaks i486-* path components

[Hideki Yamane]

control: tags -1 +unreproducible

Hi,

 I've checked this FTBFS on kfreebsd-i386 sid (on VirtualBox), but cannot
 reproduce it. So, tags it with unreproducible.



-- 
Hideki Yamane

Bug#728984: HDMI audio not working

[Andreas Beckmann]

Since these two replies probably didn't reach the original submitter, I'm
forwarding them. Also note that I uploaded 14.1~beta to unstable yesterday.

On 2014-02-12 23:30, PurpleAnkh wrote:
> It is likely that this is the same as
> https://bugs.debian.org/697266 - linux-image-3.2.0-4-amd64: Please backport
> support for HDMI audio on recent RADEON graphics cards.
> 
> Long story short: the necessary PCI IDs for the HDMI audio on this card are
> not present in the kernel - it was added in kernel 3.3. If you are able and
> willing to install linux-image from wheezy-backports this should allow the
> HDMI audio to work. Otherwise if you build the kernel yourself with the
> patch attached to that bug report, it should also work.

On 2014-02-11 13:43, Vincent Alquier wrote:> Hello,

> I think the "radeon.audio" kernel option is for open source driver only.
> 
> Have you tried with more recent fglrx version ? Catalyst 13.9 is supposed
> to add some improvements for hdmi audio.
> 
> Are you using a non-AMD DVI-to-HDMI adapter ? I think I read something on
> phoronix about HDMI audio troubles when not using the provided DVI-to-HDMI
> adapter.


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738965: [Pkg-systemd-maintainers] Bug#738965: systemd: Circular dependencies caused by Debian specific handling of runlevel S sysv init scripts.

[Jon Severinsson]

Hi Michael 

> I assume you have a SysV init script in rcS which has Required-Start:
> $remote_fs and the network.target is enabled and active (most likely pulled
> in by NetworkManager)?

Actually, the problematic init script on the Tanglu live-cd is a package with 
"Required-Start: $networking", not "Required-Start: $remote_fs". And it 
actually has to run after the networking sysv init script (which still handles 
/etc/network/interfaces), even though it does not necessarily have to run 
after NetworkManager.service, which indeed is what causes network.target to 
(indirectly) Require= sysinit.target

> > To solve this problem, while still making sure runlevel S sysv init
> > scripts are run before runlevel 2, 3, 4 and 5 sysv init scripts, I
> > would recommend changeing sysinit.target to basic.target. This would
> > not completely solve the problem, as network.target might (indirectly)
> > Require=basic.target as well, but it would mitigate it significantly
> > (as dbus.socket is no longer involved in the cycle), and makes it
> > possible to completely eliminate the cycle by changeing the network
> > providers (in this case NetworkManager.service) to not depend on
> > basic.target. (Note that it is not possible to change NetworkManger
> > to not depend on sysinit.target, as it requires dbus.socket for basic
> > operatation, and dbus.socket Requires=sysinit.target).
> > 
> > Attaching a one-line patch that would solve the systemd part of this
> > problem by replacing SPECIAL_SYSINIT_TARGET with SPECIAL_BASIC_TARGET
> > at line 4072 in debian/patches/debian-changes. I will follow up with
> > a patch to NetworkManager as a separate bug report later.
> 
> I vaguely remember that we discussed this issue a while ago and I'm not
> convinced your patch actually addresses the issue properly.

Together with a patch adding DefaultDependencies=no to NetworkManager.service 
(making it run after sysinit.d and dbus.socket but before, or parallel to, 
basic.target, but after sysinit.target and dbus.socket) it does break the 
cyclic dependency, which solves at least this particular problem.

And while I see obvious issues with not special-casing rcS.d scripts further 
than the adding of DefaultDependencies=no done by upstream, I can't see why 
using basic.target instead of sysinit.target would break anything. All normal 
init scripts, both native service files and non-rcS.d sysv init scripts, 
already depends on it, by virtue of the default DefaultDependencies=yes.

> In an ideal world, we'd simply convert all rcS SysV init scripts to
> native .service files. This will take time though.

Obviously, and not likely to happen before the release of Tanglu 1 
("aequorea"), planed for next week, and probably not even for Debian 8 
("jessie"), not to mention third party init scripts (though hopefully there 
isn't a whole lot of those in rcS.d).

> My proposal for the meantime would be to replace the $remote_fs
> dependency for rcS style SysV init scripts with $local_fs.

In addition to breaking the, presumably rare but valid, case of a script 
actually needing $remote_fs, it will not solve the problem, as $network will 
still case breakage.

I guess that additionally using networking.service instead of network.target 
for $network could work, but I feel that such a solution would be both more 
complex and more brittle than using basic.service instead of sysinit.service.

> Jon, do you want to work on such a patch?

Such a patch would be a bit more difficult, as we would want to make the 
changes 
only for rcS.d scripts, not regular sysv init scripts, but if you still are  
convinced not to go with my simpler aproach I'm willing to give it a try.

Regards
Jon Severinsson


signature.asc
Description: This is a digitally signed message part.

Bug#731860: libtar: CVE-2013-4420: directory traversal when extracting archives

[Raphael Geissert]

On 13 February 2014 19:23, Magnus Holmgren  wrote:
> tisdagen den 11 februari 2014 11.26.15 skrev du:
>> On 9 February 2014 22:08, Magnus Holmgren  wrote:
>> > The first "if" should be a "while", shouldn't it? Otherwise we'll only
>> > skip
>> > over the first "../" if file_name starts with "../../", if I'm not
>> > mistaken.
>> That's handled by the while loop right after the if. Attached test
>> case contains an entry called ../../../empty-file
>> tar tf should print a warning message and list the full path, while
>> libtar should simply print it as 'empty-file'.
>
> Yes, an odd number of ".." will yield the desired result, but the even ".."s
> will be missed.

Ah, yes, indeed. Nice catch.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org