Bug#793516: killer kills running sshd session instances

[Mike Gabriel]

Package: killer
Version: 0.90-12
Severity: important

Today I saw killer kill sshd user processes (i.e., active SSH sessions).

This should not happen. It happened on a Debian Edu jessie main server (after 
(dist-)upgrade from squeeze).

I will investigate further and provide more info while upgrading our customer 
site / deploying a new school in Lübeck.

Mike
 
-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976148

GnuPG Key ID 0x25771B13
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de


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

Bug#791367: Unable to reproduce error

[Haley Kubala]

tags 791367 + unreproducible
thanks

I was unable to reproduce the error. This built fine for me in a sid/gcc build 
enviroment.

--
Haley Kubala
Linux for HP Helion OpenStack, Hewlett-Packard


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

Bug#793517: FTBFS: fails to detect FLTK 1.3 during cmake configure

[Chris West (Faux)]

Source: fgrun
Version: 3.4.0.final-1
Severity: serious
Tags: sid
Justification: fails to build from source (but built successfully in the past)
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs

Dear Maintainer,

The package fails to build:

-- Using FLTK_LIBRARIES for fgrun: 
fltk_forms_SHARED;fltk_gl_SHARED;fltk_images_SHARED;fltk_SHARED;dl;dl
-- Performing Test HAVE_FLTK_1_3
-- Performing Test HAVE_FLTK_1_3 - Failed
CMake Error at CMakeLists.txt:245 (message):
  FLTK 1.3 is required


-- Configuring incomplete, errors occurred!

Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/fgrun.html

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

Kernel: Linux 3.19.0-23-generic (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)


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

Bug#793419: RFS: mirage/0.9.5.2-1 ITA

[Thomas Ross]

Okay. I have fixed that problem:

Mentors Page: http://mentors.debian.net/package/mirage
dget command:  dget -x
http://mentors.debian.net/debian/pool/main/m/mirage/mirage_0.9.5.2-1.dsc

Regards,
Thomas



On Thu, 23 Jul 2015 18:08:40 -0300 Eriberto 
wrote:
> tags 793419 moreinfo
> thanks
> 
> 
> Hi,
> 
> Note that you need work over the last revision in unstable (0.9.5.1-5).
> 
> Regards,
> 
> Eriberto
> 
> 
> 
> 2015-07-23 17:56 GMT-03:00 Thomas Ross :
> > Package: sponsorship-requests
> > Severity: normal
> >
> > Dear mentors,
> >
> > I am looking for a sponsor for my package "mirage"
> >
> >  * Package name: mirage
> >Version : 0.9.5.2-1
> >Upstream Author : Scott Horowitz 
> >  * URL : http://mirageiv.berlios.de/
> >  * License : GPL-3
> >Section : graphics
> >
> > It builds those binary packages:
> >
> > mirage - fast and simple GTK+ image viewer
> >
> >   To access further information about this package, please visit the
> > following URL:
> >
> >   http://mentors.debian.net/package/mirage
> >
> >
> >   Alternatively, one can download the package with dget using this command:
> >
> > dget -x
> > http://mentors.debian.net/debian/pool/main/m/mirage/mirage_0.9.5.2-1.dsc
> >
> >   More information about hello can be obtained from http://www.example.com.
> >
> >   Changes since the last upload:
> >
> > mirage (0.9.5.2-1) UNRELEASED; urgency=medium
> >
> >   * New upstream release
> >   * Save EXIF/XMP/IPTC data upon modification (Closes: #513025)
> >   * Bump Standards-Version to 3.9.6
> >   * Package adopted (Closes: #6329890)
> >
> >  -- Thomas Ross   Wed, 22 Jul 2015 22:30:32 -0400
> >
> >
> >
> >   Regards,


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

Bug#793515: FTBFS: sphinx: LoginHandler: 'module' object has no attribute 'GoogleMixin'

[Chris West (Faux)]

Source: flower
Version: 0.7.0+dfsg-2
Severity: serious
Tags: sid
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs

Dear Maintainer,

The package fails to build:

make[2]: Entering directory '/tmp/buildd/flower-0.7.0+dfsg/docs'
sphinx-build -b man -d .build/doctrees  -D today="April 13, 2015" . .build/man
Making output directory...
Running Sphinx v1.2.3

Exception occurred:
  File "/tmp/buildd/flower-0.7.0+dfsg/flower/views/auth.py", line 17, in 

class LoginHandler(BaseHandler, tornado.auth.GoogleMixin):
AttributeError: 'module' object has no attribute 'GoogleMixin'


Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/flower.html

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

Kernel: Linux 3.19.0-23-generic (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)


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

Bug#792485: etckeeper/git sets SSH host key perms to 644

[Antoine Beaupré]

Hi,

Thanks for the bug report. Normally, such bugs should be reported to
secur...@debian.org with the package maintainer in CC instead of in a
public bug tracker, but let's deal with it now that it's public...

I can confirm the bug: doing a checkout or a reset exposes private files
in `/etc` to all users, bypassing metadata saved in `/etc/.etckeeper`.

A workaround is to setup the `20restore-etckeeper` script as a
post-checkout, post-merge and post-commit hooks:

ln -s /etc/etckeeper/init.d/20restore-etckeeper /etc/.git/hooks/post-checkout
ln -s /etc/etckeeper/init.d/20restore-etckeeper /etc/.git/hooks/post-commit
ln -s /etc/etckeeper/init.d/20restore-etckeeper /etc/.git/hooks/post-merge

Unfortunately, no git hook is ran when you do git reset:

https://stackoverflow.com/questions/17247402/is-there-a-git-hook-that-runs-on-git-reset

So basically, we are screwed: there's no way for etckeeper to fix this
bug for all git commands. This would be a git bug, I believe... 

I'm hesitant in doing an upload that "fixes" this because it will give a
false sense of security: some commands will work, others won't. I'd love
to hear from Joey, the upstream author, about how to fix this
better.

The only other thing i could think of that may fix this are smudge
filters, that run whenever code is checked out.

In any case, any of those hacks will make any working tree operations
much slower because the above hook runs *all* the permission changes,
not only the relevant ones...

Any other bright ideas?

A.

-- 
Imagination is more important than knowledge
- Albert Einstein


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

Bug#793513: plasma-workspace: plasmashell crashes on shutdown

[Martin Steigerwald]

Am Freitag, 24. Juli 2015, 21:08:43 schrieb Daniel Schaal:
> Package: plasma-workspace
> Version: 4:5.3.2-3
> Severity: normal
> 
> plasmashell crashes ocassionally when shutting down, there already
> is a upstream report [0] and a upstream patch [1], backporting
> that patch fixes this problem.

Thank you. Also for including hint to upstream report and patch.

I can confirm this on one of my Plasma sessions.

On shutdown plasmashell crashes, then is restarted, then the session will 
short down without another crash.

Thanks,
-- 
Martin


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

Bug#793514: FTBFS: conflicting types for append_int

[Chris West (Faux)]

Source: staden
Version: 2.0.0+b10-1.1
Severity: serious
Tags: sid
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs

Dear Maintainer,

The package fails to build:

sam_index.c:321:14: error: conflicting types for ‘append_int’
 static char *append_int(char *cp, int i) {
  ^
In file included from /usr/include/io_lib/scram.h:52:0,
 from sam_pileup.h:4,
 from sam_index.c:17:
/usr/include/io_lib/bam.h:755:16: note: previous declaration of ‘append_int’ 
was here
 unsigned char *append_int(unsigned char *cp, int32_t i);
^
/staden-2.0.0+b10/./gap5/../global.mk:388: recipe for target 'sam_index.o' 
failed
make[2]: *** [sam_index.o] Error 1
make[2]: Leaving directory '/staden-2.0.0+b10/gap5'


Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/staden.html

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

Kernel: Linux 3.19.0-23-generic (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)


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

Bug#793508: I just asked upstream in which version gravatar.com support was added

[Martin Steigerwald]

To find out which package versions in Debian are affected.

Will let you know.

Thanks,
-- 
Martin


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

Bug#790703: Status moving forward?

[Nicola Chiapolini]

Control: severity -1 grave
Control: thanks

I am in the same situation as Matthew and run into this when upgrading my 
testing install. To get a usable KDE back, I had to downgrade. I raised the 
severity again, this way people with the listbugs in the default config at 
least get a warning.

cheers
Nicola


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

Bug#793513: plasma-workspace: plasmashell crashes on shutdown

[Daniel Schaal]

Package: plasma-workspace
Version: 4:5.3.2-3
Severity: normal

plasmashell crashes ocassionally when shutting down, there already
is a upstream report [0] and a upstream patch [1], backporting
that patch fixes this problem.

[0] https://bugs.kde.org/show_bug.cgi?id=348511
[1] http://commits.kde.org/plasma-workspace/4942878b67

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

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

Versions of packages plasma-workspace depends on:
ii  dbus-x111.8.20-1
ii  frameworkintegration5.12.0-1
ii  gdb 7.7.1+dfsg-5
ii  kactivities 5.12.0-1
ii  kde-cli-tools   4:5.3.2-2
ii  kded5   5.12.0-1
ii  kinit   5.12.0-1
ii  kio 5.12.0-1
ii  kio-extras  4:5.3.2-2
ii  libc6   2.19-19
ii  libcln6 1.3.4-1
ii  libdbusmenu-qt5-2   0.9.3+15.10.20150604-1
ii  libgcc1 1:5.1.1-14
ii  libgps213.11-3
ii  libice6 2:1.0.9-1+b1
ii  libkf5activities5   5.12.0-1
ii  libkf5auth5 5.12.0-1
ii  libkf5baloo15.9.2-3
ii  libkf5bookmarks55.12.0-1
ii  libkf5completion5   5.12.0-1
ii  libkf5configcore5   5.12.0-1
ii  libkf5configgui55.12.0-1
ii  libkf5configwidgets55.12.0-1
ii  libkf5coreaddons5   5.12.0-1
ii  libkf5crash55.12.0-1
ii  libkf5dbusaddons5   5.12.0-1
ii  libkf5declarative5  5.12.0-2
ii  libkf5globalaccel-bin   5.12.0-1
ii  libkf5globalaccel5  5.12.0-1
ii  libkf5guiaddons55.12.0-1
ii  libkf5i18n5 5.12.0-1
ii  libkf5iconthemes5   5.12.0-1
ii  libkf5idletime5 5.12.0-1
ii  libkf5itemviews55.12.0-1
ii  libkf5jobwidgets5   5.12.0-1
ii  libkf5js5   5.12.0-1
ii  libkf5jsembed5  5.12.0-1
ii  libkf5kdelibs4support5  5.12.0-2
ii  libkf5kiocore5  5.12.0-1
ii  libkf5kiofilewidgets5   5.12.0-1
ii  libkf5kiowidgets5   5.12.0-1
ii  libkf5networkmanagerqt6 5.12.0-1
ii  libkf5newstuff5 5.12.0-1
ii  libkf5notifications55.12.0-1
ii  libkf5notifyconfig5 5.12.0-1
ii  libkf5package5  5.12.0-1
ii  libkf5plasma5   5.12.0-1
ii  libkf5plasmaquick5  5.12.0-1
ii  libkf5runner5   5.12.0-1
ii  libkf5screen6   4:5.3.2-1
ii  libkf5service-bin   5.12.0-1
ii  libkf5service5  5.12.0-1
ii  libkf5solid55.12.0-1
ii  libkf5su5   5.12.0-1
ii  libkf5texteditor5   5.12.0-1
ii  libkf5textwidgets5  5.12.0-1
ii  libkf5wallet5   5.12.0-1
ii  libkf5waylandclient54:5.3.2-1
ii  libkf5waylandserver54:5.3.2-1
ii  libkf5webkit5   5.12.0-1
ii  libkf5widgetsaddons55.12.0-1
ii  libkf5windowsystem5 5.12.0-1
ii  libkf5xmlgui5   5.12.0-1
ii  libkf5xmlrpcclient5 5.12.0-1
ii  libksgrd7   4:5.3.2-2
ii  libkworkspace5-54:5.3.2-3.1
ii  libpam0g1.1.8-3.1
ii  libphonon4qt5-4 4:4.8.0-5
ii  libplasma-geolocation-interface54:5.3.2-3.1
ii  libprocesscore7 4:5.3.2-2
ii  libprocessui7   4:5.3.2-2
ii  libqalculate5   0.9.7-9
ii  libqt5core5a5.4.2+dfsg-4
ii  libqt5dbus5 5.4.2+dfsg-4
ii  libqt5gui5  5.4.2+dfsg-4
ii  libqt5network5  5.4.2+dfsg-4
ii  libqt5qml5  5.4.2-3
ii  libqt5quick55.4.2-3
ii  libqt5script5   5.4.2+dfsg-2
ii  libqt5sql5  5.4.2+dfsg-4
ii  libqt5webkit5   5.4.2+dfsg-2
ii  libqt5widgets5  5.4.2+dfsg-4
ii  libqt5x11extras55.4.2-2
ii  libqt5xml5  5.4.2+dfsg-4
ii  libsm6  2:1.2.2-1+b1

Bug#793512: htslib: FTBFS on hurd-i386: 'PATH_MAX' undeclared

[Aaron M. Ucko]

Source: htslib
Version: 1.2.1-1
Severity: important

The hurd-i386 build of htslib failed because the Hurd has no hard
limit on path lengths:

cram/cram_index.c: In function 'cram_index_load':
cram/cram_index.c:142:14: error: 'PATH_MAX' undeclared (first use in this 
function)
 char fn2[PATH_MAX];

I'd suggest conditionally imposing your own limit; I believe 4096 is
traditional.

Thanks!


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

Bug#793511: pinba-engine-mysql: FTBFS (32-bit): cannot convert 'uint64_t*' to 'Word_t*

[Aaron M. Ucko]

Source: pinba-engine-mysql
Version: 1.1.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Builds of pinba-engine-mysql for 32-bit architectures such as i386 are
failing:

  ha_pinba.cc: In member function 'int ha_pinba::read_next_row(unsigned char*, 
uint, bool)':
  ha_pinba.cc:2687:59: error: cannot convert 'uint64_t* {aka long long unsigned 
int*}' to 'Word_t* {aka long unsigned int*}' for argument '2' to 'void** 
JudyLNext(Pcvoid_t, Word_t*, PJError_t)'
   ppvalue = JudyLNext(D->tag.name_index, &str_hash, NULL);
 
Could you please take a look?

Thanks!


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

Bug#777967: libphonenumber: ftbfs with GCC-5

[tony mancill]

On 07/21/2015 08:13 AM, Matthias Klose wrote:
> Control: tags -1 + patch
> 
> packaged a new upstream version, the library needs a transition anyway. Would 
> it
> be ok to upload this version to experimental?
> 
> package at
> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+sourcepub/5227114/+listing-archive-extra

Hi Matthias,

Thank you for packaging this update.  Feel free to upload to
experimental, but I'll work on getting 7.0.8 into Debian experimental if
you don't beat me to it.

Cheers,
tony



signature.asc
Description: OpenPGP digital signature

Bug#793307: [Aptitude-devel] Bug#793307: Bug#793307: aptitude: Add a confirmation for changing 'automatic' flag

[Manuel A. Fernandez Montecelo]

2015-07-22 20:01 artem_banschikov:

On Wed, 22 Jul 2015 19:24:07 +0200 Axel Beckert  wrote:
Hi,

If we do so, we should

a) make it optional (on by default is fine for me),

