Bug#822575: debian regression: no more console output after "switching to mgag200drmfb from simple"

[Harald Dunkel]

On 04/26/2016 04:05 PM, Ben Hutchings wrote:
> 
> I'm guessing that you didn't built the mgag200 driver (CONFIG_DRM_MGA),
> right?
> 

Of course its in, as for the official kernel.

% grep -i mga /boot/config-4.5.2
CONFIG_DRM_MGA=m
CONFIG_DRM_MGAG200=m

Would you suggest to blacklist this module?

Regards
Harri




signature.asc
Description: OpenPGP digital signature

Bug#822754: winetricks: version update needed, most download links broken

[Austin English]

Package: winetricks
Version: 0.0+20151116-1
Severity: important

Dear Maintainer,

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

Microsoft has removed a ton of old service pack downloads (<=XP/2003) from their
servers. Accordingly, many winetricks verbs fail.

In addition, the version in winetricks has a ton of of other URL updates and bug
fixes in the meantime.

The major breakage was fixed in 20160219. 20160425 adds a --self-update feature
that users would find useful, but you may want to patch out. Also note that I
added some manpage fixes after the latest release, that you may want to 
cherry-pick
as well.

I'd obviously prefer 20160425, as that fixes all the current known issues 
upstream :)

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


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

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

Versions of packages winetricks depends on:
ii  cabextract  1.6-1
ii  p7zip   15.09+dfsg-4
ii  unzip   6.0-20
ii  wget1.17.1-1+b1
ii  wine1.8.1-2
ii  wine32  1.8.1-2
ii  zip 3.0-11

Versions of packages winetricks recommends:
ii  gksu   2.0.2-9
ii  sudo   1.8.15-1.1
ii  xdg-utils  1.1.1-1
ii  zenity 3.18.1.1-1

Versions of packages winetricks suggests:
ii  libwine  1.8.1-2

-- no debconf information

Bug#822744: transition: gloox

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 27/04/16 03:59, Vincent Cheng wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> Severity: normal
> 
> Hi,
> 
> I'd like to request a transition slot for src:gloox. This is a relatively 
> small
> transition, with only 3 source packages affected (tested builds against newer
> gloox, currently in experimental, results are as follows):
> 
> licq (FTBFS not related to gloox, #820106, pending autoremoval)
> 0ad (build ok, needs binNMU)
> uwsgi (build ok, needs binNMU)

Go ahead.

Cheers,
Emilio

Bug#822067: courier-mta: init scripts completely broken

[Ondřej Surý]

Just a quick reaction - I am fine with rewriting the scripts using
/etc/init.d/skeleton if it's a better fit.

Or we can simply add a custom:

do_status_override() {
status_of_proc "$DAEMON" "$NAME" -p "$PIDFILE"
}

that would implement the missing things.

And I think I found the most obvious error -> I intended to override
do_start_cmd and do_stop_cmd instead of do_start and do_stop functions
in the init-d-script-courier, and that would fix the missing logging and
probably the error codes as well. 

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

On Wed, Apr 27, 2016, at 08:38, J Mo wrote:
> 
> Most of the problems that I've found so far are actually bugs in 
> init-d-script. The rest are between init-d-script and 
> init-d-script-courier _override() functions not replicating needed 
> functionality.
> 
> 
> 
> Before I started looking into this, I had never heard of 
> /lib/init/init-d-script before.
> 
> The first thing I did was to find out who else was using it in their 
> init scripts. The answer for me turned out to be almost nobody. Of the 
> nine different hosts I looked at, I could find only one other package 
> which used it: apache2's apache-htcacheclean, for cleaning up after 
> mod_cache_disk. And even there it's not really comparable because of the 
> very limited function it performs. The main apache2 init script doesn't 
> use init-d-script.
> 
> And since nobody apparently uses it, it didn't surprise me when I 
> started finding bugs. See bug #822674 for our current most significant 
> issue. Nothing will work until that gets fixed or worked around.
> 
> It does not help that PIDFILE is missing from all of the init scripts, 
> except for courier-authdaemon, where it's wrongly declared as 
> PIDFILE="/run/courier/pid". Thus, init-d-script is looking for the 
> PIDFILES in all the wrong locations. This will have to get fixed too, 
> but won't make a difference because of the above mentioned bug.
> 
> The "exit 0" at the end of init-d-script is probably also a bug as it 
> destroys almost all return codes. I have like five other issues which 
> might get turned into bugs once I've had a second look at it tomorrow.
> 
> 
> 
> Using /etc/init.d/skeleton as a template may have seemed like a 
> reasonable place to start to write a new init script, but I don't know 
> if it's worth working around the issues I've found so far. I'm already 
> using my own init script replacements so things will work.
> 
> The Courier suite, being as weird as it is, also makes it a poor 
> candidate to fit into a per-defined structure like init-d-script
> provides.
> 
> 
> 
> Most of our other issues are that functionality normally expected isn't 
> in the init-d-script-courier _override() funcs. There's no start/stop 
> logging, no stdout, etc. That's all fixable though.
> 
> 
> 
> I will look at this more later in the week and send you some proposed 
> changes. I'm not sure if init-d-script should be ditched or not yet. I 
> like the idea of a uniform init script, but the issues I've found so far 
> explains why nobody is using it.
> 
> 
> 
> 
> On 04/21/2016 02:38 AM, Ondřej Surý wrote:
> > Please read /lib/init/init-d-script (and
> > /usr/lib/courier/init-d-script-courier) first and then come back again.
> >
> 

Bug#822755: kcalc: When launching it nothing happens

[Eric Valette]

Package: kcalc
Version: 4:15.12.1-1
Severity: grave
Justification: renders package unusable

If you launch it, nothing happens. Even launching in konsole
produce no trace at all.

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

Kernel: Linux 4.4.8 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kcalc depends on:
ii  libc6 2.23-0experimental2
ii  libgcc1   1:6.0.1-2
ii  libgmp10  2:6.1.0+dfsg-2
ii  libkf5configcore5 5.19.0-1
ii  libkf5configgui5  5.19.0-1
ii  libkf5configwidgets5  5.19.0-1
ii  libkf5coreaddons5 5.19.0-1
ii  libkf5guiaddons5  5.19.0-1
ii  libkf5i18n5   5.19.0-1
ii  libkf5notifications5  5.19.0-1
ii  libkf5widgetsaddons5  5.19.0-1
ii  libkf5xmlgui5 5.19.0-1
ii  libqt5core5a  5.6.0+dfsg-2
ii  libqt5gui55.6.0+dfsg-2
ii  libqt5widgets55.6.0+dfsg-2
ii  libqt5xml55.6.0+dfsg-2
ii  libstdc++66.0.1-2

kcalc recommends no packages.

kcalc suggests no packages.

-- no debconf information

Bug#822756: workrave: FTBFS: dh_install: Cannot find (any matches for) "usr/lib/indicators3/7/libworkrave.so"

[Chris Lamb]

Source: workrave
Version: 1.10.12-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

workrave fails to build from source in unstable/amd64:

  [..]

  make[6]: Entering directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/win32/src'
  make[6]: Nothing to be done for 'install-exec-am'.
  make[6]: Nothing to be done for 'install-data-am'.
  make[6]: Leaving directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/win32/src'
  make[5]: Leaving directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/win32/src'
  Making install in include
  make[5]: Entering directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/win32/include'
  make[6]: Entering directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/win32/include'
  make[6]: Nothing to be done for 'install-exec-am'.
  make[6]: Nothing to be done for 'install-data-am'.
  make[6]: Leaving directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/win32/include'
  make[5]: Leaving directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/win32/include'
  make[5]: Entering directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/win32'
  make[6]: Entering directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/win32'
  make[6]: Nothing to be done for 'install-exec-am'.
  make[6]: Nothing to be done for 'install-data-am'.
  make[6]: Leaving directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/win32'
  make[5]: Leaving directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/win32'
  make[4]: Leaving directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/win32'
  Making install in common
  make[4]: Entering directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/common'
  Making install in src
  make[5]: Entering directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/common/src'
  make[6]: Entering directory 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/frontend/applets/common/src'
  make[6]: Nothing to be done for 'install-exec-am'.
   /bin/mkdir -p 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/debian/tmp/usr/share/gir-1.0'
   /usr/bin/install -c -m 644 Workrave-1.0.gir 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/debian/tmp/usr/share/gir-1.0'
   /bin/mkdir -p 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/debian/tmp/usr/lib/x86_64-linux-gnu/girepository-1.0'
   /usr/bin/install -c -m 644 Workrave-1.0.typelib 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/debian/tmp/usr/lib/x86_64-linux-gnu/girepository-1.0'
   /bin/mkdir -p 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/debian/tmp/usr/lib/x86_64-linux-gnu'
   /bin/bash ../../../../libtool   --mode=install /usr/bin/install -c   
libworkrave-gtk2-private-1.0.la 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/debian/tmp/usr/lib/x86_64-linux-gnu'
  libtool: install: /usr/bin/install -c 
.libs/libworkrave-gtk2-private-1.0.so.0.0.0 
/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/debian/tmp/usr/lib/x86_64-linux-gnu/libworkrave-gtk2-private-1.0.so.0.0.0
  libtool: install: (cd 
/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/debian/tmp/usr/lib/x86_64-linux-gnu
 && { ln -s -f libworkrave-gtk2-private-1.0.so.0.0.0 
libworkrave-gtk2-private-1.0.so.0 || { rm -f libworkrave-gtk2-private-1.0.so.0 
&& ln -s libworkrave-gtk2-private-1.0.so.0.0.0 
libworkrave-gtk2-private-1.0.so.0; }; })
  libtool: install: (cd 
/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/debian/tmp/usr/lib/x86_64-linux-gnu
 && { ln -s -f libworkrave-gtk2-private-1.0.so.0.0.0 
libworkrave-gtk2-private-1.0.so || { rm -f libworkrave-gtk2-private-1.0.so && 
ln -s libworkrave-gtk2-private-1.0.so.0.0.0 libworkrave-gtk2-private-1.0.so; }; 
})
  libtool: install: /usr/bin/install -c .libs/libworkrave-gtk2-private-1.0.lai 
/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave/workrave-1.10.12/debian/tmp/usr/lib/x86_64-linux-gnu/libworkrave-gtk2-private-1.0.la
  libtool: warning: remember to run 'libtool --finish /usr/lib/x86_64-linux-gnu'
   /bin/mkdir -p 
'/home/lamby/temp/cdt.20160427081151.xZiQkHX19Z.workrave

Bug#819650: mirror submission for mirror.ba

[Emir Beganovic]

Hi Donald,

1) Can you point me in right direction for clarifying that? debian.mirror.ba
has an A record pointing to our server.

~ dig debian.mirror.ba
> ; <<>> DiG 9.8.3-P1 <<>> debian.mirror.ba
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58440
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> ;; QUESTION SECTION:
> ;debian.mirror.ba. IN A
> ;; ANSWER SECTION:
> debian.mirror.ba. 90 IN A 80.65.85.94


2) I've downloaded and set up ftpsync. The files should be all up-to-date
now.
3) Rsync is fixed now.
4) I've set the EXTENDEDTRACE="full" in ftpsync.conf but it still didn't
generate anything more. http://debian.mirror.ba/project/trace/mirror.ba
Can you give me a hand with this?

On Sun, Apr 24, 2016 at 8:16 PM, Donald Norwood 
wrote:

> Hi Emir,
>
> My apologies I did not see your email response.
>
> 1) Alias issues:
>
> The alias debian.mirror.ba points to mirror.ba.
> The mirror.ba page then links to debian.mirror.ba
>
> 2) /debian-cd/ not current:
>
> The /debian-cd/ directory is not current, your mirror has 8.2.0 and
> 8.2.0-live and not 8.4. Which your upstream is providing. Please check
> your configuration. Are you using the ftpsync script[1] we suggest?
>
> 3) Rsync does not work:
>
> rsync rsync://mirror.ba
> rsync: failed to connect to mirror.ba (80.65.85.94): Connection refused
> (111)
>
> Please check this configuration.
>
> > > Also the rsync works now. How do you check if the mirror has been
> updated?
> > > I can see it has, but you say it hasn't :)
>
> I look at the /project/trace/ directory which holds the files that the
> mirror script generates. The trace file tells us which upstream mirror
> you are using, the time your mirror updated, and what the mirror is
> carrying. Your tracefile only provides the date but a longer tracefile
> (option EXTENDEDTRACE="full" in the ftpsync.conf file) would provide
> information such as:
>
> Sun Apr 24 16:17:57 UTC 2016
> Date: Sun, 24 Apr 2016 16:17:57 +
> Date-Started: Sun, 24 Apr 2016 16:04:59 +
> Archive serial: 2016042403
> Used ftpsync version: 20160306
> Running on host: intrepid.portalus.net
> Architectures: GUESSED:{ source amd64 i386}
> Upstream-mirror: ftp.halifax.rwth-aachen.de
> SSL: false
> Total bytes received in rsync: 365271190
> Total time spent in stage1 rsync: 417
> Total time spent in stage2 rsync: 359
> Total time spent in rsync: 776
> Average rate: 470710 B/s
>
> Hope that helps. :)
>
> If you have further questions please reach out I'll do my best to walk
> you through the process.
>
>
> [1]ftp://ftp.us.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz
> Best regards,
>
> Donald Norwood
> -Debian Mirrors Team
>
>
> On Tue, 12 Apr 2016 08:14:48 + Emir Beganovic
>  wrote:
> > Hi,
> >
> > Any news on this?
> >
> > Thanks
> >
> > On Thu, Apr 7, 2016 at 1:55 AM Emir Beganovic 
> > wrote:
> >
> > > Hi Donald,
> > >
> > > I did the changes as you said.
> > >
> > > I've removed /debian and left only the /debian-cd.
> > >
> > > Also the rsync works now. How do you check if the mirror has been
> updated?
> > > I can see it has, but you say it hasn't :)
> > >
> > > I was using debian.sil.at but it seems old (2 days at least). I've
> > > switched to LeaseWeb's mirror (mirror.de.leaseweb.net) and updated the
> > > mirror.
> > >
> > > Hope it looks good now!
> > >
> > > Regards
> > >
> > >
> > > On Tue, Apr 5, 2016 at 10:36 PM Donald Norwood 
> > > wrote:
> > >
> > >> Hi Emir,
> > >>
> > >> Do you change the mirror structure? I swear I accessed this
> differently
> > >> yesterday.
> > >>
> > >> The alias listed: debian.mirror.ba no longer works. It does not have
> to
> > >> be included and is only a minor fix.
> > >>
> > >> The /debian-cd/ directory has not updated yet. Please check your
> > >> upstream provider if you are syncing and it has not updated.
> > >>
> > >> The rsync mechanism fails:
> > >> rsync rsync://mirror.ba/debian-cd
> > >> @ERROR: chroot failed
> > >>
> > >> It would be ideal to remove the /debian/ directory to avoid user
> > >> confusion as it appears on your http and ftp listings.
> > >>
> > >> Best regards,
> > >>
> > >> Donald Norwood
> > >> -Debian Mirrors Team
> > >>
> > >>
> > >>
> > >> On Tue, 05 Apr 2016 11:59:58 + Emir Beganovic
> > >>  wrote:
> > >> > Hi Donald,
> > >> >
> > >> > Our application might have been mistaken a little bit - we're
> applying
>
>

Bug#822668: Processed: cloning 822386, reassign -1 to dh-golang ..., severity of -1 is important

[Michael Stapelberg]

Can you please explain why dh-golang can’t be made to figure out build
dependencies in this particular case?

On Tue, Apr 26, 2016 at 11:56 AM, Michael Hudson-Doyle <
michael.hud...@canonical.com> wrote:

