Bug#804885: jessie-pu: package openvpn/2.3.4-5

[Alberto Gonzalez Iniesta]

On Thu, Nov 12, 2015 at 06:15:42PM +, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On 2015-11-12 16:48, Alberto Gonzalez Iniesta wrote:
> >I'd like to upload openvpn for the next point release. The reason is a
> >serious bug (#785200 and #787090) hitting multiple users. Diff is pretty
> >small:
> >
> >diff -Nru openvpn-2.3.4/debian/changelog openvpn-2.3.4/debian/changelog
> >--- openvpn-2.3.4/debian/changelog  2014-12-01 18:11:08.0
> >+0100
> >+++ openvpn-2.3.4/debian/changelog  2015-11-12 17:19:14.0
> >+0100
> >@@ -1,3 +1,10 @@
> >+openvpn (2.3.4-5+deb8u1) stable; urgency=medium
> >+
> >+  * Add --no-block to if-up.d script to avoid hanging boot on
> >+interfaces with openvpn instances. (Closes: #787090, #785200)
> 
> The BTS metadata for those bugs indicates that they also affect unstable and
> aren't currently fixed there. I think that's just a side-effect of one of
> the submitters having incorrectly re-opened the bug after it was marked as
> done in an unstable upload. If that's correct, please re-close it with the
> appropriate version; otherwise, please explain what's happening with fixing
> the issue in unstable.
> 
> Regards,
> 
> Adam


Hi Adam,

The bug was fixed in Sid in 2.3.7-1 and the reopened by mistake when
asking for the Jessie fix. It should properly tagged now.

Thanks,

Alberto



-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#780280: dak: generate rejection mail for mails with expired signature

[Jérémy Bobbio]

Ansgar Burchardt:
> It would be nice if dak would generate rejection mails for uploads that
> have a valid signature, but where the signature is expired or from an
> expired key.

It would not only be nice, it would help not being trapped in very silly
situation: files uploaded with a valid signature but with an expired
key are not removed from the queue. That means teammates are unable to
sponsor the upload while waiting for the keyring to be updated.
It's not possible to remove them using dcut either as the key will still
be expired…

I would be grateful if you could properly REJECT uploads for such cases.

Thanks,
-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#788813: [slony1-2-bin] initscript and perl tools do not agree on pidfile name

[Antti Salmela]

With the following patch to the /etc/init.d/slony1, and renaming 
/etc/slony1/slon_tools.conf
to /etc/slony1/slon_tools_replication.conf, and altering
/etc/default/slony1 to include cluster name, I can make init-script and perl 
tools both use the same
pidfile name.

SLON_TOOLS_START_NODES="replication:5"


--- slony1.orig 2015-11-10 11:04:32.0 +0200
+++ slony1.new  2015-11-10 11:04:49.0 +0200
@@ -40,7 +40,7 @@
 }
 
 pidfile() {
-   echo "/var/run/slony1/$1.pid"
+   echo "/var/run/slony1/$1.pid" | sed -e 's/:/_/;'
 }
 
 prepare_start() {

-- 
Antti Salmela

Bug#805007: pnp4nagios: Package for jessie-backports

[varacanero]

Package: pnp4nagios

Hallo,

i saw that pnp4nagios is missing in jessie, please backport it.

Greetings, Varac

Bug#805010: VTK 6.3.0 released

[Nico Schlömer]

Source: vtk6
Severity: wishlist

Dear Maintainer,

VTK 6.3.0 has been released on Sep 10, 2015 [1]. Please bump.

Cheers,
Nico


[1] http://www.kitware.com/blog/home/post/963



-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 
'wily-proposed'), (500, 'wily'), (100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-21-generic (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
Init: systemd (via /run/systemd/system)

Bug#642030: aptitude: cannot forbid more than 1 version of a package

[Vincent Lefevre]

On 2015-11-13 10:59:01 +, Manuel A. Fernandez Montecelo wrote:
> 2015-11-13 2:10 GMT+00:00 Vincent Lefevre :
> > On 2015-11-12 21:57:33 +, Manuel A. Fernandez Montecelo wrote:
> >> In your example above, using hold also would not install v2 from
> >> testing, and when v4 appears, you notice and unhold, and all is well.
> >> What's the drawback of using Hold in your use-case?
> >
> > No, when a package is on hold, aptitude does not give any notice
> > when a new version arrives. That's why I don't like it.
> 
> So when you put packages on hold in testing, say "v1", and "v2"
> appears in unstable or testing, the packages don't appear in the bunch
> of "Upgradable" when there are newer versions?

They still appear on hold, and I cannot know whether there is a new
version or not.

> > To know whether I am satisfied with some version, I need to know
> > whether there is a new version. Otherwise the package remains on
> > hold forever.
> 
> Apart from appearing in "Upgradable", one can limit the view to
> "~U~ahold" (which is like upgradable but further limiting to only
> packages on hold; if the list of Upgradable is too long to check all),
> or one can check every now and then if the packages on hold have new
> versions in their package info screen

But how can I know whether the version is new?

I have never seen the equivalent of New/Unread markers used for e-mail.

> (hopefully you don't have dozens of packages forbidden/hold).

Well, with all the packages forbidden/hold on my 4 Debian machines,
I do. :)

> If one feels that Hold is too heavy handed and that forbidding a
> versions is a hassle because other versions appear all the time, one
> can simply not upgrade the package until it's good to upgrade.

For such packages with often new versions, this is where Hold can be
used. The issue is for packages without often new versions, but with
at least two candidates for an upgrade.

> Forbidding versions will cause the same or equivalent sets of
> problems, in the packages themselves and their reverse-depends.  In
> fact, installing packages (without holding or forbidding at all) from
> experimental or from backports can also make you miss security fixes
> as well.

I use neither experimental[*] nor backports. I don't use unofficial
repositories like Debian multimedia either.

[*] Well, only in some exceptional cases to test bug fixes, but then
I track what happens.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#805011: apt-listdifferences: get message when running aptitutde install after uninstalling apt-listdifferences

[Xavier Ortiz]

Package: apt-listdifferences
Version: Uninstalled apt-listdifferences, continues to show up on aptitude 
install
Severity: minor

Dear Maintainer,

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

   * What led up to the situation?

Uninstalling apt-listdifferences

Then running:
aptitude install 

Or:
apt-get install 

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
nothing in particular
   * What was the outcome of this action?
the following output /bin/sh: 1: /usr/bin/apt-listdifferences: not found
   * What outcome did you expect instead?
Nothing. Not this output

*** End of the template - remove these template lines ***
This is an example. Isolated the line before and after the questionable message
in order to have it visually easier to find.


Debian@Desktop:~$ sudo aptitude install p7zip-full rar unrar

p7zip-full is already installed at the requested version (9.20.1~dfsg.1-4.2)
p7zip-full is already installed at the requested version (9.20.1~dfsg.1-4.2)
The following NEW packages will be installed:
  rar unrar
0 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 714 kB of archives. After unpacking 1,967 kB will be used.
Get: 1 http://ftp.us.debian.org/debian/ testing/non-free rar amd64 2:5.3.b2-1
[589 kB]
Get: 2 http://ftp.us.debian.org/debian/ testing/non-free unrar amd64 1:5.3.2-1
[125 kB]
Fetched 714 kB in 5s (132 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done

/bin/sh: 1: /usr/bin/apt-listdifferences: not found

Selecting previously unselected package rar.
(Reading database ... 197468 files and directories currently installed.)
Preparing to unpack .../rar_2%3a5.3.b2-1_amd64.deb ...
Unpacking rar (2:5.3.b2-1) ...
Selecting previously unselected package unrar.
Preparing to unpack .../unrar_1%3a5.3.2-1_amd64.deb ...
Unpacking unrar (1:5.3.2-1) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up rar (2:5.3.b2-1) ...
Setting up unrar (1:5.3.2-1) ...
update-alternatives: using /usr/bin/unrar-nonfree to provide /usr/bin/unrar
(unrar) in auto mode



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (350, 'testing'), (200, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-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
Init: systemd (via /run/systemd/system)

Bug#801674: youtube-dl: Only audio downloaded for PrBqr6nNzNY

[David Purton]

Hmmm.

Also works for me now too.

Don't know what was going on.

You can close the bug and apologies for the noise.

David

On Wed, Nov 11, 2015 at 11:48:04AM -0200, Rogério Brito wrote:
> 
> That's strange. On my system, I can use that without any problems and my
> ffmpeg will mux both the audio and the video in a matroska container.

-- 
David Purton
dcpur...@marshwiggle.net
 
For the eyes of the LORD range throughout the earth to
strengthen those whose hearts are fully committed to him.
 2 Chronicles 16:9a


signature.asc
Description: PGP signature

Bug#798122: user/usertag via control:...

[Osamu Aoki]

Hi,

I found this bug report.  Let me add a comment.

It seems BTS rejected 2 intuitive pathes to set user/usertag.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804597#5 for such
a failed attempt.   We can not use intuitive pseudoheaders in the initial
bug report to sub...@bugs.debian.org .  What ever the reason, it is nice
to support this path for consistency.

Then the following attempt to n...@bugs.debian.org
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804597#10
failed and now I understand this is a feature.  But it is more
consistent to accept this style if possible.

Of course, I eventuarlly set user/usertag via cont...@bugs.debian.org as
I expected.

Osamu

Bug#294040: aptitude: Impossible to know from which distrib/mirror the package comes

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Pierre,

2005-02-07 14:39 Pierre THIERRY:

Package: aptitude
Version: 0.2.15.8-1
Severity: wishlist

It should be possible to see in aptitude the kind of informations that
``apt-cache policy'' provides.


This is implemented now, will be released soon, so marking as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#611515: aptitude show download URL?

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Harald,

2011-01-30 08:25 Harald Dunkel:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: aptitude
Version: 0.6.3-3.2
Severity: wishlist

Would it be possible that aptitude shows the download URLs of a package
on it's info page? This would be important esp. in the case of package
conflicts, e.g. between ftp.de.debian.org and a 3rd-party repository.


This is implemented now, will be released soon, so marking as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#804898: corekeeper: should install sysctl snippet in /usr/lib/sysctl.d

[Felipe Sateler]

On 12 November 2015 at 23:52, Paul Wise  wrote:
> On Thu, 2015-11-12 at 15:30 -0300, Felipe Sateler wrote:
>
>> Please install in /usr/lib/sysctl.d. Procps also reads from there
>> using a scheme like systemd-sysctl.
>
> Which version of procps supports this? Last time I tried it didn't.

The init script uses --system since 2013, when it fixed a bug filed by... you ;)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=69

-- 

Saludos,
Felipe Sateler

Bug#804911: Incorrect chai dependency on chef package in jessie

[Antonio Terceiro]

Control: retitle -1 chef: ohai resource broken in Jessie
Control: tag -1 + patch pending

Hi, thanks for reporting this.

On Thu, Nov 12, 2015 at 11:51:10AM -0800, Noah Kantrowitz wrote:
> Package: chef
> Version: 11.12.8-2
> 
> Chef 11.12.8 clearly states that it depends on Ohai at least 7.0.4
> (https://github.com/chef/chef/blob/11.12.8/chef.gemspec#L20). As it
> stands, the jessie package depends on Ohai >= 6 and the packaged
> version is a 6.x. This results in the ohai resource being
> non-functional as it uses an API added in Ohai 7.0.0. Either Chef
> needs to be patched to not use this API (Ohai::System#all_packages
> with an argument) or the Ohai dependency needs to be corrected.

Would you please test the package from
https://people.debian.org/~terceiro/chef-jessie/ and let me know it
works for you?

I have applied the attached patch, and tested a basic usage of the ohai
resource which worked for me; if you confirm your use case is fixed I
will make a stable update with those changes.

-- 
Antonio Terceiro 
Description: Fix usage of the ohai resource against ohai 6.x
 The version of chef in Jessie was supposed to be used with ohai 7.x or later,
 which has a different API, but at the time the metadata checks weren't in
 place so this was caught before the release.
Author: Antonio Terceiro 
Origin: vendor
Bug-Debian: https://bugs.debian.org/804911
Forwarded: not-needed
Last-Update: 2015-11-13
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/lib/chef/provider/ohai.rb
+++ b/lib/chef/provider/ohai.rb
@@ -34,11 +34,7 @@ class Chef
 converge_by("re-run ohai and merge results into node attributes") do
   ohai = ::Ohai::System.new
 
-  # If @new_resource.plugin is nil, ohai will reload all the plugins
-  # Otherwise it will only reload the specified plugin
-  # Note that any changes to plugins, or new plugins placed on
-  # the path are picked up by ohai.
-  ohai.all_plugins @new_resource.plugin
+  ohai.all_plugins
   node.automatic_attrs.merge! ohai.data
   Chef::Log.info("#{@new_resource} reloaded")
 end


signature.asc
Description: PGP signature

Bug#766594: libechonest and libechonest-qt5 updated in Ubuntu PPA

[Stefan Ahlers]

Dear Maintainer,

I've updated my libechonest PPA. I've cleaned up the multiarch support
and added a transitional package for libechonest2.1. I've also build
those packages under debian sid locally. And so you should be able to
adopt my debian files.

https://launchpad.net/~justin-time/+archive/ubuntu/libechonest/+packages

I would be very happy to work together with you to push libechonest2.3
as Qt4 and Qt5 build into the debian sources.

Kindly regards,
Stefan Ahlers

Bug#804554: fonts-hack-otf: new upstream release 2.018

[Paride Legovini]

Dear Fabian,

I'm aware of the new release, I just can't find the time for it on these
busy days... I'll package it as soon as I can.
Thanks for the heads up anyway!

Paride

Bug#803013: systemd should not destroy application created cgroups

[Julian Andres Klode]

On Fri, Nov 13, 2015 at 11:36:30AM +1100, paul.sz...@sydney.edu.au wrote:
> Progress? For my efforts upstream, I got the comment:
> 
> > Sorry, but systemd implements a single-writer cgroup logic (as
> > requested by the kernel maintainers), and hence takes possesion of the
> > whole tree. ...
> 
> I observe it only uses the /sys/fs/cgroup/systemd tree.
> (I wonder about the "req by kernel" comment.)

See the end of the email.

> 
> > ... If you want your own cgroup tree to manage, use the "Delegate=yes"
> > feature in a service or scope, but otherwise systemd is in exclusive
> > control.
> 
> Do we have that? Can we have it everywhere? Can we have it by default,
> should not it be so?

No. You set Delegate=yes for the unit which manages its own cgroups
hierarchy beneath the one designated by systemd.

> 
> > Sorry, but multiple access to the cgroup tree is simply not supported.
> 
> Not if we let systemd take over the world.

This is not related to systemd. The kernel cgroups implementation moved
or is moving to a single-writer, single-hierarchy implementation with
a user space daemon arbiter. systemd implements such an arbiter.

http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign
https://wiki.freedesktop.org/www/Software/systemd/ControlGroupInterface/
https://lwn.net/Articles/555920/

While the kernel probably still allows for multiple hierarchies in order
to not break the user space interface, they should not be used anymore.

The single hierarchy changes were discussed in 2012:
  https://lwn.net/Articles/484251/ 
and introduced between 2012 and 2013. Complaining about
that 2 years later is a bit late, although it would not
have changed anything back then either, as the multiple-writer
approach is fundamentally broken.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Be friendly, do not top-post, and follow RFC 1855 "Netiquette".
- If you don't I might ignore you.

Bug#805012: transition: giflib

[Matthias Klose]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: gif...@packages.debian.org

This is #803158, moving giflib to 5.1.1.  Done as a NMU, I didn't get feedback 
from the maintainer.


The library package changes from libgif4 to libgif7.  Packages which need 
sourceful uploads (all with patches) are:


https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=giflib5;users=gif...@packages.debian.org

Not all of these are ready to support both versions of giflib, so these should 
be uploaded after giflib 5 hits unstable.


All other packages should be binNMUable. One outstanding issue is #803298. The 
build system appears to clean the build files, and then doesn't know what to do. 
Help would be appreciated.

Bug#805013: gnunet: FTBFS on hurd-i386

[Svante Signell]

Source: gnunet
Version: 0.10.1-2.1
Severity: important
Tags: patch
Usertags: hurd
User: debian-h...@lists.debian.org

Hello,

currently gnunet FTBFS on GNU/Hurd due to a missing definition of
PATH_MAX. The attached patch fixes this problem, by dynamically
allocating and freeing the required strings.

Thanks!Index: gnunet-0.10.1/src/testbed/gnunet-daemon-testbed-blacklist.c
===
--- gnunet-0.10.1.orig/src/testbed/gnunet-daemon-testbed-blacklist.c
+++ gnunet-0.10.1/src/testbed/gnunet-daemon-testbed-blacklist.c
@@ -212,7 +212,7 @@ run (void *cls, char *const *args, const
  const struct GNUNET_CONFIGURATION_Handle *c)
 {
   char *shome;
-  char fname[PATH_MAX];
+  char *fname = NULL;
 
   if (GNUNET_OK != GNUNET_CONFIGURATION_get_value_filename (c, "PATHS",
 "GNUNET_HOME",
@@ -221,7 +221,10 @@ run (void *cls, char *const *args, const
 GNUNET_break (0);
 return;
   }
-  GNUNET_assert (0 < GNUNET_snprintf (fname, PATH_MAX, "%s/whitelist", shome));
+  int len = strlen(shome) + 10 + 1;
+
+  fname = GNUNET_malloc (len);
+  GNUNET_assert (0 < GNUNET_snprintf (fname, len, "%s/whitelist", shome));
   if (GNUNET_YES == GNUNET_DISK_file_test (fname))
   {
 mode = ACCESS_ALLOW;
@@ -229,12 +232,13 @@ run (void *cls, char *const *args, const
 GNUNET_free (shome);
 return;
   }
-  GNUNET_assert (0 < GNUNET_snprintf (fname, PATH_MAX, "%s/blacklist", shome));
+  GNUNET_assert (0 < GNUNET_snprintf (fname, len, "%s/blacklist", shome));
   if (GNUNET_YES == GNUNET_DISK_file_test (fname))
   {
 mode = ACCESS_DENY;
 setup_ac (shome, c);
   }
+  GNUNET_free (fname);
   GNUNET_free (shome);
   return;
 }
Index: gnunet-0.10.1/src/testbed/gnunet-helper-testbed.c
===
--- gnunet-0.10.1.orig/src/testbed/gnunet-helper-testbed.c
+++ gnunet-0.10.1/src/testbed/gnunet-helper-testbed.c
@@ -422,12 +422,15 @@ tokenizer_cb (void *cls, void *client,
 #ifdef WINDOWS
 GNUNET_assert (0 != SetEnvironmentVariable (GNUNET_TESTING_PREFIX, evstr));
 #else
-static char evar[2* PATH_MAX];
+static char *evar = NULL;
+int len = strlen(GNUNET_TESTING_PREFIX) + 1 + strlen(evstr) + 1;
 
-GNUNET_assert (0 < GNUNET_snprintf (evar, sizeof (evar),
+evar = GNUNET_malloc (len);
+GNUNET_assert (0 < GNUNET_snprintf (evar, len,
 GNUNET_TESTING_PREFIX "=%s", evstr));
 putenv (evar);
 #endif
+GNUNET_free (evar);
 GNUNET_free (evstr);
 evstr = NULL;
   }
@@ -451,12 +454,16 @@ tokenizer_cb (void *cls, void *client,
   LOG_DEBUG ("Staring testbed with config: %s\n", config);
   binary = GNUNET_OS_get_libexec_binary_path ("gnunet-service-testbed");
   {
-static char evar[2 * PATH_MAX];
+static char *evar = NULL;
+int len = strlen(ENV_TESTBED_CONFIG) + 1 + strlen(config) + 1;
+
+evar = GNUNET_malloc (len);
 
 /* expose testbed configuration through env variable */
-GNUNET_assert (0 < GNUNET_snprintf (evar, sizeof (evar),
+GNUNET_assert (0 < GNUNET_snprintf (evar, len,
 "%s=%s", ENV_TESTBED_CONFIG, config));
 GNUNET_assert (0 == putenv (evar));
+GNUNET_free (evar);
 evstr = NULL;
   }
   testbed =

Bug#642030: aptitude: cannot forbid more than 1 version of a package

[Manuel A. Fernandez Montecelo]

2015-11-13 11:31 GMT+00:00 Vincent Lefevre :
> On 2015-11-13 10:59:01 +, Manuel A. Fernandez Montecelo wrote:
>>
>> So when you put packages on hold in testing, say "v1", and "v2"
>> appears in unstable or testing, the packages don't appear in the bunch
>> of "Upgradable" when there are newer versions?
>
> They still appear on hold, and I cannot know whether there is a new
> version or not.
> [...]

Assuming that the version is not the "candidate version" already
visible in the right-most column (which in many/most examples given so
far, it should be), I can only suggest manual review by looking into
the package info screen.


>> Forbidding versions will cause the same or equivalent sets of
>> problems, in the packages themselves and their reverse-depends.  In
>> fact, installing packages (without holding or forbidding at all) from
>> experimental or from backports can also make you miss security fixes
>> as well.
>
> I use neither experimental[*] nor backports. I don't use unofficial
> repositories like Debian multimedia either.
>
> [*] Well, only in some exceptional cases to test bug fixes, but then
> I track what happens.

Testing and unstable are also for people who are OK with getting their
hands dirty and track what happens when it is needed to, more so when
mixing versions of both.  The recent turmoil with the GCC-5 transition
is a recent enough proof of that.

When packages are on hold/forbidden/not upgraded it is also an unusual
condition, so you have to keep track of what happens.

Simply having the packages already in the Upgradable set or on Hold
(or Forbid) is a highlight and constant reminder that you have to keep
track of them to bring them out of that state.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#795651: X crashes

[Andreas Boll]

Control: tag -1 moreinfo

Is this still an issue?
What graphics hardware do you have?
Please attach the outputs of dmesg and
LC_ALL=C lspci -nn | grep 'VGA compatible controller'


On Sat, Aug 15, 2015 at 11:47:14PM -0300, Fred Maranhão wrote:
> Package: libgl1-mesa-dri
> Version: 10.6.3-1
> 
> X doesn't starts. if I remove the package, with apt-get purge
> libgl1-mesa-dri X starts normally, but without 3D acceleration.
> 
> this is the log:
> 

snip

> [38.335] (==) Matched intel as autoconfigured driver 0
> [38.335] (==) Matched intel as autoconfigured driver 1
> [38.335] (==) Matched modesetting as autoconfigured driver 2
> [38.335] (==) Matched fbdev as autoconfigured driver 3
> [38.335] (==) Matched vesa as autoconfigured driver 4
> [38.335] (==) Assigned the driver to the xf86ConfigLayout
> [38.335] (II) LoadModule: "intel"
> [38.335] (WW) Warning, couldn't open module intel
> [38.335] (II) UnloadModule: "intel"
> [38.335] (II) Unloading intel
> [38.335] (EE) Failed to load module "intel" (module does not exist, 0)

So it looks like it wants to load the intel module but can't find it.
Do you have intentionally removed the package xserver-xorg-video-intel?

> [38.335] (II) LoadModule: "modesetting"
> [38.335] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
> [38.335] (II) Module modesetting: vendor="X.Org Foundation"
> [38.335] compiled for 1.17.2, module version = 1.17.2
> [38.336] Module class: X.Org Video Driver
> [38.336] ABI class: X.Org Video Driver, version 19.0

As fallback it uses the modesetting driver.
There seems to be an issue in either modesetting, glamor or the 3d mesa
driver.

> [38.379] (EE)
> [38.379] (EE) Backtrace:
> [38.379] (EE) 0: /usr/bin/X (xorg_backtrace+0x56) [0x5639df0a6df6]
> [38.379] (EE) 1: /usr/bin/X (0x5639deef4000+0x1b7009) [0x5639df0ab009]
> [38.379] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6
> (0x7f78d6fc9000+0x35180) [0x7f78d6ffe180]
> [38.379] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6
> (0x7f78d6fc9000+0x9047e) [0x7f78d705947e]
> [38.379] (EE) 4: /usr/lib/x86_64-linux-gnu/libepoxy.so.0
> (0x7f78d38d2000+0x5402f) [0x7f78d392602f]
> [38.379] (EE) 5: /usr/lib/xorg/modules/libglamoregl.so
> (glamor_init+0x24c) [0x7f78d3dceadc]
> [38.379] (EE) 6: /usr/lib/xorg/modules/drivers/modesetting_drv.so
> (0x7f78d461c000+0x74ab) [0x7f78d46234ab]
> [38.379] (EE) 7: /usr/bin/X (AddScreen+0x101) [0x5639def4c4b1]
> [38.379] (EE) 8: /usr/bin/X (InitOutput+0x3a7) [0x5639def8e737]
> [38.379] (EE) 9: /usr/bin/X (0x5639deef4000+0x5c0aa) [0x5639def500aa]
> [38.379] (EE) 10: /lib/x86_64-linux-gnu/libc.so.6
> (__libc_start_main+0xf5) [0x7f78d6feab45]
> [38.379] (EE) 11: /usr/bin/X (0x5639deef4000+0x4668e) [0x5639def3a68e]
> [38.379] (EE)
> [38.379] (EE) Segmentation fault at address 0x0
> [38.379] (EE)
> Fatal server error:
> [38.379] (EE) Caught signal 11 (Segmentation fault). Server aborting
> [38.379] (EE)
> [38.379] (EE)

We would need a backtrace with debug symbols installed.

Thanks,
Andreas


signature.asc
Description: Digital signature

Bug#805014: pbuilder: document PBCURRENTCOMMANDLINEOPERATION

[Mattia Rizzolo]

Package: pbuilder
Version: 0.220
Severity: minor
User: pbuil...@packages.debian.org
Usertag: doc pbuilder

I rely on PBCURRENTCOMMANDLINEOPERATION since quite some time for conf
and hooks, and also told others about it.

If not that variable (because the name it's ugly and it can assume 2
values for every operation, with and without leading --), something
should be added to the "API".

I'm leaning towards PBUILDER_OPERATION, that can be one of
create
update
build
clean
login
execute

clearly PBCURRENTCOMMANDLINEOPERATION is not going anywhere soon, I'm
too lazy to think every place where I dumped it and it's a oneline
anyway.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#803013: systemd should not destroy application created cgroups

[Julian Andres Klode]

On Fri, Nov 13, 2015 at 12:50:57PM +0100, Julian Andres Klode wrote:
> On Fri, Nov 13, 2015 at 11:36:30AM +1100, paul.sz...@sydney.edu.au wrote:
> > Progress? For my efforts upstream, I got the comment:
> > 
> > > Sorry, but systemd implements a single-writer cgroup logic (as
> > > requested by the kernel maintainers), and hence takes possesion of the
> > > whole tree. ...
> > 
> > I observe it only uses the /sys/fs/cgroup/systemd tree.
> > (I wonder about the "req by kernel" comment.)
> 
> See the end of the email.

Also:
http://thread.gmane.org/gmane.linux.kernel.cgroups/6638


> 
> > 
> > > ... If you want your own cgroup tree to manage, use the "Delegate=yes"
> > > feature in a service or scope, but otherwise systemd is in exclusive
> > > control.
> > 
> > Do we have that? Can we have it everywhere? Can we have it by default,
> > should not it be so?
> 
> No. You set Delegate=yes for the unit which manages its own cgroups
> hierarchy beneath the one designated by systemd.

This is also only a mid-term workaround, and will be dropped longer
term, AFAICT from: https://lwn.net/Articles/556112/

Because the kernel maintainer *really* wants a single writer.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Be friendly, do not top-post, and follow RFC 1855 "Netiquette".
- If you don't I might ignore you.

Bug#804683: [Pkg-fonts-devel] Bug#804683: josm: Please switch to fonts-noto from fonts-droid

[Fabian Greffrath]

Hi all,

Am Freitag, den 13.11.2015, 10:56 +0530 schrieb Vasudev Kamath:
> Do you guys have any suggestion on the above issue mentioned by
> Sebastiaan.

this discussion reminds me of the one we had about the look of the
Cantarell font and how its shape changed when the Adobe CFF renderer
was enabled by default in Freetype: 

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798805

Eventually, this has led to the following threads on the Fontconfig
mailing list: 

http://lists.freedesktop.org/archives/fontconfig/2015-October/005562.html

http://lists.freedesktop.org/archives/fontconfig/2015-November/005588.html

To summarize, font hinting depends very much on the format of the font
(i.e. OTF/CFF, TTF or Type 1) and the quality of the embedded hinting
information. The wide range of combinations this enables turns the
whole thing into a mess that currently noone seems to understand. The
two threads I have posted above try to shed some light into the
situation, though.

Cheers,

Fabian


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

Bug#804882: hwclock: /etc/init.d/hwclock.sh stop does nothing at all

[Andreas Henriksson]

Hello Marcel!

Quick reply below...

On Thu, Nov 12, 2015 at 09:01:49PM -0500, Marcel wrote:
> Hi Andreas.
> 
> Thanks for your quick reply.  I appreciate it.
> 
> I reckon that the misuse of init scripts is my responsibility
> however the service integration isn't perfect yet.  A lot of
> scripts/packages still use init scripts.  Monit comes immediately
> to my mind.  It relies heavily on start/stop/restart.

Any packaged software in Debian which directly invokes an init script
(ignoring service policy etc.) instead of doing so via invoke-rc.d
(which is the programmatical variant of the administrative 'service'
interface) is in conflict with the Debian policy and thus RC-buggy.
This is because 'policy-rc.d' should be taken into consideration which
it isn't if the script is invoked directly.

https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3

> 
> And I was in a state of panic.  I know full well how catastrophic
> the results of setting the clock too far away in time could do on this
> system.  I couldn't remember the command name 'service' so I relied
> on what has been working faithfully for years, initd.

Yes, fortunately the Debian systemd maintainers have LSB hooks in place
to defer your direct invokation to became a systemctl command instead.
(FWIW, the service command would also translate into a systemctl command
when running under systemd.)

> 
> I'll complete the transition to service whenever I have spare time.
> 
> That being said, I saved the console so you can see each and every
> command I typed yesterday and the system reaction or absence of:

Awesome! Thanks.
Even more awesome would be if you can reproduce the problem while
hacking the init script to add 'set -x' at the top so we can see
each and every command being run.
Might also be useful to know your configuration for local/UTC time
in rtc, eg. /etc/adjtime
Also knowing your /etc/default/hwclock settings would be helpful.

Quick commends below (I'll try to find time to look at this
with more details in the future).

> 
> shizuma@gt5232h-a3e401d:~$ sudo /etc/init.d/hwclock.sh
> [ ok ] Usage: hwclock.sh {start|stop|reload|force-reload|show}.
> [ ok ] start sets kernel (system) clock from hardware (RTC) clock.
> [ ok ] stop and reload set hardware (RTC) clock from kernel (system) clock.

ok.

> shizuma@gt5232h-a3e401d:~$ sudo /etc/init.d/hwclock.sh stop
> shizuma@gt5232h-a3e401d:~$ date
> mercredi 11 novembre 2015, 23:26:56 (UTC-0500)
> shizuma@gt5232h-a3e401d:~$ sudo /etc/init.d/hwclock.sh show
> jeu 12 nov 2015 00:28:19 EST  -0.084876 secondes
> shizuma@gt5232h-a3e401d:~$ date
> mercredi 11 novembre 2015, 23:27:30 (UTC-0500)

So your system time seems it was 1 day behind your RTC time.
Some serious time drift right there (unless your system time was
updated without syncing the RTC earlier somehow).

> shizuma@gt5232h-a3e401d:~$ sudo /etc/init.d/hwclock.sh reload
> [info] Saving the system clock.
> [info] Hardware Clock updated to mercredi 11 novembre 2015, 23:28:07 
> (UTC-0500).

Here you just wrote your system time to the RTC, which I guess means
you messed up your RTC time.

In the init script the 'stop' and 'reload' arguments are just aliases
for the very same thing.
The reason they still behave differently seems to simply be because
'stop', 'start', 'restart' will be translated into 'systemctl 
hwclock' by the LSB init hooks for systemd. While the 'show' and
'reload' commands will not (and just run the init script code) as
there's no direct generic systemctl equivalent.

> shizuma@gt5232h-a3e401d:~$ sudo /etc/init.d/hwclock.sh show
> mer 11 nov 2015 23:28:24 EST  -0.062948 secondes
> shizuma@gt5232h-a3e401d:~$ sudo /etc/init.d/hwclock.sh stop
> shizuma@gt5232h-a3e401d:~$ sudo /etc/init.d/hwclock.sh show
> mer 11 nov 2015 23:35:14 EST  -0.969351 secondes
> shizuma@gt5232h-a3e401d:~$ date
> mercredi 11 novembre 2015, 23:37:35 (UTC-0500)
> 
> 
> I also tried the same commands on another system I maintain, with
> identical results:  stop producing no output at all:
> 
> root@NC-PH-0657-10:~# /etc/init.d/hwclock.sh show
> Thu 12 Nov 2015 06:47:32 PM MST  -0.406578 seconds
> root@NC-PH-0657-10:~# date
> Thu Nov 12 18:47:34 MST 2015
> root@NC-PH-0657-10:~# /etc/init.d/hwclock.sh stop
> root@NC-PH-0657-10:~# /etc/init.d/hwclock.sh show
> Thu 12 Nov 2015 06:47:56 PM MST  -0.922150 seconds
> 
> 
> I understand that you would not maintain initd scripts.  However an 
> issue is still present - and maybe this very bug description should be
> changed accordingly.  It's that on shutdown for reboot, the hardware clock
> wasn't properly updated.  This should be addressed.

So far the hwclock.sh script has no knowledge about systemd or
that it's obsolete/unused under systemd, but maybe it should
indeed grow a check that just aborts it if executed under systemd
environment to prevent issues like yours but really, you should
stop executing init scripts directly also. :P

> 
> I'd be more than happy to provide you with all the 

Bug#804995: ITP: proteinortho -- Detection of (Co-)orthologs in large-scale protein analysis

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: proteinortho
  Version : 5.11
  Upstream Author : Marcus Lechner 
* URL : https://www.bioinf.uni-leipzig.de/Software/proteinortho/
* License : GPL
  Programming Lang: C++, Perl, Python
  Description : Detection of (Co-)orthologs in large-scale protein analysis
 Proteinortho is a stand-alone tool that is geared towards large datasets
 and makes use of distributed computing techniques when run on multi-core
 hardware. It implements an extended version of the reciprocal best
 alignment heuristic. Proteinortho was applied to compute orthologous
 proteins in the complete set of all 717 eubacterial genomes available at
 NCBI at the beginning of 2009. Authors succeeded identifying thirty
 proteins present in 99% of all bacterial proteomes.


This package is maintained by the Debian Med team at
   git://anonscm.debian.org/debian-med/proteinortho.git

Bug#804998: voms-api-java: Replace mvn-debian with maven-debian-helper

[Emmanuel Bourg]

Source: voms-api-java
Version: 3.0.5-2
Severity: normal

Hi,

mvn-debian is going to be removed (#703373) but voms-api-java is one
of the few packages using it. It could be replaced by the DH buildsystem
provided by maven-debian-helper. This will simplify the maintenance since
the package will no longer fail to build after each upgrade of a Maven
plugin (such as #804593).

This transition can be achieved by rewriting debian/rules to something
like this:

%:
dh $@ --buildsystem=maven

The pom patching mechanic and the installation of the jars are handled
automatically.

This will require a new debian/voms-api-java.poms file containing:

pom.xml --java-lib --has-package-version

The rules for the Maven plugins in debian/maven.rules can be removed.


Emmanuel Bourg

Bug#805000: /usr/bin/gksudo: Started applications hang

[Ph. Marek]

Package: gksu
Version: 2.0.2-9
Severity: important
File: /usr/bin/gksudo

Related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599233, but 
that's a "wishlist" item, while this here is a bug.


gksudo not only swallows the stderr output, it even makes the program hang 
if there's too much (a pipe full, ie. 64kB) of output:


This here:

# gksudo -- perl -e 'printf STDERR "%500.500s\n", "a" for 0 .. 100'

just gets eaten, but

# gksudo -- perl -e 'printf STDERR "%500.500s\n", "a" for 0 .. 1000'

will hang indefinitely.

I could rescue my long-running program by emptying the pipe via 

# sudo cat /proc/$PID_OF_SUDO_BELOW_GKSUDO/fd/2

but that's unacceptable.



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

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gksu depends on:
ii  gconf-service 3.2.6-3
ii  libatk1.0-0   2.18.0-1
ii  libc6 2.19-22
ii  libcairo2 1.14.4-1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6-2
ii  libgconf-2-4  3.2.6-3
ii  libgdk-pixbuf2.0-02.32.1-1
ii  libgksu2-02.0.13~pre1-8+b1
ii  libglib2.0-0  2.46.1-2
ii  libgnome-keyring0 3.12.0-1+b1
ii  libgtk2.0-0   2.24.28-1
ii  libpango-1.0-01.38.1-1
ii  libpangocairo-1.0-0   1.38.1-1
ii  libpangoft2-1.0-0 1.38.1-1
ii  libstartup-notification0  0.12-4
ii  sudo  1.8.12-1

Versions of packages gksu recommends:
ii  gnome-keyring  3.18.2-1

gksu suggests no packages.

-- no debconf information

Bug#805001: RM: rsem [i386 armel armhf mips mipsel powerpc s390x hurd-i386 kfreebsd-i386 mips64el] -- RoQA; ANAIS; no longer built on architectures without bowtie

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

rsem is uninstallable on architectures without bowtie, therefore it
added a B-D: bowtie in the last upload and no longer builds on these
architectures (#803550).


Andreas

Bug#805002: libvirt-client: "virsh attach-disk" fails with AppArmor enabled

[Carlo Rengo]

Package: libvirt-client
Version: 1.2.21-1
Severity: serious

Dear Maintainer,

Running “virsh attach-disk   ” with AppArmor enabled 
and 
the domain confined in enforce mode gives this error:

root@host:~# virsh attach-disk debian8 
/var/lib/libvirt/images/disk_to_attach.img vdd
error: Failed to attach disk
error: internal error: unable to execute QEMU command 'device_add': Property 
'virtio-blk-device.drive' can't find value 'drive-virtio-disk3'

From journal:

audit: type=1400 audit(1447406591.802:2015): apparmor="STATUS" 
operation="profile_replace" name="libvirt-73a13868-fbfd-4dce-bbf1-effde396bb12" 
pid=57268 comm="apparmor_parser"
audit: type=1400 audit(1447406591.862:2016): apparmor="STATUS" 
operation="profile_replace" name="qemu_bridge_helper" pid=57268 
comm="apparmor_parser"
audit: type=1400 audit(1447406591.892:2017): apparmor="DENIED" operation="open" 
profile="libvirt-73a13868-fbfd-4dce-bbf1-effde396bb12" 
name="/var/lib/libvirt/images/to_attach.img" pid=56392 comm="kvm" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
audit: type=1400 audit(1447406591.952:2018): apparmor="DENIED" operation="open" 
profile="libvirt-73a13868-fbfd-4dce-bbf1-effde396bb12" 
name="/var/lib/libvirt/images/to_attach.img" pid=56392 comm="kvm" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
audit: type=1400 audit(1447406592.002:2019): apparmor="DENIED" operation="open" 
profile="libvirt-73a13868-fbfd-4dce-bbf1-effde396bb12" 
name="/var/lib/libvirt/images/to_attach.img" pid=56392 comm="kvm" 
requested_mask="rw" denied_mask="rw" fsuid=0 ouid=0
audit: type=1400 audit(1447406592.262:2020): apparmor="STATUS" 
operation="profile_replace" name="libvirt-73a13868-fbfd-4dce-bbf1-effde396bb12" 
pid=57270 comm="apparmor_parser"
audit: type=1400 audit(1447406592.342:2021): apparmor="STATUS" 
operation="profile_replace" name="qemu_bridge_helper" pid=57270 
comm=“apparmor_parser"

When putting the domain in complain/disabled mode, the error keeps showing up 
until 
the domain is destroyed/recreated or saved/restored.

This errors appears with libvirt from debian stable, debian testing and from a 
compiled 
version of the source. Ubuntu 15.10 is not affected by this bug.

Steps to reproduce:
1- Make sure AppArmor is enabled and libvirtd is confined
2- Run a VM and check if its profile is put in enforce mode
3- Run the “virsh attach-disk” , where  is 
the VM name.

Kind Regards,

Carlo

-- System Information:
Debian Release: 8.2
  APT prefers testing
  APT policy: (950, 'testing'), (895, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-rc2-jessie1.1 (SMP w/40 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#804999: canl-java: Replace mvn-debian with maven-debian-helper

[Emmanuel Bourg]

Source: canl-java
Version: 2.1.1-3
Severity: normal

Hi,

mvn-debian is going to be removed (#703373) but canl-java is one
of the few packages using it. It could be replaced by the DH buildsystem
provided by maven-debian-helper. This will simplify the maintenance since
the package will no longer fail to build after each upgrade of a Maven
plugin (such as #804462).

This transition can be achieved by rewriting debian/rules to something
like this:

%:
dh $@ --buildsystem=maven

The pom patching mechanic and the installation of the jars are handled
automatically.

This will require a new debian/canl-java.poms file containing:

pom.xml --java-lib --has-package-version

The rules for the Maven plugins in debian/maven.rules can be removed.


Emmanuel Bourg

Bug#804775: transition: bullet

[Andreas Beckmann]

On Wed, 11 Nov 2015 18:05:45 +0100 Markus Koschany  wrote:
> Am 11.11.2015 um 15:47 schrieb Emilio Pozuelo Monfort:
> > On 11/11/15 14:21, Markus Koschany wrote:
> >> I would like to request a transition for Bullet 2.83.6.
> >> Upstream made a backward-incompatible ABI change between
> >> version 2.83.5 and 2.83.6 without changing the SONAME too.
> > 
> > You can go ahead and upload this to unstable.
> Uploaded to unstable.

critterding/experimental will need a binNMU, too (but not the version in
sid, which probably uses an embedded copy).


Andreas

Bug#803743: build system

[Ghislain Vaillant]

> Upstream has changed a lot the build system. I suspect it will be
> easier in the next release.

That would be great indeed.

> For now I am using my initial cmake based system (without support for
> pkg-config).

Support for generating and installing the pkgconfig file can probably be 
added to the existing CMake (and perhaps sent upstream). I could have a 
look if you want, or do you think it is not worth the effort?


Ghis

Bug#805002: Acknowledgement (libvirt-client: "virsh attach-disk" fails with AppArmor enabled )

[Carlo Rengo]

Hi,
I’ve just realised that I made a mistake in the package name, which is 
“libvirt-clients” (instead of “libvirt-client”).

Kind Regards

Carlo

> On 13 Nov 2015, at 10:36, Debian Bug Tracking System  
> wrote:
> 
> Thank you for filing a new Bug report with Debian.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
> unknown-pack...@qa.debian.org
> 
> If you wish to submit further information on this problem, please
> send it to 805...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 805002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805002
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#805004: clang-modernize-3.8: uninstallable in sid

[Andreas Beckmann]

Package: clang-modernize-3.8
Version: 1:3.8~svn250696-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to install in
sid.

In order for the transitional package clang-modernize-3.8 to be useful,
it must be installable. Therefore the Breaks+Replaces in clang-tidy-3.8
must be versioned (<< 1:3.8~svn250696-1).


Andreas

Bug#804828: fte-docs: rename to ‘fte-doc’

[Axel Beckert]

Hi Ben,

Ben Finney wrote:
> On 13-Nov-2015, Axel Beckert wrote:
> > I do have a patch for that (attached), but I actually think that the
> > upload, going through the NEW queue and annoying users with
> > transitional packages are not worth the effort.
> 
> My understanding is that ‘fte-docs’ is still very new in Debian. Is
> that correct?

No. The oldest version of fte-docs known by snapshot.debian.org is
0.49.13-10 which has a changelog entry from February 2000. Until then,
the package never has been mentioned in the changelog, so I assume
that it's in there from the beginning (1996).

What you might have stumbled upon is #798413 (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798413#22) which
caused fte-docs to disappear in the archive for the period between two
uploads (0.50.2b6-6 and 0.50.2b6-7), so that 0.50.2b6-7 had to go
through NEW.

If it would have been a new binary package, I would have agreed. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#804996: voms-clients-java: Replace mvn-debian with maven-debian-helper

[Emmanuel Bourg]

Package: voms-clients-java
Version: 3.0.6-2
Severity: normal

Hi,

mvn-debian is going to be removed (#703373) but voms-clients-java is one
of the few packages using it. It could be replaced by the DH buildsystem
provided by maven-debian-helper. This will simplify the maintenance since
the package will no longer fail to build after each upgrade of a Maven
plugin (such as #804594).

This transition can be achieved by rewriting debian/rules to something
like this:

%:
dh $@ --buildsystem=maven

The pom patching mechanic and the installation of the jars are handled
automatically.

This will require a new debian/voms-clients-java.poms file containing:

pom.xml --java-lib --has-package-version

The rules for the Maven plugins in debian/maven.rules can be removed.


Emmanuel Bourg

Bug#801755: closed by Colin Tuckley <col...@debian.org> (Bug#801755: fixed in cqrlog 1.9.0-5)

[Colin Tuckley]

On 12/11/15 23:03, Andreas Beckmann wrote:

> OK, tested the upgrade path ... still failing, so we need a Conflicts in
> mysql-server-5.6 to ensure cqrlog gets upgraded first (and undos the
> conffile modifications). Verified that this works.
> Bug filed against mysql-5.6: #804920

Actually, I'm not sure that is correct, the file that cqrlog modifies
has a header that *explicitly* says it is used for local modifications.
Surely if that is the case it can't be a conf file?

Colin

-- 
Colin Tuckley  |  +44(0)1223 830814  |  PGP/GnuPG Key Id
Debian Developer   |  +44(0)7799 143369  | 0x38C9D903

A fool must now and then be right by chance.

Bug#804997: voms-clients-java: Missing dependency on a Java runtime

[Emmanuel Bourg]

Package: voms-clients-java
Version: 3.0.6-2
Severity: normal

Hi,

voms-clients-java installs Java based command line tools but the package
doesn't depend on a Java runtime. The commands will not work if a JRE isn't
installed.

The binary package should declare a dependency on:

default-jre-headless | java6-runtime-headless


Emmanuel Bourg

Bug#733993: loudmouth: please package github snapshot of loudmouth

[Michael Biebl]

Am 10.11.2015 um 20:59 schrieb Mikael Berthe:

> I've already done so and I think all relevant patches have been
> merged...  Let me know if you think I missed one!
> FWIW, the Fedora guys have also checked and sent their own patches so I
> think we should be up-to-date.

The only one which might still be relevant is maybe
debian/patches/06_-lasyncns.patch. Updated for 1.5.1 it would look like

Index: loudmouth-1.5.1/loudmouth-1.0.pc.in
===
--- loudmouth-1.5.1.orig/loudmouth-1.0.pc.in↦   2015-11-13
10:50:29.894614748 +0100
+++ loudmouth-1.5.1/loudmouth-1.0.pc.in↦2015-11-13 10:50:57.809547392 +0100
@@ -7,6 +7,6 @@
 Description: libloudmouth
 Requires: glib-2.0
 Version: @VERSION@
-Libs.private: @LIBIDN_LIBS@
+Libs.private: @LIBIDN_LIBS@ @ASYNCNS_LIBS@
 Libs: -L${libdir} -lloudmouth-1
 Cflags: -I${includedir}/loudmouth-1.0



Thoughts?

-- 
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#804994: Disabling domains

[martin f krafft]

Package: vmm
Version: 0.6.2-1
Severity: wishlist

It would be nice if there was an interface to disable a domain
without deleting it from the database, i.e. an is_active field of
sorts, and a UI e.g.

  vmm domainenable [domain]
  vmm domaindisable [domain]

Obviously, I can introduce the database field myself and amend my
queries, but I think this would be a useful feature to have by
default.

And then maybe even extend it to users and possibly aliases…

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#804765: Don't disable deprecated functions

[Iain Lane]

On Thu, Nov 12, 2015 at 02:17:16PM -0600, Dirk Eddelbuettel wrote:
> 
> On 11 November 2015 at 11:45, Iain Lane wrote:
> | Package: gsl
> | Version: 2.0+dfsg-1
> | Severity: normal
> | Tags: patch
> | User: ubuntu-de...@lists.ubuntu.com
> | Usertags: origin-ubuntu xenial ubuntu-patch
> | 
> | I noticed when rebuilding packages for the gsl transition in Ubuntu that
> | mrtrix FTBFS due to disabled deprecatead functions. Maybe we should
> | re-enable them for now to ease the transition? Patch attached.
> 
> Did you report that upstream too?  Looks like I no longer need the patch in
> the brand new gsl 2.1.

No I didn't, sorry - in Ubuntu the transition got entangled with a whole
bunch of other stuff (poppler, ocaml, ...) and so I was frantically
fixing many packages at once.

If mrtrix continues to build with 2.1 then by all means drop it. :)

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: Digital signature

Bug#802677: AttributeError: 'IntegrityError' object has no attribute '__traceback__'

[Neil Williams]

reopen 802677
thanks

On Thu, 12 Nov 2015 22:52:17 +0100
Thomas Goirand  wrote:

> Hi Neil,
> 
> I've kept this bug opened for a while, and tried to think about it.
> Though I see no other way but to fix your lavaserver package, as I
> don't think this is a bug in testtools, but rather an API breakage
> withe the newer version.

I don't see where or how there can be a fix in lava-server, I've since
done a lot of fixes for django1.8 support and all the tests pass again.
When I reintroduce the affected python-testtools, I get the same
traceback as before.

Traceback (most recent call last):
  File "./lava_server/manage.py", line 137, in 
legacy_main()
  File "./lava_server/manage.py", line 133, in legacy_main
execute_from_command_line(sys.argv)
  File
"/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
line 351, in execute_from_command_line utility.execute() File
"/usr/lib/python2.7/dist-packages/django/core/management/__init__.py",
line 343, in execute
self.fetch_command(subcommand).run_from_argv(self.argv) File
"/usr/lib/python2.7/dist-packages/django/core/management/commands/test.py",
line 30, in run_from_argv super(Command, self).run_from_argv(argv) File
"/usr/lib/python2.7/dist-packages/django/core/management/base.py", line
394, in run_from_argv self.execute(*args, **cmd_options) File
"/usr/lib/python2.7/dist-packages/django/core/management/commands/test.py",
line 74, in execute super(Command, self).execute(*args, **options) File
"/usr/lib/python2.7/dist-packages/django/core/management/base.py", line
445, in execute output = self.handle(*args, **options) File
"/usr/lib/python2.7/dist-packages/django/core/management/commands/test.py",
line 90, in handle failures = test_runner.run_tests(test_labels) File
"/usr/lib/python2.7/dist-packages/django/test/runner.py", line 211, in
run_tests result = self.run_suite(suite) File
"/usr/lib/python2.7/dist-packages/django/test/runner.py", line 178, in
run_suite ).run(suite) File "/usr/lib/python2.7/unittest/runner.py",
line 151, in run test(result) File
"/usr/lib/python2.7/unittest/suite.py", line 70, in __call__ return
self.run(*args, **kwds) File "/usr/lib/python2.7/unittest/suite.py",
line 108, in run test(result)
  File "/usr/lib/python2.7/dist-packages/unittest2/case.py", line 673,
in __call__ return self.run(*args, **kwds)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
606, in run return run_test.run(result)
  File "/usr/lib/python2.7/dist-packages/testtools/runtest.py", line
80, in run return self._run_one(actual_result)
  File "/usr/lib/python2.7/dist-packages/testtools/runtest.py", line
94, in _run_one return
self._run_prepared_result(ExtendedToOriginalDecorator(result)) File
"/usr/lib/python2.7/dist-packages/testtools/runtest.py", line 108, in
_run_prepared_result self._run_core() File
"/usr/lib/python2.7/dist-packages/testtools/runtest.py", line 144, in
_run_core self.case._run_test_method, self.result): File
"/usr/lib/python2.7/dist-packages/testtools/runtest.py", line 193, in
_run_user return self._got_user_exception(sys.exc_info()) File
"/usr/lib/python2.7/dist-packages/testtools/runtest.py", line 213, in
_got_user_exception self.case.onException(exc_info, tb_label=tb_label)
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
556, in onException self._report_traceback(exc_info, tb_label=tb_label)
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
592, in _report_traceback self, '__testtools_tb_locals__', False)))
File "/usr/lib/python2.7/dist-packages/testtools/content.py", line 205,
in __init__ limit=limit, capture_locals=capture_locals).format()) File
"/usr/lib/python2.7/dist-packages/traceback2/__init__.py", line 449, in
__init__ exc_value.__cause__.__traceback__, AttributeError:
'IntegrityError' object has no attribute '__traceback__'

As you can see in the traceback, there is no involvement of the
lava-server code other than to start execution.

As you have invited upstream of python-testtools to be involved, I'm
not sure why it seemed appropriate to close the bug. What testing has
been done to verify that this is not a bug in python-testtools (and if
that has been done, why invite python-testtools upstream?)

> I'd strongly suggest you, in this case, to get in touch with the
> testtools upstream, and get an advice. I've put Robert as CC, as he is
> very knowledgeable about these unit test stuff. Hopefully, he will be
> able to give a quick advice.

By changing line 556 of testcase.py:
 sed '556!d' /usr/lib/python2.7/dist-packages/testtools/testcase.py
# self._report_traceback(exc_info, tb_label=tb_label)

to
print exc_info

I actually get useful information about why the testcase is failing.

, IntegrityError('duplicate key
value violates unique constraint "auth_user_username_key"\nDETAIL:  Key
(username)=(generic-1) already exists.\n',), 

So it is self._report_traceback which is itself failing to report the
traceback.

So, 

Bug#801755: closed by Colin Tuckley <col...@debian.org> (Bug#801755: fixed in cqrlog 1.9.0-5)

[Andreas Beckmann]

On 2015-11-13 09:50, Colin Tuckley wrote:
> On 12/11/15 23:03, Andreas Beckmann wrote:
> 
>> OK, tested the upgrade path ... still failing, so we need a Conflicts in
>> mysql-server-5.6 to ensure cqrlog gets upgraded first (and undos the
>> conffile modifications). Verified that this works.
>> Bug filed against mysql-5.6: #804920
> 
> Actually, I'm not sure that is correct, the file that cqrlog modifies
> has a header that *explicitly* says it is used for local modifications.
> Surely if that is the case it can't be a conf file?

I don't see a problem here. Local modifications means $ADMIN running
$EDITOR on that file, and these have to be preserved. But conffiles are
not to be modified by maintainer scripts or the like (with the exception
of undoing the incorrectly done edits in the first place).

Check the policy about the distinction between "configuation files" and
"conffiles".
https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files


Andreas

Bug#104122: Mas en pierre dans le Sud de la France

[Belles Demeures du Sud]

Pour visualiser ce message sur votre navigateur: 


VOUS ÊTES PLUTÔT MAS EN PIERRES OU VILLA CONTEMPORAINE?

Madame, Monsieur, accédez à un cadre de vie authentique, aux senteurs 
de la Provence, avec OPUS Développement. Découvrez nos derniers mas en 
pierres et villas contemporaines, ici!


Vous êtes abonné à la newsletter d'OPUS Développement avec l'adresse 
email: 104...@bugs.debian.org

Vous pouvez vous désinscrire: 
http://communication.villas-lumina.com/HD?b=a3F-UhaeuXOWd-8fgdh96uCnYZQUrBopoHhxwPSSc-jM8QpYq9FrkaxDn6uYRrg-=EebmoTjEV2098Gr7I7oFhA
 des offres d'OPUS Développement.

En application de la loi n°78 - 17 du 6 Janvier 1978 modifiée par la 
loi du 6 Août 2004 relative à l'informatique, aux fichiers et aux 
libertés, vous disposez d'un droit d'accès, de modification, de 
rectification et de suppression des données personnelles vous 
concernant auprès de:
OPUS Développement 4, rue des Trésoriers de la Bourse 34000 Montpellier.

Bug#805003: jglobus: Replace mvn-debian with maven-debian-helper

[Emmanuel Bourg]

Source: jglobus
Version: 2.1.0-2
Severity: normal

Hi,

mvn-debian is going to be removed (#703373) but jglobus is one
of the few packages using it. It could be replaced by the DH buildsystem
provided by maven-debian-helper.

This transition can be achieved by rewriting debian/rules to something
like this:

%:
dh $@ --buildsystem=maven

override_dh_auto_build:
dh_auto_build -- package javadoc:aggregate


The pom patching mechanic and the installation of the jars are handled
automatically.

This will require a new debian/libjglobus-parent-java.poms file containing:

pom.xml --no-parent --has-package-version --package=libjglobus-parent-java
axis/pom.xml --has-package-version --package=libjglobus-axisg-java
container-test-utils/pom.xml --ignore
gram/pom.xml --has-package-version --package=libjglobus-gram-java
gridftp/pom.xml --has-package-version --package=libjglobus-gridftp-java
gss/pom.xml --has-package-version --package=libjglobus-gss-java
io/pom.xml --has-package-version --package=libjglobus-io-java
jsse/pom.xml --has-package-version --package=libjglobus-jsse-java
myproxy/pom.xml --has-package-version --package=libjglobus-myproxy-java
ssl-proxies-tomcat/pom.xml --has-package-version 
--package=libjglobus-ssl-proxies-tomcat-java
ssl-proxies/pom.xml --has-package-version --package=libjglobus--java
test-utils/pom.xml --ignore

The rules for the Maven plugins in debian/maven.rules can be removed.


Emmanuel Bourg

Bug#805031: Annual ping for Andriy Grytsenko

[Andriy Grytsenko]

Package: debian-maintainers
Severity: normal

Annual ping it is.

Thanks!


signature.asc
Description: Digital signature

Bug#457794: aptitude should show which repository provides a package

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2007-12-25 20:40 xsdg:

Package: aptitude
Version: 0.4.10-1+b1
Severity: wishlist

Currently, it seems that there is no way to determine which repository provides
a certain package.  Thus, if I want to find out if a specific package comes
from unstable or from experimental, I need to look at `apt-cache policy `
rather than being able to check via aptitude's UI.

Additionally (though I haven't actually checked), it seems that if two
repositories provide a certain package with identical version numbers, that it
may not be possible to tell which package comes from which repository.  (An
example where this might occur is that I currently have Corsac's personal XFCE
repository in my sources.list.  He might tweak a package from there, and then
upload to unstable without removing that package from his repository.  I would
like to be able to install the version from unstable rather than the version
from his repository.)


This is implemented now, will be released soon, so marking as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#805034: review Prosody data storage strategy

[Daniel Pocock]

Package: rtc.debian.org
Severity: wishlist

Prosody data (roster/buddy-list) is currently stored in files under
/var/lib/prosody

DSA would potentially support a PostgreSQL database

Prosody has a module for PostgreSQL storage:

http://prosody.im/doc/modules/mod_storage_sql

What benefits would we gain from this?  Is it more resilient, faster or
easier to support clustering?  It may be useful for reporting too (e.g.
reporting on the number of active users, average number of roster entries)

What are the risks and maintenance overheads, if any?

What is the strategy for migrating the data?  It looks like there is a tool:
http://prosody.im/doc/migrator

Bug#804315: [ralph.amis...@gmail.com: outrageous, thievery]

[John D. Hendrickson]

absolutely rediculous.  it's a GPL free source open system

your supposed to use it in your SPARE time not your business time.

you are NOT supposed to using it for private development without 
funding.  perhaps if a proffesor, paid for such things, and have chosen 
to do so (ie, GRUB is a good example of that, or "gv" ghost view (orig 
and improved) as well).  otherwise it is strictly about hobby time.


(if used for business your totally assume risk, and the world is full of 
books and information to tell you that)


you could accuse "someone" of intently wasting others time by reverse 
engineered uploads to cause intentional time/investment losses (ie, 
inserting build failures to give others headaches): that's illegal since 
the days of Rome.  and it's not easy to prove (perhaps intently, perhaps 
not).


you have absolutely no right to complain about "others using your 
donated time".  zero, none.



> usting. It is nasty. A bit strange to think that I
"know" some of those guys.

My interest in Debian pEd Dixon wrote:
Be sure to share Daniels story via social media using the buttons on his 
blog. I hope it wakes up the entire community to what happens when you 
actually do something right around here! https://t.co/NwWs9AfW87 Thanks,


On Mon, Nov 9, 2015 at 2:15 PM Richard Newton > wrote:


I agree, shame on those responsible. I have been using Debian for
almost 15 years and this is the first time I have been ashamed. Add
my name to the record "of conscientious objection."

RIchard Newton

On Mon, Nov 9, 2015 at 11:42 AM, Ralph Amissah
> wrote:

I post not in anger but sadness, I should not let my voice go
uncounted.

Attached is my note to Daniel of earlier today, before his
posting of
"an abrupt end to Debian Live". Debian Live which he said Debian
should
have (as a Debian developer) in 2006 and went on to deliver, rather
nicely (with (and without) help).

- Forwarded message from Ralph Amissah
> -

From: Ralph Amissah >
To: Daniel Baumann
Subject: outrageous, thievery
Date: Mon, 9 Nov 2015 09:28:44 -0500
Message-ID: <20151109142844.GA28261@niu>
User-Agent: Mutt/1.5.24 (2015-08-30)

Daniel, (already one of the more active Debian Developers then) I
remember you telling Debian at Debconf 2006, Mexico about how
"we"[1]
needed a live-maker within the project. I said then that I
thought this
one of the most important projects within Debian (I was
surprised that
there was not more interest and effort offered by others at the
time,
though there was some, those so keen now did not seem to pay
attention
then).  Already then it was clear that it would one day be able
to and
possibly be the preferred way to do a Debian install... as I said,
important. I saw how you contributed to Debian then, and I know
how you
have contributed since. Instead of welcoming you and your work,
there
seems to have been an effort to isolate you.

Well clearly others have seen the fruits of your labor as a
threat and
with envy, and ripe for their plucking!

Outrageous! Disgusting. It is nasty. A bit strange to think that I
"know" some of those guys.

My interest in Debian proper, dropped with your earlier
treatment, it
took away the desire to be a closer part of it. At least that
took out
much of any idealized notion of the inner workings of it. And
there have
been other moves since. I continue to be amazed by the politics of
groups within Debian.  This though has the feel of blatant thievery.
Chals characterization of a dictatorial coup would seem to be most
accurate.

It has no doubt to do with power (perhaps indirectly money is
involved
as well), your work & work area being seen as strategically
important.
They do it because they can, & justify it whatever which way
they will.

I am sorry. I feel pretty bruised on your behalf.

We have not spoken in a long while. I hope we have the chance to
talk in
happier times.

Greetings.
Ralph

P.S. We are ok, not much to report.

- End forwarded message -
[edits: addition of footnote, &; s/picking/plucking/]

Indeed I am a friend of Daniel and primarily a user of Debian (a
minor
contributor of a package (sisu[2]) that I wrote that I am happy
to have in
Debian). In other 

Bug#805040: consul-migrate: FTBFS on ppc64: undefined: maxMapSize

[Aaron M. Ucko]

Source: consul-migrate
Version: 0.1.0-1
Severity: important
Justification: fails to build from source

The consul-migrate build for (big-endian) ppc64 failed:

  # github.com/boltdb/bolt
  src/github.com/boltdb/bolt/db.go:85: undefined: maxMapSize
  src/github.com/boltdb/bolt/db.go:85: invalid array bound maxMapSize

Could you please take a look?

Thanks!

Bug#804394: [Pkg-anonymity-tools] Bug#804394: torbrowser-launcher: recommends alpha updates due to 5.5a4-hardened being added

[Ximin Luo]

It would be greatly helpful if people that don't ordinarily write code, go in 
to have a look at the code and try to send a patch upstream.

Most people working on this team have a shit-ton of other responsibilities. 
More people need to step up and contribute to FOSS. Freedom is not free.

X

On 13/11/15 13:57, dpdt1 wrote:
> On Sun, 08 Nov 2015 13:28:26 +0800 Paul Wise  wrote:
>> On Sun, 2015-11-08 at 13:09 +0800, Paul Wise wrote:
>>
>>> Normally torbrowser-launcher only downloads stable versions of Tor
>>> Browser (currently 5.0.4). Now that 5.5a4-hardened is out, torbrowser-
>>> launcher started offering it but since it is in alpha, it should not be
>>> offered to users of 5.0.X yet.
>>
>> The workaround for this appears to be to edit the settings file and
>> replace the latest_version option every 24 hours.
>>
>> ~/.config/torbrowser/settings
>>
>> -- 
>> bye,
>> pabs
>>
>> https://wiki.debian.org/PaulWise
>>
>>
> 
> 
> having the same bug.
> used the workaround above, but then i get hit by another bug #804270
> 
> so tor browser from debian is really unusable for me right now and can
> only run 5.0.3 version.
> 
> will probably download tor browser manually to use it again, untill
> those bugs are fixed.
> 
> thanks,
> 
> 
> 

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Bug#723990: youtube-dl: python3+ requirement

[Javier Cantero]

> The problem is that I don't know how to make it work with both Python 2 or
> Python 3, while still satisfying the following two points:
> 
> * Without creating extra binary packages (and having to go through the NEW
>   queue of the ftp-masters).
> 
> * Without making any use of any hackish, non-readable tricks.  Note that the
>   package currently has modules that should be usable for any version of
>   Python that we propose to support.
> 
> I would love some help with this.

There is an easy solution: to make it only a python 3 package, since the
Debian Python Policy[1] says[2]: "Packages in Debian should use Python 3
if Python 3 is supported." And also in the same page: "Programs should
use Python 3, and should not be packaged for Python 2 as well."

I think that youtube-dl supports python 3.2+ (or at least that says the
homepage). If it works with python 3, it's the perfect excuse to make
the transition now rather than wait until year 2020, and you don't need
to worry about maintaining duplicated packages or anything hackish.


 [1]: https://www.debian.org/doc/packaging-manuals/python-policy/
 [2]: https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html

-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#805041: httpbin: build python3 package

[Daniel Stender]

Source: httpbin
Version: 0.4.0+dfsg-1
Severity: wishlist
Control: block -1 by 661510

Httpbin should build also a Python 3 package.

DS

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#805027: [python-acme] not building on jessie

[Jan Wagner]

Hi there,

I spotted another problem building after fixing the sphinx issue.

It looks like the local webserver isn't running (at least in my jessie
chroot).

[...]
test_simple_verify_connection_error
(acme.challenges_test.HTTP01ResponseTest) ...
ERROR:acme.challenges:Unable to reach
http://local/.well-known/acme-challenge/eHh4eHh4eHh4eHh4eHh4eA:
ok
test_simple_verify_good_validation
(acme.challenges_test.HTTP01ResponseTest) ... ok
test_simple_verify_port (acme.challenges_test.HTTP01ResponseTest) ...
WARNING:acme.challenges:Using non-standard port for SimpleHTTP
verification: 8080
ok
[...]
test_404 (acme.standalone_test.HTTP01ServerTest) ... ERROR
test_http01_found (acme.standalone_test.HTTP01ServerTest) ...
WARNING:acme.challenges:Using non-standard port for SimpleHTTP
verification: 34328
ERROR:acme.challenges:Unable to reach
http://localhost:34328/.well-known/acme-challenge/eHh4eHh4eHh4eHh4eHh4eA: 
HTTPConnectionPool(host='127.0.0.1',
port=9): Max retries exceeded with url:
http://localhost:34328/.well-known/acme-challenge/eHh4eHh4eHh4eHh4eHh4eA
(Caused by ProxyError('Cannot connect to proxy.', error(111, 'Connection
refused')))
FAIL
test_http01_not_found (acme.standalone_test.HTTP01ServerTest) ...
WARNING:acme.challenges:Using non-standard port for SimpleHTTP
verification: 38382
ERROR:acme.challenges:Unable to reach
http://localhost:38382/.well-known/acme-challenge/eHh4eHh4eHh4eHh4eHh4eA: 
HTTPConnectionPool(host='127.0.0.1',
port=9): Max retries exceeded with url:
http://localhost:38382/.well-known/acme-challenge/eHh4eHh4eHh4eHh4eHh4eA
(Caused by ProxyError('Cannot connect to proxy.', error(111, 'Connection
refused')))
ok
test_index (acme.standalone_test.HTTP01ServerTest) ... ERROR
[...]

A full buildlog is attached.

Thanks and with kind regards, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--
 dpkg-buildpackage -rfakeroot -D -us -uc -sa
dpkg-buildpackage: source package python-acme
dpkg-buildpackage: source version 0.0.0.dev20151104-1~bpo8+1
dpkg-buildpackage: source distribution jessie-backports
dpkg-buildpackage: source changed by Jan Wagner 
 dpkg-source --before-build python-acme-0.0.0.dev20151104
dpkg-buildpackage: host architecture i386
 fakeroot debian/rules clean
dh clean --with python2,python3,sphinxdoc --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:170: python2.7 setup.py clean 
running clean
removing 
'/home/waja/python-acme-0.0.0.dev20151104/.pybuild/pythonX.Y_2.7/build' (and 
everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-2.7' does not exist -- can't clean it
I: pybuild base:170: python3.4 setup.py clean 
running clean
removing 
'/home/waja/python-acme-0.0.0.dev20151104/.pybuild/pythonX.Y_3.4/build' (and 
everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.4' does not exist -- can't clean it
   dh_clean -O--buildsystem=pybuild
 dpkg-source -b python-acme-0.0.0.dev20151104
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building python-acme using existing 
./python-acme_0.0.0.dev20151104.orig.tar.gz
dpkg-source: warning: ignoring deletion of directory acme.egg-info
dpkg-source: warning: ignoring deletion of file acme.egg-info/requires.txt, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file 
acme.egg-info/dependency_links.txt, use --include-removal to override
dpkg-source: warning: ignoring deletion of file acme.egg-info/PKG-INFO, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file acme.egg-info/top_level.txt, 
use --include-removal to override
dpkg-source: warning: ignoring deletion of file acme.egg-info/SOURCES.txt, use 
--include-removal to override
dpkg-source: warning: ignoring deletion of file acme.egg-info/entry_points.txt, 
use --include-removal to override
dpkg-source: info: building python-acme in 
python-acme_0.0.0.dev20151104-1~bpo8+1.debian.tar.xz
dpkg-source: info: building python-acme in 
python-acme_0.0.0.dev20151104-1~bpo8+1.dsc
 debian/rules build
dh build --with python2,python3,sphinxdoc --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:170: python2.7 setup.py config 
running config
I: pybuild base:170: python3.4 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/home/waja/python-acme-0.0.0.dev20151104'
dh_auto_build
I: pybuild base:170: /usr/bin/python setup.py build 
running build
running build_py
creating 
/home/waja/python-acme-0.0.0.dev20151104/.pybuild/pythonX.Y_2.7/build/acme
copying acme/util_test.py -> 

Bug#805036: Wrong systemctl path in /usr/sbin/start-dirsrv

[Yvan Masson]

Package: 389-ds-base
Version: 1.3.3.5-4

Dear maintainers,

The script /usr/bin/start-dirsrv has the wrong path for systemctl, on
line 68 : /usr/bin/systemctl.

If systemd is used, this prevents ns-slapd from restarting.

Changing the path to /bin/systemctl seems to fix the problem.

Regards,
Yvan

Bug#804870: synaptic - FR localisation patch

[Michael Vogt]

On Thu, Nov 12, 2015 at 04:09:07PM +0100, treb...@tuxfamily.org wrote:
> Package: synaptic
> Version: 0.82
> 
> Hi, please find attached a debdiff which adds French localisation to the
> fr.po file. I've been checking in the version 0.81-2 version (jessie stable
> version) and those 2 strings doesn't appear neither. So it could be
> backported as well.

Thanks! I commited the patch to git and it will be part of the
next upload.

Cheers,
 Michael

> Regards,
> Olivier

> Description: l10n FR
> Origin: LibraZiK
> Forwarded: not needed - already there upstream
> Author: Olivier Humbert 
> Reviewed-by:
> Last-Update: 2015 11 12
> 
> --- a/po/fr.po
> +++ b/po/fr.po
> @@ -1,15 +1,16 @@
>  # French translation for synaptic
> -# Copyright (c) 2011 Rosetta Contributors and Canonical Ltd 2011
> +# Copyright (c) 2011 Rosetta Contributors and Canonical Ltd 2011 and others.
>  # This file is distributed under the same license as the synaptic package.
>  # FIRST AUTHOR , 2011.
> +# Olivier Humbert , 2015.
>  #
>  msgid ""
>  msgstr ""
>  "Project-Id-Version: synaptic\n"
>  "Report-Msgid-Bugs-To: \n"
>  "POT-Creation-Date: 2011-02-10 09:41+0100\n"
> -"PO-Revision-Date: 2012-01-04 12:47+\n"
> -"Last-Translator: Bruno Patri \n"
> +"PO-Revision-Date: 2015-11-12 13:52+0100\n"
> +"Last-Translator: Olivier Humbert \n"
>  "Language-Team: French \n"
>  "Language: fr\n"
>  "MIME-Version: 1.0\n"
> @@ -2704,6 +2705,10 @@
>  msgid "Show for individual files"
>  msgstr "Afficher les d??tails par fichier"
>  
> +#: ../gtk/gtkbuilder/window_fetch.ui.h:1
> +msgid "Show individual files"
> +msgstr "Afficher les d??tails par fichier"
> +
>  #: ../gtk/gtkbuilder/window_changes.ui.h:1
>  msgid ""
>  "Mark additional required changes? @@ -3663,6 +3668,12 @@
>  msgid "Synaptic Package Manager"
>  msgstr "Gestionnaire de paquets Synaptic"
>  
> +#: ../data/com.ubuntu.pkexec.synaptic.policy.in.h:1
> +msgid "Authentication is required to run the Synaptic Package Manager"
> +msgstr ""
> +"Une authentification est requise pour ex??cuter le gestionnaire de paquets "
> +"Synaptic"
> +
>  #: ../gtk/rgfiltermanager.h:62
>  msgid "Includes"
>  msgstr "Inclut"

Bug#805038: IPv6 NDP proxy not working correctly

[Kilian Krause]

Package: strongswan
Version: 5.3.3-2
Severity: normal
Tags: ipv6 upstream patch

Hi Yves,

similar to what's stated on https://wiki.strongswan.org/issues/1008
I've had to add this:
-(snip)-
# cat /etc/strongswan.d/proxyndp.updown
case $PLUTO_VERB in
OUTDEV=$(ip -6 r get ${PLUTO_PEER_CLIENT%}|sed -ne 's,^.*dev 
\(\S\+\) .*,\1,p')
up-client-v6)
ip -6 neigh add proxy ${PLUTO_PEER_CLIENT%} dev ${OUTDEV:-eth0}
;;
down-client-v6)
ip -6 neigh delete proxy ${PLUTO_PEER_CLIENT%} dev ${OUTDEV:-eth0}
;;
esac
#
-(snip)-
to make my IPv6 work correctly inside my tunnels. I've enhanced the named
script from the bug slightly so that also allow for more than just an eth0
interface.

It would be nice if the Debian package could ship that by default until
upstream has included this or an equivalent fix to the issue.

Cheers,
Kilian

Bug#804911: Incorrect chai dependency on chef package in jessie

[Noah Kantrowitz]

> On Nov 13, 2015, at 3:20 AM, Antonio Terceiro  wrote:
> 
> Control: retitle -1 chef: ohai resource broken in Jessie
> Control: tag -1 + patch pending
> 
> Hi, thanks for reporting this.
> 
> On Thu, Nov 12, 2015 at 11:51:10AM -0800, Noah Kantrowitz wrote:
>> Package: chef
>> Version: 11.12.8-2
>> 
>> Chef 11.12.8 clearly states that it depends on Ohai at least 7.0.4
>> (https://github.com/chef/chef/blob/11.12.8/chef.gemspec#L20). As it
>> stands, the jessie package depends on Ohai >= 6 and the packaged
>> version is a 6.x. This results in the ohai resource being
>> non-functional as it uses an API added in Ohai 7.0.0. Either Chef
>> needs to be patched to not use this API (Ohai::System#all_packages
>> with an argument) or the Ohai dependency needs to be corrected.
> 
> Would you please test the package from
> https://people.debian.org/~terceiro/chef-jessie/ and let me know it
> works for you?
> 
> I have applied the attached patch, and tested a basic usage of the ohai
> resource which worked for me; if you confirm your use case is fixed I
> will make a stable update with those changes.

I'm just the messenger here, you'll have to test your patches yourself. I help 
with
Chef's IRC user support, and this was reported by an end-user that was confused
at some community cookbooks not working. You can try running the chai::default
recipe as that was the one reported to be failing, but I'll point out again 
that you
are shipping the wrong version of Ohai.

--Noah



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#802655: gnome-color-manager missing primary screen

[Pascal Obry]

Hi,

> Colour management started working for me today, no idea what change
> fixed it. 
> 
> (I had to log out and in again for the display to show up in the
> settings panel)

Likewise. Don't know what has changed.

I've seen a colord update one or two days ago and some Gtk libraries
and gnome-control-center yesterday.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Bug#756109: systemd: Please copy 70-uaccess.rules and 71-seat.rules in the initramfs

[Laurent Bigonville]

On Sun, 29 Mar 2015 05:30:23 +0200 m...@linux.it (Marco d'Itri) wrote:
> On Jul 26, Laurent Bigonville  wrote:
>
> > Do you think that it could be possible to copy 70-uaccess.rules and
> > 71-seat.rules (and maybe 73-seat-late.rules) in the initramfs?
> Adding 70-uaccess.rules is easy, but 71-seat.rules runs some programs
> like loginctl which is not available in the initramfs.
> Maybe we need a simpler rules file just for the initramfs?
> Is this change still needed?
> What do other distributions do about this?

Still would be nice to have yes.

I see two RUN in the 71-seat.rules and the loginctl one is used to lock 
the session in case a keylogger is inserted while the machine is booted, 
is it a problem if the command fails? The other one is udevadm, isn't 
this one already in the initramfs?


Looking at fedora, I see that they are copying the following rules:

inst_rules \
70-uaccess.rules \
71-seat.rules \
73-seat-late.rules \
90-vconsole.rules \
99-systemd.rules

but indeed they are also installing the loginctl apparently (and 
systemd-sysctl for 99-systemd.rules).


Cheers,

Laurent

Bug#805037: qemubuilder: Add qemu machine type overwrite.

[Benedikt Spranger]

Package:qemubuilder
Version: 0.75
Severity: wishlist
Tags: patch

Dear Maintainer,

using qemubuilder for armel and armhf in an automated build environment
causes some extra work due to different qemu machine types. Using the
same kernel for both architectures like in all other cases is not
possible since a different qemu machine type is choosen. Add a
qemu machine type overwrite to be able to force the same machine type
for armel and armhf.

Tested in my build environment with machine type "virt" to build
armhf- and armel-Packages for wheezy, jessie, stretch and sid.

Regards
Bene

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages qemubuilder depends on:
ii  debootstrap 1.0.75
ii  libc6   2.19-22
ii  pbuilder0.220
ii  qemu-kvm [kvm]  1:2.4+dfsg-4
ii  qemu-system 1:2.4+dfsg-4

qemubuilder recommends no packages.

qemubuilder suggests no packages.

-- no debconf information

>From 98f9ea42155f7711996b600edc8d8f7943bf86f5 Mon Sep 17 00:00:00 2001
From: Benedikt Spranger 
Date: Thu, 12 Nov 2015 19:57:18 +0100
Subject: [PATCH] qemubuilder: Add qemu machine type overwrite.

qemubuilder determine the build architecture to select the qemu machine
type from a hardcoded list. This prohibits to build armel and armhf using
the same kernel. Add a qemu machine type overwrite.

Signed-off-by: Benedikt Spranger 
---
 parameter.c   | 14 ++
 parameter.h   |  1 +
 qemuarch.c|  7 ++-
 qemuarch.h|  2 +-
 qemubuilder.c |  2 +-
 5 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/parameter.c b/parameter.c
index 8c015a6..54abf4c 100644
--- a/parameter.c
+++ b/parameter.c
@@ -146,6 +146,14 @@ int load_config_file(const char* config, pbuilderconfig* pc)
 	{
 	  pc->arch=strdup_strip_quote(delim);
 	}
+	  else if (!strcmp(buf, "MACHINE"))
+	{
+	  pc->mach=strdup_strip_quote(delim);
+	}
+	  else if (!strcmp(buf, "MACH"))
+	{
+	  pc->mach=strdup_strip_quote(delim);
+	}
 	  else if (!strcmp(buf, "BASEPATH"))
 	{
 	  pc->basepath=strdup_strip_quote(delim);
@@ -246,6 +254,7 @@ int cpbuilder_dumpconfig(pbuilderconfig* pc)
   DUMPSTR(initrd);
   DUMPINT(memory_megs);
   DUMPSTR(arch);
+  DUMPSTR(mach);
   return 0;
 }
 
@@ -291,6 +300,7 @@ int parse_parameter(int ac, char** av,
 {"inputfile", required_argument, 0, 0},
 {"outputfile", required_argument, 0, 0},
 {"architecture", required_argument, 0, 0},
+{"machine", required_argument, 0, 0},
 {"http-proxy", required_argument, 0, 0},
 
 /* cowbuilder specific options */
@@ -448,6 +458,10 @@ int parse_parameter(int ac, char** av,
 	{
 	  pc.arch=strdup(optarg);
 	}
+	  else if (!strcmp(long_options[index_point].name,"machine"))
+	{
+	  pc.mach=strdup(optarg);
+	}
 	  else if (!strcmp(long_options[index_point].name,"arch-diskdevice"))
 	{
 	  pc.arch_diskdevice=strdup(optarg);
diff --git a/parameter.h b/parameter.h
index 9ef23a7..d4eac52 100644
--- a/parameter.h
+++ b/parameter.h
@@ -57,6 +57,7 @@ typedef struct pbuilderconfig
   char* smp;
   int memory_megs;		/* megabytes of memory */
   char* arch;
+  char* mach;
   char* arch_diskdevice;
 
   enum {
diff --git a/qemuarch.c b/qemuarch.c
index 3fe7f11..5003144 100644
--- a/qemuarch.c
+++ b/qemuarch.c
@@ -160,8 +160,13 @@ const char* qemu_arch_qemu(const char* arch)
 /**
  * arch-specific routine; the machine spec for this arch
  */
-const char* qemu_arch_qemumachine(const char* arch)
+const char* qemu_arch_qemumachine(const struct pbuilderconfig* pc)
 {
+  const char *arch = pc->arch;
+
+  if (pc->mach)
+return strdup(pc->mach);
+
   if (!strcmp(arch, "arm") ||
   !strcmp(arch, "armel"))
 return "versatilepb";
diff --git a/qemuarch.h b/qemuarch.h
index 12d989e..c374a6f 100644
--- a/qemuarch.h
+++ b/qemuarch.h
@@ -12,7 +12,7 @@ const int qemu_create_arch_serialdevice(const char* basedir, const char* arch);
 const int qemu_create_arch_devices(const char* basedir, const char* arch);
 char* get_host_dpkg_arch();
 const char* qemu_arch_qemu(const char* arch);
-const char* qemu_arch_qemumachine(const char* arch);
+const char* qemu_arch_qemumachine(const struct pbuilderconfig* pc);
 const char* qemu_arch_tty(const char* arch);
 
 #endif
diff --git a/qemubuilder.c b/qemubuilder.c
index 4436703..904ea4f 100755
--- a/qemubuilder.c
+++ b/qemubuilder.c
@@ -267,7 +267,7 @@ static int fork_qemu(const char* hda, const char* hdb, const struct pbuilderconf
 {
   /* this is the child process */
   const char* qemu = qemu_arch_qemu(pc->arch);
-  const char* machine = 

Bug#802655: gnome-color-manager missing primary screen

[Sven Arvidsson]

On Thu, 2015-10-29 at 13:55 +0100, Pascal Obry wrote:
> Some other interresting information:
> 
> - using lightdm I can see all the screen in gcm
> 
> - reverting to gdm3/stable I can see all the screen in gcm
> 
> So it sounds like an issue with gdm3 from testing/unstable version
> 3.18.0-2 0

Hi,

Colour management started working for me today, no idea what change
fixed it. 

(I had to log out and in again for the display to show up in the
settings panel)

-- 
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 6FAB5CD5





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

Bug#805027: [python-acme] not building on jessie

[Jan Wagner]

Hi there,

Am 13.11.15 um 15:44 schrieb Jan Wagner:
> PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N -bhtml docs/
> build/html
> Making output directory...
> Running Sphinx v1.2.3
> 
> Exception occurred:
>   File "conf.py", line 130, in 

this (specific) problem should be fixed with the attached patch. I guess
that works also for python-letsencrypt and
python-letsencrypt-apache. When I should provide you with patches for
those, please just tell me.

Thanks, Jan.
-- 
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--
From c0c019596c6fe26a931e0383abc87ee8db080901 Mon Sep 17 00:00:00 2001
From: Jan Wagner 
Date: Fri, 13 Nov 2015 18:06:45 +0100
Subject: [PATCH] Add build-dependency python-sphinx-rtd-theme (>= 0.1.9-1~)

This is needed to build even on jessie (and maybe earlier).
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index edaa883..2f30729 100644
--- a/debian/control
+++ b/debian/control
@@ -18,6 +18,7 @@ Build-Depends: debhelper (>= 9~),
python-setuptools,
python-six,
python-sphinx (>= 1.3.1-1~),
+   python-sphinx-rtd-theme (>= 0.1.9-1~),
python-sphinxcontrib.programoutput,
python-tz,
python-werkzeug,


signature.asc
Description: OpenPGP digital signature

Bug#805035: ITP: pidgin-gpg -- OpenPGP plugin for Pidgin

[Gunnar Wolf]

Paulo Roberto Alves de Oliveira (aka kretcheu) dijo [Fri, Nov 13, 2015 at 
02:03:05PM -0200]:
> * Package name: pidgin-gpg
>   Version : 0.9
>   Upstream Author : Alexander.Murauer.
> * URL : https://github.com/segler-alex/Pidgin-GPG
> * License : GPL-3
>   Programming Lang: C
>   Description : OpenPGP plugin for Pidgin
> 
> pidgin-gpg is a plugin for the Pidgin instant messaging program which enables
> it to communicate with Jabber/XMPP peers in an encrypted manner using the
> OpenPGP standard, which is understood by other clients, such as centericq,
> gajim, kopete and mcabber.
> 
> Another package (pidgin-openpgp) intent to do the same think but not working
> anymore.

This has me a bit at unease. I don't know precisely how this plugin
works, what its UI is, or many, many other details... But:

OpenPGP key pairs are a very valuable asset for many of us. Of course,
those of us participating in the Debian project as DDs or DMs (or
those interested in joining) hold them in high value as they are our
main means of identification for the project. And there are many "best
practices", not all of them we all follow (i.e. I'd like to use a
smartcard for my keys, but I don't), but we expect all parties to
excercise a minimum common degree of care.

So, we take care to avoid storing our key pairs in computers
directly-connected to the Internet. We avoid keeping the key material
in "live" memory besides their ephimeral use. And what I feel most
important in this regard: GPG keys use cases are usually restricted to
signing documents/items, not for encrypting whole communication
sessions.

That is, in order to send this mail, I will input my key
passphrase. And according to my mail client configuration, the key
passphrase will be forgotten after a 5 minute interval.

If I add pidgin-gpg to my Pidgin, I will (probably - Again, depends on
the details of implementation) have:

- Key material in memory for the whole duration of my Pidgin session
  (which in my case means "always")

- Together with its passphrase (if it aims at not being obnoxious and
  asking for it over and over and over and over)

- In a network-connected and network-activated program

- In a fine piece of software, but one that has not been audited for
  security and lists tens of security advisories for the last few
  years, some of them leading to information leaks:

  https://www.pidgin.im/news/security/

- And for an application that already has a strong, different model
  for session encryption, better suited for full-session handling:
  OTR.

So... If you believe I'm mistaken on this, please go ahead. But do
consider the liabilities this brings to our users!


signature.asc
Description: Digital signature

Bug#804777: Missing UTF8 in vsftpd FEAT

[Jörg Frings-Fürst]

Hello Rainer,

thank you for your quick answer.

Can you add 

utf8_filesystem=YES

to your vsftpd.conf, restart vsftpd and test it again?

CU
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54526 Niederkail

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.





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

Bug#330503: aptitude: wrong dependency resolution, cannot update one package

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Martin,

2005-09-28 13:55 Martin Koeppe:

Package: aptitude
Version: 0.2.15.9-6
Severity: normal


Updating one package with complex dependencies fails:
I tried to update from slang1a-utf8 (1.4.9dbs-8) to
libslang1-utf8 (1.4.9dbs-10).

The following dependencies exist:

slang1a-utf8 (1.4.9dbs-8)
 Conflicts: slang1-utf8

libslang1-utf8 (1.4.9dbs-10)
 Conflicts: slang1-utf8, slang1a-utf8
 Replaces:  slang1a-utf8
 Provides:  slang1a-utf8

util-linux (2.12-7+kbsd.1)
 PreDepends: slang1a-utf8 (>1.4.4-7.1)

Installing libslang1-utf8 is not possible, even though it should be possible
to replace slang1a-utf8 with libslang1-utf8 without any problems.
I know that kfreebsd-i386 is not an official architecture,
but I think the dependency resolution algorithm has not changed there.

I also tested with
# apt-get -s install libslang1-utf8
but this wanted to remove util-linux as well.

I report this issue here nevertheless to make you aware of it,
in case aptitude has its own dependency resolution.
If that's wrong then please reassign it.


Sorry that this report has not been handled for a decade now.

I think that the problem was that util-linux depended on a version with
"greater", while virtual packages (Provides) did not support this kind
of relationship (I think that there is now support for this in the
works, but not finished yet).  In any case it looks to me a specific and
transitient problem with the dependencies of the packages themselves or
this problem with virtual packages, not a bug in aptitude per se.

I was trying to look at the changelogs and bugtracker of the related
packages, but the slang ones are not even present now.  I couldn't find
anything conclusive.

Not sure if we can do much about this report by now, sorry.

Did you find this problem in more instances, especially with kfreebsd?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#805032: Parallel builds FTBFS on amd64 and ppc64el in Ubuntu

[Graham Inggs]

Source: yade
Version: 1.20.0-5
Severity: wishlist
Tags: patch


Hi Maintainer

I disabled parallel builds of yade for all architectures in Ubuntu, as 
per the attached patch.

It has fixed the FTBFS on amd64 and ppc64el there.

Please consider doing the same so that yade may be sync'd automatically 
in future.


Regards
Graham

--- yade-1.20.0/debian/rules	2015-10-26 16:57:35.0 +
+++ yade-1.20.0/debian/rules	2015-11-12 14:50:20.0 +
@@ -3,13 +3,8 @@
 tmpInstall = $(CURDIR)/debian/tmp
 tmpDirMatplotLib = $(CURDIR)/debian/matplotlib
 
-ifneq (,$(filter $(DEB_HOST_ARCH), arm64))
 %:
 	dh $@ --builddirectory=$(BUILDDIR) --with python2
-else
-%:
-	dh $@ --builddirectory=$(BUILDDIR) --with python2 --parallel
-endif
 
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed,-no-keep-memory
 

Bug#805026: Unpackaged plugins in package strongswan

[Thomas Antepoth (debian)]

Dear maintainers,


I'm indebted to you for a beer.

Found my missing plugins in "libcharon-extra-plugins".

Thanks and sorry for the report.


Thomas

Bug#783770: Fwd: [Patch] Shall we update CUDA to 7.0.28 ? (#783770)

[lumin]

Hi,

On Fri, 2015-11-13 at 15:21 +0100, Samuel Thibault wrote:
> Thanks for your contribution that will hopefully help getting cuda 7.0
> or 7.5 packages out faster.

I do hope so. :-)

> > FYI: As far as I know, in my experiments,
> > a Tesla K20C GPU works 5+ times faster than an Intel Xeon W3690.
> 
> That's not a reason for rushing to CUDA 7.0 or later.  A K20C will work
> fine with CUDA 6.5.  Also, helping free software to support NVIDIA GPUs
> would help avoiding the issue :)

Well, I mean Caffe could work without CUDA but it is slow, so in order
to boost Caffe up I need a set of working build-deps, i.e.
we should import CUDA 7.5, which should be OK working with GCC-5.

> I guess there is no way to backport the CUDA 7.5 fixes to support GCC-5?
> (damn the non-free software...)

I think there is nearly no way doing so, even if we know what to change
to backport GCC-5 support into CUDA 7.0. That's because the CUDA's EULA
FORBIDS ANY KIND OF MODIFICATION, e.g. strip'ing the huge ELFs...
So 

> Urgl, so CUDA 7.0 is not even enough?
> 
> I guess we may want to skip 7.0 and directly upload 7.5.

Yes, NVCC 7.0.27 (shipped in CUDA 7.0.28, the version number is correct)
still complains about G{CC,++} >> 4.10. That means CUDA 7.0 refuses to
work with GCC-5 in my case.

So can we skip CUDA 7.0 ?

If that's OK, then I'll be glad to get CUDA 7.5 and
import it again.

> So yes, the answer is: "please be patient, we are working on it. Help is
> welcome".

I plan to take care of this package for some time.

Thank you for comment :-)
-- 
 .''`.   Lumin
: :' : 
`. `'   
  `-638B C75E C1E5 C589 067E  35DE 6264 5EB3 5F68 6A8A


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

Bug#513622: aptitude: Please add a field showing package repository to package description

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Micha,

2009-01-30 19:30 Micha Feigin:

Package: aptitude
Version: 0.4.11.11-1
Severity: wishlist


Please add a field to aptitude's package description showing which repository 
the package
is comming from.

When a package is available from more than one configured repository it's very
difficult (if not impossible) to figure out which one comes from where, 
esspecially
without installing it first, and the version number is not always a good enough
indication.

For example if one has testing/unstable/experimental or external repositories
configured at the same time. It would be very helpful if a field showing the
repository is added to the package display list.


This is implemented now, will be released soon, so marking as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#805027: [python-acme] not building on jessie

[Jan Wagner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi there,

Am 13.11.15 um 15:44 schrieb Jan Wagner:
> Exception occurred: File "conf.py", line 130, in  
> ImportError: No module named sphinx_rtd_theme

just FYI. Exactly the same problem exists in python-letsencrypt and
python-letsencrypt-apache.

Cheers, Jan.
- -- 
Never write mail to , you have been warned!
- -BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V-
PS PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
- --END GEEK CODE BLOCK--
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)

iQIcBAEBCgAGBQJWRgaiAAoJEAxwVXtaBlE+f84P/376DFPAuTM76Z3VR9AoxlZy
6QLgZ5c492cP1u0cOgMXmJxJz8LRJq4Vslr9lfy6R2/rAcoiwzxbQcUHE+/64FO2
kKMKSaFvkKTkPcNY7rj5iYCCtnlIay7SVf/efQ94+TgOw3rqMfcc3BigZ9rrv6nK
MzFycyh8IFQ1mwiNpNyNQcUL/5CqlbU1QuzE0wHp4MzQYKkHWuha/M9qQnIauAms
m0qKvOrvSorgG90b5lWrm2QDTP5XAKwLX/nKfE78Ms6T/KQODJoJmMccFEFmwa2o
KKU0tBXT8j7LYJ9SrSJacaQkL5Cz8SBzNpDgwVldrSOF6u/er4sYjsfwaPX+DZaj
gHnpVumLuLUsUethHy9kWJX00Y+pZkgNJ1qCWP1YLeFTd0ttlvFA9XlkqQWsyWzv
0NQgdf3IWqdYl++xVA6ABgoL+/2rzGGd8aUlQildnYlgH9fa8lNY7X+LDxyGL7Sc
xpyyqz79BHAWhxkltiUIQ5/9+8axckSTU1QVNYyG1zOS3AyVaRRzIHjRq43dOCnT
4g3BCp6oJRhxlNaiggVSF7dfp+cg8CXsRUnap5vgubpwL8Ip0B1Zl7deSmS+9+cB
T8qOtCle5R+zd5fogdYimw9kNdOrjW5wyP/hZrD8pXdBUu53shI1Gpfs6xgKz/h8
N39Ss8SvvAbHNqOiwX6d
=Orfj
-END PGP SIGNATURE-

Bug#805035: ITP: pidgin-gpg -- OpenPGP plugin for Pidgin

[Paulo Roberto Alves de Oliveira (aka kretcheu)]

Package: wnpp
Severity: wishlist
Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)" 

* Package name: pidgin-gpg
  Version : 0.9
  Upstream Author : Alexander.Murauer.
* URL : https://github.com/segler-alex/Pidgin-GPG
* License : GPL-3
  Programming Lang: C
  Description : OpenPGP plugin for Pidgin

pidgin-gpg is a plugin for the Pidgin instant messaging program which enables
it to communicate with Jabber/XMPP peers in an encrypted manner using the
OpenPGP standard, which is understood by other clients, such as centericq,
gajim, kopete and mcabber.

Another package (pidgin-openpgp) intent to do the same think but not working
anymore.

Bug#805039: consul-migrate: FTBFS (32-bit): MDB_INVALID: File is not an LMDB file

[Aaron M. Ucko]

Source: consul-migrate
Version: 0.1.0-1
Severity: important
Justification: fails to build from source

Builds of consul-migrate for 32-bit architectures (armel, armhf, and
i386) all failed:

  === RUN   TestMigrator_data
  --- FAIL: TestMigrator_data (0.00s)
  migrator_test.go:60: err: MDB_INVALID: File is not an LMDB file
  === RUN   TestMigrator_new
  --- PASS: TestMigrator_new (0.00s)
  === RUN   TestMigrator_migrate
  --- FAIL: TestMigrator_migrate (0.00s)
  migrator_test.go:130: err: Failed to connect MDB: MDB_INVALID: File is 
not an LMDB file %!s(MISSING)

Could you please take a look?

Thanks!

Bug#521190: aptitude state-bundle command man pages should be informative

[Manuel A. Fernandez Montecelo]

Control: severity -1 minor
Control: tags -1 + help newcomer


Hi Gokdeniz,

2009-03-25 16:00 Gokdeniz Karadag:

package: aptitude

Hi,

Man pages for aptitude-create-state-bundle  and  aptitude-run-state-bundle do
not explain their purpuse clearly.

Man pages state "what" they do ( "unpacks bundle, invokes program" etc. ) but
does not hint "why" you should be doing it.

It should detail what the user will achive by running this pair of commands and
is it a complete replacement of "dpkg --set-selections < file && apt-get
dselect-upgrade"


Thanks for the report.

I am tagging it as +help in the case that somebody feels generous and
wants to handle this bug.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#804860: Got it to work

[Clark]

  Apparently there was a dependency problem which was not picked up 
when I installed it.
  Installing the files need to get cmake to work on the source also 
fixed the problem running
the program.  The last thing I downloaded was libkf5kdelibs4support-dev 
which also
installed about 100 dependencies so I don't know what was missing 
originally.

Clark

Bug#399019: aptitude: now view for manually installed packages

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix


Hi,

2006-11-17 07:11 Tino Keitel:

Package: aptitude
Version: 0.4.3-1
Severity: normal

Hi,

aptitude is intended to replace debfoster. However, it would be a much
better replacement if aptitude had a view with all packages that are
manually installed, so that I can see only relevant packages and decide if
it should be removed from this list or not.


2011-12-19 03:53 Daniel Hartwig:

severity 399019 wishlist
thanks


aptitude is intended to replace debfoster. However, it would be a much
better replacement if aptitude had a view with all packages that are
manually installed, so that I can see only relevant packages and decide if
it should be removed from this list or not.


This can be achieved with the package display limit [1] set to
"?installed !?automatic". (press `l' in the curses interface)

Refer to the search terms reference [2] for more details.

[1] http://algebraicthunk.net/~dburrows/projects/aptitude/doc/en/ch01s01s03.html
[2] http://algebraicthunk.net/~dburrows/projects/aptitude/doc/en/ch02s03s05.html



It could be a good idea to create a new view for this, but since the
alternative is so easy to arrive to (in the main view, typing 'l' and
then '~i!~M' and then OK button), I am not sure that it's worth it.

Also, nobody seconded this request in the ~decade that it has been open.

In the meantime, I am marking as +wontfix at the moment, to try to clean
up the list of issues that are more likely to be implemented in the near
future.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#805030: libssh: New packaging for libssh upstream release 0.7.2

[Sven Haardiek]

Source: libssh
Severity: wishlist

Hej,

i needed a newer version of libssh than is packaged in debian jessie, so i
updated the packaging to libssh 0.7.2.

The packaging can be found under
https://github.com/shaardie/package-libssh

Maybe it can be used for jessie backports or even debian sid.

Bug#805016: Realized what the line through the font title is....

[Xavier Ortiz]

It's the window border that highlights the focused window. It's layered
over the font, giving it the  "strike through" look.

Bug#805033: Please add Sergio Durigan Junior as a Debian Maintainer

[Sergio Durigan Junior]

Package: debian-maintainer
Severity: normal
Tags: patch

Hi,

Please add my key to the DM keyring.  Attached is the jetring changeset.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/



add-D0EB762865FC5E36
Description: Binary data


signature.asc
Description: PGP signature

Bug#804315: [ralph.amis...@gmail.com: outrageous, thievery]

[Ed Dixon]

John is your reply to mine suggesting that Daniels message should be
shared? If so you have read much more into it than what I said. I think I
must be misunderstanding your point and reading it wrong. I think it may be
in reply to his message or even this whole mess but even so I still
strongly disagree with what you wrote. Can you clarify your point here for
us more?

Thanks,

On Fri, Nov 13, 2015 at 8:46 AM John D. Hendrickson 
wrote:

> absolutely rediculous.  it's a GPL free source open system
>
> your supposed to use it in your SPARE time not your business time.
>
> you are NOT supposed to using it for private development without
> funding.  perhaps if a proffesor, paid for such things, and have chosen
> to do so (ie, GRUB is a good example of that, or "gv" ghost view (orig
> and improved) as well).  otherwise it is strictly about hobby time.
>
> (if used for business your totally assume risk, and the world is full of
> books and information to tell you that)
>
> you could accuse "someone" of intently wasting others time by reverse
> engineered uploads to cause intentional time/investment losses (ie,
> inserting build failures to give others headaches): that's illegal since
> the days of Rome.  and it's not easy to prove (perhaps intently, perhaps
> not).
>
> you have absolutely no right to complain about "others using your
> donated time".  zero, none.
>
>
>  > usting. It is nasty. A bit strange to think that I
> "know" some of those guys.
>
> My interest in Debian pEd Dixon wrote:
> > Be sure to share Daniels story via social media using the buttons on his
> > blog. I hope it wakes up the entire community to what happens when you
> > actually do something right around here! https://t.co/NwWs9AfW87 Thanks,
> >
> > On Mon, Nov 9, 2015 at 2:15 PM Richard Newton  > > wrote:
> >
> > I agree, shame on those responsible. I have been using Debian for
> > almost 15 years and this is the first time I have been ashamed. Add
> > my name to the record "of conscientious objection."
> >
> > RIchard Newton
> >
> > On Mon, Nov 9, 2015 at 11:42 AM, Ralph Amissah
> > > wrote:
> >
> > I post not in anger but sadness, I should not let my voice go
> > uncounted.
> >
> > Attached is my note to Daniel of earlier today, before his
> > posting of
> > "an abrupt end to Debian Live". Debian Live which he said Debian
> > should
> > have (as a Debian developer) in 2006 and went on to deliver,
> rather
> > nicely (with (and without) help).
> >
> > - Forwarded message from Ralph Amissah
> > > -
> >
> > From: Ralph Amissah  > >
> > To: Daniel Baumann
> > Subject: outrageous, thievery
> > Date: Mon, 9 Nov 2015 09:28:44 -0500
> > Message-ID: <20151109142844.GA28261@niu>
> > User-Agent: Mutt/1.5.24 (2015-08-30)
> >
> > Daniel, (already one of the more active Debian Developers then) I
> > remember you telling Debian at Debconf 2006, Mexico about how
> > "we"[1]
> > needed a live-maker within the project. I said then that I
> > thought this
> > one of the most important projects within Debian (I was
> > surprised that
> > there was not more interest and effort offered by others at the
> > time,
> > though there was some, those so keen now did not seem to pay
> > attention
> > then).  Already then it was clear that it would one day be able
> > to and
> > possibly be the preferred way to do a Debian install... as I
> said,
> > important. I saw how you contributed to Debian then, and I know
> > how you
> > have contributed since. Instead of welcoming you and your work,
> > there
> > seems to have been an effort to isolate you.
> >
> > Well clearly others have seen the fruits of your labor as a
> > threat and
> > with envy, and ripe for their plucking!
> >
> > Outrageous! Disgusting. It is nasty. A bit strange to think that
> I
> > "know" some of those guys.
> >
> > My interest in Debian proper, dropped with your earlier
> > treatment, it
> > took away the desire to be a closer part of it. At least that
> > took out
> > much of any idealized notion of the inner workings of it. And
> > there have
> > been other moves since. I continue to be amazed by the politics
> of
> > groups within Debian.  This though has the feel of blatant
> thievery.
> > Chals characterization of a dictatorial coup would seem to be
> most
> > accurate.
> >
> > It has no doubt to do 

Bug#796611: github PR for pkg-ferm

[Andreas Henriksson]

Hello.

For the record, I've posted a PR on github related to this issue
a while ago:

https://github.com/formorer/pkg-ferm/pull/1

Regards,
Andreas Henriksson

Bug#767682: D-I: installer hangs on re-formatting ext4 partition (having grub in the partition boot record).

[Ashish SHUKLA]

Following is a workaround for this problem in preseed environment that worked
for me:

d-i partman/early_command string sed -r -e 
'/^[[:space:]]*mkfs\./s/^([[:space:]]*)(mkfs\.[^[:space:]]+)/\1\2 -F/g' -i 
/lib/partman/commit.d/50format_ext3

HTH
-- 
Ashish SHUKLA

“If a  6600 used paper  tape instead of core  memory, it would  use up
tape at about 30 miles/second.”
   (Grishman, Assembly Language Programming)

Sent from my Emacs


signature.asc
Description: PGP signature

Bug#804110: xserver-xorg-video-nouveau: fresh install debian-8.2.0-amd64, Xfce yields black screen at login

[Sven Joachim]

On 2015-11-13 00:35 +0100, David Christensen wrote:

> On 11/12/2015 02:05 PM, Sven Joachim wrote:
>> Please press 'e' rather than 'c' in the grub
>> menu and edit the line starting with "linux".
>
> Okay:
>
>   linux   /vmlinuz-3.16.0-4-amd64 root=/dev/mapper/sda3_crypt\
>  ro  quiet systemd.unit=multi-user.target
>
>
> Then press Ctrl+x to boot.  I arrive at a text console.  Login as root:
>
> root@i72720qm:~# lsmod | grep ^nouveau
> nouveau  1122419  1
>
>
> So, it appears that the nouveau kernel module is loaded.

This is nice, but not consistent with the result in your original
report.  Can you please send the complete dmesg output?

> Login as unprivileged user.  Start X Windows:
>
> toor@i72720qm:~$ startx
>
>
> I arrive at the Xfce desktop.
>
>
> When I log out, I arrive back at the text console where I left off.
>
>
> So, now I have a work-around (that reminds me of ~10 years ago).
>
>
> I would still like to get the graphical login manager working.

Probably something like this would work (see modules-load.d(5)):

# echo nouveau > /etc/modules-load.d/nouveau.conf

This would hopefully load the nouveau kernel module early enough.
However, I still don't understand why this apparently isn't done by
udev.

Cheers,
   Sven

Bug#800471: lxc: CVE-2015-1335

[Salvatore Bonaccorso]

Hi Antonio,

On Fri, Nov 13, 2015 at 01:48:29PM +0100, Florian Weimer wrote:
> * Antonio Terceiro:
> 
> > On Tue, Sep 29, 2015 at 10:33:27PM +0200, Salvatore Bonaccorso wrote:
> >> Source: lxc
> >> Version: 1:1.0.7-10
> >> Severity: important
> >> Tags: security upstream patch fixed-upstream
> >
> > I intend to upload the attached diff to jessie-security. I am uploading
> > the same fix for unstable shortly.
> 
> Looks good, except for this part:
> 
> diff --git a/debian/gbp.conf b/debian/gbp.conf
> new file mode 100644
> index 000..28f6bb3
> --- /dev/null
> +++ b/debian/gbp.conf
> @@ -0,0 +1,2 @@
> +[DEAFULT]
> +debian-branch = debian/jessie
> 
> I'm not sure if this belongs there, and there seems to be a typo.

Additionally to that, are the patches actually complete?

This lxc update contained regressions initially which resulted in
http://www.ubuntu.com/usn/usn-2753-2/ and
http://www.ubuntu.com/usn/usn-2753-3/

AFAICS (but correct me if I'm wrong, I just only skimmed really
quickly over the proposed debdiff) patches from 2753-2 and 2753-3 are
not included.

Regards,
Salvatore

Bug#804828: fte-docs: rename to ‘fte-doc’

[Ben Finney]

On 13-Nov-2015, Axel Beckert wrote:
> Hi Ben,
> 
> Ben Finney wrote:
> > My understanding is that ‘fte-docs’ is still very new in Debian.
> > Is that correct?
> 
> No. [explanation of ‘fte-docs’ re-appearing in Debian]
> 
> If it would have been a new binary package, I would have agreed. :-)

Thanks for the explanation. I'll leave this bug report open at
severity “wishlist”.

-- 
 \  “I have never made but one prayer to God, a very short one: ‘O |
  `\   Lord, make my enemies ridiculous!’ And God granted it.” |
_o__)—Voltaire |
Ben Finney 


signature.asc
Description: PGP signature

Bug#719695: Prefer symlinks over Alias= for non-matching service names

[Felipe Sateler]

Control: tags -1 upstream fixed-upstream
Control: forwarded -1 https://github.com/systemd/systemd/pull/1515

On Mon, 03 Aug 2015 23:26:41 +0530 Ritesh Raj Sarraf  wrote:
> Package: systemd
> Version: 223-2
> Followup-For: Bug #719695
>
> Hello,
>
> I am hit by the same problem.
>
> So far, we've shipped a SysV init script /etc/init.d/multipath-tools,
> whereas upstream ships the service file as multipathd.service
>
> I haven't read through all the details on this bug report, but I'd like your 
> advise
> on how to proceed. Initially I created an Alias=multipath-tools.service, but 
> that
> did not work. It did not sense the Alias= setting, and instead picked the 
> init script.
>
> I think the manpage should be updated accordingly on whatever the conclusion 
> is.
>
> And looking at this bug report, I'm not sure if this has been concluded.
>

It wasn't. However, just today it was merged upstream a change that
makes it possible to follow static links during enable operation.

This means that for stretch we should recommend using static links,
that is: Add a link shipped in /lib/systemd/system from the alias name
to the unit name.

This change will be part of 228.

Saludos

Bug#726302: nautilus-share: use dh-autoreconf to build package

[Daniel Neis]

Hello,

I've tested the patch attached to this thread and it works.

I've setup an aarch64 qemu with instruction from:
https://wiki.debian.org/Arm64Port#Debootstrap_arm64

Have read about the autoreconf at:
https://wiki.debian.org/Autoreconf

Applied the patch and rebuild the package with instructions from:
https://www.debian.org/doc/manuals/maint-guide/build.en.html

Kind regards,
Daniel

Bug#804882: hwclock: /etc/init.d/hwclock.sh stop does nothing at all

[Marcel]

Hi again,

Commented inline.

You'll find more details concerning this issue.

* Andreas Henriksson (andr...@fatal.se) wrote:
> Hello Marcel!
> 
> Quick reply below...
> 
> On Thu, Nov 12, 2015 at 09:01:49PM -0500, Marcel wrote:
> > Hi Andreas.
> > 
> > Thanks for your quick reply.  I appreciate it.
> > 
> > I reckon that the misuse of init scripts is my responsibility
> > however the service integration isn't perfect yet.  A lot of
> > scripts/packages still use init scripts.  Monit comes immediately
> > to my mind.  It relies heavily on start/stop/restart.
> 
> Any packaged software in Debian which directly invokes an init script
> (ignoring service policy etc.) instead of doing so via invoke-rc.d
> (which is the programmatical variant of the administrative 'service'
> interface) is in conflict with the Debian policy and thus RC-buggy.
> This is because 'policy-rc.d' should be taken into consideration which
> it isn't if the script is invoked directly.

I realize that, but I don't care.  I expect packages to work,  When
they don't, I reconfigure.   Only debian maintainers should care about this.
That is my opinion.

> 
> https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3
> 
> > 
> > And I was in a state of panic.  I know full well how catastrophic
> > the results of setting the clock too far away in time could do on this
> > system.  I couldn't remember the command name 'service' so I relied
> > on what has been working faithfully for years, initd.
> 
> Yes, fortunately the Debian systemd maintainers have LSB hooks in place
> to defer your direct invokation to became a systemctl command instead.
> (FWIW, the service command would also translate into a systemctl command
> when running under systemd.)
> 
> > 
> > I'll complete the transition to service whenever I have spare time.
> > 
> > That being said, I saved the console so you can see each and every
> > command I typed yesterday and the system reaction or absence of:
> 
> Awesome! Thanks.
> Even more awesome would be if you can reproduce the problem while
> hacking the init script to add 'set -x' at the top so we can see
> each and every command being run.

Yes of course.  See the attached file 'stop.txt'.  Strange enough,
'hwclock.sh stop' is reported doing its job with 'set -x' whereas
I know for a fact that it did not without.

> Might also be useful to know your configuration for local/UTC time
> in rtc, eg. /etc/adjtime

shizuma@gt5232h-a3e401d:~$ cat /etc/adjtime
-0.135568 1447433065 0.00
1447433065
LOCAL

> Also knowing your /etc/default/hwclock settings would be helpful.

BADYEAR=no
HWCLOCKACCESS=yes
HWCLOCKPARS=
HCTOSYS_DEVICE=rtc0

> 
> Quick commends below (I'll try to find time to look at this
> with more details in the future).

No emergency.  Daylights savings are ON for all winter.
It would be great if it were fixed for spring though.

> 
> > 
> > shizuma@gt5232h-a3e401d:~$ sudo /etc/init.d/hwclock.sh
> > [ ok ] Usage: hwclock.sh {start|stop|reload|force-reload|show}.
> > [ ok ] start sets kernel (system) clock from hardware (RTC) clock.
> > [ ok ] stop and reload set hardware (RTC) clock from kernel (system) clock.
> 
> ok.
> 
> > shizuma@gt5232h-a3e401d:~$ sudo /etc/init.d/hwclock.sh stop
> > shizuma@gt5232h-a3e401d:~$ date
> > mercredi 11 novembre 2015, 23:26:56 (UTC-0500)
> > shizuma@gt5232h-a3e401d:~$ sudo /etc/init.d/hwclock.sh show
> > jeu 12 nov 2015 00:28:19 EST  -0.084876 secondes
> > shizuma@gt5232h-a3e401d:~$ date
> > mercredi 11 novembre 2015, 23:27:30 (UTC-0500)
> 
> So your system time seems it was 1 day behind your RTC time.

No, it was 1 hour.  There's 1h between 11120028 and 2328,
not 25.

> Some serious time drift right there (unless your system time was
> updated without syncing the RTC earlier somehow).
> 

It's not drift.  It's daylight savings turned on.

And yes, 'system time was updated without syncing the RTC earlier 
somehow':  The system time was updated sunday to compensate for
daylight savings.  It's automatic.  But on shutdown 2 days ago, the
RTC wasn't automatically updated from system time as it should have.  

Upon restart, the system time was updated from the wrong RTC time.

So the system restarted with 1 hr ahead of time, and worse, with 1 day 
ahead of time too.

See excerpt of syslog:

(...)
Nov 11 23:03:26 gt5232h-a3e401d kmotion_hkd1[20621]: signal SIGHUP detected, 
re-reading config file
Nov 11 23:03:26 gt5232h-a3e401d freshclam[987]: Update process terminated
Nov 12 00:14:13 gt5232h-a3e401d rsyslogd: [origin software="rsyslogd" 
swVersion="8.4.2" x-pid="1262" x-info="http://www.rsyslog.com;] start
Nov 12 00:14:13 gt5232h-a3e401d rsyslogd-2307: warning: ~ action is deprecated, 
consider using the 'stop' statement instead [try http://www.rsyslog.co
m/e/2307 ]
(...)

I rebooted at 23:03
The log ends at 11:03 PM on 11/11 and restarts at 12:14 AM on 11/12
You see a 1 hr 11 minutes difference whereas it was really 11 minutes.
It took 11 minutes because a filecheck was triggered.

Bug#804860: Narrowing required additional dependencies

[Clark]

  Installing just kinit and kio with its associated dependencies is 
sufficient to

cure the problem.

Clark

Bug#804670: /etc/init.d/rpcbind restart is racy

[duck]

Control: affects -1 nfs-kernel-server


Coin,

I tried with --retry=0/30/KILL/5 and it seems to work nicely.

Could you please do a fix for stable too?

Regards.

--
Marc Dequènes

Bug#805045: kismet: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 

Package: kismet 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the Dutch translation of kismet debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
=== 

-- 
Groetjes,
Frans

===
http://www.frans-spiesschaert.homenet.org
http://home.base.be/vt6362833/



nl.po.gz
Description: application/gzip


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

Bug#755790: lft: use autotools-dev to fix FTBFS on arm64

[Daniel Neis]

Hello,

I've tested the patch attached to this thread and it works.

I've setup an aarch64 qemu with instruction from:
https://wiki.debian.org/Arm64Port#Debootstrap_arm64

Have read about the autoreconf at:
https://wiki.debian.org/Autoreconf

Downloaded the code, applied the patch and rebuild the package with
instructions from:
https://www.debian.org/doc/manuals/maint-guide/build.en.html

Kind regards,
Daniel

Bug#723990: youtube-dl: python3+ requirement

[Rogério Brito]

Hi, Javier.

On Nov 13 2015, Javier Cantero wrote:
> > The problem is that I don't know how to make it work with both Python 2 or
> > Python 3, while still satisfying the following two points:
> > 
> > * Without creating extra binary packages (and having to go through the NEW
> >   queue of the ftp-masters).
> > 
> > * Without making any use of any hackish, non-readable tricks.  Note that the
> >   package currently has modules that should be usable for any version of
> >   Python that we propose to support.
> > 
> > I would love some help with this.
> 
> There is an easy solution: to make it only a python 3 package, since the
> Debian Python Policy[1] says[2]: "Packages in Debian should use Python 3
> if Python 3 is supported." And also in the same page: "Programs should
> use Python 3, and should not be packaged for Python 2 as well."
> 
> I think that youtube-dl supports python 3.2+ (or at least that says the
> homepage). If it works with python 3, it's the perfect excuse to make
> the transition now rather than wait until year 2020, and you don't need
> to worry about maintaining duplicated packages or anything hackish.

I like your proposal, but I would still like to support Python 2 programs,
if possible---I have one program that helps with downloads from edX.org and
sites based on its code that still support Python 2 or Python 3.

Anyway, I think that changing the dependency to Python 3 is probably the way
to go.  Oh, thanks for the links to the Python Policy. I will have to study
it a bit closer to bring the package more up-to-date with the
best-practices.


Thanks,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#804110: xserver-xorg-video-nouveau: fresh install debian-8.2.0-amd64, Xfce yields black screen at login

[David Christensen]

On 11/13/2015 08:42 AM, Sven Joachim wrote:

Can you please send the complete dmesg output?


Attached.



Probably something like this would work (see modules-load.d(5)):

# echo nouveau > /etc/modules-load.d/nouveau.conf

This would hopefully load the nouveau kernel module early enough.
However, I still don't understand why this apparently isn't done by
udev.


That worked -- now it boots to the graphical login manager.


Anything else?


David



dmesg.out.gz
Description: GNU Zip compressed data

Bug#805043: RM: mate-settings-daemon [hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- RoQA; outdated binaries still depending on gstreamer 0.10

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove the old mate-settings-daemon binaries on [hurd-i386
kfreebsd-amd64 kfreebsd-i386]. These old binaries still depend on
gstreamer 0.10, while the new, fixed releases don't build due to
problems with ALSA not being available on BSD/Hurd.

Cheers,
Moritz

Bug#804905: (no subject)

[Marcin Kulisz]

Hi Mattia,

patch is working perfectly, thx a lot for quick fix.
-- 

|_|0|_|  |
|_|_|0| "Heghlu'Meh QaQ jajVam"  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3


signature.asc
Description: PGP signature

Bug#726511: r-base: ARM regexp hack needs to be extended for arm64

[Daniel Neis]

Hello,

the issue on the r-project bug tracker was closed as fixed and r-base
is now available to apt-get install on aarch64 .
With this, I think we can close this issue =)

Kind regards,
Daniel

Bug#804911: Incorrect chai dependency on chef package in jessie

[Antonio Terceiro]

On Fri, Nov 13, 2015 at 08:39:56AM -0800, Noah Kantrowitz wrote:
> 
> > On Nov 13, 2015, at 3:20 AM, Antonio Terceiro  wrote:
> > 
> > Control: retitle -1 chef: ohai resource broken in Jessie
> > Control: tag -1 + patch pending
> > 
> > Hi, thanks for reporting this.
> > 
> > On Thu, Nov 12, 2015 at 11:51:10AM -0800, Noah Kantrowitz wrote:
> >> Package: chef
> >> Version: 11.12.8-2
> >> 
> >> Chef 11.12.8 clearly states that it depends on Ohai at least 7.0.4
> >> (https://github.com/chef/chef/blob/11.12.8/chef.gemspec#L20). As it
> >> stands, the jessie package depends on Ohai >= 6 and the packaged
> >> version is a 6.x. This results in the ohai resource being
> >> non-functional as it uses an API added in Ohai 7.0.0. Either Chef
> >> needs to be patched to not use this API (Ohai::System#all_packages
> >> with an argument) or the Ohai dependency needs to be corrected.
> > 
> > Would you please test the package from
> > https://people.debian.org/~terceiro/chef-jessie/ and let me know it
> > works for you?
> > 
> > I have applied the attached patch, and tested a basic usage of the ohai
> > resource which worked for me; if you confirm your use case is fixed I
> > will make a stable update with those changes.
> 
> I'm just the messenger here, you'll have to test your patches yourself. I 
> help with
> Chef's IRC user support, and this was reported by an end-user that was 
> confused
> at some community cookbooks not working.

I did test it (as I mentioned); I couldn't know that you were relaying
someone else's issues, since you didn't tell me that.

> You can try running the chai::default recipe as that was the one
> reported to be failing,

I have no idea what chai is, can you please provide a link? A search on
https://supermarket.chef.io/ didn't return anything useful.

> but I'll point out again that you are shipping the wrong version of
> Ohai.

I understood that at the first time you mentioned. Unfortunately that is
not something I can fix at this point for a stable release.

-- 
Antonio Terceiro 


signature.asc
Description: PGP signature

Bug#804110: xserver-xorg-video-nouveau: fresh install debian-8.2.0-amd64, Xfce yields black screen at login

[Sven Joachim]

On 2015-11-13 18:39 +0100, David Christensen wrote:

> On 11/13/2015 08:42 AM, Sven Joachim wrote:
>> Can you please send the complete dmesg output?
>
> Attached.

I see two notable things here:

- There is no sign of the i915 module being loaded, I guess the on-board
  graphics is disabled in the BIOS/UEFI?

- The boot seems to stall for 27 seconds.  That is probably unrelated to
  this bug, but if you want to find out why, systemd-analyze(1) is your
  friend.

>> Probably something like this would work (see modules-load.d(5)):
>>
>> # echo nouveau > /etc/modules-load.d/nouveau.conf
>>
>> This would hopefully load the nouveau kernel module early enough.
>> However, I still don't understand why this apparently isn't done by
>> udev.
>
> That worked -- now it boots to the graphical login manager.
>
>
> Anything else?

No - I don't think I'll be able to solve the problem, but at least you
have an easy workaround.

Cheers,
   Sven

Bug#804886: pdf2djvu: Unusable conversion result

[Jakub Wilk]

* Janusz S. Bień , 2015-11-12, 17:59:
The enclosed file is converted incorrectly, the output is not usable. 
The program was invoked without any parameters (except of course input 
and output files).


This looks like a buggy PDF file to me.

The physical size of the PDF file is just 13pt×16pt (or 4.6mm×5.7mm in 
metric units). pdf2djvu's default resolution is 300dpi, so the resulting 
DjVu size is 54×67 pixels.


You might want to use the --guess-dpi option the get a more legible 
result.


--
Jakub Wilk