Completely agree.

b) only ask for confirmation if it would catch more than one package
   (i.e. for whole branches)

I thought about three options: ask for one package, ask for multiple
packages, not ask at all. There is file deletion dialog in Ranger
file-manager made in this way.

c) only for "m", not for "M" (as the subject may suggest)

Confirmation for "M" may be added for consistency.

Anyway I'll be glad if you make exactly as you said as it will entirely solve
my problem.

Best regards, Artyom.



What about Undo (Control-U), as Axel suggested in the previous e-mail?

IMO it is a more general solution, and already implemented, so it should be
favoured rather than adding these new options (unless it does not work).


Cheers.
--
Manuel A. Fernandez Montecelo 


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

Bug#788147: libtap-parser-sourcehandler-pgtap-perl: diff for NMU version 3.29-1.1, take two

[Damyan Ivanov]

Hi again,

Here's second version of the NMU diff, this time also fixing the 
runtime dependency for Test::Harness.

Previous NMU cancelled, this one uploaded to DELAYED/5 again.


Cheers,
dam
diff -Nru libtap-parser-sourcehandler-pgtap-perl-3.29/debian/changelog libtap-parser-sourcehandler-pgtap-perl-3.29/debian/changelog
--- libtap-parser-sourcehandler-pgtap-perl-3.29/debian/changelog	2013-12-29 21:43:23.0 +0200
+++ libtap-parser-sourcehandler-pgtap-perl-3.29/debian/changelog	2015-07-24 21:46:48.0 +0300
@@ -1,3 +1,11 @@
+libtap-parser-sourcehandler-pgtap-perl (3.29-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace perl-modules alternative (build) dependency with plain perl
+Closes: #788147
+
+ -- Damyan Ivanov   Fri, 24 Jul 2015 18:46:46 +
+
 libtap-parser-sourcehandler-pgtap-perl (3.29-1) unstable; urgency=low
 
   * Imported Upstream version 3.29
diff -Nru libtap-parser-sourcehandler-pgtap-perl-3.29/debian/control libtap-parser-sourcehandler-pgtap-perl-3.29/debian/control
--- libtap-parser-sourcehandler-pgtap-perl-3.29/debian/control	2013-12-29 21:42:07.0 +0200
+++ libtap-parser-sourcehandler-pgtap-perl-3.29/debian/control	2015-07-24 21:42:39.0 +0300
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Pierre Chifflier 
 Build-Depends: debhelper (>= 9),
-perl-modules (>= 5.14) | libtest-harness-perl (>=3.23),
+perl (>= 5.14) | libtest-harness-perl (>=3.23),
 libtest-pod-coverage-perl,
 libtest-pod-perl
 Standards-Version: 3.9.5
@@ -11,7 +11,7 @@
 
 Package: libtap-parser-sourcehandler-pgtap-perl
 Architecture: all
-Depends: ${misc:Depends}, ${perl:Depends}, perl-modules (>= 5.14) | libtest-harness-perl (=3.23-1)
+Depends: ${misc:Depends}, ${perl:Depends}, perl (>= 5.14) | libtest-harness-perl (>= 3.23)
 Conflicts: pgtap (<= 0.24-1)
 Description: Unit testing tools for pgTAP
  TAP::Parser::SourceHandler::pgTAP is a set of tools for PostgreSQL unit

Bug#793510: Uninstallable: Depends: python-sqlalchemy (< 0.10) but 1.0.8+ds1-1 is in sid

[Chris West (Faux)]

Package: python-sqlsoup
Version: 0.9.0+dfsg-2
Severity: serious
Tags: sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs

Dear Maintainer,

The package can't be installed due to broken dependencies.
python-sqlalchemy 1.0.6 was uploaded to unstable 2015-06-25.


# apt-get install python-sqlsoup

The following packages have unmet dependencies:
 python-sqlsoup : Depends: python-sqlalchemy (< 0.10) but 1.0.8+ds1-1 is to be 
installed
E: Unable to correct problems, you have held broken packages.

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

Kernel: Linux 3.19.0-22-generic (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)


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

Bug#793509: FTBFS: test_leftover and test_one_newline fail when stdin is closed(?)

[Chris West (Faux)]

Source: exabgp
Version: 3.4.12-1
Severity: important
Tags: sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs

Dear Maintainer,

When stdin is closed (e.g. when the build is being run automatically by a 
builder)
the some of the tests fail:

env INTERPRETER=python ETC=/tmp/buildd/exabgp-3.4.12/etc/exabgp 
exabgp_log_enable=false nosetests ./qa/tests/*_test.py
F.F..
==
FAIL: test_leftover (control_test.TestControl)
--
Traceback (most recent call last):
  File "/tmp/buildd/exabgp-3.4.12/qa/tests/control_test.py", line 76, in 
test_leftover
self.validate('-\nx\n-','x')
  File "/tmp/buildd/exabgp-3.4.12/qa/tests/control_test.py", line 59, in 
validate
self.assertEqual(string, check)
AssertionError: '' != 'x'

==
FAIL: test_one_newline (control_test.TestControl)
--
Traceback (most recent call last):
  File "/tmp/buildd/exabgp-3.4.12/qa/tests/control_test.py", line 69, in 
test_one_newline
self.validate('x\n','x')
  File "/tmp/buildd/exabgp-3.4.12/qa/tests/control_test.py", line 59, in 
validate
self.assertEqual(string, check)
AssertionError: '' != 'x'

You can reproduce this with some:

$ :|dpkg-buildpackage


Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/exabgp.html

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

Kernel: Linux 3.19.0-22-generic (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)


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

Bug#746967: buildd.debian.org: d-i daily builds happen with unsigned code from alioth

[Cyril Brulebois]

Aurelien Jarno  (2015-07-24):
> On 2015-07-24 19:49, Cyril Brulebois wrote:
> > Hi Aurélien,
> > 
> > Aurelien Jarno  (2015-03-18):
> > > With the help of Hector Oron, we have been able to setup this on the
> > > porterbox of 4 architectures: arm64, armel, armhf and mips. This has
> > > been done by allowing the d-i role account on the porterboxes. As a
> > > nice side effect, this mean that d-i people can now do/fix the setup
> > > themselves without having to go through the buildd team. The code used
> > > is available in the porterbox branch of the di-autobuild git.
> > > 
> > > Note that the chroots on the porterbox are created in a very similar
> > > way than on the newer buildds (it's even done by the same script
> > > IIRC), so the problems should be similar. For example both were
> > > affected by bug#775136.
> > 
> > Is there any doc on how to create the needed bits on a porterbox to add
> > d-i autobuilding? I suspect anyone in the d-i group should be able to do
> > so (plus the ssh key dance on dillon afterwards)? I've pinged Hector but
> > apparently he didn't have the procedure in mind. :)
> > 
> > It'd be nice to have that (1) for later uses of course, and (2) so that
> > I can set up d-i autobuilding on abel again since it got reinstalled
> > recently.
> 
> I don't know if you can consider that as a documentation, but there is
> a procedure in the README file in the git [1]. Be sure to select the
> proper branch though (currently 'master' for the code for the buildds
> and 'porterbox' for the code for the porterboxes).
> 
> Aurelien
> 
> [1] https://buildd.debian.org/git/di-autobuild.git

Apparently most files are actually already there on abel, and it might
be that the only missing bit is the crontab entry (I'll see what happens
with the currently running manual build).

But the README certainly looks like what I was hoping for, thanks!


Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#718816: Bug#749355: parallel: /usr/bin/parallel conflicts with moreutils' parallel

[Antoine Beaupré]

On 2015-07-11 15:24:09, Nicolas Schier wrote:
> Dear Antoine,
>
> thanks for your good summary and your patience ...
>
> just to get it right, could you please check if I did get it right (the 
> moreutils side):
>
>  1. Package 'moreutils' installs /usr/bin/mparallel and depends on 
> package 'moreutils-parallel'; the latter installs a symlink
> /usr/bin/parallel -> mparallel
> 'moreutils-parallel' conflicts 'parallel-gnu' and 'parallel <= 
> 20141022+ds1-1'

I suggested /usr/bin/parallel.moreutils - it seems less ambiguous than
mparallel and will allow discovery through commandline completion.

This otherwise seems to make sense.

>  2. 'ikiwiki-hosting' is changed to use 'mparallel' or to depend on 
> 'moreutils-parallel' and use '/usr/bin/parallel'
> 'ikiwiki-hosting' is changed to stop conflicting with parallel

Good.

>  3. Package 'moreutils' recommends (no more depends) on 
> 'moreutils-parallel'

Also makes sense.

>> It's my first time dealing with diversions so I hope I got this
>> right. Any constructive modifications on the above checklists are
>> welcome here!
>
> Right now, I can't see why we should use diversions: if 
> moreutils-parallel and parallel-gnu conflict with each other and just 
> install a symlink to their implementation each, everything should be 
> clear.  Or did I get something wrong?

I am not sure. I had the idea of using diversions instead of symlinks to
handle the /usr/bin/parallel command itself. But now I am not sure it's
the right way to go.

If we use symlinks, shouldn't we use the alternatives system? Then it
would avoid making the two packages conflict with each other too... The
problem with that, of course, is we then do not know which version we
are using and have no way of enforcing that.

So I guess your approach is better. I am not sure how to handle this
otherwise.

A.

-- 
Either you're with us or you're with the terrorist state.


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

Bug#793507: linux-image-3.2.0-4-amd64: Repeated "BUG: soft lockup" followed by system freeze

[Benjamin Moody]

Package: src:linux
Version: 3.2.68-1+deb7u2
Severity: important

Dear Maintainer,

The kernel reported a series of messages of the form "BUG: soft lockup":

$ grep BUG /var/log/syslog.1
Jul 23 01:33:00 physionet2 kernel: [08.348031] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 01:33:28 physionet2 kernel: [36.348024] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 01:34:08 physionet2 kernel: [76.348025] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 01:34:36 physionet2 kernel: [555604.348024] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 01:35:04 physionet2 kernel: [555632.348024] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 01:35:32 physionet2 kernel: [555660.348025] BUG: soft lockup - CPU#3 
stuck for 23s! [apache2:7555]
...
Jul 23 03:10:12 physionet2 kernel: [561340.348023] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 03:10:12 physionet2 kernel: [561340.532039] BUG: soft lockup - CPU#5 
stuck for 23s! [ATM:30084]
Jul 23 03:10:13 physionet2 kernel: [561340.992064] BUG: soft lockup - CPU#10 
stuck for 22s! [challenge-d:6735]
Jul 23 03:10:13 physionet2 kernel: [561341.084076] BUG: soft lockup - CPU#11 
stuck for 22s! [apcupsd:2873]
Jul 23 03:10:13 physionet2 kernel: [561341.268087] BUG: soft lockup - CPU#13 
stuck for 22s! [ATM:20277]
Jul 23 03:10:40 physionet2 kernel: [561368.072017] BUG: soft lockup - CPU#0 
stuck for 22s! [kswapd0:93]
$ grep BUG /var/log/syslog.1 | wc -l
298

(Full contents of one of these messages shown below.)

As you can see, this happened many times over a period of an hour and
a half.  During this time, the system was still working on some level
(the apache log shows a steady stream of requests), but I have no idea
if anything unusual was going on.  At 03:01:06, the apache log stops.
At 03:10:40, the system log abruptly cuts off in the middle of an
error message.

When I came to look at the machine the next day, it was *mostly*
frozen - neither apache, nor ssh, nor any other network services were
responding; however, it still responded to pings, and nmap still
reported various ports as open.  The console was blank and did not
respond to CapsLock, NumLock, nor Ctrl+Alt+Delete.

I have no idea how to debug this.  Obviously a web search turns up
huge numbers of results for "BUG: soft lockup" (including other Debian
bugs), but I have no idea if any of them are relevant to my case, nor
have I found any information about how to narrow down the problem.
Please tell me if there is anything I can do to make it possible to
figure out what is going on if this happens in the future.

The first error message:
-
Jul 23 01:33:00 physionet2 kernel: [08.348031] BUG: soft lockup - CPU#3 
stuck for 22s! [apache2:7555]
Jul 23 01:33:00 physionet2 kernel: [08.348145] Modules linked in: 
ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables 
ipt_REJECT xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack 
iptable_filter ip_tables x_tables nfsd nfs nfs_acl auth_rpcgss fscache lockd 
sunrpc xfs loop cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod 
radeon snd_pcm ttm drm_kms_helper drm snd_page_alloc power_supply snd_timer 
amd64_edac_mod nv_tco snd k10temp i2c_nforce2 i2c_algo_bit edac_mce_amd shpchp 
soundcore edac_core evdev i2c_core mperf pcspkr psmouse serio_raw processor 
thermal_sys button ext4 crc16 jbd2 mbcache sr_mod cdrom sg usbhid mptsas hid 
scsi_transport_sas mptscsih sd_mod crc_t10dif ata_generic e1000e pata_amd 
mptbase e1000 3w_9xxx ohci_hcd sata_nv libata ehci_hcd usbcore scsi_mod 
usb_common [last unloaded: scsi_wait_scan]
Jul 23 01:33:00 physionet2 kernel: [08.348226] CPU 3 
Jul 23 01:33:00 physionet2 kernel: [08.348228] Modules linked in: 
ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables 
ipt_REJECT xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack 
iptable_filter ip_tables x_tables nfsd nfs nfs_acl auth_rpcgss fscache lockd 
sunrpc xfs loop cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod 
radeon snd_pcm ttm drm_kms_helper drm snd_page_alloc power_supply snd_timer 
amd64_edac_mod nv_tco snd k10temp i2c_nforce2 i2c_algo_bit edac_mce_amd shpchp 
soundcore edac_core evdev i2c_core mperf pcspkr psmouse serio_raw processor 
thermal_sys button ext4 crc16 jbd2 mbcache sr_mod cdrom sg usbhid mptsas hid 
scsi_transport_sas mptscsih sd_mod crc_t10dif ata_generic e1000e pata_amd 
mptbase e1000 3w_9xxx ohci_hcd sata_nv libata ehci_hcd usbcore scsi_mod 
usb_common [last unloaded: scsi_wait_scan]
Jul 23 01:33:00 physionet2 kernel: [08.348274] 
Jul 23 01:33:00 physionet2 kernel: [08.348278] Pid: 7555, comm: apache2 Not 
tainted 3.2.0-4-amd64 #1 Debian 3.2.68-1+deb7u2 Supermicro H8QM3/H8QM3
Jul 23 01:33:00 physionet2 kernel: [08.348284] RIP: 
0010:[]  [] __bitmap_empty+0xa/0x52
Jul 23 01:33:00 physionet2 kernel: [08.348296] RSP: 0018:880432583d88  
EFLAGS: 021

Bug#793508: kmail: contacts gravatar.com to fetch face images of senders of opened mails by default

[Martin Steigerwald]

Package: kmail
Version: 4:4.14.5-1
Severity: important

Dear Maintainer,

I just found out after reading kde-pim upstream mailing list that KMail as
packaged in Debian experimental, I am not sure whether the Sid version is
also affected, contacts gravatar.com to fetch face images of senders of
opened mails by default¹.

This was not the intention of the developer adding gravatar.com support to
it.

I just posted the following information to debian-kde mailing list:

---
If you do not want KMail to connect to gravatar.com to find faces for mail
identities, you can disable it in Configure / Appearance / Message window
(last one roughly translated from german).
---

But as not everyone reads it and this is a privacy leak, it may make sense
to upload a package that changes the default.

As to the thread the "enabled by default" mistake has been fixed in KF5
based kmail which is due to release with KDE Applications 15.08 in August.

Please note it is not my intention to point fingers or such. I assume good
intentions, errors can happen. So this is just about fixing the privacy
leak being enabled by default.


[1] kde-pim mailinglist, Thread "[Kde-pim] how does kmail find face-like
images from mail senders ?" started by Martin Koller, specifically:
Message-ID: <2126112.rfxk9ju...@collossus.ingo-kloecker.de>
Message-ID: <1996527.JvW9aqgcpS@linux-19td>

Mailinglist archive at https://mail.kde.org/pipermail/kde-pim/ is currently
broken.

Thanks,
Martin

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

Kernel: Linux 4.2.0-rc3-tp520-btrfstrim+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages kmail depends on:
ii  kde-runtime   4:14.12.3-1
ii  kdepim-runtime4:4.14.6-1
ii  kdepimlibs-kio-plugins4:4.14.6-1
ii  libakonadi-calendar4  4:4.14.6-1
ii  libakonadi-contact4   4:4.14.6-1
ii  libakonadi-kde4   4:4.14.6-1
ii  libakonadi-kmime4 4:4.14.6-1
ii  libakonadiprotocolinternals1  1.13.0-7
ii  libc6 2.19-19
ii  libcalendarsupport4   4:4.14.5-1
ii  libfollowupreminder4  4:4.14.5-1
ii  libgcc1   1:5.1.1-14
ii  libgpgme++2   4:4.14.6-1
ii  libgrantlee-core0 0.4.0-2
ii  libincidenceeditorsng44:4.14.5-1
ii  libkabc4  4:4.14.6-1
ii  libkalarmcal2 4:4.14.6-1
ii  libkcalcore4  4:4.14.6-1
ii  libkcalutils4 4:4.14.6-1
ii  libkcmutils4  4:4.14.2-5
ii  libkdecore5   4:4.14.2-5
ii  libkdepim44:4.14.5-1
ii  libkdeui5 4:4.14.2-5
ii  libkio5   4:4.14.2-5
ii  libkleo4  4:4.14.5-1
ii  libkmanagesieve4  4:4.14.5-1
ii  libkmime4 4:4.14.6-1
ii  libknotifyconfig4 4:4.14.2-5
ii  libkontactinterface4a 4:4.14.6-1
ii  libkparts44:4.14.2-5
ii  libkpgp4  4:4.14.5-1
ii  libkpimidentities44:4.14.6-1
ii  libkpimtextedit4  4:4.14.6-1
ii  libkpimutils4 4:4.14.6-1
ii  libkprintutils4   4:4.14.2-5
ii  libksieveui4  4:4.14.5-1
ii  libmailcommon44:4.14.5-1
ii  libmailimporter4  4:4.14.5-1
ii  libmailtransport4 4:4.14.6-1
ii  libmessagecomposer4   4:4.14.5-1
ii  libmessagecore4   4:4.14.5-1
ii  libmessagelist4   4:4.14.5-1
ii  libmessageviewer4 4:4.14.5-1
ii  libpimcommon4 4:4.14.5-1
ii  libqt4-dbus   4:4.8.7+dfsg-1
ii  libqt4-network4:4.8.7+dfsg-1
ii  libqt4-xml4:4.8.7+dfsg-1
ii  libqtcore44:4.8.7+dfsg-1
ii  libqtgui4 4:4.8.7+dfsg-1
ii  libqtwebkit4  2.3.4.dfsg-3
ii  libsendlater4 4:4.14.5-1
ii  libsolid4 4:4.14.2-5
ii  libstdc++65.1.1-14
ii  libtemplateparser44:4.14.5-1
ii  perl  5.20.2-6

Versions of packages kmail recommends:
ii  gnupg-agent 2.0.28-3
ii  gnupg2  2.0.28-3
ii  kdepim-doc  4:4.14.5-1
pn  kdepim-themeditors  
ii  ktnef   4:4.14.5-1
ii  pinentry-gnome3 [pinentry-x11]  0.9.5-2
ii  pinentry-gtk2 [pinentry-x11]0.9.5-2
ii  pinentry-qt4 [pinentry-x11] 0.9.5-2

Versions of packages kmail suggests:
ii  bogofilter1.2.4+dfsg1-3
pn  clamav

Bug#793360: More complete patches

[Raphael Hertzog]

Hi,

On Fri, 24 Jul 2015, David Kalnischkies wrote:
> Long story short: I think this hack should finally be replaced with the
> transition of the manual-bit on "removal" of packages. oldlibs packages
> should forward their manual-bit to dependencies on remove (and the
> autoremover calculate with this) just like metapackages should push
> their bit downwards on removal: mydesktop depends mydesktop-core depends
> browser, texteditor. On removal of browser, mydesktop-core and mydesktop
> are removed as well, but the bit of mydesktop is pushed to
> mydesktop-core and that state is pushed further to texteditor. Bonus
> points if no pushing happens if I remove mydesktop explicitely. That
> also means that if mydesktop-core decides that texteditor2 is a better
> texteditor and flips to it the old obsolete texteditor (as well as the
> trillion oldlibs it depends on) can leave my system via autoemove (if
> I am willing to let that happen of course).

I like this! But I'm afraid that I can't justify to spend more time on
this issue (neither to implement this nor to add test cases, I'm sorry).

> I implemented a simple autobit forwarding for disappearing packages and
> at least since then this never-markauto thing is on my list. Having it
> broken entirely now might be a good excuse to finally work on it…
> /me adds it to DebCamp list

/me looks forward to it and I'll be at Debconf too.

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/


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

Bug#789518: wagon2: FTBFS in sid

[Hans Joachim Desserud]

I took a look at this issue, and while I haven't solved the problems
I've found some clues which might be useful for the next person.

One of the things I found was an Ubuntu build log [1] from when it
built successfully. I know some packages have Ubuntu-deltas, but
for the most part its the same set of packages as Debian had at
the time.


adding libxbean-java to Build-Depends makes

no difference.

Looking at the build log, it looks it was already pulled in due
to some dependency or another. I tried looking at whether the
missing class in question had changed in any obvious way in the
meantime, but didn't find anything suspicious.

I also briefly experimented with replacing libxbean-java and a
couple of other packages with .debs from stable, but didn't
see any difference.

What I believe is happening is that some test is run, which
happens to extend PlexusTestCase from plexus-container-default [2]
which again ends up in libxbean-java, does some reflection magic (?)
and fails to find a class. And it looks like the problem is that
something in this chain has changed since the package was built.

What I find really interesting is that I found another RC bug [3]
which has a strangely similar (but not identical!) stacktrace
and ends up complaining about not finding the same class. And
this also goes through PlexusTestCase and the rest of the chain.
So while I don't know what's going on, I'm fairly sure these two
are connected in some way.

[1] 
https://launchpadlibrarian.net/188300331/buildlog_ubuntu-vivid-amd64.wagon2_2.7-1_UPLOADING.txt.gz

[2] https://tracker.debian.org/pkg/plexus-container-default
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788980

--
mvh / best regards
Hans Joachim Desserud
http://desserud.org


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

Bug#793506: python-enum34: enum.enum

[Jakub Wilk]

Package: python-enum34
Version: 1.0.4-1
Severity: minor

$ md5sum /usr/lib/python2*/*/enum/[e_]*.py
eeb357cbf7ef717fe5bea0dced0d  
/usr/lib/python2.7/dist-packages/enum/__init__.py
eeb357cbf7ef717fe5bea0dced0d  /usr/lib/python2.7/dist-packages/enum/enum.py

This is weird...


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

--
Jakub Wilk


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

Bug#793419:

[Thomas Ross]

Sorry, what do you mean by that?

Regards,
Thomas

Bug#746967: buildd.debian.org: d-i daily builds happen with unsigned code from alioth

[Aurelien Jarno]

On 2015-07-24 19:49, Cyril Brulebois wrote:
> Hi Aurélien,
> 
> Aurelien Jarno  (2015-03-18):
> > With the help of Hector Oron, we have been able to setup this on the
> > porterbox of 4 architectures: arm64, armel, armhf and mips. This has
> > been done by allowing the d-i role account on the porterboxes. As a
> > nice side effect, this mean that d-i people can now do/fix the setup
> > themselves without having to go through the buildd team. The code used
> > is available in the porterbox branch of the di-autobuild git.
> > 
> > Note that the chroots on the porterbox are created in a very similar
> > way than on the newer buildds (it's even done by the same script
> > IIRC), so the problems should be similar. For example both were
> > affected by bug#775136.
> 
> Is there any doc on how to create the needed bits on a porterbox to add
> d-i autobuilding? I suspect anyone in the d-i group should be able to do
> so (plus the ssh key dance on dillon afterwards)? I've pinged Hector but
> apparently he didn't have the procedure in mind. :)
> 
> It'd be nice to have that (1) for later uses of course, and (2) so that
> I can set up d-i autobuilding on abel again since it got reinstalled
> recently.

I don't know if you can consider that as a documentation, but there is
a procedure in the README file in the git [1]. Be sure to select the
proper branch though (currently 'master' for the code for the buildds
and 'porterbox' for the code for the porterboxes).

Aurelien

[1] https://buildd.debian.org/git/di-autobuild.git

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


signature.asc
Description: Digital signature

Bug#792532: lynx: w3m consistency would be nice

[Anonymous]

Package: lynx
Version: 2.8.9dev1-2
Followup-For: Bug #792532

Andy,

Thanks for the reply.  In principle, I would not be fussy about how
the fail-safe is implemented, so long as there is a means to fail
safely.

But I suggest that whatever the syntax is, it would be useful if it
were consistent with other browsers.  Inventing yet another way of
expressing something adds complexity to the overall gnu environment.
E.g. isn't it a bit irritating that w3m looks for the variable
"HTTP_PROXY", and lynx looks for "http_proxy"?

For the matter at hand, w3m also lacks a fail-safe, so I created bug
792234 at the same time.  Perhaps there could be some coordination.

If lynx aligns with the "links" browser, links has these options:

  -http-proxy 
  -ftp-proxy 
  -https-proxy 
  -socks-proxy 

  as well as this (poorly worded) option:

  -only-proxies <0>/<1>
 "1" causes that Links won't initiate any non-proxy connection.
 It is useful for anonymization with tor or similar networks.

cURL has:

  -U, --proxy-user 
  -x, --proxy <[protocol://][user:password@]proxyhost[:port]>
  -p, --proxytunnel
  --proxy1.0 
  --proxy-ntlm
  --proxy-digest
  --proxy-basic
  --proxy-anyauth
  --proxy-header 
  --noproxy 

  env vars: http_proxy, HTTPS_PROXY <= it's bizarre that casing is
   inconsistent
wget has:

  --no-proxy
  --proxy-user=user
  --proxy-password=password

  env vars: http_proxy, https_proxy, ftp_proxy, no_proxy

  wget can also force a proxy to be used, but it's somewhat clumsy.
  It requires config file options to be given on the commandline.
  E.g. "wget -e use_proxy=yes -e http_proxy=$proxy http://www.eff.org";

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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 lynx depends on:
ii  lynx-cur  2.8.9dev1-2+b1

lynx recommends no packages.

lynx suggests no packages.

-- no debconf information


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

Bug#787680: Qt5: Applications disappear or crash when screen is switched

[Ralf Jung]

Hi,

>> That patch has now been accepted and merged upstream:
>> 
>> Considering how many KDE packages landed in their Qt 5 version recently,
>> it'd be great if a recent enough snapshot (or 5.5.0 with the patch
>> backported) could fix this issue.
> 
> Sadly the patch is not easy to backport as the code has changed too much 
> between 5.4.2 and 5.0.0 

Yeah, a backport wouldn't be worth it - this builds on top of quite a
few other changes that made the screen stuff much more reliable. The
actual patch only fixes a small missing piece, but it's been the last
piece for me ;-)