> On 26 April 2016 at 21:36, Ondřej Surý  wrote:
> > I am fine to do whatever you suggest, so just to make it right, I
> > should:
> >
> > 1. remove dh-golang from Build-Depends
>
> I guess this is not strictly necessary...
>
> > 2. remove --with=golang from dh invocation
>
> But once you've done this, you can and probably should do 1)
>
> > 3. set 'misc:Built-Using=golang-github-abh-geoip-dev' by hand when on
> > amd64
>
> Yes. Unfortunately, as far as I know generating proper Built-Using
> headers is more awkward than it should be. I think you want to do
> something like:
>
>  dpkg-query --showformat '${source:Package} (= ${source:Version}), '
> --show golang-github-abh-geoip-dev >> debian/knot-resolver.substvars
>
> (-buildmode=c-shared is supported on more architectures in Go 1.6, but
> that's an entirely different thing :-)
>
> Cheers,
> mwh
>
> > And that's it?
> >
> > Cheers,
> > --
> > Ondřej Surý 
> > Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
> >
> > On Tue, Apr 26, 2016, at 11:29, Michael Hudson-Doyle wrote:
> >> Hmm, that package just isn't going to work with the new way of
> >> computing Built-Using in dh-golang. I don't want to change it back,
> >> because it most ways the new way is better. Not sure what to suggest,
> >> as there is only one golang-* build-dependency, maybe just do that by
> >> hand?
> >>
> >> On 26 April 2016 at 21:12, Debian Bug Tracking System
> >>  wrote:
> >> > Processing commands for cont...@bugs.debian.org:
> >> >
> >> >> clone 822386 -1
> >> > Bug #822386 [knot-resolver] knot-resolver: FTBFS: can't load package:
> package .: no buildable Go source files
> >> > Bug 822386 cloned as bug 822668
> >> >> reassign -1 dh-golang
> >> > Bug #822668 [knot-resolver] knot-resolver: FTBFS: can't load package:
> package .: no buildable Go source files
> >> > Bug reassigned from package 'knot-resolver' to 'dh-golang'.
> >> > No longer marked as found in versions
> knot-resolver/1.0.0~beta3-31-g79a8440-1.
> >> > Ignoring request to alter fixed versions of bug #822668 to the same
> values previously set
> >> >> retitle -1 dh-golang: makes packages FTBFS with 'no buildable Go
> source files'
> >> > Bug #822668 [dh-golang] knot-resolver: FTBFS: can't load package:
> package .: no buildable Go source files
> >> > Changed Bug title to 'dh-golang: makes packages FTBFS with 'no
> buildable Go source files'' from 'knot-resolver: FTBFS: can't load package:
> package .: no buildable Go source files'.
> >> >> severity -1 important
> >> > Bug #822668 [dh-golang] dh-golang: makes packages FTBFS with 'no
> buildable Go source files'
> >> > Severity set to 'important' from 'serious'
> >> >> thanks
> >> > Stopping processing here.
> >> >
> >> > Please contact me if you need assistance.
> >> > --
> >> > 822386: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822386
> >> > 822668: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822668
> >> > Debian Bug Tracking System
> >> > Contact ow...@bugs.debian.org with problems
> >> >
>



-- 
Best regards,
Michael

Bug#720386: aptitude: Upgrade marks newly installed packages as manually installed

[Vincent Lefevre]

On 2016-04-26 23:47:13 +0100, Manuel A. Fernandez Montecelo wrote:
> Many of these problems were fixed in releases of the 0.7 series; I
> suppose that this was one of those cases.

Note that I can at least notice a related issue with aptitude 0.7.2-1
or later: libgnomevfs2-0 was automatically installed by the installer,
then I manually installed aptitude 0.7.2-1 (i.e. this was the first
version installed), and I can notice now that libgnomevfs2-0 is
marked as manually installed (though I have never forced its manual
installation). It had only been upgraded by aptitude 0.7.5
(libgnomevfs2-0:amd64 1:2.24.4-6.1 -> 1:2.24.4-6.1+b1).

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

Bug#822696: Package: amd64-microcode, new version makes the system very slow

[Anand Sivaram]

Henrique,

Thanks a lot for your prompt reply.

I installed the latest (3.20160316.1) and now the problem is not seen.
To confirm, I switched a couple of times between 2.20160316.1 and
3.20160316.1 both amd64/i386, rebooted after each time.  I am not seeing
the problem.

There might have been some issue during the initrd of the original time
when I saw the problem.

As, I could not reproduce, please close the bug.

Thanks and Regards

Anand



On 26 April 2016 at 22:51, Henrique de Moraes Holschuh 
wrote:

> On Tue, Apr 26, 2016, at 14:09, Anand Sivaram wrote:
>
> Package: amd64-microcode
> Version: 3.20160316.1
>
> CPU (Processor): AMD Athlon(tm) 5350 APU with Radeon(tm) R3
> Motherboard: Gigabyte GA-AM1M-S2H
>
> I am using Debian Unstable and did a dist-upgrade and amd64-microcode
> got upgraded to 3.20160316.1 from 2.20160316.1
>
> From that time, I am seeing my disk access becoming too slow.
> My SSD used to give "Timing buffered disk reads" of around 400 MB/sec
> before and it got reduced to 30 MB/sec with this newer microcode.
>
>
> I downgraded my current microcode and it started working again.
>
> I could provide any other information to debug this problem.
>
>
> I need the full kernel boot log with both the new, and the old microcode,
> please.
>
> You can get it either from /var/log/dmesg (sysvinit), or using journalctl
> -k (systemd).
>
> I also need the output of /proc/cpuinfo  (on both microcodes, please).
>
> --
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique de Moraes Holschuh 
>
>

Bug#822757: roc-rospack: FTBFS on hurd-i386

[Svante Signell]

Source: ros-rospack
Version: 2.2.5-3
Severity: important
Tags: patch
Usertags: hurd
User: debian-h...@lists.debian.org

Hello,

Currently ros-rospack FTBFS on GNU/Hurd due to usage of PATH_MAX, which is not
defined. The attached patch fixes this for all UNIX cases by dynamically
allocating and de-allocating the needed strings. The patch works fine for UNIX,
but has not been tested if the WIN32 or MINGW32 versions are affected. In case
of any doubts about the patch, please forward this patch to the upstream
authors, so I can communicate directly with them.

Thanks!
Index: ros-rospack-2.2.5/src/rospack.cpp
===
--- ros-rospack-2.2.5.orig/src/rospack.cpp
+++ ros-rospack-2.2.5/src/rospack.cpp
@@ -2011,11 +2011,14 @@ Rosstackage::writeCache()
   }
   else
   {
-char tmp_cache_dir[PATH_MAX];
-char tmp_cache_path[PATH_MAX];
-strncpy(tmp_cache_dir, cache_path.c_str(), sizeof(tmp_cache_dir));
+int len = cache_path.size() + 1;
+char *tmp_cache_dir = (char *)malloc(len);
+strncpy(tmp_cache_dir, cache_path.c_str(), len);
+// make sure tmp_cache_dir is NULL terminated
+tmp_cache_dir[len - 1] = '\0';
 #if defined(_MSC_VER)
 // No dirname on Windows; use _splitpath_s instead
+char tmp_cache_path[PATH_MAX];
 char drive[_MAX_DRIVE], dir[_MAX_DIR], fname[_MAX_FNAME], ext[_MAX_EXT];
 _splitpath_s(tmp_cache_dir, drive, _MAX_DRIVE, dir, _MAX_DIR, fname, _MAX_FNAME,
  ext, _MAX_EXT);
@@ -2023,11 +2026,18 @@ Rosstackage::writeCache()
 _makepath_s(full_dir, _MAX_DRIVE + _MAX_DIR, drive, dir, NULL, NULL);
 snprintf(tmp_cache_path, sizeof(tmp_cache_path), "%s\\.rospack_cache.XX", full_dir);
 #elif defined(__MINGW32__)
+char tmp_cache_path[PATH_MAX];
 char* temp_name = tempnam(dirname(tmp_cache_dir),".rospack_cache.");
 snprintf(tmp_cache_path, sizeof(tmp_cache_path), temp_name);
 delete temp_name;
 #else
-snprintf(tmp_cache_path, sizeof(tmp_cache_path), "%s/.rospack_cache.XX", dirname(tmp_cache_dir));
+char *tmp_cache_path = NULL;
+char *temp_dirname = strdup(dirname(tmp_cache_dir));
+free(tmp_cache_dir);
+len = strlen(temp_dirname) + 22 + 1;
+tmp_cache_path = (char *)malloc(len);
+snprintf(tmp_cache_path, len, "%s/.rospack_cache.XX", temp_dirname);
+free(temp_dirname);
 #endif
 #if defined(__MINGW32__)
 // There is no equivalent of mkstemp or _mktemp_s on mingw, so we resort to a slightly problematic
@@ -2085,6 +2095,9 @@ Rosstackage::writeCache()
 }
   }
 }
+#if !defined(_MSC_VER) && !defined(__MINGW32__) && !defined(WIN32)
+		 free(tmp_cache_path);
+#endif
   }
 }
 

Bug#822668: Processed: cloning 822386, reassign -1 to dh-golang ..., severity of -1 is important

[Michael Hudson-Doyle]

On 27 April 2016 at 19:22, Michael Stapelberg  wrote:
> Can you please explain why dh-golang can’t be made to figure out build
> dependencies in this particular case?

Because nothing in the packaging tells dh-golang anything about the Go
bits -- it doesn't set DH_GOPKG or Xs-Go-Import-Path or use the golang
dh buildsystem. I guess we could put back the
built-using-from-Build-Depends code and use both that *and* the go
list-using code I added...

Cheers,
mwh

> On Tue, Apr 26, 2016 at 11:56 AM, Michael Hudson-Doyle
>  wrote:
>>
>> On 26 April 2016 at 21:36, Ondřej Surý  wrote:
>> > I am fine to do whatever you suggest, so just to make it right, I
>> > should:
>> >
>> > 1. remove dh-golang from Build-Depends
>>
>> I guess this is not strictly necessary...
>>
>> > 2. remove --with=golang from dh invocation
>>
>> But once you've done this, you can and probably should do 1)
>>
>> > 3. set 'misc:Built-Using=golang-github-abh-geoip-dev' by hand when on
>> > amd64
>>
>> Yes. Unfortunately, as far as I know generating proper Built-Using
>> headers is more awkward than it should be. I think you want to do
>> something like:
>>
>>  dpkg-query --showformat '${source:Package} (= ${source:Version}), '
>> --show golang-github-abh-geoip-dev >> debian/knot-resolver.substvars
>>
>> (-buildmode=c-shared is supported on more architectures in Go 1.6, but
>> that's an entirely different thing :-)
>>
>> Cheers,
>> mwh
>>
>> > And that's it?
>> >
>> > Cheers,
>> > --
>> > Ondřej Surý 
>> > Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
>> >
>> > On Tue, Apr 26, 2016, at 11:29, Michael Hudson-Doyle wrote:
>> >> Hmm, that package just isn't going to work with the new way of
>> >> computing Built-Using in dh-golang. I don't want to change it back,
>> >> because it most ways the new way is better. Not sure what to suggest,
>> >> as there is only one golang-* build-dependency, maybe just do that by
>> >> hand?
>> >>
>> >> On 26 April 2016 at 21:12, Debian Bug Tracking System
>> >>  wrote:
>> >> > Processing commands for cont...@bugs.debian.org:
>> >> >
>> >> >> clone 822386 -1
>> >> > Bug #822386 [knot-resolver] knot-resolver: FTBFS: can't load package:
>> >> > package .: no buildable Go source files
>> >> > Bug 822386 cloned as bug 822668
>> >> >> reassign -1 dh-golang
>> >> > Bug #822668 [knot-resolver] knot-resolver: FTBFS: can't load package:
>> >> > package .: no buildable Go source files
>> >> > Bug reassigned from package 'knot-resolver' to 'dh-golang'.
>> >> > No longer marked as found in versions
>> >> > knot-resolver/1.0.0~beta3-31-g79a8440-1.
>> >> > Ignoring request to alter fixed versions of bug #822668 to the same
>> >> > values previously set
>> >> >> retitle -1 dh-golang: makes packages FTBFS with 'no buildable Go
>> >> >> source files'
>> >> > Bug #822668 [dh-golang] knot-resolver: FTBFS: can't load package:
>> >> > package .: no buildable Go source files
>> >> > Changed Bug title to 'dh-golang: makes packages FTBFS with 'no
>> >> > buildable Go source files'' from 'knot-resolver: FTBFS: can't load 
>> >> > package:
>> >> > package .: no buildable Go source files'.
>> >> >> severity -1 important
>> >> > Bug #822668 [dh-golang] dh-golang: makes packages FTBFS with 'no
>> >> > buildable Go source files'
>> >> > Severity set to 'important' from 'serious'
>> >> >> thanks
>> >> > Stopping processing here.
>> >> >
>> >> > Please contact me if you need assistance.
>> >> > --
>> >> > 822386: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822386
>> >> > 822668: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822668
>> >> > Debian Bug Tracking System
>> >> > Contact ow...@bugs.debian.org with problems
>> >> >
>
>
>
>
> --
> Best regards,
> Michael

Bug#822734: Fwd: linux-grsec for desktop computers - paxd.conf necessary

[Yves-Alexis Perez]

On mar., 2016-04-26 at 21:52 +, Amarildo Júnior wrote:
> Package: linux-grsec
> 
> 
> I noticed I need to manually add Pax flags to binaries such as sddm,
> sddm-greeter, iceweasel, synaptic, etc, in order to have a funcional
> Desktop with Debian and the GRSec Kernel.
> 
> In order to make things more friendly, I suggest that the developer(s) add
> a file called "paxd.conf" in which many binaries are listed. With this
> file, the desktop is ready to use with most programs already listed.
> 
> This file automatically gets installed in Arch Linux, and here are it's
> contents:

Hi,

I don't think it should be shipped in the linux-grsec image package. Please
reassign to the relevant package (paxctld?)

Regards,
-- 
Yves-Alexis



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

Bug#822474: mira: FTBFS: error: 'accumulate' is not a member of 'std'

[Michael Crusoe]

Thank you Martin for your report. I've contacted upstream who has already
fixed the issue in a soon to be released new version.

Bug#804139: bumblebee: after recent xorg + nvidia updates in sid, "Cannot access secondary GPU - error"

[ø]

> Hi,
> 
> I actually found that it works for me with a rootless Xorg, but the
> legacy wrapper breaks it.
> 
> Do you have xserver-xorg-legacy installed?
> 
> Kind regards,
> Luca Boccassi

Yes I had. I installed it when after upgrading to rootless Xorg on the
firt time optirun ceased to work.

Great news is after removing it, it works again! Oh my God! I've been
months with this, I never thought on uninstalling legacy xorg again.

Many many thanks.

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

Bug#794562: 0ad: Test 0ad with new version of nvidia-texture-tools

[Pedretti Fabio]

Is this still needed? IIRC nvtt from git master was too unstable and there
is no plan to update debian to it. So this could be closed.

Bug#822758: network-manager-gnome: nm-applet crashes with low WiFi Signal

[Don Jajo]

Package: network-manager-gnome
Version: 1.1.93-1
Severity: normal

Dear Maintainer,


At school with my School WiFi which is very low at my location, nm-applet
crashes with this error after sometime, because of low signal

GLib:ERROR:/build/glib2.0-2CrUwg/glib2.0-2.48.0/./glib/gvarianttypeinfo.c:163:g_variant_type_info_check:
assertion failed: (info->alignment == 0 || info->alignment == 1 ||
info->alignment == 3 || info->alignment == 7)




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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-x11 1.10.8-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  gnome-icon-theme 3.12.0-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-7
ii  libcairo21.14.6-1+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.0-1
ii  libgtk-3-0   3.18.9-1
ii  libmm-glib0  1.4.14-1
ii  libnm0   1.1.94-1
ii  libnma0  1.1.93-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libsecret-1-00.18.3-1
ii  network-manager  1.1.94-1
ii  policykit-1-gnome0.105-2

Versions of packages network-manager-gnome recommends:
ii  gnome-keyring   3.18.3-1
ii  gnome-shell [notification-daemon]   3.18.1-1
ii  iso-codes   3.67-1
ii  mobile-broadband-provider-info  20140317-1
ii  plasma-widgets-workspace [notification-daemon]  4:4.11.13-2
ii  plasma-workspace [notification-daemon]  4:5.4.3-2
ii  xfce4-notifyd [notification-daemon] 0.2.4-3+b1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

Bug#822751: [pkg-golang-devel] Bug#822751: Lintian fixes for golang 1.6

[Hilko Bengen]

* Tianon Gravi:

> On 26 April 2016 at 22:50, Potter, Tim (HPE Linux Support)
>  wrote:
>> Hi there. Here is a patch to remove various Lintian errors that have
>> popped up when
>> building Golang 1.6.1 under Jessie. I'm not sure whether these
>> warnings are new,
>> for Go 1.6 or whether they are due to a Lintian upgrade.
>
> Any particular reason to add these as explicit overrides other than to
> quiet lintian?  They are legitimate issues, and they aren't "FTP
> Master Rejects" issues (lintian --ftp-master-rejects), 

"binary-from-other-architecture" is irrelevant for test data, so the
override is correct. (How else would one test an ELF parser?) I'd add a
comment explaining the override, though.

"source-is-missing" is wrong for
src/debug/elf/testdata/go-relocation-test* because all have been
generated from hello.c, using different toolchains.

src/runtime/race/README explains hso race_*.syso have been generated, so
perhaps the corresponding sources ought to be added as a patch.

Cheers
-Hilko

Bug#822759: torbrowser-launcher: provide alternatives for x-www-browser and gnome-www-browser

[Santiago Ruano Rincón]

Package: torbrowser-launcher
Version: 0.2.4-2
Severity: wishlist
Tags: patch

Attached a patch to manage torbrowser-launcher as alternative for
x-www-browser and gnome-www-browser. This will be more useful once
821093 get closed though.

Cheers,

Santiago
From 8abde7a42df40f2716280c49ed649907a6782552 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Santiago=20Ruano=20Rinc=C3=B3n?= 
Date: Wed, 27 Apr 2016 10:05:56 +0200
Subject: [PATCH] postinst, prerm: manage torbrowser-launcher as alternative
 for x-www-browser and gnome-www-browser (update-alternatives)

---
 debian/torbrowser-launcher.postinst | 15 +++
 debian/torbrowser-launcher.prerm| 15 +++
 2 files changed, 30 insertions(+)
 create mode 100644 debian/torbrowser-launcher.postinst
 create mode 100644 debian/torbrowser-launcher.prerm

diff --git a/debian/torbrowser-launcher.postinst b/debian/torbrowser-launcher.postinst
new file mode 100644
index 000..d0f7c1c
--- /dev/null
+++ b/debian/torbrowser-launcher.postinst
@@ -0,0 +1,15 @@
+#! /bin/sh
+
+set -e
+
+# dh_installdeb will replace this with shell code automatically
+# generated by other debhelper scripts.
+
+#DEBHELPER#
+
+if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] ; then
+update-alternatives --install /usr/bin/x-www-browser \
+x-www-browser /usr/bin/torbrowser-launcher 40
+update-alternatives --install /usr/bin/gnome-www-browser \
+gnome-www-browser /usr/bin/torbrowser-launcher 40
+fi
diff --git a/debian/torbrowser-launcher.prerm b/debian/torbrowser-launcher.prerm
new file mode 100644
index 000..68e162f
--- /dev/null
+++ b/debian/torbrowser-launcher.prerm
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+set -e
+
+# dh_installdeb will replace this with shell code automatically
+# generated by other debhelper scripts.
+
+#DEBHELPER#
+
+if [ "$1" = "remove" ] || [ "$1" = "disappear" ]; then
+update-alternatives --remove x-www-browser /usr/bin/torbrowser-launcher
+update-alternatives --remove gnome-www-browser /usr/bin/torbrowser-launcher
+fi
+
+
-- 
2.8.1



signature.asc
Description: PGP signature

Bug#822760: icedtea-8-plugin: Java applet loads but control buttons do not work

[Vince]

Package: icedtea-8-plugin
Version: 1.6.2-3
Severity: important

Dear Maintainer,

 

   * What led up to the situation? After most recent upgrade (apt-get 
dist-upgrade), icedtea was removed.
 When I reinstalled it, the applet would load but the control buttons would not 
work. Eg http://ssd.jpl.nasa.gov/sbdb.cgi?sstr=2015%20XE352;orb=1.
 Also, none of the objects in the applet are moving. 

   * What exactly did you do (or not do) that was effective (or
 ineffective)? Pressed various control buttons which had no effect. Eg, 
could not zoom in or out.
   * What was the outcome of this action? It had no effect on the applet. Eg, 
selecting or deselecting the date option has no effect.
 Zoom in or out did not work, planets/asteroids not orbiting.
   * What outcome did you expect instead? For the control buttons to control 
the applet and to see the planets/asteroids orbiting.




-- System Information:
Distributor ID: Sparky
Description:SparkyLinux
Release:4
Codename:   Tyche
Architecture: x86_64

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

Versions of packages icedtea-8-plugin depends on:
ii  icedtea-netx   1.6.2-3
ii  libc6  2.22-6
ii  libgcc11:5.3.1-14
ii  libglib2.0-0   2.48.0-1
ii  libstdc++6 5.3.1-14
ii  openjdk-8-jre  8u77-b03-3+b1

icedtea-8-plugin recommends no packages.

icedtea-8-plugin suggests no packages.

-- no debconf information

Bug#822316: openvrml: diff for NMU version 0.18.9-7.1

[Tobias Frost]

Source: openvrml
Followup-For: Bug #822316

After the last NMU built fine on all needed archs,
I rescheduled this NMU to 0-day


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

Kernel: Linux 4.3.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#822474: mira: FTBFS: error: 'accumulate' is not a member of 'std'

[Andreas Tille]

On Wed, Apr 27, 2016 at 09:53:57AM +0200, Michael Crusoe wrote:
> Thank you Martin for your report. I've contacted upstream who has already
> fixed the issue in a soon to be released new version.

Thanks for contacting upstream which was on my todo list after the
simple fix.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#822751: [pkg-golang-devel] Bug#822751: Bug#822751: Lintian fixes for golang 1.6

[Michael Hudson-Doyle]

On 27 April 2016 at 20:13, Hilko Bengen  wrote:

> src/runtime/race/README explains hso race_*.syso have been generated, so
> perhaps the corresponding sources ought to be added as a patch.

I have a more comprehensive fix for this one in Ubuntu:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807455

Cheers,
mwh

Bug#822263: cups printing from 2 recently patched systems stops with incomplete spooling; printer works fine with Windows

[Brian Potkin]

tags 822263 - moreinfo
thanks



On Tue 26 Apr 2016 at 10:39:31 -0700, Dave Martin wrote:

> I'm not sure if this will help at all, but I re-tested cups printing on my
> netbook (wheezy, cups 1.5.2) to again make sure the print server and printer
> are working properly.  (and just to clarify, this netbook is a 3rd machine,
> not to be confused with the other 2 machines which both suffer the
> referenced printing problems).  I printed 2 cups test pages, a simple text

[...Snip...]

It does help. Taken with the information in your previous mail and the lack of
any obvious misbehaviour shown in the cups error logs, it could be we are
looking at something similar to Ubuntu bug #213081 and Debian bug #478062.

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/213081

and

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

The advice offered there is:

  1. Power-off the printer to totally clear the corrupt job.
  2. Clear the printer spool queue ('cancel -a -x').
  3. Power-on the printer
  4. Do '/sbin/sysctl -n net.ipv4.tcp_frto' and confirm the current
 value is 2.
  5. 'sysctl -w net.ipv4.tcp_frto=0' (as root).

If it works

  net.ipv4.tcp_frto=0

is put in /etc/sysctl.conf so that the change survives rebooting.

Regards,

Brian.

Bug#822689: [fonts-cantarell] Incorrect widths for some accented characters

[Jean Bréfort]

Looks like an upgrade to cantarell-0.0.24 would fix the issue.

Regards,
J. Brefort

Bug#822761: xfdesktop4: Cannot select images from most folders for desktop

[Vince]

Package: xfdesktop4
Version: 4.12.3-2
Severity: normal

Dear Maintainer,



   * What led up to the situation? When I try to select a photo/image for my 
desktop, the folder with the image/s appears, but the images are 
"greyed out". That is, if I click on the image, it will not appear on my 
desktop. 
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I was able to partially solve the problem by adding the 
folder with the desired image/photo to my Thunar file manager bookmarks.
   * What was the outcome of this action? I could then select images in that 
folder for my desktop.
   * What outcome did you expect instead? To be able select images/photos for 
my desktop from any folder regardless of whether or not it is 
bookmarked in thunar.




-- System Information:
Distributor ID: Sparky
Description:SparkyLinux
Release:4
Codename:   Tyche
Architecture: x86_64

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

Versions of packages xfdesktop4 depends on:
ii  exo-utils0.10.7-1
ii  libc62.22-6
ii  libcairo21.14.6-1+b1
ii  libdbus-1-3  1.10.8-1
ii  libdbus-glib-1-2 0.106-1
ii  libexo-1-0   0.10.7-1
ii  libgarcon-1-00.4.0-2
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.0-1
ii  libgtk2.0-0  2.24.30-1.1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libthunarx-2-0   1.6.10-2
ii  libwnck222.30.7-5
ii  libx11-6 2:1.6.3-1
ii  libxfce4ui-1-0   4.12.1-2
ii  libxfce4util74.12.1-2
ii  libxfconf-0-24.12.0-2+b1
ii  xfdesktop4-data  4.12.3-2

Versions of packages xfdesktop4 recommends:
ii  dbus-x11 1.10.8-1
ii  librsvg2-common  2.40.15-1
pn  tumbler  
ii  xdg-user-dirs0.15-2

Versions of packages xfdesktop4 suggests:
ii  menu  2.1.47

-- no debconf information

Bug#822682: libharfbuzz0b: breaks display of ê/ô/û with fonts-cantarell

[Raphael Hertzog]

Control: clone -1 -2
Control: reassign -2 fonts-cantarell 0.0.21-1
Control: retitle -2 fonts-cantarell: some accented characters have zero-width
Control: forwarded -2 https://bugzilla.gnome.org/show_bug.cgi?id=762386
Control: tag -2 + patch fixed-upstream

On Tue, 26 Apr 2016, Raphaël Hertzog wrote:
> With this version of harfbuzz and fonts-cantarell 0.0.21-1 I get
> incorrectly formatted accents in labels in GTK-3 apps at least.