> so it won't happen before the gcc5 transition which is 
> due to start in a week.
> 
> I will probably not work too much (if anything at all) in 5.5.0 until we get 
> the gcc5 transition stuff solved, so it will be most probably material for 
> 5.5.1.

I see, okay. Good luck with that transition!

Kind regards,
Ralf


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

Bug#793505: Xjadeo - obsolete PDF in the package

[trebmuh]

Package: xjadeo
Version: 0.8.0-2

Talking with upstream today, it does look that the PDF documentation 
(introduced back in september 2010 by Alessio in this commit 
https://anonscm.debian.org/cgit/pkg-multimedia/xjadeo.git/commit/?id=639142cf16fce704d6d58e96ae262f4fe7a0bc96 
) is by far outdated. Eg: the qt GUI no longer exists, openGL is not 
mentioned, etc..
In addition, there is nowaday an online resource automatically build at 
each release which is much more relevant for any curious user.


Suggestion is to drop it.

Best,
Olivier


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

Bug#777983: Different problem in 0.10.2.2

[Lisandro Damián Nicanor Pérez Meyer]

On Saturday 11 July 2015 12:38:47 Dmitry Smirnov wrote:
[snip]
> Looks like "qtbase-opensource-src" needs to be re-built with "-fPIC"...

Which is the case since 5.4.2 reached unstable on june 22. What that message 
is telling you is that you need to build litecoin with -fPIC.

Also please CC the maintainers of the package when you mark it as affected, I 
could have checked this sooner :-/
 
-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#793504: sysbench dep8 test

[dann frazier]

Source: mysql-5.6
Version: 5.6.25-3
Severity: wishlist
Tags: patch

The attached patch adds a dep8 test that runs sysbench against the server
for 60s. This reproduces a data corruption issue on arm64 and ppc64el
on certain systems.
diff -urpN mysql-5.6-5.6.25.orig/debian/tests/control mysql-5.6-5.6.25/debian/tests/control
--- mysql-5.6-5.6.25.orig/debian/tests/control	2015-07-22 10:51:55.0 -0600
+++ mysql-5.6-5.6.25/debian/tests/control	2015-07-24 11:54:12.973732556 -0600
@@ -2,6 +2,10 @@ Tests: smoke
 Depends: mysql-server-5.6
 Restrictions: allow-stderr needs-root breaks-testbed
 
+Tests: sysbench
+Depends: mysql-server-5.6, sysbench
+Restrictions: allow-stderr needs-root breaks-testbed
+
 Tests: upstream
 Depends: mysql-testsuite-5.6
 Restrictions: allow-stderr breaks-testbed