So this is effectively a bug in fonts-cantarell which is fixed in
versions >= 0.0.23. So we need to add a breaks in libharfbuzz on a fixed
version. Unfortunately, a newer upstream version of fonts-cantarell is
currently blocked on a newer fontforge (see #818964 and #745732).

In the mean time, we might want to cherry pick the upstream fix here:
https://git.gnome.org/browse/cantarell-fonts/commit/?id=434a116b0941cd794e6eec0613b7479d2c96503e

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#802460: Pending fixes for bugs in the golang-text package

[pkg-go-maintainers]

tag 802460 + pending
thanks

Some bugs in the golang-text package are closed in revision
47f3155ac8220b620f0893f3bba95bbc46f66451 in branch 'master' by
Anthony Fok

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-text.git/commit/?id=47f3155

Commit message:

Merge patch by James Page to re-enable test suite

from 0.0~git20130502-1ubuntu1 (Closes: #802460)

Bug#822763: RM: root-system [armel armhf hurd-i386 mips mipsel] -- RoQA; blocks removal of libpng 1.2

[Tobias Frost]

Package: ftp.debian.org
Severity: normal

According to dak, libpng1.2 removal needs removal of root-system of said archs.
 ssh mirror.ftp-master.debian.org "dak rm -Rn libpng" says
(...)
root-system: libroot-graf2d-graf5.34 [armel armhf hurd-i386 mips mipsel]
 libroot-graf2d-postscript5.34 [armel armhf hurd-i386 mips mipsel]
 libroot-static [armel armhf hurd-i386 mips mipsel]
 root-plugin-graf2d-asimage [armel armhf hurd-i386 mips mipsel]
 root-plugin-graf2d-x11 [armel armhf hurd-i386 mips mipsel]

As it is unlikely that root-system is fixed soon (Uploader looks MIA from here),
please remove this package from the archs, also with the dependencies fastjet 
and rivet
(both same maintainer)

I've asked the question if the package should be removed from Debian completly 
already
in #822085, but for this drastical step I want to give the science team more 
time.
(and take care of libpng removal first)


Many thanks.

--
tobi

Bug#822669: debhelper: dh_installinit add autoscript for non-existent init script when service file exists

[Raphael Hertzog]

On Tue, 26 Apr 2016, Tianon Gravi wrote:
> (the "[ -x "/etc/init.d/#SCRIPT#" ]" bit,
> https://anonscm.debian.org/cgit/debhelper/debhelper.git/tree/autoscripts/postinst-init)
> 
> Is this check not working properly?

It is working... but as you noted since we know that there is not init
script, we could as well get rid of those.

> > Furthermore the presence of those snippets lead to lintian
> > warnings/errors:
> > W: hostapd-wpe: init.d-script-not-marked-as-conffile etc/init.d/hostapd-wpe
> > E: hostapd-wpe: init.d-script-not-included-in-package etc/init.d/hostapd-wpe
> 
> The lintian warnings are strange, and I think should be considered a
> false-positive in the lintian code itself (since the lines they're
> detecting in postinit are wrapped by an appropriate conditional). :(

So if you don't think that you can drop those lines easily, you might
want to clone this bug against lintian to get those errors fixed, i.e.
linitian should not assume that the package is supposed to contain an
init script if the postints contains those lines.

> I looked a little bit at the dh_installinit code to see how easy it
> would be to remove these lines completely when they're not necessary,
> but it's definitely not trivial (which I think is why the "if"
> statement was added in the first place).

It's probably easier to fix this is when you tackle #822670 (full support
of systemd units as currently provide by dh-systemd).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#803719: gnome-bluetooth: Bluetooth settings in control panel states visibility is as "Bastien's computer"

[Paul Wise]

Control: found -1 3.18.3-1

On Fri, 1 Apr 2016 23:01:48 -0600 Kevin McDonald wrote:

> The correct hostname now appears in the bluetooth settings GUI.
> 
> Confirmed on version 3.18.3-1.

Here I still get "Bastien's computer".

Also the UI file still has that too:

https://sources.debian.net/src/gnome-bluetooth/3.18.3-1/lib/settings.ui/?hl=388#L388

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#821763: xserver-xorg-video-radeon: LibreOffice Preferences UI font corruption on AMD A6-1450 APU/Radeon HD 8250

[Michel Dänzer]

On 24.04.2016 12:43, J Mo wrote:
> 
> How I am I supposed to use EXA mode to disable glamor?

That's not what I meant. I'm interested in whether the problem occurs
with the nVidia GPU as well using the modesetting driver and glamor.


> I just spent the last hour trying to do this unsuccessfully. Xorg
> -configure always fails with "Number of created screens does not match
> the number of detected devices", which seems to be a known issue.
> Manually creating the file causes Xorg to fail. All other attempts at
> modifying the config results in Xorg failing to start.

All you should need in /etc/X11/xorg.conf is something like:

Section "Device"
Identifier "Device0"
Driver "modesetting"
EndSection


However, it occurred to me that glamor might not work on a GTX 970
unless you're using very recent upstream snapshots of Mesa and the kernel.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#821871: [Pkg-xfce-devel] Bug#821871: lightdm: Missing cursor and flicking after unlock with XFCE, clears after VT switch

[Yves-Alexis Perez]

control: reassign -1 xserver-xorg-video-intel
control: forcemerge 819083 -1
control: affects -1 lightdm

On mer., 2016-04-20 at 11:22 +0800, Nathaniel Roach wrote:
> Package: lightdm
> Version: 1.18.1-1
> Severity: important
> 
> Dear Maintainer,
> 
> When using XFCE4 and lightdm, after unlocking the mouse cursor is not
> visible (but does exist) and there is often flickering. The cursor may
> reappear while using gnome-terminal, as it hides/un-hides the cursor, but
> the easiest fix is switching to TTY1 and back (also clears the flickering).
> 
> I'm filing it against lightdm, but it may be an XOrg bug. As it does not
> happen with GNOME/GDM3, I'd presume it may lie in how lightdm handles the VT
> switch.
> 
> I'm running debian testing x64 on a Thinkpad X200 with a custom kernel, but
> it's also effecting other users with newer hardware (T460, for example) and
> is not specific to my kernel build/config.
> 

This is actually #819083 which is unfortunately not available (error 500)
right now from the web interface.

Regards,
-- 
Yves-Alexis



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

Bug#822103: [Pkg-xfce-devel] Bug#822103: light-locker: Cannot unlock screen

[Yves-Alexis Perez]

control: tag -1 unreproducible moreinfo
control: severity -1 important

On jeu., 2016-04-21 at 12:04 +0200, Lars Behrens wrote:
> Screen cannot be unlocked after 'light-locker-command -l' as neither
> keyboard nor mouse action brings up the unlocking dialog, screen just
> stays dark. SSH access still working though.
> 
Sorry but it works just fine for me, you'll have to explain your setup a bit
more.

Regards,
-- 
Yves-Alexis



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

Bug#822231: [Pkg-xfce-devel] Bug#822231: xfce4-terminal: Fira Code font not displayed correctly

[Yves-Alexis Perez]

control: tag -1 moreinfo
On ven., 2016-04-22 at 11:35 +0200, Pierre Rudloff wrote:
> When using the Fira Code font (https://github.com/tonsky/FiraCode) in
> xfce4-terminal, it is not displayed correctly:
> https://lut.im/zjp9Yafejo/4D45RlqhZxDsoqvI.png
> 
> Here is the same code displayed with DejaVu:
> https://lut.im/op2lxcBm8K/3HvKRCcBjytoudXw.png
> 
> I suppose it is because Fira Code uses ligatures.

I'd assume it's something in GTK+ or vte, actually. Can you try with another
vte based terminal like lxterminal and report back?

Regards,
-- 
Yves-Alexis



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

Bug#720386: aptitude: Upgrade marks newly installed packages as manually installed

[Manuel A. Fernandez Montecelo]

2016-04-27 8:37 GMT+01:00 Vincent Lefevre :
> On 2016-04-26 23:47:13 +0100, Manuel A. Fernandez Montecelo wrote:
>> Many of these problems were fixed in releases of the 0.7 series; I
>> suppose that this was one of those cases.
>
> Note that I can at least notice a related issue with aptitude 0.7.2-1
> or later: libgnomevfs2-0 was automatically installed by the installer,
> then I manually installed aptitude 0.7.2-1 (i.e. this was the first
> version installed), and I can notice now that libgnomevfs2-0 is
> marked as manually installed (though I have never forced its manual
> installation). It had only been upgraded by aptitude 0.7.5
> (libgnomevfs2-0:amd64 1:2.24.4-6.1 -> 1:2.24.4-6.1+b1).

That can be caused by many things, internal and external to aptitude,
but in any case it is unrelated to the original bug report (aptitude
not marking deps pulled in as "auto") -- so it's OK for it to remain
closed.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#822733: tzdata: Drop /etc/timezone

[Aurelien Jarno]

On 2016-04-26 23:37, Martin Pitt wrote:
> Package: tzdata
> Version: 2016d-2
> Severity: wishlist
> 
> /etc/localtime got turned into a symlink in 2016a-1 (see bug #803144),
> now that /usr gets mounted from the initrd.
> 
> This now leaves /etc/timezone completely redundant, as you should get
> exactly the same answer by readlink /etc/localtime -- and if you do
> not get the same answer, you have an inconsistency. /etc/localtime
> obviously "wins" for the actual clock (as that's what programs are
> reading), but you presumably get the /etc/timezone value in some
> "system configuration tool" packages which read /etc/timezone first.
> 
> https://codesearch.debian.net/perpackage-results/%2Fetc%2Ftimezone
> shows a fair number of hits, but it's actually not so bad: as
> /etc/timezone is a Debianism and /etc/localtime the distro-agnostic
> standard, a lot of software which isn't Debian specific already looks
> at both and only falls back to /etc/timezone if /etc/localtime does
> not exist. A desktop installation boots fine and with the correct
> time/zone after removing /etc/timezone.

Unfortunately it seems a lot of software are actually using
/etc/timezone to configure the time zone. When switching to a symlink
this made people unhappy, see for example bug#813226. This bug points to
the following query:

https://github.com/search?q=%2Fetc%2Ftimezone+dpkg-reconfigure+noninteractive+tzdata&type=Code&utf8=%E2%9C%93

> If you are generally open to the idea, I can look through the above
> codesearch results more closely to see which packages need fixing,
> file bugs, and block this bug on those. But as that's quite some work,
> I'd first like to discuss this with you.

What we can probably do is to stop looking or creating /etc/timezone
if it doesn't exist, but keep updating it if it exists. What do you
think?

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#735377: 3.0 (native) silently ignores many binary files by default.

[Raphael Hertzog]

On Tue, 26 Apr 2016, Holger Levsen wrote:
> Having done this, I checked my ~/.devscripts and found this:
> 
> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-uc -us -I -i"
> 
> Is this why?

Yes. -I and --tar-ignore in debian/source/options are cumulative.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#822692: [Pkg-phototools-devel] Bug#822692: Strange overscroll effect in settings

[Yuri D'Elia]

On Wed, Apr 27 2016, David Bremner  wrote:
> Hi Yuri;
>
> Thanks for the report. This annoyance, and several others, are due to
> changes in libgtk-3-0 3.20. The darktable team is working on a new point
> release that should fix these annoyances, hopefully sometime within the
> next week or so.

I personally wished darktable used the standard (system) GTK theme.
I'm not super-fond of the contrast and size of the visual elements.

Bug#735377: 3.0 (native) silently ignores many binary files by default.

[Holger Levsen]

On Wed, Apr 27, 2016 at 11:15:27AM +0200, Raphael Hertzog wrote:
> > DEBUILD_DPKG_BUILDPACKAGE_OPTS="-uc -us -I -i"
> > Is this why?
> Yes. -I and --tar-ignore in debian/source/options are cumulative.

ok, thanks! I've had "-I -i" there for years & have just removed it now,
curious what future uploads of mine this will break ;-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#822764: kstars: Unable to download new data.

[Vince]

Package: kstars
Version: 4:15.08.3-1+b2
Severity: important

Dear Maintainer,



   * What led up to the situation? After installing Kstars and running for the 
first time, I was unable to download new data.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I had to manually download the data from reading file 
https://edu.kde.org/kstars/downloads/knewstuff.xml. This contained the 
URLs from which to download the data.
   * What was the outcome of this action? Able to manually download data.
   * What outcome did you expect instead? To be able to download it 
automatically from kstars.




-- System Information:
Distributor ID: Sparky
Description:SparkyLinux
Release:4
Codename:   Tyche
Architecture: x86_64

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

Versions of packages kstars depends on:
ii  kstars-data4:15.08.3-1
ii  libc6  2.22-6
ii  libcfitsio43.380-2
ii  libgcc11:5.3.1-14
ii  libkf5configcore5  5.16.0-1
ii  libkf5configgui5   5.16.0-1
ii  libkf5configwidgets5   5.16.0-1
ii  libkf5coreaddons5  5.16.0-1
ii  libkf5i18n55.16.0-1
ii  libkf5iconthemes5  5.16.0-1
ii  libkf5kiocore5 5.16.0-1
ii  libkf5kiofilewidgets5  5.16.0-1
ii  libkf5kiowidgets5  5.16.0-1
ii  libkf5newstuff55.16.0-1
ii  libkf5plotting55.16.0-1
ii  libkf5widgetsaddons5   5.16.0-1
ii  libkf5xmlgui5  5.16.0-1
ii  libqt5core5a   5.5.1+dfsg-16+b1
ii  libqt5dbus55.5.1+dfsg-16+b1
ii  libqt5gui5 5.5.1+dfsg-16+b1
ii  libqt5printsupport55.5.1+dfsg-16+b1
ii  libqt5sql5 5.5.1+dfsg-16+b1
ii  libqt5svg5 5.5.1-2
ii  libqt5widgets5 5.5.1+dfsg-16+b1
ii  libstdc++6 5.3.1-14
ii  libwcs55.15-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages kstars recommends:
pn  astrometry.net  
ii  indi-bin1.1.0-2
ii  xplanet 1.3.0-3+b1

Versions of packages kstars suggests:
pn  khelpcenter  
pn  konqueror

-- no debconf information

Bug#822765: augeas-lenses: Krb5 lens fails to parse default krb5.conf

[Roland Mas]

Package: augeas-lenses
Version: 1.2.0-0.2+deb8u1
Severity: normal

Dear Maintainer,

Trying to puppetize some changes to a (pristine, freshly-installed) krb5.conf 
file, I run into the following parse errors:

1) missing krb524_server parameter:

CSAIL.MIT.EDU = {
kdc = kerberos-1.csail.mit.edu
kdc = kerberos-2.csail.mit.edu
admin_server = kerberos.csail.mit.edu
default_domain = csail.mit.edu
krb524_server = krb524.csail.mit.edu
}

2) realm names starting with a digit:

1TS.ORG = {
kdc = kerberos.1ts.org
admin_server = kerberos.1ts.org
}

3) realm names starting with a lowercase letter:

stanford.edu = {
kdc = krb5auth1.stanford.edu
kdc = krb5auth2.stanford.edu
kdc = krb5auth3.stanford.edu
master_kdc = krb5auth1.stanford.edu
admin_server = krb5-admin.stanford.edu
default_domain = stanford.edu
}

I believe that the lens as shipped by Debian should be able to address
the krb5.conf file as shipped by Debian.  The following patch addresses
all three problems.

--- krb5.aug.orig   2016-04-27 11:13:15.824046489 +0200
+++ krb5.aug2016-04-27 11:12:46.031915687 +0200
@@ -21,7 +21,7 @@
and realms in the [appdefaults] section.
 *)
 
-let realm_re = /[A-Z][.a-zA-Z0-9-]*/
+let realm_re = /[a-zA-Z0-9][.a-zA-Z0-9-]*/
 let app_re = /[a-z][a-zA-Z0-9_]*/
 let name_re = /[.a-zA-Z0-9_-]+/
 
@@ -83,7 +83,7 @@
 let realms =
   let simple_option = /kdc|admin_server|database_module|default_domain/
   |/v4_realm|auth_to_local(_names)?|master_kdc|kpasswd_server/
-  |/admin_server|ticket_lifetime|pkinit_anchors/ in
+  |/admin_server|ticket_lifetime|pkinit_anchors|krb524_server/ in
   let subsec_option = /v4_instance_convert/ in
   let option = subsec_entry simple_option eq comment in
   let subsec = [ indent . key subsec_option . eq_openbr .

Thanks,

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
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)

augeas-lenses depends on no packages.

augeas-lenses recommends no packages.

Versions of packages augeas-lenses suggests:
pn  augeas-doc  

-- no debconf information

Bug#822489: armhf ABI detection crashing ldconfig on arm64

[Aurelien Jarno]

On 2016-04-26 00:33, Steve McIntyre wrote:
> On Mon, Apr 25, 2016 at 09:57:00AM +0200, Aurelien Jarno wrote:
> >On 2016-04-25 00:30, Steve McIntyre wrote:
> >> Package: libc6-bin
> >> Severity: serious
> >> Version: 2.22-7
> >> Tags: patch
> >> 
> >> Hi folks,
> >> 
> >> Steev has reported some crashing using ldconfig on arm64 systems with
> >> armhf added as a secondary architecture - he's using this config in
> >> Kali, for example.
> >> 
> >> Working through the problem with him on #debian-arm, I can see that
> >> it's a problem with our/my patch for ARM ABI detection. On older
> >> binaries that predate the new ABI flags in the ELF header, we're still
> >> parsing the ARM attributes. That works fine on armel/armhf, but on
> >> arm64 this code is being built wrongly using native (ELF64)
> >> types. This patch is the obvious fix - enforce using ELF32 types for
> >> all arches.
> >
> >You have the same code in unsubmitted-ldconfig-cache-abi.diff, so I
> >guess it also have to be patched?
> 
> Ah, yes - good point. I'd not considered that yet. Hmmm, pondering
> some more...
> 
> No, we're safe here. In *that* case, we're running inside the armhf
> (or armel) version of ld.so, *not* in the arm64 version. There's no
> problem there. Does that make sense to you?

Ok, thanks for looking.

> >> It seems that we still have some older packages without the ABI flags
> >> attached - libshout3 is one such. :-(
> >
> >Frankly we are keeping "temporary" hacks for quite too long on armhf. I
> >would like to drop the following patches after the Stretch release:
> >
> >- local-soname-hack.diff
> 
> Can go away easily I think, yes. The old soname should already be
> history now.

Ok.

> >- unsubmitted-ldconfig-cache-abi.diff
> 
> Should go away after stretch, agreed.
> 
> >- unsubmitted-ldso-abi-check.diff
> >- unsubmitted-ldso-multilib.diff
> 
> U. I don't think these two can go away *at all* without breaking
> multi-arch on ARM.
> 
> The first one could do with updating to use the new ARM ABI float
> flags in preference to the old, slow ARM attributes scan (as an
> optimisation), but the concept isn't going to change.
> 
> The second one is also necessary to deal with finding two different
> float ABIs in the ld.so cache.

Ok. Do you think these patches can be upstreamed then?

> >Could you please ensure that all the binaries in the archive that still
> >needs these patches are rebuilt?
> 
> I'll look again for broken/old stuff. I thought you'd already pushed
> binNMUs for everything outstanding, though??

I have done that for the local-soname-hack.diff patch. According to my
list the only remaining binaries are the following ones:

  argus-client_2.0.6.fixes.1-3
  cuba_3.0+2024-2
  icebreaker_1.21-11
  ipkungfu_0.6.1-6
  isakmpd_20041012-7.2
  libprinterconf_0.5-12
  nget_0.27.1-11

They are not in stretch anymore, so we should just make sure they are
removed from sid before we can drop the patch.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#822764: Extra information on Kstars download bug

[Vince Barwinski]

The error message I get when I try to download data from kstars is:

Loading of providers from file
http://edu.kde.org/kstars/downloads/providers.xml failed.

Cheers

Bug#822679: Attempts to mount /proc as a regular user

[cgzones]

I can confirm this bug.
It seems this is already fixed upstream; can you please cherry pick this
https://github.com/SELinuxProject/selinux/commit/5a8d8c499b2ef80eaa7b5abe2ec68d7101e613bf
patch?

Bug#819275: check-support-status outputs a blank line, which is not cron friendly

[Harald Hannelius]

I was about to file a bug as well, since I just got a lot of e-mail from 
different cron-daemons. The normal convention would be to not say anything 
if there isn't anything to tell, wouldn't it?


At the very least don't output a single newline.

--
A: Top Posters!  |  s/y Charlotta |
Q: What is the most annoying thing on mailing lists? |FIN-2674|
  http://www.fe83.org/ Finn Express Purjehtijat ry   |  = |
Harald H Hannelius | harald (At) iki (dot) fi | GSM +358 50 594 1020

Bug#804139: bumblebee: after recent xorg + nvidia updates in sid, "Cannot access secondary GPU - error"

[Luca Boccassi]

On Wed, 2016-04-27 at 09:57 +0200, ø wrote:
> > Hi,
> > 
> > I actually found that it works for me with a rootless Xorg, but the
> > legacy wrapper breaks it.
> > 
> > Do you have xserver-xorg-legacy installed?
> > 
> > Kind regards,
> > Luca Boccassi
> 
> Yes I had. I installed it when after upgrading to rootless Xorg on the
> firt time optirun ceased to work.
> 
> Great news is after removing it, it works again! Oh my God! I've been
> months with this, I never thought on uninstalling legacy xorg again.

Great!

I suspect it's due to the different path. I'll try to investigate, and
eventually add a Breaks: xserver-xorg-legacy if it can't be done.

Kind regards,
Luca Boccassi


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

Bug#822575: debian regression: no more console output after "switching to mgag200drmfb from simple"

[Ben Hutchings]

Control: tag -1 - moreinfo

On Wed, 2016-04-27 at 09:01 +0200, Harald Dunkel wrote:
> On 04/26/2016 04:05 PM, Ben Hutchings wrote:
> > 
> > 
> > I'm guessing that you didn't built the mgag200 driver
> > (CONFIG_DRM_MGA),
> > right?
> > 
> Of course its in, as for the official kernel.
> 
>   % grep -i mga /boot/config-4.5.2
>   CONFIG_DRM_MGA=m
>   CONFIG_DRM_MGAG200=m

Oh of course, mga and mgag200 are two different drivers.  Thanks for
working out what I meant.

> Would you suggest to blacklist this module?

Not in general, but that should work around the bug.  That is
effectively what we were doing before version 4.4~rc5-1~exp1 to avoid
conflicts with older X drivers (while xserver-xorg-video-modesetting
would override that blacklisting).  Since we don't patch mgag200 any
more, I don't understand why you are seeing a bug with the official
kernel package and yet not with a custom kernel.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#822766: pyglet: provide pyglet for python 3

[Ghislain Antony Vaillant]

Source: pyglet
Severity: wishlist

Dear Maintainers,

According to the respective PyPI page [1], the latests release of pyglet
supports Python 3. Please consider packaging it for Debian and provide a
corresponding python3-pyglet package, so that present and future packages
can use it (vispy, which I intend to work on, is one of them).

I would have offered to update the packaging myself as I am part of the DPMT
but usage of both git-dpm and cdbs, which I am not familiar with, puts me off.

[1] https://pypi.python.org/pypi/pyglet

Best regards,
Ghis


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

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

Bug#822692: [Pkg-phototools-devel] Bug#822692: Strange overscroll effect in settings

[David Bremner]

Yuri D'Elia  writes:

> I personally wished darktable used the standard (system) GTK theme.
> I'm not super-fond of the contrast and size of the visual elements.

This seems unlikely to change any time soon. Since I don't use GTK
themes myself, I'm not really the best person to understand the issues,
but upstream seems quite attached to their visual style.

d

Bug#822728: RFS: libtcod/1.6.0~pre1+dfsg-1 [ITP] -- graphics and utility library for roguelike developers

[Jakub Wilk]

* Adam Borowski , 2016-04-27, 05:27:

export DEB_BUILD_OPTIONS=parallel=`grep ^processor /proc/cpuinfo|wc -l`


Refuse the temptation to parse /proc/cpuinfo. Use nproc(1) instead.

--
Jakub Wilk

Bug#822733: tzdata: Drop /etc/timezone

[Martin Pitt]

Hello Aurelien,

Aurelien Jarno [2016-04-27 11:13 +0200]:
> Unfortunately it seems a lot of software are actually using
> /etc/timezone to configure the time zone. When switching to a symlink
> this made people unhappy, see for example bug#813226. This bug points to
> the following query:
> 
> https://github.com/search?q=%2Fetc%2Ftimezone+dpkg-reconfigure+noninteractive+tzdata&type=Code&utf8=%E2%9C%93

Interesting, thanks for that link. It seems the majority is writing
that file for a subsequent dpkg-reconfigure, but I've seen a few reads
as well. It seems over time a lot of software out there has adopted
this Debianism.

Wrt. to #813226, I admittedly don't understand why /etc/localtime
being a file or symlink is in any way related to which of
/etc/localtime vs. /etc/timezone should have priority over the other
on reconfiguration. I mean, the *.config scripts surely may treat them
differently, but that's just an implementation detail, not a
conceptual/design problem?

Software (both tzdata itself and also other things reading/changing
it) needs to get along with /etc/localtime being a symlink either way,
even before tzdata 2016a-1.

> What we can probably do is to stop looking or creating /etc/timezone
> if it doesn't exist, but keep updating it if it exists. What do you
> think?

That might be cleaner in situations where someone explicitly removes
it, but a lot less useful to avoid the redundancy problem.

Anyway, it seems to me that this is too deeply entrenched in the
software world by now, so  I figure is is a case for 'wontfix' and
just closing this report?

Thanks!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

Bug#822767: libgtk-3-0: emacs icons and scrollbar arrows disappeared

[Jörg-Volker Peetz]

Package: libgtk-3-0
Version: 3.20.3-1
Severity: normal

Dear Maintainer(s),

this version changes the emacs24 (24.5+1-6) appearance. The icons in the
menu bar vanish and in the scrollbar the up and down arrows
("-GtkScrollbar-has-backward-stepper") disappear.

Are changes in gtk.css needed or additional packages?

Regards,
jvp.


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

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

Versions of packages libgtk-3-0 depends on:
ii  libatk-bridge2.0-0  2.18.1-3
ii  libatk1.0-0 2.20.0-1
ii  libc6   2.22-6
ii  libcairo-gobject2   1.14.6-1+b1
ii  libcairo2   1.14.6-1+b1
ii  libcolord2  1.3.2-1
ii  libcups22.1.3-5
ii  libepoxy0   1.3.1-1
ii  libfontconfig1  2.11.0-6.4
ii  libfreetype62.6.3-3
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libglib2.0-02.48.0-1
ii  libgtk-3-common 3.20.3-1
ii  libjson-glib-1.0-0  1.2.0-1
ii  libpango-1.0-0  1.40.1-1
ii  libpangocairo-1.0-0 1.40.1-1
ii  libpangoft2-1.0-0   1.40.1-1
ii  librest-0.7-0   0.7.93-1
ii  libsoup2.4-12.54.0.1-2
ii  libwayland-client0  1.10.0-2
ii  libwayland-cursor0  1.10.0-2
ii  libwayland-egl1-mesa [libwayland-egl1]  11.1.3-1
ii  libx11-62:1.6.3-1
ii  libxcomposite1  1:0.4.4-1
ii  libxcursor1 1:1.1.14-1+b1
ii  libxdamage1 1:1.1.4-2+b1
ii  libxext62:1.3.3-1
ii  libxfixes3  1:5.0.1-2+b2
ii  libxi6  2:1.7.6-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.5.0-1
ii  libxml2 2.9.3+dfsg1-1
ii  libxrandr2  2:1.5.0-1
ii  shared-mime-info1.6-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin  3.20.3-1

Versions of packages libgtk-3-0 suggests:
pn  gvfs 
ii  librsvg2-common  2.40.15-1

-- no debconf information

Bug#822728: RFS: libtcod/1.6.0~pre1+dfsg-1 [ITP] -- graphics and utility library for roguelike developers

[Gianfranco Costamagna]

Hi, some general notes:


Adam, do you plan to sponsor the package? in this case can I set you as owner? 
:)

Fabian, why are you trying to package an upstream snapshot?
(not asking to package 1.5.1, I'm just wondering about why a new library should
eventually enter Debian in a snapshot form)

cheers,

G.


Il Mercoledì 27 Aprile 2016 5:30, Adam Borowski  ha 
scritto:
On Tue, Apr 26, 2016 at 10:22:32PM +0200, Fabian Wolff wrote:
>  * Package name: libtcod

I'm afraid that it builds only on 64-bit architectures (I tried amd64 and
arm64), on 32-bit ones (x32 armhf i386) it fails with:

dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libtcod0/DEBIAN/symbols doesn't match 
completely debian/libtcod0.symbols
--- debian/libtcod0.symbols (libtcod0_1.6.0~pre1+dfsg-1_x32)
+++ dpkg-gensymbolsZSmCIg2016-04-27 02:14:30.890101840 +
@@ -1511,7 +1511,7 @@
  (c++)"TCODSystem::newMutex()@Base" 1.6.0~pre1
  (c++)"TCODSystem::newSemaphore(int)@Base" 1.6.0~pre1
  (c++)"TCODSystem::newThread(int (*)(void*), void*)@Base" 1.6.0~pre1
- (c++)"TCODSystem::readFile(char const*, unsigned char**, unsigned 
long*)@Base" 1.6.0~pre1
+#MISSING: 1.6.0~pre1+dfsg-1# (c++)"TCODSystem::readFile(char const*, unsigned 
char**, unsigned long*)@Base" 1.6.0~pre1
  (c++)"TCODSystem::registerSDLRenderer(ITCODSDLRenderer*)@Base" 1.6.0~pre1
  (c++)"TCODSystem::saveScreenshot(char const*)@Base" 1.6.0~pre1
  (c++)"TCODSystem::setClipboard(char const*)@Base" 1.6.0~pre1
@@ -1560,6 +1560,7 @@
  (c++)"TCODZip::~TCODZip()@Base" 1.6.0~pre1
  TCOD_CRenderer@Base 1.6.0~pre1
  (c++)"TCOD_path_func(int, int, int, int, void*)@Base" 1.6.0~pre1
+ _ZN10TCODSystem8readFileEPKcPPhPj@Base 1.6.0~pre1+dfsg-1
  end_struct@Base 1.6.0~pre1
  error@Base 1.6.0~pre1
  internalListener@Base 1.6.0~pre1

So you need to adjust the symbols file.

Also, it'd be nice if you added --parallel to the dh call, it massively
speeds up builds[1] on any non-museal machine.  It's default in upcoming
debhelper 10.


Meow!

[1]. To actually make --parallel work, the person running the build needs to
set: export DEB_BUILD_OPTIONS=parallel=`grep ^processor /proc/cpuinfo|wc -l`
but this is outside the packaging.
-- 
A tit a day keeps the vet away.

Bug#802801: python-coverage: FTBFS: calling function returned 100.0, not a test

[Julien Cristau]

On Wed, Apr 27, 2016 at 13:48:42 +1000, Ben Finney wrote:

> Control: tags -1 + unreproducible help
> 
> On 20-Apr-2016, Julien Cristau wrote:
> > It fails on all buildds: 
> > https://buildd.debian.org/status/package.php?p=python-coverage
> 
> I see that, however it just doesn't happen in my clean chroots. I am
> not able to reproduce the problem.
> 
> Without a procedure to reproduce and investigate the behaviour, I
> don't know what I can do to progress this.
> 
I just ran "sbuild -d sid python-coverage_3.7.1+dfsg.1-1.dsc" and it
failed with

> python3.5 setup.py test -vv
> running test
> running egg_info
> writing dependency_links to coverage.egg-info/dependency_links.txt
> writing top-level names to coverage.egg-info/top_level.txt
> writing coverage.egg-info/PKG-INFO
> writing entry points to coverage.egg-info/entry_points.txt
> reading manifest file 'coverage.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no previously-included files matching '*.pyc' found anywhere in 
> distribution
> writing manifest file 'coverage.egg-info/SOURCES.txt'
> running build_ext
> building 'coverage.tracer' extension
> x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
> -Wstrict-prototypes -g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
> -I/usr/include/python3.5m -c coverage/tracer.c -o 
> build/temp.linux-x86_64-3.5/coverage/tracer.o
> x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
> -Wl,-z,relro -Wl,-z,relro -g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
> build/temp.linux-x86_64-3.5/coverage/tracer.o -o 
> /<>/python-coverage-3.7.1+dfsg.1/coverage/tracer.cpython-35m-x86_64-linux-gnu.so
> Unknown command: 'test'
> Use 'coverage help' for help.
> debian/rules:87: recipe for target 'test-python3.5' failed
> make[1]: *** [test-python3.5] Error 1

which matches at least some of the buildd failures.

Cheers,
Julien

Bug#822759: torbrowser-launcher: provide alternatives for x-www-browser and gnome-www-browser

[Holger Levsen]

control: block -1 by 821093
thanks

Hi Santiago,

On Wed, Apr 27, 2016 at 10:12:52AM +0200, Santiago Ruano Rincón wrote:
> Attached a patch to manage torbrowser-launcher as alternative for
> x-www-browser and gnome-www-browser. This will be more useful once
> 821093 get closed though.

thanks for your patch, but indeed, this has to wait until #821093 is
fixed, because without it, torbrowser can hardly provide a sensible
browser ;-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#822692: [Pkg-phototools-devel] Bug#822692: Strange overscroll effect in settings

[Yuri D'Elia]

On Wed, Apr 27 2016, David Bremner  wrote:
> Yuri D'Elia  writes:
>
>> I personally wished darktable used the standard (system) GTK theme.
>> I'm not super-fond of the contrast and size of the visual elements.
>
> This seems unlikely to change any time soon. Since I don't use GTK
> themes myself, I'm not really the best person to understand the issues,
> but upstream seems quite attached to their visual style.

I know, and it's one of the reasons I used rawtherapee for quite some
time in the past. But I'm tired to squint just for some visual style. I
use themes to get consistency, and Darktable doesn't even respect the
system font size!

Oh well...

Bug#822768: myrepos: Consider popular VCS software as Recommends

[Geert Stappers]

Package: myrepos
Version: 1.20160122
Severity: normal

Dear Maintainer,

Hello Joey,

myrepos/debian/control has these lines


Section: vcs
Depends:
 ${misc:Depends}
Suggests:
 ack-grep,
 bzr,
 curl,
 cvs,
 darcs,
 fossil,
 git-core | git (>= 1:1.7),
 kdesdk-scripts,
 liburi-perl,
 mercurial,
 subversion,
 subversion-tools,
 vcsh
Provides:
 mr
Replaces:
 mr
Recommends:
 libhtml-parser-perl,
 libio-pty-easy-perl,
 libwww-perl,
 perl
Description: tool to manage all your version control repos


That means that none version control system
will be installed upon `aptitude install myrepos`

Please consider to move subversion and git
from "Suggests:" to "Recommends:"

That I ask for git and subversion is because I think
those two are the most popular VCS.


Regards
Geert Stappers
While reading https://wiki.debian.org/DebianInstaller/CheckOut

Bug#822769: debci: Obsolete test results shown

[Gordon Ball]

Source: debci
Version: 1.1.2
Severity: wishlist

Dear Maintainer,

Packages which previously included a test but have subsequently had it removed 
still
appear in the package list with the last result shown.

See, eg r-bioc-annotationdbi on ci.d.n: the test was last run (failed) in 2014 
but the
result is still shown in the package list with no indication that the result is
1) very old and 2) applies to a package version superseded even in stable.

The web interface should probably stop listing packages for which the last 
result
is older than some threshold, or add an annotation indicating the age or that 
the
package version is no longer current. 

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

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

Bug#822728: RFS: libtcod/1.6.0~pre1+dfsg-1 [ITP] -- graphics and utility library for roguelike developers

[Adam Borowski]

Control: owner -1 !

On Wed, Apr 27, 2016 at 09:45:18AM +, Gianfranco Costamagna wrote:
> Adam, do you plan to sponsor the package? in this case can I set you as 
> owner? :)

Sure, can do.  I did most of the review already, and if we decide otherwise
wrt 1.6-pre1, can always unset.

> Fabian, why are you trying to package an upstream snapshot?
> (not asking to package 1.5.1, I'm just wondering about why a new library 
> should
> eventually enter Debian in a snapshot form)

Upstream says:
# Note that 1.6 is bleeding edge and still needs polishing before it can
# replace 1.5.  It is recommended you use 1.5.

On the other hand, moving from SDL1.2 to SDL2 is a big change, so I
understand wanting to use the new version already, both for programs using
this library and to avoid doing this part of packaging twice.

On the third hand, though, there's a significant risk the API/ABI might
change before final 1.6.

-- 
A tit a day keeps the vet away.

Bug#822672: RFS: freecell-solver/4.2.0-0.1 [NMU]

[Markus Koschany]

Control: owner -1 !

Am 26.04.2016 um 12:10 schrieb Shlomi Fish:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "freecell-solver"

Hi Shlomi,

First of all thank you for updating freecell-solver. Your effort is much
appreciated. I intend to sponsor your package and to upload it to the
DELAYED/10 queue, should there be no reaction from the maintainer within
the next couple of days.

In general the changes look good to me but there is one serious issue
and a couple of smaller, non-intrusive ones which are already present in
the current package. While we are at it we should fix them.

You can use Lintian to detect them and by creating the lintianrc file in

~/.config/lintian/lintianrc

with the following content:

info=yes
display-info=yes
display-experimental=yes
pedantic=yes
show-overrides=yes
color=auto
verbose=yes

or by looking at this page

http://mentors.debian.net/package/freecell-solver

The serious one is the incomplete copyright file:

The copyright file states that all code is in the public domain. This is
not correct. There are source files with different license headers, e.g

Your own code is licensed under the MIT/Expat license.

board_gen/make_pysol_freecell_board.py (GPL-2+)
patsolve-shlomif/patsolve/ga/mt19937.c (LGPL)


Copyright (c) 2002 Tom Holroyd (Expat/MIT License)

Copyright (C) 2014 insane coder (http://insanecoding.blogspot.com/,
http://asprintf.insanecoding.org/)
+
+Permission to use, copy, modify, and distribute this software for any
+purpose with or without fee is hereby granted, provided that the above
+copyright notice and this permission notice appear in all copies.
+
+THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

Please update debian/copyright accordingly.

Optional: You could transform the file to copyright format 1.0.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/


Other issues:

Only debian/control.in should be modified because the package uses
DEB_AUTO_UPDATE_DEBIAN_CONTROL from CDBS.

Dependency on debhelper should be debhelper (>= 9). Please remove the
duplicate entry debhelper (>= 7) in debian/control and update
debian/control.in accordingly.

debian/control.in: Please update the Vcs-fields to use Debian's
canonical URLs.

Vcs-Browser:
https://anonscm.debian.org/cgit/collab-maint/freecell-solver.git
Vcs-Git: https://anonscm.debian.org/git/collab-maint/freecell-solver.git

Please install the upstream changelog (NEWS.txt) in debian/rules with

DEB_INSTALL_CHANGELOGS_ALL := NEWS.txt

Since you are upstream for freecell-solver please consider to fix the
following minor issues:

There is a typo in main.c: explictly => explicitly

Please consider to write a man page for freecell-solver-config.

There is a spelling error in fc-solve.6 allows to => allows one to.

You could cryptographically sign your package, so that debian/watch can
verify its integrity.

https://lintian.debian.org/tags/debian-watch-may-check-gpg-signature.html

You might want to run check-all-the-things on your code. It executes
different checkers which may help you to improve freecell-solver.

e.g.

pep8 --ignore W191 . (Improvement suggestions how to style your code
according to pep8)

find -type f -iname '*.sh' -exec checkbashisms {} +

There are multiple *.sh files that don't seem to have a #! interpreter line.

There are more typos which can be found with

codespell --quiet-level=3

$ cppcheck -j1 --quiet -f . | grep -vF 'cppcheck: error: could not find
or open any of the paths given.'
[fc_pro_range_solver.c:429]: (error) Memory leak: binary_output.file
[state.h:32]: (error) Invalid number of character '{' when these macros
are defined: 'COMPACT_STATES'.
[state.h:32]: (error) Invalid number of character '{' when these macros
are defined: 'DEBUG_STATES'.
[state.h:32]: (error) Invalid number of character '{' when these macros
are defined: 'INDIRECT_STACK_STATES'.


Regards,

Markus











signature.asc
Description: OpenPGP digital signature

Bug#822728: RFS: libtcod/1.6.0~pre1+dfsg-1 [ITP] -- graphics and utility library for roguelike developers

[Gianfranco Costamagna]

Hi Adam,


>Sure, can do.  I did most of the review already, and if we decide otherwise
>wrt 1.6-pre1, can always unset.


thanks a lot for that, it helps in avoiding double checking of packages :)
and double reviews :D

># Note that 1.6 is bleeding edge and still needs polishing before it can
># replace 1.5.  It is recommended you use 1.5.
>
>On the other hand, moving from SDL1.2 to SDL2 is a big change, so I
>understand wanting to use the new version already, both for programs using
>this library and to avoid doing this part of packaging twice.


+1 for moving away from SDL1.2

>On the third hand, though, there's a significant risk the API/ABI might>change 
>before final 1.6.


well, if 1.6 gets released in a short time, we might not even have 
reverse-dependencies
in the archive, so... who cares?

/me says something about putting the package on experimental

cheers!
and thanks
Gianfranco

Bug#822770: RFS: pidgin-sipe/1.21.0-1 -- Pidgin plugin for MS Office Communicator and MS Lync

[Jakub Adam]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for package "pidgin-sipe", whose source code is at:

  https://anonscm.debian.org/cgit/collab-maint/pidgin-sipe.git

or you may also:

  dget -x 
http://mentors.debian.net/debian/pool/main/p/pidgin-sipe/pidgin-sipe_1.21.0-1.dsc

It builds this binary package:

  pidgin-sipe - Pidgin plugin for MS Office Communicator and MS Lync

Changes since the last upload:

pidgin-sipe (1.21.0-1) unstable; urgency=medium

  * New upstream release.
- Feature #91: Support embedded XML as buddy photo URL
- Feature #90: Add AppStream metadata file
- Feature #89: Improve "Join scheduled conference" dialog
- Feature #87: Support multiple HTTP cookies
- Feature #85: XML raw extract should ignore name space
- Fixed #311: Crash when SIP transport becomes invalid
- Fixed #293: Mandatory wsa:MessageID node missing
- add support for Lync File Transfer protocol
- add build options to "About SIPE plugin" message
  * Drop fix-hppa-ftbfs.patch (applied upstream).
  * Drop pidgin-sipe-dbg in favour of autogenerated debug package.
  * Remove obsolete build dependency on libzephyr-dev.
  * Enable bindnow hardening flag.

 -- Jakub Adam   Wed, 27 Apr 2016 10:16:53 +0200