diff -urpN mysql-5.6-5.6.25.orig/debian/tests/sysbench mysql-5.6-5.6.25/debian/tests/sysbench
--- mysql-5.6-5.6.25.orig/debian/tests/sysbench	1969-12-31 17:00:00.0 -0700
+++ mysql-5.6-5.6.25/debian/tests/sysbench	2015-07-24 11:55:22.526624572 -0600
@@ -0,0 +1,57 @@
+#!/bin/sh
+set -ex
+
+# dep8 sysbench test for mysql-server
+# Author: dann frazier 
+#
+# This test should be declared in debian/tests/control with the
+# following restrictions:
+#
+# needs-root (needed to reset the root mysql password)
+# breaks-testbed (because it resets the root mysql password)
+# allow-stderr
+#
+# This test runs sysbench against a test database. The goal is to see if the
+# server is stable enough to deal with multiple threads of concurrent activity.
+# It serves as a regression test for LP: #1427406 (arm64/ppc64-specific).
+#
+
+debconf-set-selections <

Bug#788568: [Reproducible-builds] Bug#788568: Bug#788568: Bug#788568: still there?

[Mattia Rizzolo]

On Fri, Jul 24, 2015 at 07:41:30PM +0200, Holger Levsen wrote:
> On Freitag, 24. Juli 2015, Mattia Rizzolo wrote:
> > you won't find anything on /tmp because we set TMPDIR on the debbindiff
> > call to a the temporary directory we delete just after the build.
> 
> do we delete this TMPDIR also when we notify about the problem and ask for 
> debugging it? If so we should either stop deleting it or drop the 
> notification. (And if not, what happens to those temp dirs?)

actually we don't, and in the past you could see what was left in the artifacts
directory.. I'm not sure why this time there is none.

>  
> > Though for us is not a problem anymore /tmp, it's still for our user. I
> > renamed the bug title to reflect the current+real problem.
> 
> cool, thanks!

[erm... re-reading my sentence above i see how awful it is :\ sorry]

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: Digital signature

Bug#787680: Qt5: Applications disappear or crash when screen is switched

[Lisandro Damián Nicanor Pérez Meyer]

On Thursday 23 July 2015 12:58:30 Ralf Jung wrote:
[snip] 
> That patch has now been accepted and merged upstream:
> 
> Considering how many KDE packages landed in their Qt 5 version recently,
> it'd be great if a recent enough snapshot (or 5.5.0 with the patch
> backported) could fix this issue.

Sadly the patch is not easy to backport as the code has changed too much 
between 5.4.2 and 5.0.0 so it won't happen before the gcc5 transition which is 
due to start in a week.

I will probably not work too much (if anything at all) in 5.5.0 until we get 
the gcc5 transition stuff solved, so it will be most probably material for 
5.5.1.

Kinds regards, Lisandro.

-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#792532: lynx: w3m consistency would be nice

[Jack Ryan]

Package: lynx
Version: 2.8.9dev1-2
Followup-For: Bug #792532

Andy,

Thanks for the reply.  In principle, I would not be fussy about how
the fail-safe is implemented, so long as there is a means to fail
safely.

But I suggest that whatever the syntax is, it would be useful if it
were consistent with other browsers.  Inventing yet another way of
expressing something adds complexity to the overall gnu environment.
E.g. isn't it a bit irritating that w3m looks for the variable
"HTTP_PROXY", and lynx looks for "http_proxy"?

For the matter at hand, w3m also lacks a fail-safe, so I created bug
792234 at the same time.  Perhaps there could be some coordination.

If lynx aligns with the "links" browser, links has these options:

  -http-proxy 
  -ftp-proxy 
  -https-proxy 
  -socks-proxy 

  as well as this (poorly worded) option:

  -only-proxies <0>/<1>
 "1" causes that Links won't initiate any non-proxy connection.
 It is useful for anonymization with tor or similar networks.

cURL has:

  -U, --proxy-user 
  -x, --proxy <[protocol://][user:password@]proxyhost[:port]>
  -p, --proxytunnel
  --proxy1.0 
  --proxy-ntlm
  --proxy-digest
  --proxy-basic
  --proxy-anyauth
  --proxy-header 
  --noproxy 

  env vars: http_proxy, HTTPS_PROXY <= it's bizarre that casing is
   inconsistent
wget has:

  --no-proxy
  --proxy-user=user
  --proxy-password=password

  env vars: http_proxy, https_proxy, ftp_proxy, no_proxy

  wget can also force a proxy to be used, but it's somewhat clumsy.
  It requires config file options to be given on the commandline.
  E.g. "wget -e use_proxy=yes -e http_proxy=$proxy http://www.eff.org";

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 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 lynx depends on:
ii  lynx-cur  2.8.9dev1-2+b1

lynx recommends no packages.

lynx suggests no packages.

-- no debconf information


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

Bug#791246: confirming transition

[Matthias Klose]

Control: tags -1 + confirmed

needs the transition, or else reverse dependencies will fail to build.


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

Bug#746967: buildd.debian.org: d-i daily builds happen with unsigned code from alioth

[Cyril Brulebois]

Hi Aurélien,

Aurelien Jarno  (2015-03-18):
> With the help of Hector Oron, we have been able to setup this on the
> porterbox of 4 architectures: arm64, armel, armhf and mips. This has
> been done by allowing the d-i role account on the porterboxes. As a
> nice side effect, this mean that d-i people can now do/fix the setup
> themselves without having to go through the buildd team. The code used
> is available in the porterbox branch of the di-autobuild git.
> 
> Note that the chroots on the porterbox are created in a very similar
> way than on the newer buildds (it's even done by the same script
> IIRC), so the problems should be similar. For example both were
> affected by bug#775136.

Is there any doc on how to create the needed bits on a porterbox to add
d-i autobuilding? I suspect anyone in the d-i group should be able to do
so (plus the ssh key dance on dillon afterwards)? I've pinged Hector but
apparently he didn't have the procedure in mind. :)

It'd be nice to have that (1) for later uses of course, and (2) so that
I can set up d-i autobuilding on abel again since it got reinstalled
recently.


Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#788568: [Reproducible-builds] Bug#788568: Bug#788568: still there?

[Holger Levsen]

Hi Mattia,

On Freitag, 24. Juli 2015, Mattia Rizzolo wrote:
> you won't find anything on /tmp because we set TMPDIR on the debbindiff
> call to a the temporary directory we delete just after the build.

do we delete this TMPDIR also when we notify about the problem and ask for 
debugging it? If so we should either stop deleting it or drop the 
notification. (And if not, what happens to those temp dirs?)
 
> Though for us is not a problem anymore /tmp, it's still for our user. I
> renamed the bug title to reflect the current+real problem.

cool, thanks!


cheers,
Holger




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

Bug#791463: Quick review

[Andrew Shadura]

Hi,

If it uses pmake, I think I can help. Hold on.

:)

A.

Bug#793360: More complete patches

[David Kalnischkies]

On Thu, Jul 23, 2015 at 06:59:19PM +0200, Raphael Hertzog wrote:
> Regression introduced in 50ef3344c3afaaf9943142906b2f976a0337d264.

Nitpicking, but that commit "just" breaks this completely, it was broken
before if a package changed sections (like oldlibs usually do) …


In general, I would be happy if you could formalize the manual tests you
have done in a testcase for ./test/integration as that is the kind of
stuff which is never tested manually if you don't happen to suspect
something to be wrong with it in the first place… I mean, the commit you
reference… what could possibly go wrong… q.e.d.


> Up to now, only dependencies leading to new package installations were
> marked as manually installed. With this change, a package that is already
> installed and marked as auto-installed and that is needed to satisfy a
> dependency of a package maching APT::Never-MarkAuto-Sections will be
> switched to manually installed too.

The first patch has similar effects for upgrades, but with the second it
is indeed as you describe… just… what that means is that a user can't
set a package to 'auto' if it happens to be a dependency of
a never-markauto package – or, the user can, but his configuration is
overridden on the next upgrade/install of a depending never-markauto
package as you explicitely set the bit all the time rather than on first
install as before (as advertised in your commit message).

That could be interpreted as ignoring user configuration… at random.
Restoring the old behavior okay, but adding this on top of it… feels
wrong even if I understand why you implemented it.



Frankly, I never liked this "hack". What we are trying to do here is
avoiding theoretical correct autoremove-suggestions on the remove of
certain packages as they are in practice cause for confusion at best and
a big problem for users who follow the suggestion at the worst.

Long story short: I think this hack should finally be replaced with the
transition of the manual-bit on "removal" of packages. oldlibs packages
should forward their manual-bit to dependencies on remove (and the
autoremover calculate with this) just like metapackages should push
their bit downwards on removal: mydesktop depends mydesktop-core depends
browser, texteditor. On removal of browser, mydesktop-core and mydesktop
are removed as well, but the bit of mydesktop is pushed to
mydesktop-core and that state is pushed further to texteditor. Bonus
points if no pushing happens if I remove mydesktop explicitely. That
also means that if mydesktop-core decides that texteditor2 is a better
texteditor and flips to it the old obsolete texteditor (as well as the
trillion oldlibs it depends on) can leave my system via autoemove (if
I am willing to let that happen of course).

I implemented a simple autobit forwarding for disappearing packages and
at least since then this never-markauto thing is on my list. Having it
broken entirely now might be a good excuse to finally work on it…
/me adds it to DebCamp list


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

Bug#793484: expat CVE-2015-1283 affected versions

[GCS]

Control: found -1 2.0.1-7+squeeze1