Regards,

Jakub




signature.asc
Description: OpenPGP digital signature

Bug#802801: python-coverage: FTBFS: calling function returned 100.0, not a test

[Ben Finney]

On 27-Apr-2016, Julien Cristau wrote:
> On Wed, Apr 27, 2016 at 13:48:42 +1000, Ben Finney wrote:
> 
> I just ran "sbuild -d sid python-coverage_3.7.1+dfsg.1-1.dsc" and it
> failed with
> 
> > python3.5 setup.py test -vv
> > […]
> > Unknown command: 'test'
> > Use 'coverage help' for help.
> > debian/rules:87: recipe for target 'test-python3.5' failed
> > make[1]: *** [test-python3.5] Error 1
> 
> which matches at least some of the buildd failures.

Okay, but that would be worthy of a separate bug report. I'm not able
to reproduce the behaviour originally reported.

-- 
 \ “If you can do no good, at least do no harm.” —_Slapstick_, |
  `\ Kurt Vonnegut |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#822768: Hello Richih

[Geert Stappers]

On Wed, Apr 27, 2016 at 10:09:06AM +, Debian Bug Tracking System wrote:
> On Wed, Apr 27, 2016 at 12:04:59PM +0200, Geert Stappers wrote:
> > Package: myrepos
> > Version: 1.20160122
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > Hello Joey,
> > 
>
> Thank you for filing a new Bug report with Debian.
>
> Your message has been sent to the package maintainer(s):
>  Richard Hartmann 
>

Hello Richih,

Saying hi to Joey was a mixture of happy memories and reading in changelog

myrepos (1.20160123) UNRELEASED; urgency=medium

  * Strip .git extension when registering vsch repositories.
Thanks, Don March
  * Disable git pager when mr status runs git stash list.

 -- Joey Hess   Sat, 02 Apr 2016 15:10:58 -0400

myrepos (1.20160122) unstable; urgency=medium

  * Fix one missing call to safe_abs_path.
Thanks, Chris Arndt

 -- Joey Hess   Fri, 22 Jan 2016 18:44:56 -0400

which shows recent Debian activity of Joey Hess.

I learnt that I should check Maintainer-field in debian/control.



So became a personal 'Hello Joey' a personal email with Cc to bts.


Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: Digital signature

Bug#822560: [Aptitude-devel] Bug#822560: aptitude: Pressing "q" to quit after installation leaves a black terminal

[Ralf Jung]

Hi,

> In my case (using konsole) it just goes blank as part of restoring
> curses, then shuts down and the previous lines of the screen are
> visible, without painting any extra blank lines in between.
> 
> aptitude doesn't print empty lines on purpose, so printing a message
> like "Shutting down..." wouldn't help in this case -- if the extra blank
> lines are printed (as far as aptitude can tell) for no apparent reason
> and out of aptitude's control, then the "Shutting down..." message from
> aptitude would disappear from the visible part of the terminal as well
> when those blank lines are printed.
> 
> So the key is to find out why the blanking of the screen happens.

Maybe there was a misunderstanding here, but there are no unexpected
"blank lines". What happens is that the entire console goes black after
pressing "q". Then, after some time (longer than I would expect),
the prompt appears as expected. Additional empty lines appear only if I
hit "" while the screen is black.
  The bug was reported because I was not patient enough to wait for this
black screen to go away -- after 2 or 3 seconds, I concluded that
something went wrong and did Ctrl-C. That's why I suggested to use
curses to show some "Shutting down..." instead of going black. curses
should be fast enough for that; after all, if I just hit "" (no
"q"), then the aptitude main window immediately appears (and it tells me
to wait a little while it does some work). The slow bit here is
aptitude, not curses.

Kind regards,
Ralf

Bug#822771: php-pear: Invalid argument supplied for foreach() in /usr/share/php/PEAR/Command.php on + XML Extension not found

[Ivan Sergio Borgonovo]

Package: php-pear
Version: 1:1.10.1+submodules+notgz-8
Severity: grave
Justification: renders package unusable

I discovered I've the same problem described here:
http://serverfault.com/questions/589877/pecl-command-produces-long-list-of-errors
examining horde log files

A long list of
Invalid argument supplied for foreach() in /usr/share/pear/PEAR/...
ending with

PHP Warning:  require_once(/lib/Application.php): failed to open stream:
No such file or directory in /usr/bin/horde-alarms on line 21
PHP Fatal error:  require_once(): Failed opening required
'/lib/Application.php' (include_path='.:/usr/share/php:') in
/usr/bin/horde-alarms on line 21

This also seems to be related with some pear issue not setting horde_dir

Simply running
pear list-all
or any other pear command end up in the same list of
Invalid argument supplied for foreach() in /usr/share/pear/PEAR/...
ending with
XML Extension not found

thanks

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

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

Versions of packages php-pear depends on:
ii  php-common1:35
ii  php-xml   1:7.0+35
ii  php5.6-cli [php-cli]  5.6.18+dfsg-11
ii  php7.0-xml [php-xml]  7.0.5-3

php-pear recommends no packages.

php-pear suggests no packages.

-- no debconf information

Bug#822772: vxl FTBFS on Alpha; patch fix_alphacomp.patch needs updating.

[Michael Cree]

Source: vxl
Version: 1.17.0.dfsg2-4
Severity: important
Justification: fails to build from source (but built in past)
User: debian-al...@lists.debian.org
Usertags: alpha

vxl FTBFS on Alpha with [1]:

cd /«PKGBUILDDIR»/obj-alpha-linux-gnu/vcl/tests && /usr/bin/c++   
-DVXL_LEGACY_ERROR_REPORTING -DVXL_WARN_DEPRECATED -DVXL_WARN_DEPRECATED_ONCE 
-I/«PKGBUILDDIR»/obj-alpha-linux-gnu/vcl -I/«PKGBUILDDIR»/vcl 
-I/«PKGBUILDDIR»/obj-alpha-linux-gnu/core -I/«PKGBUILDDIR»/core  -g -O2 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -o 
CMakeFiles/vcl_test_all.dir/test_iterator.o -c 
/«PKGBUILDDIR»/vcl/tests/test_iterator.cxx
In file included from /«PKGBUILDDIR»/v3p/Qv/QvLib.cxx:69:0:
/«PKGBUILDDIR»/v3p/Qv/QvDict.cxx: In member function 'QvDictEntry*& 
QvDict::findEntry(const char*) const':
/«PKGBUILDDIR»/v3p/Qv/QvDict.cxx:97:24: error: 'intptr_t' was not declared in 
this scope
 entry = &buckets[ (intptr_t)key % tableSize];

In the file v3p/Qv/QvDict.cxx there is some conditional compilation
depending on the macro __alpha, presumably put there to support
Alpha OSF1 Unix, but is incorrect for Alpha Linux.  The first hunk
in the patch debian/patches/fix_alphacomp.patch attempts to correct
this but botches the fix. The best solution is to entirely remove
the conditional compilation on the macro __alpha and leave Alpha
Linux to use the generic Linux compilation path.  I attach an updated
fix_alphacomp.patch.  With that vxl builds to completion on Alpha.

Cheers
Michael.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=vxl&arch=alpha&ver=1.17.0.dfsg2-4&stamp=1460289377
Description: __alpha is a processor, not an OS
Author: Mathieu Malaterre 
Last-Update: 2011-12-12
Forwarded: http://sourceforge.net/mailarchive/message.php?msg_id=28569493
Bug: https://sourceforge.net/apps/trac/vxl/ticket/66

Index: vxl-1.17.0.dfsg2/v3p/Qv/QvDict.cxx
===
--- vxl-1.17.0.dfsg2.orig/v3p/Qv/QvDict.cxx
+++ vxl-1.17.0.dfsg2/v3p/Qv/QvDict.cxx
@@ -8,9 +8,7 @@
 #  include  /* for malloc and friends */
 # endif
 #else
-# if defined(__alpha) /* there is no inttypes.h here */
-   typedef unsigned long intptr_t;
-# elif defined(__CYGWIN__)
+# if defined(__CYGWIN__)
 #  include  /* for intptr_t on Cygwin */
 # elif defined(__BORLANDC__)
 #  if __BORLANDC__ < 0x0560
Index: vxl-1.17.0.dfsg2/core/vil/vil_stream_url.cxx
===
--- vxl-1.17.0.dfsg2.orig/core/vil/vil_stream_url.cxx
+++ vxl-1.17.0.dfsg2/core/vil/vil_stream_url.cxx
@@ -25,7 +25,7 @@
 # include 
 # include// htons()
 # ifdef __alpha
-#  include// htons() [ on e.g. DEC alpha, htons is in machine/endian.h]
+//#  include// htons() [ on e.g. DEC alpha, htons is in machine/endian.h]
 # endif
 # define SOCKET int
 #elif defined (VCL_WIN32) && !defined(__CYGWIN__)
Index: vxl-1.17.0.dfsg2/core/vil1/vil1_stream_url.cxx
===
--- vxl-1.17.0.dfsg2.orig/core/vil1/vil1_stream_url.cxx
+++ vxl-1.17.0.dfsg2/core/vil1/vil1_stream_url.cxx
@@ -24,7 +24,7 @@
 # include 
 # include// htons()
 # ifdef __alpha
-#  include// htons() [ on e.g. DEC alpha, htons is in machine/endian.h]
+//#  include// htons() [ on e.g. DEC alpha, htons is in machine/endian.h]
 # endif
 # define SOCKET int
 #elif defined (VCL_WIN32) && !defined(__CYGWIN__)
Index: vxl-1.17.0.dfsg2/core/vul/vul_url.cxx
===
--- vxl-1.17.0.dfsg2.orig/core/vul/vul_url.cxx
+++ vxl-1.17.0.dfsg2/core/vul/vul_url.cxx
@@ -27,7 +27,7 @@
 # include 
 # include// htons()
 # ifdef __alpha
-#  include   // htons() [ on e.g. DEC alpha, htons is in machine/endian.h ]
+//#  include   // htons() [ on e.g. DEC alpha, htons is in machine/endian.h ]
 # endif
 # define SOCKET int
 

Bug#822773: debtree: support multiple packages as input

[Nicholas Brown]

Package: debtree
Version: 1.0.10
Severity: wishlist

It would be great to be able to specify a list of packages as a parameter and
have debtree generate a combined dependency graph for them.



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

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

Versions of packages debtree depends on:
ii  dctrl-tools  2.23
ii  libapt-pkg-perl  0.1.29+b2
ii  perl 5.20.2-3+deb8u4
ii  ucf  3.0030

Versions of packages debtree recommends:
ii  graphviz  2.38.0-7

debtree suggests no packages.

Bug#803866: vcmi: diff for NMU version 0.98+dfsg-2.1

[Johannes Schauer]

Quoting Sebastian Ramacher (2016-04-25 09:18:54)
> I've prepared an NMU for vcmi (versioned as 0.98+dfsg-2.1) and uploaded it to
> DELAYED/2. Please feel free to tell me if I should delay it longer.

thanks a lot for fixing this before I got to it!

cheers, josch


signature.asc
Description: signature

Bug#822672: RFS: freecell-solver/4.2.0-0.1 [NMU]

[Paul Wise]

On Wed, Apr 27, 2016 at 6:19 PM, Markus Koschany wrote:

> First of all thank you for updating freecell-solver. Your effort is much
> appreciated. I intend to sponsor your package and to upload it to the
> DELAYED/10 queue, should there be no reaction from the maintainer within
> the next couple of days.

Please note that the maintainer surfaced in the meantime:

https://lists.debian.org/msgid-search/87a8kfv59x@errge.nilcons.com

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#822774: Prefer libapache2-mod-php7.0

[Michael Biebl]

Package: php7.0-common
Version: 7.0.5-3
Severity: normal

Hi,

today's upgrade installed php7.0-fpm, which in turn starts a separate
process.

The reason is the following Depends in php7.0:

php7.0-fpm | libapache2-mod-php7.0 | php7.0-cgi

The package description of php7.0-fpm though reads:
"Note that MOST Apache users probably want the libapache2-mod-php7.0
package".

If that is the case, why is libapache2-mod-php7.0 not the first
alternative, so pulled in by default instead of php7.0-fpm?


Regards,
Michael


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

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

Versions of packages php7.0 depends on:
ii  libapache2-mod-php7.0  7.0.5-3
ii  php7.0-common  7.0.5-3

php7.0 recommends no packages.

php7.0 suggests no packages.

Versions of packages php7.0-common depends on:
ii  libc62.22-7
ii  libssl1.0.2  1.0.2g-2
ii  php-common   1:35
ii  ucf  3.0036

-- no debconf information

Bug#820875: redmine-plugin-custom-css: fails to install: redmine triggers fail

[Dmitry Smirnov]

Antonio, could you please have a look at #820875 ?

It started happening recently and I'm not sure if everything is all right in 
Redmine. My "solution" to fixing this problem is to install assets to

/usr/share/redmine/public/plugin_assets/redmine_custom_css/

instead of 

/usr/share/redmine/plugins/redmine_custom_css

Is this is how plugins' assets should be installed?

Please advise.

-- 
Cheers,
 Dmitry Smirnov.

---

If liberty means anything at all, it means the right to tell people what
they do not want to hear.
-- George Orwell


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

Bug#822672: RFS: freecell-solver/4.2.0-0.1 [NMU]

[Markus Koschany]

Control: noowner -1 !

Am 27.04.2016 um 12:44 schrieb Paul Wise:
> On Wed, Apr 27, 2016 at 6:19 PM, Markus Koschany wrote:
> 
>> First of all thank you for updating freecell-solver. Your effort is much
>> appreciated. I intend to sponsor your package and to upload it to the
>> DELAYED/10 queue, should there be no reaction from the maintainer within
>> the next couple of days.
> 
> Please note that the maintainer surfaced in the meantime:
> 
> https://lists.debian.org/msgid-search/87a8kfv59x@errge.nilcons.com
> 

Thanks for the heads-up. Shlomi, I suggest that you coordinate the
upload with Gergely now. Gergely, please see

https://lists.debian.org/debian-mentors/2016/04/msg00600.html

for my comments on the package available at

http://mentors.debian.net/package/freecell-solver

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#822775: libgmpada: FTBFS due to uninstallable build dependencies

[John Paul Adrian Glaubitz]

Source: libgmpada
Version: 0.0.20131223-4
Severity: serious
Justification: fails to build from source
User: debian-...@lists.debian.org
Usertags: gnat-6

Hi!

libgmpada fails to build from source in unstable since its build
dependencies can no longer be installed:

Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 sbuild-build-depends-libgmpada-dummy : Depends: gnat-4.9 but it is not going 
to be installed
E: Unable to correct problems, you have held broken packages.
apt-get failed.
E: Package installation failed
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

This is a result of gnat in unstable defaulting to gnat-6 [1] and
gnat-6 conflicting with gnat-4.9 and libgmpgada having both
gnat and gnat-4.9 in its build dependencies.

I assume this will affect many other packages which are still
build-depending on gnat-4.9 directly, so it might be a good
idea to look at all Ada packages in Debian.

Cheers,
Adrian

> [1] https://packages.qa.debian.org/g/gnat/news/20160426T112022Z.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#804772: TAR: testsuite failure: 163 165 failed (GNU/hurd and kfreebsd-*)

[Gianfranco Costamagna]

control: tags -1 patch
control: tags -1 pending

on deferred/5, feel free to speed it up.


g.


Il Domenica 24 Aprile 2016 18:33, Andreas Beckmann  ha scritto:
Hi,

On Wed, 11 Nov 2015 11:26:10 + (UTC) Gianfranco Costamagna
 wrote:
> Attached the patch that should fix the kfreebsd and hurd test failures
on test
> 163 and 165.
>
> (I'm not going to NMU them I guess, because they aren't release
architectures)

On Sat, 2 Jan 2016 18:40:54 + Steven Chamberlain
 wrote:
> I just tested the patch posted by Gianfranco, and it has fixed the
> test failures on kfreebsd-amd64, thanks!
> 
> Please consider uploading this to sid because latest autogen is
> BD-Uninstallable on kfreebsd and hurd until we have tar >= 1.28.

This patch is now sitting here for nearly half a year ... it would be
nice if this could be uploaded to fix build problems on the non-linux
architectures, e.g. in packages using --clamp-mtime for reproducibility.


Andreas

Bug#822770: RFS: pidgin-sipe/1.21.0-1 -- Pidgin plugin for MS Office Communicator and MS Lync

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi Jakub,


can you please explain the changes below (to me or in changelog)

-usr/lib/*/purple-2/libsipe.so usr/lib/purple-2
-usr/share/locale/*
-usr/share/pixmaps/*


-DEB_CONFIGURE_EXTRA_FLAGS := --enable-purple --disable-telepathy 
--enable-openssl=no
+DEB_CONFIGURE_EXTRA_FLAGS := --libdir=/usr/lib --enable-purple 
--disable-telepathy --enable-openssl=no
+
+export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow


1) maybe you can try to hardening=+all

and --libdir=/usr/lib seems a good way to avoid multiarch...
why?

2) I see "libpurple-dev (>= 2.10.11-1.1)"


and this on changelog:
+   - add support for Lync File Transfer protocol (Jakub Adam)
+ * requires libpurple >= 2.12.0


maybe you should bump the version?

other stuff LGTM

G.


Il Mercoledì 27 Aprile 2016 12:30, Jakub Adam  ha scritto:
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for package "pidgin-sipe", whose source code is at:

  https://anonscm.debian.org/cgit/collab-maint/pidgin-sipe.git

or you may also:

  dget -x 
http://mentors.debian.net/debian/pool/main/p/pidgin-sipe/pidgin-sipe_1.21.0-1.dsc

It builds this binary package:

  pidgin-sipe - Pidgin plugin for MS Office Communicator and MS Lync

Changes since the last upload:

pidgin-sipe (1.21.0-1) unstable; urgency=medium

  * New upstream release.
- Feature #91: Support embedded XML as buddy photo URL
- Feature #90: Add AppStream metadata file
- Feature #89: Improve "Join scheduled conference" dialog
- Feature #87: Support multiple HTTP cookies
- Feature #85: XML raw extract should ignore name space
- Fixed #311: Crash when SIP transport becomes invalid
- Fixed #293: Mandatory wsa:MessageID node missing
- add support for Lync File Transfer protocol
- add build options to "About SIPE plugin" message
  * Drop fix-hppa-ftbfs.patch (applied upstream).
  * Drop pidgin-sipe-dbg in favour of autogenerated debug package.
  * Remove obsolete build dependency on libzephyr-dev.
  * Enable bindnow hardening flag.

-- Jakub Adam   Wed, 27 Apr 2016 10:16:53 +0200

Regards,

Jakub

Bug#820826: libc6-dev-amd64: Multiarch allows conflicting packages, and apt-get does not detect this

[Aurelien Jarno]

On 2016-04-12 21:04, Sean wrote:
> Package: libc6-dev-amd64
> Version: 2.19-18+deb8u4
> Severity: normal
> 
> Dear Maintainer,
> 
> I'm not an expert in the cross-compilation toolchain or its Debian repository 
> configuration, but the libc6-dev-* packages appear to be set up with 
> architecture qualifiers so that only one will ever be installed; since they 
> conflict.
> Multiarch support allows multiple of these packages to be attempted to be 
> installed.
> 
> 1. The wrong package for the architecture is allowed to be installed through 
> multiarch with no complaints (and possibly as a dependency of, eg, a 
> misconfigured other package)
> 2. If apt-get is requested to install another, conflicting, package in this 
> family, it will attempt to do so until dpkg discovers the conflict and the 
> operation fails with no error message explaining why
> 1+2. Synergistically, this can allow the wrong package to get onto a system 
> with no complaints, then when the legitimate package is required by 
> something, apt-get cannot install it though it attempts to, giving a dpkg 
> error message that doesn't explain the underlying problem (and apt-get 
> suggests apt-get -f install, which does nothing to fix it of course)

This has already been reported multiple time, for example in #702962.
Anyway apt-get simply do not support cross-architecture conflict, so
there is nothing that can be done on the libc side.

> + Also, the package naming scheme may be confusing to intermediate and novice 
> users if they're expected to find that a package is incorrectly installed and 
> which one, as libc6-dev-amd64 is *not* to be installed on amd64 systems, and 
> similarly for libc6-dev-i386 and i386 systems; their qualifiers are setup to 
> only be allowed on the opposite architecture (unless multiarch is enabled, 
> which entirely leads to this situation)
> 
> + I presume this would apply to other architectures as well, and possibly 
> other packages (esp. cross-compilation related ones?), but these were the 
> packages I personally encountered in this event.

I don't see how do you want to call the amd64 libc without using the
amd64 name in it. These names have been there for almost 10 years, so
I don't think they are problematic.

I am therefore closing this bug.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#822416: Install LVM with Free PE, partman-?????

[Philipp Kern]

On 2016-04-24 09:18, Geert Stappers wrote:

| Install a starting point.
| More complicated configuration can be done on the installed system.
| KISS



Keep It Simple


There is also the inverse direction here: The user will be confused as 
to why so much of the drive's capacity is missing and needs to resort to 
not so simple and potentially destructive tooling to rectify the 
situation. That's not really simple either, right?


Not really arguing for one way or another, but one sysadmin's KISS is 
another user's WTF. :)


Kind regards
Philipp Kern

Bug#822774: [php-maint] Bug#822774: Prefer libapache2-mod-php7.0

[Ondřej Surý]

Hi,

I am almost convinced to revert the change back, but I got as many
questions about:

"I am installing nginx, so why is apache2 being pulled in?", so I
decided to make FPM preferred SAPI.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

On Wed, Apr 27, 2016, at 12:49, Michael Biebl wrote:
> Package: php7.0-common
> Version: 7.0.5-3
> Severity: normal
> 
> Hi,
> 
> today's upgrade installed php7.0-fpm, which in turn starts a separate
> process.
> 
> The reason is the following Depends in php7.0:
> 
> php7.0-fpm | libapache2-mod-php7.0 | php7.0-cgi
> 
> The package description of php7.0-fpm though reads:
> "Note that MOST Apache users probably want the libapache2-mod-php7.0
> package".
> 
> If that is the case, why is libapache2-mod-php7.0 not the first
> alternative, so pulled in by default instead of php7.0-fpm?
> 
> 
> Regards,
> Michael
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200,
>   'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages php7.0 depends on:
> ii  libapache2-mod-php7.0  7.0.5-3
> ii  php7.0-common  7.0.5-3
> 
> php7.0 recommends no packages.
> 
> php7.0 suggests no packages.
> 
> Versions of packages php7.0-common depends on:
> ii  libc62.22-7
> ii  libssl1.0.2  1.0.2g-2
> ii  php-common   1:35
> ii  ucf  3.0036
> 
> -- no debconf information
> 
> ___
> pkg-php-maint mailing list
> pkg-php-ma...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint

Bug#822713: [Debian-med-packaging] Bug#822713: elastix: FTBFS with GCC 6: marked 'override', but does not override

[Martin Michlmayr]

* Gert Wollny  [2016-04-26 21:25]:
> Control: forwarded -1 https://github.com/mstaring/elastix/issues/5
> 
> Until upstream fixes this I'll re-upload forcing -std=c++03. 

Maybe you can close this bug when you do...

> However, I prefer to keep this bug open until elastix can be build
> without forcing an older C++ standard.

... and open a new minor/wishlist bug about this.

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#822769: debci: Obsolete test results shown

[Antonio Terceiro]

On Wed, Apr 27, 2016 at 11:17:17AM +0100, Gordon Ball wrote:
> Source: debci
> Version: 1.1.2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Packages which previously included a test but have subsequently had it 
> removed still
> appear in the package list with the last result shown.
> 
> See, eg r-bioc-annotationdbi on ci.d.n: the test was last run (failed) in 
> 2014 but the
> result is still shown in the package list with no indication that the result 
> is
> 1) very old and 2) applies to a package version superseded even in stable.
> 
> The web interface should probably stop listing packages for which the last 
> result
> is older than some threshold, or add an annotation indicating the age or that 
> the
> package version is no longer current.

https://ci.debian.net/packages/r/r-bioc-annotationdbi/unstable/amd64/
explicitly lists the date and package version of when the test was last
run.

anyway, even though it would be nice to somehow handle the case where a
package has its test metadata removed, it is very low priority for me at
the moment. as usual, patches are welcome.


signature.asc
Description: PGP signature

Bug#822776: ITP: maffilter -- process genome alignment in the Multiple Alignment Format

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: maffilter
  Version : 1.1.0
  Upstream Author : Julien Dutheil 
* URL : http://biopp.univ-montp2.fr/repos/sources/maffilter/
* License : CeCILL
  Programming Lang: C++
  Description : process genome alignment in the Multiple Alignment Format
 MafFilter applies a series of "filters" to a MAF file, in order to
 clean it, extract data and computer statistics while keeping track of
 the associated meta-data such as genome coordinates and quality scores.
 .
  * It can process the alignment to remove low-quality / ambiguous /
masked regions.
  * It can export data into a single or multiple alignment file in
format such as Fasta or Clustal.
  * It can read annotation data in GFF or GTF format, and extract the
corresponding alignment.
  * It can perform sliding windows calculations.
  * It can reconstruct phylogeny/genealogy along the genome alignment.
  * It can compute population genetics statistics, such as site
frequency spectrum, number of fixed/polymorphic sites, etc.


This package will be maintained by the Debian Med team at
https://anonscm.debian.org/git/debian-med/maffilter.git

Bug#822778: evolution-ews NTLM authentification problem after samba upgrade

[noname@]

Package: evolution-ews
Version: 3.18.5-1
Severity: normal
Tags: newcomer

Dear Maintainer,

A system-update causes evolution-ews to fail. Each attempt to 
connect to the EWS server brought up a password dialog but the
connection could not be retrieved anymore.

Other symptoms and a more accurate description
including solutions can be found in

https://bugzilla.redhat.com/show_bug.cgi?id=1327072

My personal workaround was finally:
replacing /usr/bin/ntlm_auth with the version from
winbind_4.2.10+dfsg-0+deb8u2_amd64.deb (jessie)

The better solution is of course to patch evolution-ews as done
by the Fedora team.

best regards

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

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

Versions of packages evolution-ews depends on:
ii  evolution   3.18.5.1-1
ii  libatk1.0-0 2.20.0-1
ii  libc6   2.22-7
ii  libcairo-gobject2   1.14.6-1+b1
ii  libcairo2   1.14.6-1+b1
ii  libcamel-1.2-54 3.18.5-1
ii  libebackend-1.2-10  3.18.5-1
ii  libebook-contacts-1.2-2 3.18.5-1
ii  libecal-1.2-19  3.18.5-1
ii  libedata-book-1.2-253.18.5-1
ii  libedata-cal-1.2-28 3.18.5-1
ii  libedataserver-1.2-21   3.18.5-1
ii  libedataserverui-1.2-1  3.18.5-1
ii  libevolution3.18.5.1-1
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libglib2.0-02.48.0-1
ii  libgtk-3-0  3.18.9-1
ii  libical1a   1.0.1-0.1
ii  libjavascriptcoregtk-3.0-0  2.4.11-1
ii  libmspack0  0.5-1
ii  libnspr42:4.12-2
ii  libnspr4-0d 2:4.12-2
ii  libnss3 2:3.23-2
ii  libnss3-1d  2:3.23-2
ii  libpango-1.0-0  1.40.1-1
ii  libpangocairo-1.0-0 1.40.1-1
ii  libsecret-1-0   0.18.3-1
ii  libsoup2.4-12.52.2-1
ii  libsqlite3-03.12.1-1
ii  libwebkitgtk-3.0-0  2.4.11-1
ii  libxml2 2.9.3+dfsg1-1

evolution-ews recommends no packages.

evolution-ews suggests no packages.

-- no debconf information

Bug#820875: redmine-plugin-custom-css: fails to install: redmine triggers fail

[Antonio Terceiro]

Control: reassign -1 redmine
Control: found -1 3.2.1-1

On Wed, Apr 27, 2016 at 09:11:55PM +1000, Dmitry Smirnov wrote:
> Antonio, could you please have a look at #820875 ?
> 
> It started happening recently and I'm not sure if everything is all right in 
> Redmine. My "solution" to fixing this problem is to install assets to
> 
> /usr/share/redmine/public/plugin_assets/redmine_custom_css/
> 
> instead of 
> 
> /usr/share/redmine/plugins/redmine_custom_css
> 
> Is this is how plugins' assets should be installed?

No. the whole plugin is to be installed in
/usr/share/redmine/plugins/redmine_custom_css; this seems to be a
problem with the redmine packaging introduced in 3.2.1-1; plugin assets
used to be handled correctly before that and I think I broke it.


signature.asc
Description: PGP signature

Bug#822780: apt sends invalid HTTP Host: headers for local IPv6 addresses

[Christoph Weber]

Package: apt
Version: 1.0.9.8.3
Severity: normal
Tags: ipv6

Dear Maintainer,

I have a repository server running on fe80::1, which is easy to access
for new systems because of IPv6 SLAAC -- normally, this just works.

Since I upgraded to Jessie, I cannot reach it via apt anymore, because
apt sends invalid Host: headers:

| # apt -o Debug::Acquire::http=yes update
[...]
| GET /dists/test-base/Release HTTP/1.1
| Host: [fe80::1%tap0]:8080
| Cache-Control: max-age=0
| Accept: text/*
| User-Agent: Debian APT-HTTP/1.3 (1.0.9.8.3)

This results in a "bad request" from Apache 2.2 on the server. RFC 7230,
section "5.4. Host" tells us:

Host = uri-host [ ":" port ]

And "uri-host" references "host" in RFC 3986, section "3.2.2. Host".
To be concise: IPv6 addresses shall be written as groups of four
hexadecimal digits in square brackets, but the interface identifier
should be left out. (BTW: it has no meaning to the server, as it is
local to the client.)

Therefore I believe apt should strip out interface identifiers when
constructing Host headers, while it should still use them to create
the TCP connection.

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "i386";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "false";
APT::Install-Suggests "false";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-3\.16\.0-4-686-pae$";
APT::NeverAutoRemove:: "^linux-headers-3\.16\.0-4-686-pae$";
APT::NeverAutoRemove:: "^linux-image-extra-3\.16\.0-4-686-pae$";
APT::NeverAutoRemove:: "^linux-signed-image-3\.16\.0-4-686-pae$";
APT::NeverAutoRemove:: "^kfreebsd-image-3\.16\.0-4-686-pae$";
APT::NeverAutoRemove:: "^kfreebsd-headers-3\.16\.0-4-686-pae$";
APT::NeverAutoRemove:: "^gnumach-image-3\.16\.0-4-686-pae$";
APT::NeverAutoRemove:: "^.*-modules-3\.16\.0-4-686-pae$";
APT::NeverAutoRemove:: "^.*-kernel-3\.16\.0-4-686-pae$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.16\.0-4-686-pae$";
APT::NeverAutoRemove:: "^linux-tools-3\.16\.0-4-686-pae$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Never-MarkAuto-Sections:: "oldlibs";
APT::Never-MarkAuto-Sections:: "restricted/oldlibs";
APT::Never-MarkAuto-Sections:: "universe/oldlibs";
APT::Never-MarkAuto-Sections:: "multiverse/oldlibs";
APT::Architectures "";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "1";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "2";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-9n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "3";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-9";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "4";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "5";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-9";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt/";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::mirrors "mirrors/";
Dir::State::extended_states 

Bug#822779: elastix should compile without forcing older than c++11 standard

[Gert Wollny]

Package: elastix
Version: 4.8-8
Severity: wishlist
Tags: upstream

Currently, the package requires -std=c++03 with g++-6 to compile, this should
be corrected.

- gert



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

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

Versions of packages elastix depends on:
ii  libc6 2.22-6
ii  libgcc1   1:6-20160117-1
ii  libgomp1  6-20160117-1
ii  libinsighttoolkit4.9  4.9.1-1
ii  libstdc++66-20160117-1
ii  zlib1g1:1.2.8.dfsg-2+b1

elastix recommends no packages.

Versions of packages elastix suggests:
ii  elastix-doc  4.8-5

-- no debconf information

Bug#816607: libcharls1: void EncoderStrategy::AppendToBitStream(LONG, LONG): Assertion `bitpos >=0' failed

[Andreas Tille]

Hi Sjors,

thanks for the bug report and sorry for the slow response.  Formerly
Mathieu Malaterre maintained this package but he left the Debian Med
team and left a gap behind.  I'd willing to help to some extend but it
would be really great if you could try to send a patch or at least point
me to the upstream commit to keep my effort for this particular package
low since I'm uneducated in the field of imaging.

Kind regards

  Andreas.

On Thu, Mar 03, 2016 at 01:51:50PM +0100, Sjors Gielen wrote:
> Package: libcharls1
> Version: 1.0-6
> Severity: important
> 
> Dear Maintainer,
> 
> I can reliably reproduce an assertion failure in LibCharLS version 1.0-6. My
> investigation into this is still pending, but nonetheless I wanted to raise
> this early so that we could discuss potential fixes.
> 
> The assertion happens in EncoderStrategy with very specific inputs, that occur
> for me in production. From my early investigation, I can see that the
> AppendToBitStream function is called while bitpos is 0, with a length of 31,
> causing bitpos to become -31. The Flush() function is then called to raise
> bitpos back to >= 0, but after 4 iterations bitpos is still at -1, causing an
> assertion failure. I'm not sure yet about the semantic meaning of this, or
> where the true bug is.
> 
> This bug has been known upstream for a while[0], and is said to be fixed in
> master, but there has been no CharLS release for years and I haven't figured
> out where it is fixed exactly just yet.
> 
> I can reproduce this bug by saving a lossless JPEG image through the DICOM
> Toolkit. It appears I'm not the only one, as somebody reported this already in
> 2012[1] and a colleague of mine in 2014[2]. I will attempt to produce a fully
> self-sufficient test case without DCMTK if needed.
> 
> [0] http://charls.codeplex.com/workitem/10742
> [1] http://forum.dcmtk.org/viewtopic.php?f=1&t=3412
> [2] https://bugs.launchpad.net/ubuntu/+source/charls/+bug/1329695
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.3.0-1-amd64 (SMP w/1 CPU core)
> 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)
> 
> Versions of packages libcharls1 depends on:
> ii  libc6  2.21-9
> ii  libgcc11:5.3.1-8
> ii  libstdc++6 5.3.1-8
> ii  multiarch-support  2.21-9
> 
> libcharls1 recommends no packages.
> 
> libcharls1 suggests no packages.
> 
> -- no debconf information
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#822648: Needs DEP-11 support