Squeeze, Wheezy and Jessie versions are all affected by this security issue. :(


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

Bug#793503: lintian: Please warn on obsolete URLs

[Guillem Jover]

Package: lintian
Version: 2.5.35
Severity: wishlist

Hi!

There are several URLs that are known to be obsolete, and that even if
they currently work, will disappear in the future or point to stale sites.

Among those there are at least:

  code.google.com
  gitorious.org
  codehaus.org

I think it would make sense to warn on those whenever they appear at
least in any of the Vcs or Homepage fields.

Thanks,
Guillem


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

Bug#788568: [Reproducible-builds] Bug#788568: still there?

[Mattia Rizzolo]

Control: retitle -1 debbindiff: cleanup the temporary dir after SIGTERM

On Fri, Jul 24, 2015 at 06:41:37PM +0200, Holger Levsen wrote:
> Hi,
> 
> upon seeing this:
> 
> [18:37] -   KGB-2- | (#debian-reproducible) debbindiff calls on 
> https://reproducible.debian.net/unstable/amd64/icedove or 
> https://jenkins.debian.net/job/reproducible_builder_epsilon/21466/console 
> left 
> cruft, please help investigate and fix 788568
> [18:39] -   KGB-2- | (#debian-reproducible) 
> https://reproducible.debian.net/artifacts/r00t-me/icedove_unstable_tmp-5QgiE/ 
> published, debbindiff 26 had troubles with these...
> 
> I checked /tmp and found nothing related:
> 
> root@jenkins:~# find /tmp -maxdepth 1 -name tmp*debbindiff | xargs ls -ld
> drwx-- 15 root root 12288 Jul 20 13:33 .
> root@jenkins:~#
> 
> So I wonder if this bug can be closed and the irc notification turned off?


Yes, it's still there.

you won't find anything on /tmp because we set TMPDIR on the debbindiff call to
a the temporary directory we delete just after the build.

Though for us is not a problem anymore /tmp, it's still for our user. I renamed
the bug title to reflect the current+real problem.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: Digital signature

Bug#793502: workrave: Workrave doesn't show icon in system tray of kde plasma 5

[Michael Meier]

Package: workrave
Version: 1.10.6-2
Severity: normal

workrave needs to be updated to show an icon in the new kde plasma 5 system 
tray.
as a lot of older applications it can't show them there anymore.


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

Kernel: Linux 4.0.0-2-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 workrave depends on:
ii  libatk1.0-0  2.16.0-2
ii  libatkmm-1.6-1   2.22.7-2.1
ii  libc62.19-19
ii  libcairo-gobject21.14.2-2
ii  libcairo21.14.2-2
ii  libcairomm-1.0-1 1.10.0-1.1
ii  libdbusmenu-glib412.10.2-1
ii  libdbusmenu-gtk3-4   12.10.2-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-4
ii  libgcc1  1:5.1.1-14
ii  libgdk-pixbuf2.0-0   2.31.4-2
ii  libgdome2-0  0.8.1+debian-6
ii  libglib2.0-0 2.44.1-1.1
ii  libglibmm-2.4-1c2a   2.44.0-1
ii  libgstreamer0.10-0   0.10.36-1.5
ii  libgtk-3-0   3.16.5-1
ii  libgtk2.0-0  2.24.28-1
ii  libgtkmm-3.0-1   3.16.0-1
ii  libice6  2:1.0.9-1+b1
ii  libindicator3-7  0.5.0-2
ii  libpanel-applet0 3.16.1-3
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libpangomm-1.4-1 2.36.0-1
ii  libpulse-mainloop-glib0  6.0-2
ii  libpulse06.0-2
ii  libsigc++-2.0-0c2a   2.4.1-1
ii  libsm6   2:1.2.2-1+b1
ii  libstdc++6   5.1.1-14
ii  libx11-6 2:1.6.3-1
ii  libxfce4util74.12.1-2
ii  libxml2  2.9.1+dfsg1-5
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  workrave-data1.10.6-2
ii  xfce4-panel  4.12.0-3

workrave recommends no packages.

Versions of packages workrave suggests:
pn  gnome-panel  
pn  gnome-shell  

-- no debconf information


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

Bug#788568: still there?

[Holger Levsen]

Hi,

upon seeing this:

[18:37] -   KGB-2- | (#debian-reproducible) debbindiff calls on 
https://reproducible.debian.net/unstable/amd64/icedove or 
https://jenkins.debian.net/job/reproducible_builder_epsilon/21466/console left 
cruft, please help investigate and fix 788568
[18:39] -   KGB-2- | (#debian-reproducible) 
https://reproducible.debian.net/artifacts/r00t-me/icedove_unstable_tmp-5QgiE/ 
published, debbindiff 26 had troubles with these...

I checked /tmp and found nothing related:

root@jenkins:~# find /tmp -maxdepth 1 -name tmp*debbindiff | xargs ls -ld
drwx-- 15 root root 12288 Jul 20 13:33 .
root@jenkins:~#

So I wonder if this bug can be closed and the irc notification turned off?


cheers,
Holger


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

Bug#793479: tcpdump: tcpdump prints "dropped privs to " message to stdout, should be stderr

[Romain Francoise]

Hi,

On Fri, Jul 24, 2015 at 01:57:29PM +0200, Hilko Bengen wrote:
> I have been using tcpdump like this for ages:
>
> /usr/sbin/tcpdump -Z $user -S0 -p -n U -B $bufsz -i $iface -w - "$rule"
>
> [...]
>
> Post-processing of the resulting streams broke after upgrading to jessie
> because tcpdump prints that bit of information about dropping privileges
> to standard output.

Hmm, that's unfortunate, and the fix is trivial enough that I can
probably get it into stable for the next point release.

However, I don't agree with the severity of this bug. Your use case is
quite atypical.

-- 
Romain Francoise 
http://people.debian.org/~rfrancoise/


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

Bug#792853: debian-policy: please disallow colons in upstream_version

[Guillem Jover]

Hi!

On Sun, 2015-07-19 at 20:25:04 -0700, Russ Allbery wrote:
> Guillem Jover  writes:
> > So, in principle 2) and 3) are mostly problems in dpkg, 1) might be a
> > quite good indication that upstreams do not usually do this, and 4) a
> > very strong deterrent for them to do so.
> 
> > I'm ambivalent on disallowing this in Debian, and even if policy ends
> > up disallowing it might still make sense to allow it in dpkg in case
> > someone outside Debian is using such thing (although I'm having a bit
> > of a hard time seeing this being used in practice).
> 
> I feel like simplicity in our version numbering scheme is best.  It's
> clear that no one is currently using this, and this message is the first
> time I recall it even coming up.  That implies that we're not losing much
> (if anything) by not supporting this, even though we claimed it was
> supported.
> 
> The simplest approach for Debian seems to be to just forbid colons in
> upstream version numbers.  This also simplifies parsing mildly.

Right, makes sense. Although I wouldn't like for that regression in
dpkg to be used as a “fait accompli” argument.

> (Obviously, dpkg is free to be more generous, although it's convenient
> when dpkg aligns with Debian Policy in a way that doesn't require writing
> a separate Lintian rule.)

So I've decided I'll merge the fix for now, which can always be
reverted if Debian Policy forbids its usage, but in that case I'd
probably implement a proper staged deprecation process, with warnings
and all, to catch the possible but improbable external users.

Thanks,
Guillem


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

Bug#647317: CVE-2011-4092

[Philipp Kern]

On 2015-07-22 13:15, Jonathan Wiltshire wrote:
Recently you fixed one or more security problems and as a result you 
closed

this bug. These problems were not serious enough for a Debian Security
Advisory, so they are now on my radar for fixing in the following 
suites

through point releases:

squeeze (6.0.8) - use target "oldstable"

Please prepare a minimal-changes upload targetting each of these 
suites,
and submit a debdiff to the Release Team [0] for consideration. They 
will

offer additional guidance or instruct you to upload your package.


This was a "fix by removal". Maybe your script should match for +rm 
fixed versions?


Kind regards and thanks
Philipp Kern


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

Bug#793392: ITP: dcmtkpp -- Wrappers around DCMTK to have an easier API

[Julien Lamy]

Le 24/07/2015 16:43, Steve M. Robbins a écrit :
> On July 23, 2015 08:44:04 PM Philip Hands wrote:
>> Julien Lamy  writes:
> 
>>> * Package name: dcmtkpp
>>>
>>>   Version : 0.2.1
>>>   Upstream Author : Julien Lamy 
>>>
>>> * URL : https://github.com/lamyj/dcmtkpp
>>> * License : CeCILL-B
>>>
>>>   Programming Lang: C++
>>>   Description : Wrappers around DCMTK to have an easier API
>>>
>>> DCMTK++ is a set of wrappers around DCMTK, leveraging C++ constructs to
>>> have an easier API, notably for the networking part. Included are
>>> exception-based error handling, generic access to datasets elements,
>>> standard JSON representation of datasets, explicit messages and generic
>>> implementation of SCU and SCP.
>>
>> Some indication of what field of endeavour this package might be of
>> interest to would be helpful.
>>
>> It seems, after some searching, that DCMTK is an acronym encompassing the
>> acronym DICOM, which is something to do with medical imaging.
>>
>> Medical imagining is a minority interest, so it would be good if the
>> short description allowed the majority of people to quickly determine
>> that they don't need this.
>>
>> Something like:  C++ library for dealing with DICOM medical imagery
> 
> Philip: I agree with essentially all your points.  
> 
> However, while acknowledging that medical imaging is indeed "minority 
> interest": within that community, DCMTK is a very well-known DICOM toolkit, 
> so 
> I'd advocate for retaining DCMTK in the short description.
> 
> Perhaps: C++ wrapper library for DCMTK (DICOM medical imaging toolkit)

Philip and Steve: thank you for your suggestions. I have written the ITP
bug report way too quickly, and the description indeed needs a lot of
clarifying. My apologies for this.

Would you agree with the following modifications?

Short description: C++ wrapper library for DCMTK (DICOM toolkit)

Long description:
DCMTK++ is a wrapper library for DCMTK, a toolkit handling the DICOM
medical imaging standard. DCMTK++ leverages C++ constructs to provide a
more user-friendly API, notably for the networking part. Included in
DCMTK++ are exception-based error handling, generic access to datasets
elements, standard JSON representation of datasets, and generic
implementation of messages, clients and servers for the various DICOM
protocols.

Other relevant information:
Compared to the two main free-software C++ DICOM toolkits (DCMTK and
GDCM), DCMTK++ provides either additional features (generic
implementation of DICOM servers, missing from GDCM) and a modern C++ API
(missing from DCMTK). We think that developers of DICOM application
would benefit from DCMTK++, in term of code readability and ease of
application maintenance.

The package will be maintained by the Debian Med team [1], and packaging
is underway on Alioth [2].

[1] https://lists.debian.org/debian-med/2015/07/msg00112.html
[2] https://anonscm.debian.org/cgit/debian-med/dcmtkpp.git/

I hope this clarifies your concerns; don't hesitate to come back to me
if you have more questions.

Best regards,
-- 
Julien Lamy



signature.asc
Description: OpenPGP digital signature

Bug#793501: please package new upstream version 1.2.0

[Steinar H. Gunderson]

Package: cubemap
Version: 1.1.2-1+b1
Severity: wishlist

Hi,

I've released Cubemap 1.2.0; please take a look at packaging it.
There are no security or other critical fixes (so no stable upload
is needed), but some new features that are nice to have for HTML5
.

There's also a small correction in the package description; since
1.1.0, there's no per-stream fwmark support, since it's been
obsoleted with sch_fq. I'd suggest replacing the last paragraph
with something like:

 Its features include high performance, high availability, per-stream
 TCP pacing support (with sch_fq) and reflection of all muxes VLC
 can offer over HTTP or UDP.


-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (750, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages cubemap depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.22
ii  libc62.19-18
ii  libgcc1  1:4.9.2-10
pn  libprotobuf7 
ii  libstdc++6   4.9.2-10
ii  lsb-base 4.1+Debian13+nmu1

cubemap recommends no packages.

Versions of packages cubemap suggests:
ii  logrotate   3.8.7-1+b1
ii  munin-node  2.0.25-1


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

Bug#793500: libhtmlparser-java: /​usr/​share/​doc/​libhtmlparser-​java-​doc/​api/​ is not always included in the built package

[Holger Levsen]

Source: libhtmlparser-java
Version: 1.6.20060610.dfsg0-5 
Severity: important
Tags: sid stretch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locales

Dear Maintainer,

While working on the "reproducible builds" effort [1], we have noticed that 
libhtmlparser-java does not always include all of 
/​usr/​share/​doc/​libhtmlparser-​java-​doc/​api/​ is in the built package.

Check 
https://reproducible.debian.net/dbd/unstable/amd64/libhtmlparser-java_1.6.20060610.dfsg0-5.debbindiff.html
(which is also attached to this bug report) to see the difference in the build
result, a lot of files are missing in the first build.

I'm guessing this is because the first build was done with LANG="en_GB.UTF-8"
and LC_ALL unset,  while the second build was done with LANG="fr_CH.UTF-8" and
LC_ALL="fr_CH.UTF-8". 

The difference between the two build logs, which is available at 
https://reproducible.debian.net/logdiffs/unstable/amd64/libhtmlparser-java_1.6.20060610.dfsg0-5.diff.gz
seems to confirm this:

 jarparser:
 [mkdir] Created dir: 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/lib
@@ -1183,8 +1169,8 @@
  [echo] ***
 
 init:
- [echo] today is Jul 15, 2015
- [echo] versionTag=1_6_20150715
+ [echo] today is juil. 16, 2015
+ [echo] versionTag=1_6_20150716
  [echo] previous version number = 1.6
  [echo] previous version type = Release Build
  [echo] previous version date = Jun 10, 2006
@@ -1220,28 +1206,25 @@
   [javadoc] Loading source files for package org.htmlparser.sax...
   [javadoc] Loading source files for package org.htmlparser.scanners...
   [javadoc] Loading source files for package org.htmlparser.tags...
-  [javadoc] 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/src/org/htmlparser/util/Translate.java:162:
 error: unmappable character for encoding ASCII
-  [javadoc] // Portions ?? International Organization for 
Standardization 1986
-  [javadoc] ^
-  [javadoc] 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/src/org/htmlparser/util/Translate.java:162:
 error: unmappable character for encoding ASCII
-  [javadoc] // Portions ?? International Organization for 
Standardization 1986
-  [javadoc]  ^
-  [javadoc] 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/src/org/htmlparser/util/Translate.java:271:
 error: unmappable character for encoding ASCII
-  [javadoc] // Portions ?? International Organization for 
Standardization 1986:
-  [javadoc] ^
-  [javadoc] 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/src/org/htmlparser/util/Translate.java:271:
 error: unmappable character for encoding ASCII
-  [javadoc] // Portions ?? International Organization for 
Standardization 1986:
-  [javadoc]  ^
-  [javadoc] 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/src/org/htmlparser/util/Translate.java:445:
 error: unmappable character for encoding ASCII
-  [javadoc] // Portions ?? International Organization for 
Standardization 1986:
-  [javadoc] ^
-  [javadoc] 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/src/org/htmlparser/util/Translate.java:445:
 error: unmappable character for encoding ASCII
-  [javadoc] // Portions ?? International Organization for 
Standardization 1986:
-  [javadoc]  ^
   [javadoc] Loading source files for package org.htmlparser.util...
   [javadoc] Loading source files for package org.htmlparser.util.sort...
   [javadoc] Loading source files for package org.htmlparser.visitors...
-  [javadoc] 6 errors
+  [javadoc] Constructing Javadoc information...
+  [javadoc] javadoc: warning - Error fetching URL: 
http://java.sun.com/j2se/1.4.2/docs/api/package-list
+  [javadoc] javadoc: warning - Error fetching URL: 
http://www.saxproject.org/apidoc/package-list
+  [javadoc] Registered Taglet HtmlTaglet ...
+  [javadoc] Standard Doclet version 1.7.0_79
+  [javadoc] Building tree for all the packages and classes...
+  [javadoc] Generating 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/docs/javadoc/org/htmlparser/visitors/UrlModifyingVisitor.html...
+  [javadoc] Copying file 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/src/doc-files/using.html 
to directory 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/docs/javadoc/doc-files...
+  [javadoc] Copying file 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/src/doc-files/building.html
 to directory 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/docs/javadoc/doc-files...
+  [javadoc] Copying file 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/src/doc-files/overview.html
 to directory 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/docs/javadoc/doc-files...
+  [javadoc] Generating 
/tmp/buildd/libhtmlparser-java-1.6.20060610.dfsg0/src/docs/javadoc/serialized-form.html...
+  [javadoc] Copying file 
/tmp/buildd/libh

Bug#793499: debian-policy: The Installed-Size algorithm is out-of-date

[Guillem Jover]

Package: debian-policy
Version: 3.9.7.0
Severity: wishlist

Hi!

As discussed in the debian-policy list, the Installed-Size algorithm
as implemented in dpkg-gencontrol changed due to #650077. So the
current wording is out-of-sync. Please see the thread starting at
,
with the current implementation
.

Thanks,
Guillem


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

Bug#793496: Merging duplicate bug

[Raphael Hertzog]

Control: forcemerge 793495 -1

Sorry, it's a duplicate. Merging it with the other.

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/


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

Bug#793498: mutt-kz: Should not be of priority "standard"

[Axel Beckert]

Package: mutt-kz
Version: 1.5.23.1-5
Severity: normal

Hi,

please use "Priority: optional" for this package instead of "Priority:
standard". This is no package users do expect in a standard
installation.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (111, 'buildd-unstable'), 
(111, 'buildd-experimental'), (110, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages mutt-kz depends on:
ii  libassuan0 2.2.1-1
ii  libc6  2.19-19
ii  libcomerr2 1.42.13-1
ii  libgnutls-deb0-28  3.3.16-1
ii  libgpg-error0  1.19-2
ii  libgpgme11 1.5.5-3
ii  libgssapi-krb5-2   1.13.2+dfsg-2
ii  libidn11   1.31-1
ii  libk5crypto3   1.13.2+dfsg-2
ii  libkrb5-3  1.13.2+dfsg-2
ii  libncursesw5   5.9+20150516-2
ii  libnotmuch40.20.2-1
ii  libsasl2-2 2.1.26.dfsg1-13
ii  libtinfo5  5.9+20150516-2
ii  libtokyocabinet9   1.4.48-3
ii  mutt   1.5.23-3

mutt-kz recommends no packages.

mutt-kz suggests no packages.

-- no debconf information


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

Bug#793497: mutt-kz: Package description far too similar to the one of mutt

[Axel Beckert]

Package: mutt-kz
Version: 1.5.23.1-5
Severity: normal

Hi,

the long package description of mutt-kz only differs by one added list
item from the one from mutt ("* Not much integration"). Please explain
explicitly what's the difference to mutt and maybe also what's the
difference to notmuch-mutt.

I also suggest to change the first line of the long package description
from "Mutt is a sophisticated text-based Mail User Agent" to "Mutt-KZ is
fork of Mutt, a sophisticated text-based Mail User Agent, which
additionally provides ..." or similar.

Please also use a different short package description. It's currently
_identical_ to the one from mutt.

Additionally you should write the name of "notmuch" without a blank: Use
"Notmuch integration" instead of "Not much integration". See also the
package description of the package "notmuch".

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (111, 'buildd-unstable'), 
(111, 'buildd-experimental'), (110, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages mutt-kz depends on:
ii  libassuan0 2.2.1-1
ii  libc6  2.19-19
ii  libcomerr2 1.42.13-1
ii  libgnutls-deb0-28  3.3.16-1
ii  libgpg-error0  1.19-2
ii  libgpgme11 1.5.5-3
ii  libgssapi-krb5-2   1.13.2+dfsg-2
ii  libidn11   1.31-1
ii  libk5crypto3   1.13.2+dfsg-2
ii  libkrb5-3  1.13.2+dfsg-2
ii  libncursesw5   5.9+20150516-2
ii  libnotmuch40.20.2-1
ii  libsasl2-2 2.1.26.dfsg1-13
ii  libtinfo5  5.9+20150516-2
ii  libtokyocabinet9   1.4.48-3
ii  mutt   1.5.23-3

mutt-kz recommends no packages.

mutt-kz suggests no packages.

-- no debconf information


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

Bug#793496: About the security issues affecting xfsprogs in Squeeze

[Raphael Hertzog]

Hello Nathan,

the Debian LTS team recently reviewed the security issue(s) affecting your
package in Squeeze:
https://security-tracker.debian.org/tracker/CVE-2012-2150

We decided that we would not prepare a squeeze security update (usually
because the security impact is low and that we concentrate our limited
resources on higher severity issues and on the most widely used packages).
That said the squeeze users would most certainly benefit from a fixed
package.

If you want to work on such an update, you're welcome to do so. Please
try to follow the workflow we have defined here:
http://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-...@lists.debian.org
(via a debdiff, or with an URL pointing to the the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. However please make sure to
submit a tested package.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.
-- 
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/


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

Bug#793492: Should this package be removed?

[Emmanuel Bourg]

Le 24/07/2015 17:30, Moritz Muehlenhoff a écrit :

> The version of azureus currently in the archive has been uploaded
> in 2009 and it many upstream releases behind. It has been dropped
> from testing back in 2013 and the last upload was in 2011. Since
> there's apparently no current maintenance interest in Vuze/Azureus
> and since there are plenty of other Torrent clients in Debian I
> suggest we remove it from the archive.

Hi Moritz,

I'm interested in reviving Azureus, but that's a low priority item on my
todo list. Stephen Nelson also voiced its interest [1].

Emmanuel Bourg

[1] https://lists.debian.org/debian-java/2015/04/msg00084.html


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

Bug#793496: xfsprogs: CVE-2012-2150: xfs_metadump information disclosure flaw

[Raphael Hertzog]

Source: xfsprogs
Severity: important
Tags: security

Hi,

the following vulnerability was published for xfsprogs.

CVE-2012-2150[0]:
xfs_metadump information disclosure flaw

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2012-2150
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2150
Please adjust the affected versions in the BTS as needed.

There are no upstream patches yet but they should be published shortly
according to https://marc.info/?l=oss-security&m=143766249112576&w=2

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/


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

Bug#758871: rrdtool-dbg: does not contain debug symbols for librrd_th

[Jean-Michel Vourgère]

Control: tags -1 moreinfo

Hello Folkert

Your wrote:
> rrdtool-dbg: does not contain debug symbols for librrd_th


I rebuilt version 1.4.8-1.1 and here's an extract of the build logs with
DH_VERBOSE=1 :

> dh_strip -a --dbg-package=rrdtool-dbg
> (...)
> install -d debian/rrdtool-dbg/usr/lib/debug/.build-id/86
> 
> objcopy --only-keep-debug --compress-debug-sections 
> debian/librrd4/usr/lib/librrd_th.so.4.2.1 
> debian/rrdtool-dbg/usr/lib/debug/.build-id/86/53ea4714da9eaf4abe6b19532bf7685483e383.debug
> 
> chmod 644 
> debian/rrdtool-dbg/usr/lib/debug/.build-id/86/53ea4714da9eaf4abe6b19532bf7685483e383.debug
> 
> strip --remove-section=.comment --remove-section=.note --strip-unneeded 
> debian/librrd4/usr/lib/librrd_th.so.4.2.1
> 
> objcopy --add-gnu-debuglink 
> debian/rrdtool-dbg/usr/lib/debug/.build-id/86/53ea4714da9eaf4abe6b19532bf7685483e383.debug
>  debian/librrd4/usr/lib/librrd_th.so.4.2.1

So it looks like the symbols are in the -dbg package.

Running valgrind, I find the same level of information in rrdtools that
in other libraries.

Valgrind is not a tool I know much about.

Can you explain what you expected?

Here, if I run
> valgrind -d -v -v --leak-check=full rrdtool graph temperature.png
DEF:t=temperature.rrd:temp:AVERAGE LINE1:t#FF:"temperature\l"
(should work with any command), I get:
> (...)
> --20065-- Reading syms from /usr/bin/rrdtool
> --20065--svma 0x401620, avma 0x401620
> --20065--   Considering 
> /usr/lib/debug/.build-id/d3/910add213ad29a1b3f751982fe540a21f76987.debug ..
> --20065--   .. build-id is valid
> (...)
> --20065-- Reading syms from /usr/lib/librrd.so.4.2.1
> --20065--svma 0x0072b0, avma 0x0004e3c2b0
> --20065--   Considering 
> /usr/lib/debug/.build-id/ab/17988d14073d564daf60499867b0cbb018b2f5.debug ..
> --20065--   .. build-id is valid

And so on.

Can you try it with "-d -v -v" and post the "Reading syms from" blocks,
please?

If I uninstall rrdtool-dbg, I have errors like
> --20198-- Reading syms from /usr/lib/librrd.so.4.2.1
> --20198--svma 0x0072b0, avma 0x0004e3c2b0
> --20198--object doesn't have a symbol table

so I guess this is working ok.



Reading other bug repports, I can see that there are issue with valgrind
not showing the line numbers. Is that your issue?

See:
https://bugs.debian.org/701480
https://bugs.debian.org/780173

Please keep us informed if this is it.


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

Bug#793495: CVE-2012-2150 xfsprogs: xfs_metadump information disclosure

[Moritz Muehlenhoff]

Package: xfsprogs
Version: 3.2.3
Severity: important
Tags: security

Please see http://seclists.org/oss-sec/2015/q3/181
for details.

Cheers,
Moritz


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

Bug#793308: About bug 793308 : Ticks and arrows appear reversed in Libreoffice menus

[Rene Engelhard]

tag 793308 + unreproducible
tag 793308 + moreinfo
thanks

Hi,

On Fri, Jul 24, 2015 at 01:28:43PM +0200, Rene Engelhard wrote:
> On Fri, Jul 24, 2015 at 09:20:38AM +0200, Etienne MAHE wrote:
> >  would like to fix this issue in the next days. This problem also occurs
> >  with other desktop environments and other themes (I have tested on XFCE
> >  and with Clearlooks-phenix). If I uninstall this package, the gtk
> >  integration is bad but the arrows are properly displayed. Could you
> 
> I can at least say that with the 4.4.4 backport to jessie this problem DOES 
> NOT
> appear. I didn't yet check with unstable/testing. But that suggests to me 
> that it's
> some interaction issue between LO and some (newer) Gtk2 libraries...
> 
> $ COLUMNS="120" dpkg -l libreoffice-gtk
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version   Architecture  Description
> +++--=-=-=
> ii  libreoffice-gtk  1:4.4.4-1~bpo8+1  amd64 office 
> productivity suite -- GTK+ integration

And I can't reproduce it either on a uptodate sid.

Regards,
 
Rene


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

Bug#789952: This is also an issue with 6300

[Eigil Skjæveland]

Same problem here. It always says 1 Mb/s.

$ uname -a
Linux thinkpad 4.0.0-2-amd64 #1 SMP Debian 4.0.8-2 (2015-07-22) x86_64 GNU/Linux

$ sudo iwconfig wlan0
wlan0 IEEE 802.11abgn  ESSID:"NAME"  
  Mode:Managed  Frequency:2.467 GHz  Access Point: 14:D6:4D:E3:FC:60   
  Bit Rate=1 Mb/s   Tx-Power=15 dBm   
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Encryption key:off
  Power Management:off
  Link Quality=70/70  Signal level=-38 dBm  
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:204  Invalid misc:53   Missed beacon:0

$ sudo dmesg | grep iwlwifi | head
[2.728248] iwlwifi :02:00.0: can't disable ASPM; OS doesn't have ASPM 
control
[2.732117] iwlwifi :02:00.0: firmware: direct-loading firmware 
iwlwifi-6000-4.ucode
[2.733113] iwlwifi :02:00.0: loaded firmware version 9.221.4.1 build 
25532 op_mode iwldvm
[2.763053] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEBUG disabled
[2.763130] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[2.763205] iwlwifi :02:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[2.763283] iwlwifi :02:00.0: Detected Intel(R) Centrino(R) Ultimate-N 
6300 AGN, REV=0x74
[2.763503] iwlwifi :02:00.0: L1 Enabled - LTR Disabled
[   74.391444] iwlwifi :02:00.0: L1 Enabled - LTR Disabled
[   74.400438] iwlwifi :02:00.0: Radio type=0x0-0x3-0x1


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

Bug#793492: Should this package be removed?

[Moritz Muehlenhoff]

Package: azureus
Severity: serious

The version of azureus currently in the archive has been uploaded
in 2009 and it many upstream releases behind. It has been dropped
from testing back in 2013 and the last upload was in 2011. Since
there's apparently no current maintenance interest in Vuze/Azureus
and since there are plenty of other Torrent clients in Debian I
suggest we remove it from the archive.

If you agree, please reassign this bug to ftp.debian.org

Cheers,
Moritz


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

Bug#793493: debian-policy: Update dpkg-architecture flags information

[Guillem Jover]

Package: debian-policy
Version: 3.9.7.0
Severity: wishlist
Tags: patch

Hi!

Here's a partial update to match the current dpkg-architecture output.
I've left the MULTIARCH variable alone, because that's supposedly
tracked on another bug.

The wording might be a bit unnatural, review by a native speaker
advised. :)

Thanks,
Guillem
From 0bc030c417adfa7ca50944c918101dd9ce62bebb Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Fri, 24 Jul 2015 17:17:58 +0200
Subject: [PATCH 1/2] Update information about DEB_TARGET_* variables

These are used to support building cross-compilers. Introduced in
dpkg 1.17.14.
---
 policy.sgml | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 404dc73..72a2505 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2175,9 +2175,16 @@ zope.
 	  the architecture on which debian/rules is run and
 	  the package build is performed.  The host architecture is the
 	  architecture on which the resulting package will be installed
-	  and run.  These are normally the same, but may be different in
+	  and run.  The target architecture is the architecture of the
+	  packages that the compiler currently being built will generate.
+	  These are normally the same, but may be different in
 	  the case of cross-compilation (building packages for one
-	  architecture on machines of a different architecture).
+	  architecture on machines of a different architecture), building a
+	  cross-compiler (a compiler package that will generate objects for
+	  one architecture, built on a machine of a different architecture)
+	  or a Canadian cross-compiler (a compiler that will generate
+	  objects for one architecture, built on a machine of a different
+	  architecture, that will run on yet a different architecture).
 	
 
 	
@@ -2205,8 +2212,9 @@ zope.
 		DEB_*_GNU_TYPE)
 	  
 	  where * is either BUILD for specification of
-	  the build architecture or HOST for specification of the
-	  host architecture.
+	  the build architecture, HOST for specification of the
+	  host architecture or TARGET for specification of the
+	  target architecture.
 	
 
 	
-- 
2.5.0.rc2.392.g76e840b

From 70aaad841a5067db2737ea658532eb92d9376888 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Fri, 24 Jul 2015 17:19:06 +0200
Subject: [PATCH 2/2] Update information about DEB_*_ARCH_* variables

Mention DEB_*_ARCH_BITS and DEB_*_ARCH_ENDIAN. Introduced in dpkg 1.15.4.
---
 policy.sgml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/policy.sgml b/policy.sgml
index 72a2505..b7f0464 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2197,6 +2197,12 @@ zope.
 		DEB_*_ARCH_CPU (the Debian CPU name)
 	
 	
+		DEB_*_ARCH_BITS (the Debian CPU pointer size in bits)
+	
+	
+		DEB_*_ARCH_ENDIAN (the Debian CPU endianness)
+	
+	
 		DEB_*_ARCH_OS (the Debian System name)
 	
 	
-- 
2.5.0.rc2.392.g76e840b

Bug#793491: RFP: rocksdb -- A persistent key-value store for fast storage environments

[Luca Bruno]

Package: wnpp
Severity: wishlist

* Package name: rocksdb
  Version : 3.11.2
  Upstream Author : Facebook, Inc.
* URL : http://rocksdb.org/
* License : BSD-3
  Programming Lang: C++
  Description : A persistent key-value store for fast storage environments

RocksDB is an embeddable persistent key-value store for fast storage.
It can also be the foundation for a client-server database but the
current focus is on embedded workloads.
RocksDB can be used by applications that need low latency database accesses.

This is needed as a dependency for osquery.


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

Bug#439888: frobby

[Doug Torrance]

Dependency update: frobby has been accepted into Debian unstable.


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

Bug#793490: Please enable paranoia option for chroot and setuid/setgid

[Bernhard Schmidt]

Package: isc-dhcp
Version: 4.3.2-1
Severity: wishlist

Hi,

since ISC DHCP 4.1.0 the formerly standalone PARANOIA patch by Ari
Edelkind has been included upstream. It provides additional command
line options for chroot, setuid and setgid. However it needs a
special configure flag for these features.

Please add --enable-paranoia to the configure flags.

I have compile- and runtime tested it on the amd64 architecture. 
This configure option has been enabled in SuSE for years and should
be safe for use.

Note that I'm not requesting to use these new features in a default
Debian installation, they should just be compiled into the binary.

Note that there is mentioning of the new arguments in the upstream
manpage for dhcpd(8), I will try to think of something and attach a
patch when I'm done.

Best Regards,
Bernhard


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

Bug#793451: Bug confirmation

[Patrick Reichel]

I can confirm this problem at my up-to-date Testing (with amarok
2.8.0-2.1+b2).

Even re-reading my whole collection ends with an empty collection view.


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

Bug#771224: linux-image-3.16.0-4-amd64: Recurring traces from tcp_fragment+0x2b1/0x2c0 (linux-3.16.7/net/ipv4/tcp_output.c:1085)

[Roman Lebedev]

Control: notfound 771224 4.0.8-2

So i have been running 4.x.y series kernel for some time now, and i
have not seen those traces in 4.x.y kernel so far.
I believe it means that it was fixed upstream and bug can be closed accordingly.

Thanks!

PS: i do not know how to close bugs here, or if the first line of this
mail is correct

Roman.


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

Bug#793486: Vacation

[racke]

Andreas Beckmann writes:


Package: interchange-cat-standard
Version: 5.7.7-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.


From the attached log (scroll to the bottom...):


  Selecting previously unselected package interchange-cat-standard.
  (Reading database ...
(Reading database ... 11471 files and directories currently installed.)
  Preparing to unpack .../interchange-cat-standard_5.7.7-2_all.deb ...
  Unpacking interchange-cat-standard (5.7.7-2) ...
  Setting up interchange-cat-standard (5.7.7-2) ...
  dpkg: error processing package interchange-cat-standard (--configure):
   subprocess installed post-installation script returned error exit status 10
  Errors were encountered while processing:
   interchange-cat-standard


cheers

Andreas


Hello,


We are on vacation till 2nd August.


In urgent cases please call our cellphone. 



Regards
   Racke


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

Bug#793270: pdf2djvu: change of type in system_error might break with GCC-5

[Matthias Klose]

On 07/22/2015 06:37 PM, Jakub Wilk wrote:
> Hi Matthias!
> 
> [Disclaimer: I'm not the maintainer, just a random bug onlooker.]
> 
> * Matthias Klose , 2015-07-22, 13:34:
>> GCC PR libstdc++/66145 is a regression in GCC 5 which won't be fixed upstream
>> in time for the GCC defaults change.
> 
> https://gcc.gnu.org/PR66145 is about catching std::ios_base::failure, but the
> bug subject says about changes in std::system_error. It wasn't clear to me
> what's the relation of these two classes. So apparently in C++11 (but not in
> C++98) std::ios_base::failure is a subclass of std::system_error.
> 
> pdf2djvu tries to catch std::ios_base::failure in a few places. The version in
> the archive, which was built built with GCC 4.9, does it successfully (both 
> with
> libstdc++6 5.1.1-14 and 5.2.1-11):
> 
> $ pdf2djvu /usr/share/doc/quilt/quilt.pdf -o /cannot/write/here
> I/O error (basic_ios::clear)
> 
> However, when you rebuild the package against g++-5_5.1.1-14, catching the
> exception no longer works:
> 
> $ pdf2djvu /usr/share/doc/quilt/quilt.pdf -o /cannot/write/here
> terminate called after throwing an instance of 'std::ios_base::failure'
>  what():  basic_ios::clear
> Aborted
> 
>> The work around is to rebuild the affected packages after GCC 5 is the 
>> default
>> compiler.
> 
> AFAICS rebuilding doesn't help; it only makes things worse...

I forgot to make the corresponding change in libstdc++6, now fixed in 5.2.1-12.
 This now should break the not rebuild pdf2djvu.


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

Bug#793392: ITP: dcmtkpp -- Wrappers around DCMTK to have an easier API

[Steve M. Robbins]

On July 23, 2015 08:44:04 PM Philip Hands wrote:
> Julien Lamy  writes:

> > * Package name: dcmtkpp
> > 
> >   Version : 0.2.1
> >   Upstream Author : Julien Lamy 
> > 
> > * URL : https://github.com/lamyj/dcmtkpp
> > * License : CeCILL-B
> > 
> >   Programming Lang: C++
> >   Description : Wrappers around DCMTK to have an easier API
> > 
> > DCMTK++ is a set of wrappers around DCMTK, leveraging C++ constructs to
> > have an easier API, notably for the networking part. Included are
> > exception-based error handling, generic access to datasets elements,
> > standard JSON representation of datasets, explicit messages and generic
> > implementation of SCU and SCP.
> 
> Some indication of what field of endeavour this package might be of
> interest to would be helpful.
> 
> It seems, after some searching, that DCMTK is an acronym encompassing the
> acronym DICOM, which is something to do with medical imaging.
> 
> Medical imagining is a minority interest, so it would be good if the
> short description allowed the majority of people to quickly determine
> that they don't need this.
> 
> Something like:  C++ library for dealing with DICOM medical imagery

Philip: I agree with essentially all your points.  

However, while acknowledging that medical imaging is indeed "minority 
interest": within that community, DCMTK is a very well-known DICOM toolkit, so 
I'd advocate for retaining DCMTK in the short description.

Perhaps: C++ wrapper library for DCMTK (DICOM medical imaging toolkit)

-Steve


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

Bug#793244: git-crypt: change of type in system_error might break with GCC-5

[Matthias Klose]

On 07/22/2015 08:05 PM, Andrew Ayer wrote:
> tags 793244 + confirmed
> thanks
> 
> On Wed, 22 Jul 2015 13:33:34 +
> Matthias Klose  wrote:
> 
>> GCC PR libstdc++/66145 is a regression in GCC 5 which won't be fixed
>> upstream in time for the GCC defaults change.  The work around is to
>> rebuild the affected packages after GCC 5 is the default compiler.
>> Please look at the code and decide, if the package is affected. If
>> not, please just close the issue.  If it's a real issue, I'll add
>> the packages affected to libstdc++6's Breaks attributes, with the
>> version of the package at the time of the defaults change.
> 
> I've confirmed that git-crypt is affected.  However, are you sure that
> rebuilding is a sufficient workaround?  When I tried building with g++
> 5.2.1-11 from experimental, I had to use -D_GLIBCXX_USE_CXX11_ABI=0 in
> order to successfully catch std::ios_base::failure.  Should I modify
> git-crypt to build with this flag?

no, that was an omission in libstdc++6, now fixed in 5.2.1-12.


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

Bug#793489: ghostscript: CVE-2015-3228: Integer overflow

[Raphael Hertzog]

Package: ghostscript
Severity: important
Tags: security patch

Hi,

the following vulnerability was published for ghostscript.

CVE-2015-3228[0]: Integer overflow

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2015-3228
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3228
Please adjust the affected versions in the BTS as needed.

All the versions in Debian are affected by the underlying problem
in the memory allocation (see
http://bugs.ghostscript.com/show_bug.cgi?id=696070) but experimental
(9.15~rc1~dfsg-1) does not trigger the segfault due do other changes.

You can reproduce the problem with this:
$ wget http://bugs.ghostscript.com/attachment.cgi?id=11776 -O /tmp/test.ps
$ ps2pdf /tmp/test.ps
Segmentation fault

The suggested patch is here:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=0c0b0859

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/


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

Bug#793404: massive waste of CPU time in debian/rules by inline commands

[Guillem Jover]

Control: block -1 by 657390

[ Blocking on that, because there's currently no other such bug. So
  not to imply this is lintian maintainers sole responsibility. ]

Hi!

On Fri, 2015-07-24 at 12:19:36 +0200, Jakub Wilk wrote:
> dpkg-buildpackage -B will run debian/rules 4 times: once to determine if
> build-arch exist, and once for every target: clean, build(-arch),
> binary-arch.

Ideally the first would disappear though. Please see the blocking bug
report for a tentative plan on how to do so.

Thanks,
Guillem


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

Bug#793488: amd-opencl-icd: Update to 1:15.7-1 broke opencl

[Roman Lebedev]

Package: amd-opencl-icd
Version: 1:15.7-1
Severity: important

Dear Maintainer,

It appears that last fglrx update broke OpenCL.
Example: here is the output of clinfo (from amd-clinfo)

$ clinfo
Number of platforms: 1
  Platform Profile:  FULL_PROFILE
  Platform Version:  OpenCL 2.0 AMD-APP (1800.5)
  Platform Name: AMD Accelerated Parallel 
Processing
  Platform Vendor:   Advanced Micro Devices, Inc.
  Platform Extensions:   cl_khr_icd 
cl_amd_event_callback cl_amd_offline_devices 


  Platform Name: AMD Accelerated Parallel 
Processing
Number of devices:   1
  Device Type:   CL_DEVICE_TYPE_CPU
  Vendor ID: 1002h
  Board name:
  Max compute units: 8
  Max work items dimensions: 3
Max work items[0]:   1024
Max work items[1]:   1024
Max work items[2]:   1024
  Max work group size:   1024
  Preferred vector width char:   16
  Preferred vector width short:  8
  Preferred vector width int:4
  Preferred vector width long:   2
  Preferred vector width float:  8
  Preferred vector width double: 4
  Native vector width char:  16
  Native vector width short: 8
  Native vector width int:   4
  Native vector width long:  2
  Native vector width float: 8
  Native vector width double:4
  Max clock frequency:   4013Mhz
  Address bits:  64
  Max memory allocation: 8413209600
  Image support: Yes
  Max number of images read arguments:   128
  Max number of images write arguments:  64
  Max image 2D width:8192
  Max image 2D height:   8192
  Max image 3D width:2048   


   
  Max image 3D height:   2048   


   
  Max image 3D depth:2048   


   
  Max samplers within kernel:16 


   
  Max size of kernel argument:   4096   


   
  Alignment (bits) of base address:  1024   


   
  Minimum alignment (bytes) for any datatype:128


   
  Single precision floating point capability


   
Denorms: Yes


   
Quiet NaNs:  Yes

   

Bug#793487: squid: fails to install: FATAL: Ipc::Mem::Segment::create failed to shm_open(/squid-cf__metadata.shm): (13) Permission denied

[Andreas Beckmann]

Package: squid
Version: 3.5.6-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package squid.
  (Reading database ... 
(Reading database ... 9951 files and directories currently installed.)
  Preparing to unpack .../squid_3.5.6-1_amd64.deb ...
  Unpacking squid (3.5.6-1) ...
  Processing triggers for systemd (222-2) ...
  Setting up squid (3.5.6-1) ...
  Creating Squid HTTP proxy spool directory structure
  2015/07/23 12:29:22| storeDirWriteCleanLogs: Starting...
  2015/07/23 12:29:22|   Finished.  Wrote 0 entries.
  2015/07/23 12:29:22|   Took 0.00 seconds (  0.00 entries/sec).
  FATAL: Ipc::Mem::Segment::create failed to shm_open(/squid-cf__metadata.shm): 
(13) Permission denied
  
  dpkg: error processing package squid (--configure):
   subprocess installed post-installation script returned error exit status 1
  Processing triggers for systemd (222-2) ...
  Errors were encountered while processing:
   squid


Even though I haven't seen such an error before (previous squid and squid3
packages were tested without problems), this could be related to the piuparts
test setup. In that case feel free to reduce the severity and tell us what
squid "needs".


cheers,

Andreas


squid_3.5.6-1.log.gz
Description: application/gzip

Bug#741573: #741573: Menu Policy and Consensus

[Josselin Mouette]

Sam Hartman  wrote: 
That seems very unlikely to me.  Diversity is an important part of
Debian.  I think it is likely that the TC is going to value the Debian
Menu as long as Bill or someone else is going to work on it.  I would
expect us to value the menu enough to enable those who want to
contribute to it to do so.

Given the state menu is in, reading this is… flabbergasting, to say the
least. I would answer tons of things, but fortunately they have already
been put together concisely: http://islinuxaboutchoice.com/ 

I think that's consistent with the consensus proposal that you asked us
to consider in this bug.

The consensus proposal was, in order to preserve some bits of Bill’s
ego, to let menu die slowly by stopping to require mandatory entries for
a useless menu system that only a handful of obscure window managers are
still able to display. Now that Bill has made very clear, by completely
giving in to ridicule, that his ego should not be a problem, Charles is
merely proposing to accelerate that process and avoid pain for everyone.

-- 
Joss


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

Bug#793486: interchange-cat-standard: fails to install in sid: post-installation script returned error exit status 10

[Andreas Beckmann]

Package: interchange-cat-standard
Version: 5.7.7-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package interchange-cat-standard.
  (Reading database ... 
(Reading database ... 11471 files and directories currently installed.)
  Preparing to unpack .../interchange-cat-standard_5.7.7-2_all.deb ...
  Unpacking interchange-cat-standard (5.7.7-2) ...
  Setting up interchange-cat-standard (5.7.7-2) ...
  dpkg: error processing package interchange-cat-standard (--configure):
   subprocess installed post-installation script returned error exit status 10
  Errors were encountered while processing:
   interchange-cat-standard


cheers

Andreas


interchange-cat-standard_5.7.7-2.log.gz
Description: application/gzip

Bug#793484: squeeze update of expat?

[Raphael Hertzog]

Hello Laszlo,

the Debian LTS team would like to fix the security issues which are
currently open in the Squeeze version of expat:
https://security-tracker.debian.org/tracker/CVE-2015-1283

Would you like to take care of this yourself? We are still understaffed so
any help is always highly appreciated.

If yes, please follow the workflow we have defined here:
http://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-...@lists.debian.org
(via a debdiff, or with an URL pointing to the the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
-- 
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/


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

Bug#793331: RFS: postsrsd/1.2-1 [ITP]

[Oxan van Leeuwen]

Hi,

On 24-07-15 02:43, Cameron Norman wrote:

I see the prerm file is empty -- why not just delete it?
Oops, that's a leftover from the switch to dh_apparmor. I've deleted it 
in the git repository.



Also, why do you patch the sysv-redhat init script if you end up using
the sysv-lsb one? I think you can drop that part of the patch.
Yes, it's probably not that useful to keep that patch. It shouldn't hurt 
either though.



Finally, have you actually tested the AppArmor profile works on Debian?

Yes, I've tested it.

Cheers,
Oxan


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

Bug#793429: dgit: importing the whole package history from snapshot.d.o into dgit

[Ian Jackson]

Andreas Beckmann writes ("Bug#793429: dgit: importing the whole package history 
from snapshot.d.o into dgit"):
> Package: dgit
> Version: 1.0
> Severity: wishlist
> 
> Is there a possibility to import the complete history of a package from
> snapshot.d.o into dgit (soemthing like git-import-dscs --debsnap)?

There is nothing stopping a maintainer doing that, and pushing the
result to dgit.  (This ought to be done by the maintainer because it
is up to the maintainer what shape the dgit git graph should be.)

> (that history may not be linear but a tree or dag ... although that
> would probably mean manual postprocessing before the initial push)

There is no requirement for the history to be linear.  NMU history has
to be linear.

Ian.


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

Bug#793331: RFS: postsrsd/1.2-1 [ITP]

[Oxan van Leeuwen]

Hi Tomasz,

Yes, I'm still looking for a sponsor.

Cheers,
Oxan

On 23-07-15 23:40, Tomasz Buchert wrote:

Hi Oxan,
still looking for a sponsor? I've just wanted to implement
SRS on my mail server!

Tomasz




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

Bug#793340: mumble: Crash with a screen reader

[Chris Knadle]

On 07/23/2015 08:35 PM, Jean-Philippe MENGUAL wrote:
> Hi,
> 
> ok I Cc debian-kde too, as it's related to Qt.
> 
> Surprised you can't reproduce. Have you tried with MATE?

Yes, I tried with MATE.  Both for Sid amd64 natively, and Jessie amd64
in a VM.  [I had just loaded MATE again the other day, because I find I
like using it.  I normally use KDE but Sid was updated to Plasma 5 and I
find it's a bit different than KDE4 was.]

> Or another DE?

I haven't tried it under any other DEs/WMs so far.  I was focusing on
MATE because that's where the issue was seen.

> Other problems you mention are true, but I don't mention them as it's
> more general accessibility problems. They're boring, but not critical as
> they don't make mumble crash.
> 
> Well... maybe it's a related-hardware problem (memory leak or something

That's possible.  I recently had a machine that was having a lot of
unexplained Segfaults and hangs, and memtest86+ showed that there was a
section of memory that had errors.  There's nothing in this report that
makes me suspect that's the issue specifically, but if you could run
memtest86+ and let it complete one full run that would be good as it
would likely rule out a memory hardware issue.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us


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

Bug#793040: [Openexr-devel] Assertion `relError < .1' failed.

[Mathieu Malaterre]

sparc results just came out:
https://buildd.debian.org/status/fetch.php?pkg=openexr&arch=sparc&ver=2.2.0-1&stamp=1437746630

It is also failing and sparc is a big-endian arch.

On Fri, Jul 24, 2015 at 9:37 AM, Mathieu Malaterre  wrote:

> Seems to happen on every single big-endian archs we have in debian: mips,
> s390x, hppa and ppc64
>
>
> https://buildd.debian.org/status/fetch.php?pkg=openexr&arch=mips&ver=2.2.0-1&stamp=1437058713
>
> https://buildd.debian.org/status/fetch.php?pkg=openexr&arch=s390x&ver=2.2.0-1&stamp=1436979566
>
> http://buildd.debian-ports.org/status/fetch.php?pkg=openexr&arch=hppa&ver=2.2.0-1&stamp=1437015228
>
> http://buildd.debian-ports.org/status/fetch.php?pkg=openexr&arch=ppc64&ver=2.2.0-1&stamp=1437002247
>
> Same goes for powerpc I reported earlier. Do you have access to big-endian
> arch ?
>
> On Thu, Jul 23, 2015 at 4:39 PM, Karl Rasche  wrote:
>
>> Mathieu -
>>
>> Is there any straightforward way to trip the issue without being on a
>> ppc?
>>
>> Karl
>>
>>
>> On Monday, July 20, 2015, Mathieu Malaterre  wrote:
>>
>>> Dear all,
>>>
>>>
>>> We are seeing the following issue on powerpc when running the testsuite
>>> for openexr:
>>>
>>> lt-IlmImfTest: compareDwa.cpp:122: void compareDwa(int, int, const
>>> Imf_2_2::Array2D&, const Imf_2_2::Array2D&,
>>> Imf_2_2::RgbaChannels): Assertion `relError < .1' failed.
>>> /bin/bash: line 5: 16682 Aborted ${dir}$tst
>>> FAIL: IlmImfTest
>>>
>>> Could someone please comment on this issue ?
>>>
>>> Thanks much !
>>>
>>> full ref:
>>>
>>>
>>> https://buildd.debian.org/status/fetch.php?pkg=openexr&arch=powerpc&ver=2.2.0-1&stamp=1436979505
>>>
>>
>

Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard

[Maxime Ripard]

On Fri, Jul 24, 2015 at 02:58:31PM +0200, Hans de Goede wrote:
> There is slightly more to it then those 5 lines, but yes we should enable
> voltage scaling on more boards. This mostly requires someone to simply
> just do the work.
> 
> I've a workshop on dts this weekend at our localhacker space and the plan
> is for the people attending to get some handson experience by them doing
> this work (amongst other things)  :)

While I agree with you on the fact that more board needs to have the
regulators enabled, I really don't think that making some newbies
doing it without any schematics (and boards I guess?) is a good thing
when it comes to something that can permanently damage a board.

I'd expect that such changes would be carefully done and tested before
being submitted.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Bug#778099: ratbox-services: diff for NMU version 1.2.4+repack-2.1

[duck]

Coin,

On 2015-07-24 00:01, gregor herrmann wrote:

I've prepared an NMU for ratbox-services (versioned as 
1.2.4+repack-2.1) and

uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.


That's very kind of you. I delayed this work because I needed a take a 
decision about the future of this package, and that's now done (see 
#793408).


If you feel I'm wrong or you really like this piece of software, then 
feel free to adopt it :-).


Regards.

--
Marc Dequènes


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

Bug#778099: ratbox-services: diff for NMU version 1.2.4+repack-2.1

[gregor herrmann]

On Fri, 24 Jul 2015 15:10:38 +0200, Marc Dequènes (duck) wrote:

> >I've prepared an NMU for ratbox-services (versioned as
> >1.2.4+repack-2.1) and uploaded it to DELAYED/5. Please feel free
> >to tell me if I should delay it longer.
> That's very kind of you. I delayed this work because I needed a take a
> decision about the future of this package, and that's now done (see
> #793408).

Ah, funny coincidence :)
 
> If you feel I'm wrong or you really like this piece of software, then feel
> free to adopt it :-).

No, I just wanted to fix an RC bug; removing the package also has the
same effect, so that's fine for me :)


Cheers,
gregor, cancelling the NMU

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: James Taylor: Walking Man


signature.asc
Description: Digital Signature

Bug#789385: libosm-gary68-perl: diff for NMU version 0.0~svn26727-1.1

[Damyan Ivanov]

Control: tags 789385 + patch
Control: tags 789385 + pending

Dear maintainer,

I've prepared an NMU for libosm-gary68-perl (versioned as 
0.0~svn26727-1.1) and uploaded it to DELAYED/5. Please feel free to 
tell me if I should delay it longer.

Regards.
diff -Nru libosm-gary68-perl-0.0~svn26727/debian/changelog libosm-gary68-perl-0.0~svn26727/debian/changelog
--- libosm-gary68-perl-0.0~svn26727/debian/changelog	2011-09-30 23:29:05.0 +0300
+++ libosm-gary68-perl-0.0~svn26727/debian/changelog	2015-07-24 15:55:54.0 +0300
@@ -1,3 +1,11 @@
+libosm-gary68-perl (0.0~svn26727-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build dependency on libmodule-build-perl
+Closes: #789385 -- FTBFS with perl 5.22
+
+ -- Damyan Ivanov   Fri, 24 Jul 2015 12:55:53 +
+
 libosm-gary68-perl (0.0~svn26727-1) unstable; urgency=low
 
   * Initial release (Closes: #643916)
diff -Nru libosm-gary68-perl-0.0~svn26727/debian/control libosm-gary68-perl-0.0~svn26727/debian/control
--- libosm-gary68-perl-0.0~svn26727/debian/control	2011-09-30 23:29:05.0 +0300
+++ libosm-gary68-perl-0.0~svn26727/debian/control	2015-07-24 15:56:16.0 +0300
@@ -10,6 +10,7 @@
  , libdbi-perl
  , libgd-gd2-perl
  , libgeo-proj4-perl
+ , libmodule-build-perl
  , libwww-perl
 Standards-Version: 3.9.2
 Homepage: http://svn.openstreetmap.org/applications/utils/gary68/OSM/

Bug#741573: #741573: Menu Policy and Consensus

[Sam Hartman]

> "Charles" == Charles Plessy  writes:

Charles> I made efforts to keep the wording mild, but I think that
Charles> it was an error.
>> From your attiude as the lead person behind the Debian Menu, it
>> is clear that
Charles> it has no future.  For one decade, you have taken no
Charles> leadership to build this future.  As a consequence, I think
Charles> that the next step is to plan its replacement and
Charles> deprecation.  Maybe the TC will come to this conclusion.

That seems very unlikely to me.  Diversity is an important part of
Debian.  I think it is likely that the TC is going to value the Debian
Menu as long as Bill or someone else is going to work on it.  I would
expect us to value the menu enough to enable those who want to
contribute to it to do so.

I think that's consistent with the consensus proposal that you asked us
to consider in this bug.


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

Bug#793482: ITP: bookkeeper -- Replicated log service

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: bookkeeper
  Version : 4.2.4
  Upstream Author : The Apache Software Foundation
* URL : http://bookkeeper.apache.org
* License : Apache-2.0
  Programming Lang: Java
  Description : Replicated log service

BookKeeper is a replicated log service which can be used to build replicated
state machines. A log contains a sequence of events which can be applied to
a state machine. BookKeeper guarantees that each replica state machine will
see all the same entries, in the same order.

This package is a dependency of Hadoop


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

Bug#793198: systemd: poweroff, reboot without stopping services and unmounting

[Пронин Илья Сергеевич]

Well, thank you for patience! 

I have to switch to sysv-init or openrc. It does fsck at boot time and
tells everything is clean.

I insist that systemd is main suspect, but I could be wrong.

Thank you anyway.

--
best regards,
Eli


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

Bug#793198: systemd: poweroff, reboot without stopping services and unmounting

[Michael Biebl]

Am 24.07.2015 um 15:22 schrieb Пронин Илья Сергеевич:
> Well, thank you for patience! 
> 
> I have to switch to sysv-init or openrc. It does fsck at boot time and
> tells everything is clean.
> 
> I insist that systemd is main suspect, but I could be wrong.

What I've seen so far indicates otherwise. The logs show a clean
shutdown with the file systems unmounted.

Please keep systemd running and debugging enabled.
If you get errors during boot, please attach the shutdown log from the
*preceding* shutdown and the journalctl dump from the boot with the errors.

Is there anything special about this setup? Custom configuration, custom
initramfs, anything?

Thanks,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard

[m . silentcreek]

Am Freitag, 24. Juli 2015 14:49:42 UTC+2 schrieb Thomas Kaiser:
> Ah, now I think I understand. You're talking about these lines here?
> 
> 
>     
> https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/dts/sun7i-a20-cubietruck.dts#L244-L269
>
Yes. 
> 
> So while using CONFIG_REGULATOR_AXP20X=y will bring working cpufreq support 
> to the cubietruck, shouldn't adding these lines to the device trees of the 
> other 5 A20 devices enable CPU voltage scaling there?

Basically yes. The point that Chen-Yu made is that he and other developers 
don't have all boards available to verify that all of these boards use the same 
layout for their wiring. Therefore they just leave these bits out. I'm actually 
working on a small patch to add these regulator bits to the BananaPi and 
possibly BananaPro dts files. I will post it soon, when I gathered enough 
information to ensure everything works fine. But anyway, we're getting offtopic 
here. So let's postpone this discussion until then.

Cheers,

Timo

Bug#793485: makedumpfile missing fadump patches

[Chris J Arges]

Package: makedumpfile
Version: 1:1.5.8-3

Ubuntu bug (LP: #1415562) introduced a patch for fadump support on
POWER8. Please re-introduce this into the debian version. The current
Ubuntu bug tracking this is (LP: #1475497).

Thanks,
--chris j arges


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

Bug#793198: systemd: poweroff, reboot without stopping services and unmounting

[Michael Biebl]

Am 24.07.2015 um 14:41 schrieb Пронин Илья Сергеевич:
>  авг 08 04:01:14 shambler systemd-fsck[416]: /dev/sda6 contains a file
>  system with errors, check forced. 1736 авг 08 04:01:14 shambler
>  systemd-fsck[375]: /dev/sda8 contains a file system wit h errors,
>  check forced. 1737 авг 08 04:01:14 shambler
>  systemd-fsck[375]: /dev/sda8: Inode 13, i_size is 29040 , should
>  be 35840.  FIXED.

In the other logs you posted, it shows that umount has been run
successfully for /home during shutdown.

So I can't explain why you get such fs errors during boot. Maybe a
kernel or hardware issue.
Please check your RAM. Please boot from a recovery CD and run an
extended SMART check and fsck/badblocks on all your fs.







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



signature.asc
Description: OpenPGP digital signature

Bug#793483: docker.io: New Docker version 1.7.1 available

[Carl Chenet]

Package: docker.io
Version: 1.6.2~dfsg1-1
Severity: wishlist

Dear Maintainer,


Docker 1.7.1 is available. Please consider packaging it and why not backporting 
it to Jessie.

Regards,
Carl Chenet

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

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

Versions of packages docker.io depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.22
ii  iptables 1.4.21-2+b1
ii  libapparmor1 2.9.2-3
ii  libc62.19-18
ii  libdevmapper1.02.1   2:1.02.90-2
ii  libsqlite3-0 3.8.7.1-1+deb8u1
ii  perl 5.20.2-6

Versions of packages docker.io recommends:
ii  aufs-tools   1:3.2+20130722-1.1
ii  ca-certificates  20141019
ii  cgroupfs-mount   1.2
ii  git  1:2.1.4-2.1
ii  xz-utils 5.1.1alpha+20120614-2+b3

Versions of packages docker.io suggests:
pn  btrfs-tools  
ii  debootstrap  1.0.70
pn  lxc  
pn  rinse

-- no debconf information


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

Bug#789409: librg-exception-perl: diff for NMU version 1.0.3-1.1

[Damyan Ivanov]

Control: tags 789409 + patch
Control: tags 789409 + pending

Dear maintainer,

I've prepared an NMU for librg-exception-perl (versioned as 1.0.3-1.1) 
and uploaded it to DELAYED/5. Please feel free to tell me if I should 
delay it longer.

Regards.
diff -Nru librg-exception-perl-1.0.3/debian/changelog librg-exception-perl-1.0.3/debian/changelog
--- librg-exception-perl-1.0.3/debian/changelog	2012-07-14 09:26:42.0 +0300
+++ librg-exception-perl-1.0.3/debian/changelog	2015-07-24 15:58:40.0 +0300
@@ -1,3 +1,11 @@
+librg-exception-perl (1.0.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build dependency on libmodule-build-perl
+Closes: #789409 -- FTBFS with perl 5.22
+
+ -- Damyan Ivanov   Fri, 24 Jul 2015 12:58:08 +
+
 librg-exception-perl (1.0.3-1) unstable; urgency=low
 
   * Initial release (Closes: #681098)
diff -Nru librg-exception-perl-1.0.3/debian/control librg-exception-perl-1.0.3/debian/control
--- librg-exception-perl-1.0.3/debian/control	2012-07-20 09:57:56.0 +0300
+++ librg-exception-perl-1.0.3/debian/control	2015-07-24 15:59:08.0 +0300
@@ -4,7 +4,7 @@
 Maintainer: Debian Med Packaging Team 
 Uploaders: Ariane Boehm , Laszlo Kajan 
 Build-Depends: debhelper (>= 8)
-Build-Depends-Indep: perl
+Build-Depends-Indep: perl, libmodule-build-perl
 Standards-Version: 3.9.3
 Homepage: http://rostlab.org/
 Vcs-Svn: svn://svn.debian.org/debian-med/trunk/packages/librg-exception-perl/trunk/

Bug#793484: expat: CVE-2015-1283: Multiple integer overflows in the XML_GetBuffer function

[Raphael Hertzog]

Package: expat
Severity: grave
Tags: security patch

Hi,

the following vulnerability was published for expat.

CVE-2015-1283[0]:
| Multiple integer overflows in the XML_GetBuffer function in Expat
| through 2.1.0, as used in Google Chrome before 44.0.2403.89 and other
| products, allow remote attackers to cause a denial of service
| (heap-based buffer overflow) or possibly have unspecified other impact
| via crafted XML data, a related issue to CVE-2015-2716.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2015-1283
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1283
Please adjust the affected versions in the BTS as needed.

It looks like that Mozilla wrote a patch here:
https://hg.mozilla.org/releases/mozilla-esr31/rev/2f3e78643f5c

And chromium reused that patch too.

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/


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

Bug#793185: [linux-sunxi] Re: forwarding a bug: cpufreq missing in debian stable on a cuibeboard

[Hans de Goede]

Hi,

On 24-07-15 14:49, Thomas Kaiser wrote:

Hi,

Timo wrote:


I think what Maxime was trying to say is, that while all of your boards
support Cpufreq, only the Cubietruck supports voltage scaling because only
Cubietruck has the power regulator nodes defined in it's dts file (just
have a look at the last lines of the Cubitruck dts file and compare that to
the dts file, let's say, for Bananapi). On the other boards, the frequency
is scaled, but the voltage always stays at 1.4V as set in U-Boot (that
means the voltages in the cpufreq operating points are not used on these
boards). At least that's what I understand after a recent email axchange
with Chen-Yu Tsai.



Ah, now I think I understand. You're talking about these lines here?


https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/dts/sun7i-a20-cubietruck.dts#L244-L269

So while using CONFIG_REGULATOR_AXP20X=y will bring working cpufreq support
to the cubietruck, shouldn't adding these lines to the device trees of the
other 5 A20 devices enable CPU voltage scaling there?


There is slightly more to it then those 5 lines, but yes we should enable
voltage scaling on more boards. This mostly requires someone to simply
just do the work.

I've a workshop on dts this weekend at our localhacker space and the plan
is for the people attending to get some handson experience by them doing
this work (amongst other things)  :)

Regards,

Hans


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