[Mark Hindley]

Package apt-cacher
forcemerge 821159 822648
thanks

On Mon, 25 Apr 2016, 23:42:09 BST, Daniel Richard G.  wrote:

> Package: apt-cacher
> Version: 1.7.12
> Severity: important
> 
> https://wiki.debian.org/DEP-11
> 
> The new DEP-11 package metadata format, as used in Ubuntu Xenial
> (16.04), is not supported by the current version of apt-cacher. This
> makes the program unusable for newer versions of the distribution.

Thanks. I think this is a duplicate of #821159. I gave an updated 
index_files_regexp config that the OP suggested meybe the fix (although I 
wasn't completely sure of his response). Could you try that.

I noice that your apt-get trace has some additional SHA1 filenames, that I 
wasn't expecting, so the #821159 may be incomplete.

Thanks.

Mark

Bug#822263: cups printing from 2 recently patched systems stops with incomplete spooling; printer works fine with Windows

[Dave Martin]

Bingo!  I did steps 1-5, and now printing is working fine.  *Thank you!*

Is this really a Debian or kernel bug (or regression)?  if so, what 
steps should be taken to report it?


...and are there ramifications to setting frto=0?



On 04/27/2016 01:23 AM, Brian Potkin wrote:

tags 822263 - moreinfo
thanks



On Tue 26 Apr 2016 at 10:39:31 -0700, Dave Martin wrote:


I'm not sure if this will help at all, but I re-tested cups printing on my
netbook (wheezy, cups 1.5.2) to again make sure the print server and printer
are working properly.  (and just to clarify, this netbook is a 3rd machine,
not to be confused with the other 2 machines which both suffer the
referenced printing problems).  I printed 2 cups test pages, a simple text

[...Snip...]

It does help. Taken with the information in your previous mail and the lack of
any obvious misbehaviour shown in the cups error logs, it could be we are
looking at something similar to Ubuntu bug #213081 and Debian bug #478062.

   https://bugs.launchpad.net/ubuntu/+source/linux/+bug/213081

and

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

The advice offered there is:

   1. Power-off the printer to totally clear the corrupt job.
   2. Clear the printer spool queue ('cancel -a -x').
   3. Power-on the printer
   4. Do '/sbin/sysctl -n net.ipv4.tcp_frto' and confirm the current
  value is 2.
   5. 'sysctl -w net.ipv4.tcp_frto=0' (as root).

If it works

   net.ipv4.tcp_frto=0

is put in /etc/sysctl.conf so that the change survives rebooting.

Regards,

Brian.

Bug#822697: general: qt5 apps in gnome do not use the gtk style as they should

[Dmitry Shachnev]

Control: reassign -1 libqt5widgets5 5.5.1+dfsg-16
Control: tags -1 moreinfo

Hi Miguel,

On Tue, Apr 26, 2016 at 06:20:10PM +0100, Miguel Negrao wrote:
> Qt5 apps (e.g. qmapshack) do not use the gtk style as should be the default.
> Because of this they look a bit more ugly, for instance the buttons to close
> panes have a black X instead of a white X on red background. Launching the qt5
> binary with '-style=gtk' gives the right look, but the system should be
> configured such that this is not necessary.

This most likely means that Qt does not recognize your desktop as needing GTK+
integration. Can you please check what is the value of XDG_CURRENT_DESKTOP
environment variable on your system?

Also, please keep in mind that the GTK+ style will be removed in Qt 5.7,
and the recommended alternative is using custom themes like Adwaita-Qt.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#822781: libpdfbox-java: Command line tools missing / java -jar pdfbox.jar not working

[Peter Van Biesen]

Package: libpdfbox-java
Version: 1:1.8.11+dfsg-1
Severity: normal

Dear Maintainer,

I tried to use the pdfbox as documented,
https://pdfbox.apache.org/1.8/commandline.html , e.g.

java -jar /usr/share/java/pdfbox.jar Decrypt

But this always results in
no main manifest attribute, in /usr/share/java/pdfbox.jar

Is this expected behavior ? Or do I need to install another package ?

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

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

Versions of packages libpdfbox-java depends on:
ii  libfontbox-java  1:1.8.7+dfsg-1

libpdfbox-java recommends no packages.

libpdfbox-java suggests no packages.

-- no debconf information

-- 

Peter Van Biesen
Systems Administrator
IT-Team/exploitatie&beheer

VLAAMS AGENTSCHAP VOOR PERSONEN MET EEN HANDICAP
www.vaph.be



-- 

Raadpleeg uw VAPH-dossier online via http://mijn.vaph.be.

-
http://www.vaph.be/disclaimer

Bug#816607: Partial patch

[Mathieu Malaterre]

This does not qualify as `tag patch` but since it does improve
slightly the situation, I am posting it here for reference.


bug816607.patch
Description: Binary data

Bug#819395: RFS: stormlib-listfiles/2015-04-20-1 [ITP]

[Gianfranco Costamagna]

Hi Pali and mentors,

(redirecting the question to -mentors, because I don't have a strong opinion on 
this)


>Looks like we do not have exact license text as those file "were
>generated" by brute-force methods by more people and put into public
>domain. People names (or nick names) are already included in copyright
>file. That is all what I know and cannot do more. If there are or there
>are not law problems it is probably question for other people...

there should be a verbatim copy of the license included in the upstream tarball

look e.g. to 

https://ftp-master.debian.org/REJECT-FAQ.html
License II and III sections


so, either you have to document how the license is obtained, or how to 
reproduce the files
generation.

I know licenses are a waste of time for somebody (they were for me when I 
started
my contributions in Debian :p )...
but they are the best way to get your package rejected by ftpmasters!

So, this point is really a showstopper for the inclusion in Debian of the tool
(BTW if you want to ask ftpmasters about their opinion let me know their 
answer).

I would like to avoid uploading and get a reject, but I would consider an
upload with a ping to ftpmasters about this issue.

cheers,

Gianfranco


Il Martedì 26 Aprile 2016 23:07, Pali Rohár  ha scritto:
On Thursday 21 April 2016 10:16:29 Pali Rohár wrote:
> On Tuesday 19 April 2016 08:36:49 Gianfranco Costamagna wrote:
> > Hi,
> > 
> > >There is no more info about it just as it is public domain, no
> > >more license texts... What to write into paragraph then??
> > 
> > everything is a license, and public domain is a license too.
> > https://codesearch.debian.net/results/License:%20public-domain/page
> > _0
> > 
> > G.
> 
> Looks like we do not have exact license text as those file "were
> generated" by brute-force methods by more people and put into public
> domain. People names (or nick names) are already included in
> copyright file. That is all what I know and cannot do more. If there
> are or there are not law problems it is probably question for other
> people...

Gianfranco, what else needs to be done? I think I done everything what I 
was able to do...


-- 
Pali Rohár
pali.ro...@gmail.com

Bug#822697: general: qt5 apps in gnome do not use the gtk style as they should

[Miguel Negrão]

Hi Dmitry,

Thanks for looking at this.

On 27-04-2016 13:47, Dmitry Shachnev wrote:
> This most likely means that Qt does not recognize your desktop as needing GTK+
> integration. Can you please check what is the value of XDG_CURRENT_DESKTOP
> environment variable on your system?

miguel@miguel-MacBookPro:~$ echo $XDG_CURRENT_DESKTOP
GNOME

> Also, please keep in mind that the GTK+ style will be removed in Qt 5.7,
> and the recommended alternative is using custom themes like Adwaita-Qt.

As long as Adwaita-Qt is installed and is picked up automatically by qt5
apps, that is fine with me. My only issue is that the current default
theme for qt5 apps doesn't match well with gnome, and looks lees than ideal.

Btw, I also tested on a fresh install of debian, with gnome, and the
same issue happens. I installed taskel gnome-desktop.

Best,
Miguel



signature.asc
Description: OpenPGP digital signature

Bug#822782: Please update Pidgin to latest upstream release

[Jakub Adam]

Package: src:pidgin
Severity: important

Packaging Pidgin 2.10.12 solves problem with failing voice calls after 
libfarstream-0.2-5 has been updated
to version 0.2.7 in Debian.

Thanks,

Jakub



signature.asc
Description: OpenPGP digital signature

Bug#819394: RFS: stormlib/9.20-1 [ITP]

[Gianfranco Costamagna]

Hi, the packaging seems good now, I would like to ask you a final question:

how do you feel about using the same license for debian packaging and upstream?
(asking about changing GPL-3+ to MIT).

Forwarding patches otherwise would be impossible without a relicense.

and the copyright still needs to be updated:

>So in this case, how to update copyright? Just for src/lzma? Or for all
>other embedded libraries even when they are not used and needed?


you have to list *every* copyright and license on copyright file, regardless
of it being used or not.
This is a showstopper for ftpmasters.


let me know,

Gianfranco





Il Lunedì 18 Aprile 2016 22:24, Pali Rohár  ha scritto:
Now I updated stormlib package on mentors.debian.net.


-- 
Pali Rohár
pali.ro...@gmail.com

Bug#822783: eztrace-contrib: FTBFS with libc 2.23: 'memcpy' was not declared in this scope

[Graham Inggs]

Package: eztrace-contrib
Version: 1.1-2-1
Severity: important
Tags: patch
User: debian-gl...@lists.debian.org
Usertags: 2.23

Hi Maintainer

Eztrace-contrib FTBFS with glibc 2.23 available in Experimental and
Ubuntu Xenial.

> /usr/include/string.h: In function ‘void* __mempcpy_inline(void*, const 
> void*, size_t)’:
> /usr/include/string.h:652:42: error: ‘memcpy’ was not declared in this scope
>return (char *) memcpy (__dest, __src, __n) + __n;
>   ^
> /usr/include/string.h: In function ‘void* __mempcpy_inline(void*, const 
> void*, size_t)’:
> /usr/include/string.h:652:42: error: ‘memcpy’ was not declared in this scope
>return (char *) memcpy (__dest, __src, __n) + __n;
>   ^
> /usr/include/string.h: In function ‘void* __mempcpy_inline(void*, const 
> void*, size_t)’:
> /usr/include/string.h:652:42: error: ‘memcpy’ was not declared in this scope
>return (char *) memcpy (__dest, __src, __n) + __n;

I found a similar issue had been reported for TensorFlow [1], and the solution:

> @e14159 can you try with -D_FORCE_INLINES? I just had the same issue with pcl,
> I checked the string.h header, and using that preprocessor directive skips 
> the block
> where the memcpy error appears. There's probably a cleaner workaround 
> though...

I also encountered and reported a similar issue in Theano [2].

I was able to get eztrace-contrib to build in Ubuntu by adding
-D_FORCE_INLINES to CPPFLAGS as per the attached patch.

Regards
Graham


[1] https://github.com/tensorflow/tensorflow/issues/1346
[2] https://github.com/Theano/Theano/pull/4369
diff -Nru eztrace-contrib-1.1-2/debian/rules eztrace-contrib-1.1-2/debian/rules
--- eztrace-contrib-1.1-2/debian/rules  2016-02-05 13:56:09.0 +0200
+++ eztrace-contrib-1.1-2/debian/rules  2016-03-31 14:13:55.0 +0200
@@ -3,6 +3,7 @@
 DEB_HOST_ARCH_CPU=$(shell dpkg-architecture -qDEB_HOST_ARCH_CPU)
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
+export DEB_CPPFLAGS_MAINT_APPEND = -D_FORCE_INLINES
 
 ifeq ($(DEB_HOST_ARCH_CPU),s390x)
 OPENMPI=no

Bug#822210: sdl2-config.cmake: extra leading / trailing whitespace

[Gianfranco Costamagna]

Hi Manuel and libsdl2 developers!


How do you feel about the patch below?
I think we should apply it, to avoid cmake breakages in linux systems.

thanks for considering it,

--- a/configure.in
+++ b/configure.in
@@ -97,7 +97,7 @@
 
 if test x$have_no_cygwin = xyes; then
 BASE_CFLAGS="-mno-cygwin"
-BASE_LDFLAGS="-mno-cygwin"
+BASE_LDFLAGS=" -mno-cygwin"
 fi
 BASE_CFLAGS="$BASE_CFLAGS -I/usr/include/mingw"
 ;;
@@ -123,7 +123,7 @@
 #fi
 #done
 SDL_CFLAGS="$BASE_CFLAGS"
-SDL_LIBS="-lSDL2 $BASE_LDFLAGS"
+SDL_LIBS="-lSDL2$BASE_LDFLAGS"
 CPPFLAGS="$CPPFLAGS $EXTRA_CFLAGS"
 CFLAGS="$CFLAGS $EXTRA_CFLAGS"
 LDFLAGS="$LDFLAGS $EXTRA_LDFLAGS"

(probably also BASE_CFLAGS needs some similar patching)

cheers,


Gianfranco


Il Domenica 24 Aprile 2016 19:22, Jason Pleau  ha scritto:
Hi Gianfranco,

On Fri, 22 Apr 2016 14:23:53 +0200 Gianfranco Costamagna
 wrote:
> Hi,
> > set(SDL2_LIBRARIES "-L${SDL2_LIBDIR}  -lSDL2 ")
> 
> I know where that space comes from:
> 
> quoting configure.in
> 
> SDL_LIBS="-lSDL2 $BASE_LDFLAGS"
> 
> 
> changing to 
> SDL_LIBS="-lSDL2$BASE_LDFLAGS"
> 
> fixes the issue, because in our case BASE_LDFLAGS is undefined.
> 
> I'm not sure why the cmake build is not even creating it, and I'm not sure how
> to best fix the issue.
> 
> I think a patch would be welcome, so the maintainers can apply it if needed :)

I attached a patch, would something like this be an acceptable solution
? If yes I think we should forward upstream

> 
> thanks for the bug report,
> 
> Gianfranco
> 

-- 
Jason Pleau

Bug#822784: mypaint: Does not start "TypeError: GLib.filename_to_utf8() takes exactly 2 arguments (4 given)"

[Ulrik Sverdrup]

Package: mypaint
Version: 1.2.0-1.1+b2
Severity: important

Dear Maintainer,

mypaint does not start, output is:

INFO: mypaint: Installation layout: conventional POSIX-like structure with 
prefix u'/usr'
INFO: lib.i18n: POSIX: LANG='sv_SE.utf8'
INFO: lib.i18n: POSIX: LANGUAGE=None
Traceback (most recent call last):
  File "/usr/bin/mypaint", line 462, in 
main.main(datapath, iconspath, old_confpath, version=version)
  File "/usr/share/mypaint/gui/main.py", line 92, in main
lib.glib.init_user_dir_caches()
  File "/usr/share/mypaint/lib/glib.py", line 109, in init_user_dir_caches
logger.debug("Init g_get_user_config_dir(): %r", get_user_config_dir())
  File "/usr/share/mypaint/lib/glib.py", line 71, in get_user_config_dir
return filename_to_unicode(d_fs)
  File "/usr/share/mypaint/lib/glib.py", line 57, in filename_to_unicode
ustring = GLib.filename_to_utf8(opsysstring, -1, 0, 0)
TypeError: GLib.filename_to_utf8() takes exactly 2 arguments (4 given)

Since it mentions locale and utf8 for some reason, I also confirmed it
behaves the same with LANG=C.

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

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

Versions of packages mypaint depends on:
ii  gir1.2-gtk-3.0   3.18.9-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-7
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libgcc1  1:5.3.1-14
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.0-1
ii  libgomp1 5.3.1-14
ii  libgtk-3-0   3.18.9-1
ii  libjson-c3   0.12-3
ii  liblcms2-2   2.7-1
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpng16-16  1.6.21-2
ii  libpython2.7 2.7.11-8
ii  libstdc++6   5.3.1-14
ii  mypaint-data 1.2.0-1.1
ii  python   2.7.11-1
ii  python-gi-cairo  3.20.0-2
ii  python-numpy 1:1.11.0-1
pn  python2.7:any
pn  python:any   

Versions of packages mypaint recommends:
ii  shared-mime-info  1.5-2

Versions of packages mypaint suggests:
pn  mypaint-data-extras  

-- no debconf information