Bug#1072298: python3-smart-open: Make dependency on azure optional

[Erich Schubert]

Package: python3-smart-open
Version: 5.2.1-6
Severity: normal

The installation of python3-azure, python3-azure-storage took a considerable
amount of time (for precompilation), but I do not use it, nor intend to 
use it.


2,4G    /usr/lib/python3/dist-packages/azure/

this size is not quite OK for something one does not use, and I only 
have two Python version installed.


This also holds for python3-boto3, and others might not need 
python3-paramiko.


But I did not negatively notice these regarding compilation times and 
error messages (the azure stuff appears to be full of invalid escape 
sequences originating from Windows file names in the documentation). 
These two are much smaller (101M and 3M).


It should be trivial to make these dependencies only suggested or 
recommended.

The file transport.py already silently catches ImportError to
detect missing dependencies.

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

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to de_DE.utf-8), LANGUAGE not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-smart-open depends on:
ii  python3    3.11.8-1
ii  python3-azure  20240522+git-2
ii  python3-azure-storage  20240522+git-2
ii  python3-boto3  1.34.46+dfsg-1
ii  python3-paramiko   3.4.0-1
ii  python3-requests   2.31.0+dfsg-2

python3-smart-open recommends no packages.

python3-smart-open suggests no packages.

-- no debconf information

Bug#1057249: elki: please package v0.8

[Erich Schubert]

block 1057249 by 998708
thanks

There are at least these two blockers to updating ELKI in Debian:

1. Gradle in Debian is 4.4.1, from 2017, current Gradle is 8.6 #998708

2. JaFaMa is not packaged in Debian https://github.com/jeffhain/jafama
(we should possibly eliminate this dependency from ELKI)

Regards,
Erich

Am 02.12.23 um 04:52 schrieb Alexandre Detiste:

Source: elki
Version: 0.7.1-10.1
Severity: normal

A new version 0.8 is available:

https://github.com/elki-project/elki/releases/tag/release0.8.0


Please also add a debian/watch file.

Greetings

-- System Information:
Debian Release: trixie/sid
   APT prefers testing
   APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1051418: bad patch: debian/patches/0013-Fix-comparision-if-char-is-unsigned.patch

[Erich Schubert]

tag 1051418 +patch
thanks

Removing the bad patch
debian/patches/0013-Fix-comparision-if-char-is-unsigned.patch
and rebuilding the package fixes this bug.

Bug#1051418: obs unusable

[Erich Schubert]

In my opinion, this is a grave bug.

It makes OBS almost unusable for me, because any click on a window 
source crashes obs. You cannot even remove these sources!


Recording an entire screen still works, but not recording single windows.

The earlier message by Michael Neilly suggests that maybe this Debian 
patch is causing the problem:


https://sources.debian.org/src/obs-studio/30.0.2%2Bdfsg-2/debian/patches/0013-Fix-comparision-if-char-is-unsigned.patch/

Note that it diverges from the linked upstream patch 
https://github.com/obsproject/obs-studio/pull/9184/files


Can you refresh this patch?

Regards,
Erich Schubert

Bug#1057249: elki: please package v0.8

[Erich Schubert]

I have been considering to drop the package, simply because all you need 
to get is a single jar file - no installation necessary, and hence there 
is little benefit from having a full Debian package. Because the build 
process is now Gradle instead of Maven, the package build needs to be 
updated. And so far, there is no dependency on elki that I know of.


Regards,
Erich

Am 02.12.23 um 04:52 schrieb Alexandre Detiste:

Source: elki
Version: 0.7.1-10.1
Severity: normal

A new version 0.8 is available:

https://github.com/elki-project/elki/releases/tag/release0.8.0


Please also add a debian/watch file.

Greetings

-- System Information:
Debian Release: trixie/sid
   APT prefers testing
   APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1002838: pdfarranger: Error "Can't convert ObjectHelper" when saving

[Erich Schubert]

Package: pdfarranger
Version: 1.8.0-1
Followup-For: Bug #1002838

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pdfarranger/pdfarranger.py", line 976,
in choose_export_pdf_name
self.save(mode, file_out)
File "/usr/lib/python3/dist-packages/pdfarranger/pdfarranger.py", line 160,
in wrapper
func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pdfarranger/pdfarranger.py", line 1050,
in save
exporter.export(self.pdfqueue, to_export, file_out, mode, m)
File "/usr/lib/python3/dist-packages/pdfarranger/exporter.py", line 165, in
export
new_page = pdf_output.make_indirect(new_page)
TypeError: Can't convert ObjectHelper (or subclass) to Object 
implicitly. Use

.obj to get access the underlying object.


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

Kernel: Linux 5.14.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to de_DE.utf-8), LANGUAGE not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pdfarranger depends on:
ii gir1.2-glib-2.0 1.70.0-2
ii gir1.2-gtk-3.0 3.24.31-1
ii gir1.2-poppler-0.18 21.11.0-1
ii python3 3.9.8-1
ii python3-cairo 1.20.1-3
ii python3-dateutil 2.8.1-6
ii python3-gi 3.42.0-3
ii python3-gi-cairo 3.42.0-3
ii python3-pikepdf 4.2.0+dfsg-1
ii python3-pkg-resources 59.6.0-1

Versions of packages pdfarranger recommends:
ii python3-img2pdf 0.4.2-1

pdfarranger suggests no packages.

-- no debconf information

Bug#1002838: pdfarranger: Error "Can't convert ObjectHelper" when saving

[Erich Schubert]

Package: pdfarranger
Version: 1.8.0-1
Severity: important

When trying to join multiple PDF using pdfarranger, I get the following 
error

when trying to save the result:

Can't convert ObjectHelper to Object (or subclass) implicitly.
Use .obj to get access to the underlying object.

As this looks like a programmer error message, maybe some dependency has
changed, and ".obj" needs to be inserted somewhere in the code?


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

Kernel: Linux 5.14.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to de_DE.utf-8), LANGUAGE not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pdfarranger depends on:
ii gir1.2-glib-2.0 1.70.0-2
ii gir1.2-gtk-3.0 3.24.31-1
ii gir1.2-poppler-0.18 21.11.0-1
ii python3 3.9.8-1
ii python3-cairo 1.20.1-3
ii python3-dateutil 2.8.1-6
ii python3-gi 3.42.0-3
ii python3-gi-cairo 3.42.0-3
ii python3-pikepdf 4.2.0+dfsg-1
ii python3-pkg-resources 59.6.0-1

Versions of packages pdfarranger recommends:
ii python3-img2pdf 0.4.2-1

pdfarranger suggests no packages.

-- no debconf information

Bug#998736: adb: Version update: "adb peer" missing for Android 11+

[Erich Schubert]

Package: adb
Version: 1:29.0.6-1
Severity: important

In order to use "adb connect" with an android 11 device, it appears to be
necessary to peer first with a PIN. This functionality is not available 
in the

package, and this likely can be solved by updating to upstream 11+ (30.0.0
added wireless pairing)

Bug#986027: Fwd: [Bug 1706594] 100% CPU usage on WebExtensions process

[Erich Schubert]

A fix is scheduled for Firefox 95 apparently.

https://bugzilla.mozilla.org/show_bug.cgi?id=1706594

https://hg.mozilla.org/mozilla-central/rev/2c21101c4b3b

After removing the webext-* packages and installing the extensions 
manually, the issue did not reoccur for me. So if you want a workaround, 
uninstall the packaged extensions, and install them via the browser instead.


Regards,
Erich

Bug#986027: Fwd: [Bug 1706594] 100% CPU usage on WebExtensions process

[Erich Schubert]

Apparently, there exists a preliminary fix for this issue.

 Forwarded Message 
Subject:[Bug 1706594] 100% CPU usage on WebExtensions process
Date:   Thu, 23 Sep 2021 18:22:36 +



*Comment # 32  
on Bug 1706594  
from Luca Greco [:rpl] [:luca] [:lgreco]  at 
2021-09-23 11:22:34 PDT *


I just looked to the debian bug report linked from comment 5 
 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986027) and then to 
the content of the debian packages for one of the extension mentioned in 
that bug and then I realized that the extension installed from these 
debian packages are unpackaged and so they should be triggering the 
exact same issue that I was able to trigger consistently using the STR 
from comment 15  (where ABP has to also be 
loaded as unpacked to trigger the issue consistently).


e.g. the content of thewebext-private-badger one from 
packages.ubuntu.com (debian.packages.org seems to don't be able to show 
the list of files, but they should be packaged exactly in the same way 
from this perspective):


 * https://packages.ubuntu.com/hirsute/all/webext-privacy-badger/filelist

This confirms that the attached fix should also be covering the issue 
experienced by debian/ubuntu users that are installing extensions from 
deb packages instead of installing them from addons.mozilla.org (or by 
installing the signed xpi non temporarily).


(I'm also clearing the previously assigned needinfos, I discussed the 
proposed approach used in the current version of the attached patch with 
Nika over Matrix and we will continue on phabricator).

Bug#991696: Bug#991698: Possible CVE-2014-5461 in enigma-data

[Erich Schubert]

reassign 991698 enigma

merge 991698 991696

thanks

It does not make sense to report the bug against the *data* package. Its 
in the binary, not the data. No need to report it twice.


Also, why use a screenshot of the diff, and not just the diff directly, 
wtf? Why would you make a screenshot of a diff in the first place?


Clearly this should be fixed, but the security implications are very 
limited.



The enigma package currently is not maintained. A new upstream version 
exists.


Someone has indicated the intent to adopt the package, but not much has 
happened so far: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902855



Am 30.07.21 um 13:12 schrieb Movses Tovmasyan:

Package: enigma-data
Version: 1.20-dfsg.1-2.1
Tags: patch

enigma-data uses the obsolete version of minilua
(single-file port of Lua) which has CVE-2014-5461
Patch attached below.

Bug#991917: python3-wikitrans: Wiki 2 html conversion errors

[Erich Schubert]

Hi,

3. WikiDelimNodes (generated by wikimarkup: ''Example'') cause raw
JSON to be
inserted in the HTML:

Can you give more detail, please?


I believe this article causes the problem:

https://simpsons.fandom.com/wiki/John_Swartzwelder?action=edit

It may be because of seemingly mismatched quotes:

''The Simpsons''' 16th season

which is rendered (supposedly correct) as: "/The Simpsons'/ 16th season"

Regards,
Erich

Bug#991917: python3-wikitrans: Wiki 2 html conversion errors

[Erich Schubert]

Package: python3-wikitrans
Version: 1.3-1
Severity: important
Tags: upstream
X-Debbugs-Cc: g...@gnu.org

Unfortunately, the wikitrans package fails to convert wiki to html quite 
often.


Here are some errors I noticed when processing the Simpsons fandom wiki:

1. This upstream patch should be included in the package:

https://git.gnu.org.ua/wikitrans.git/commit/?id=c785e3ad767b12a13ae75a3513ec88a4d1144210

2. A wrong variable name is used here:
File "/usr/lib/python3/dist-packages/wikitrans/wikimarkup.py", line 662, in
parse_ref
list.append(self.parse_tag(tok))
TypeError: descriptor 'append' for 'list' objects doesn't apply to a
'HtmlTagNode' object

Here, `list` is the standard class, the instance apparently was renamed to
`seq` in some places. Looks like a copy and paste error to me, as in other
location the local variable is named `list`.

https://git.gnu.org.ua/wikitrans.git/tree/wikitrans/wikimarkup.py?id=c785e3ad767b12a13ae75a3513ec88a4d1144210#n662

3. WikiDelimNodes (generated by wikimarkup: ''Example'') cause raw JSON 
to be

inserted in the HTML:

{"content": "''", "type": "DELIM", "wikinode": "WikiDelimNode"}

A simple workaround (but not a proper solution) is to override the __str__
method as follows:

wikitrans.wiki2html.WikiDelimNode.__str__ = lambda self: ""

Alternatively, one could return `self.content`, but a proper solution 
would be

to generate opening and closing em and bold tags I guess; but I am only
interested in the text, so this hotfix works for me.

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL

set to de_DE.utf-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-wikitrans depends on:
ii python3 3.9.2-3

python3-wikitrans recommends no packages.

python3-wikitrans suggests no packages.

Bug#977112: texlive-latex-extra: dinbrief package is broken with texlive 20201203

[Erich Schubert]

Package: texlive-latex-extra
Version: 2020.20201129-1
Severity: normal

The dinbrief package (last updated upstream 2000?) is broken now (it 
worked before the recent uploads of 20201203):


! Undefined control sequence.
\set@color ...\@pdfcolorstack push{\current@color
  }\aftergroup \reset@color
\sbox  #1#2->\setbox #1\hbox {\color@setgroup
  #2\color@endgroup }
\@item ...i \fi \sbox \@tempboxa {\makelabel {#1}}
  \global \setbox 
\@labels \...


   \relax


https://groups.google.com/forum/embed/#!topic/de.comp.text.tex/ORKhTTha9EQ

The following workaround worked for me:

after \begin{document}, insert:
\makeatletter\let\default@color\current@color\makeatother


I don't know whether it is worth fixing this package upstream, or 
dropping it,
given that it seems to be dead upstream for 20 years now. I guess I will 
try to

switch to scrlttr2.



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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to de_DE.utf-8), LANGUAGE not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages texlive-latex-extra depends on:
ii  libcommons-logging-java    1.2-2
ii  libpdfbox-java 1:1.8.16-2
ii  preview-latex-style    12.2-1
ii  python3    3.9.0-4
ii  tex-common 6.15
ii  texlive-base   2020.20201203-2
ii  texlive-binaries   2020.20200327.54578-5
ii  texlive-latex-recommended  2020.20201203-2
ii  texlive-pictures   2020.20201203-2

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2020.20201203-2
ii  texlive-plain-generic  2020.20201129-1

Versions of packages texlive-latex-extra suggests:
ii  icc-profiles    2.1-2
ii  libfile-which-perl  1.23-1
pn  libspreadsheet-parseexcel-perl  
ii  python3-pygments    2.7.1+dfsg-1
pn  texlive-latex-extra-doc 

Versions of packages tex-common depends on:
ii  dpkg  1.20.5
ii  ucf   3.0043

Versions of packages tex-common suggests:
ii  debhelper  13.3

Versions of packages texlive-latex-extra is related to:
ii  tex-common    6.15
ii  texlive-binaries  2020.20200327.54578-5

-- no debconf information

Bug#959657: olive-editor: Does not start: symbol lookup error

[Erich Schubert]

Package: olive-editor
Version: 20200210-1
Severity: grave
Justification: renders package unusable

olive-editor: symbol lookup error: /lib/libOpenColorIO.so.1: undefined 
symbol:

_ZN4YAML6detail9node_data12empty_scalarB5cxx11E

Clearly the dependencies are not tight enough, and the package needs to be
rebuilt for the current library versions.



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

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: 
LC_ALL set to de_DE.utf-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) 
(ignored: LC_ALL set to de_DE.utf-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages olive-editor depends on:
ii  ffmpeg 7:4.2.2-1+b1
ii  frei0r-plugins 1.7.0-1
ii  libavcodec58   7:4.2.2-1+b1
ii  libavfilter7   7:4.2.2-1+b1
ii  libavformat58  7:4.2.2-1+b1
ii  libavutil56    7:4.2.2-1+b1
ii  libc6  2.30-4
ii  libgcc-s1  10-20200418-1
ii  libopencolorio1v5  1.1.1~dfsg0-6+b1
ii  libopenimageio2.1  2.1.13.0~dfsg0-1
ii  libqt5core5a   5.12.5+dfsg-10
ii  libqt5gui5 5.12.5+dfsg-10
ii  libqt5multimedia5  5.12.5-1+b1
ii  libqt5multimedia5-plugins  5.12.5-1+b1
ii  libqt5widgets5 5.12.5+dfsg-10
ii  libstdc++6 10-20200418-1
ii  libswresample3 7:4.2.2-1+b1
ii  libswscale5    7:4.2.2-1+b1

olive-editor recommends no packages.

olive-editor suggests no packages.

-- no debconf information

Bug#934989: openjdk-11-jre: Performance of JDK11/12 is 10%-15% worse than JDK8

[Erich Schubert]

Hi,

To reproduce the experiments, get the (older than what I used) ELKI 
standalone jar here:


https://elki-project.github.io/releases/release0.7.5/elki-bundle-0.7.5.jar

The data set can be downloaded here:

http://elki.dbs.ifi.lmu.de/datasets/multiview/aloi/aloi-hsb-2x2x2.csv.gz

A suitable command line is:

taskset -c 0 $JAVA_HOME/bin/java \
-jar elki-bundle-0.7.5.jar \
cli -time -dbc.in aloi-hsb-2x2x2.csv.gz \
-algorithm clustering.DBSCAN -dbscan.minpts 20 -dbscan.epsilon 0.01 \
-evaluator NoAutomaticEvaluation -resulthandler DiscardResultHandler

the "cli" command runs this headless; the "-time" parameter enables a 
minimal output of statistics. The last two parameter disable the 
(unnecessary for this purpose) evaluation and result output. tasksets 
forces this to use only the first CPU (except for the garbage 
collection, everything is single-threaded in this call).


The output is just three lines of statistics:

de.lmu.ifi.dbs.elki.datasource.FileBasedDatabaseConnection.load: 1967 ms
de.lmu.ifi.dbs.elki.algorithm.clustering.DBSCAN.average-neighbors: 
84.39775963718822

de.lmu.ifi.dbs.elki.algorithm.clustering.DBSCAN.runtime: 258124 ms

You can ignore the second line. The first is the time needed for parsing 
the csv.gz, the last line is the runtime of DBSCAN without index (adding 
an index with additional command line options speeds this up a lot, but 
for regression testing it does make sense to also look at the 
linear-scanning runtime). Alternatively, you can use the wall-clock-time 
measurement with /usr/bin/time, if you prefer that.


Regards,
Erich


On 8/17/19 9:29 PM, tony mancill wrote:


Hello Erich,

On Sat, Aug 17, 2019 at 08:41:23PM +0200, Erich Schubert wrote:

Subject: openjdk-11-jre: Performance of JDK11/12 is 10%-15% worse than JDK8
Package: openjdk-11-jre
Version: 11.0.4+11-1
Severity: normal
Tags: upstream

In my benchmarks, JDK 11 and 12 scores around 10%-20% worse runtime
than JDK 8.

I also tried Oracle Graal CE and Graal EE, and they perform even
worse. I also tried AdoptOpenJDK packages, and these perform similar
to the Debian versions.

The difference is substantial; this is not a toy microbenchmark that
only tests a single tiny code fragment. Instead, I run ELKI to
benchmark DBSCAN clustering on a dataset with over 100k points; a
typical workload that I am interested in.  This code is well
optimized, and requires very little garbage collection (5 young gen
runs each, about 80 ms total GC time). Memory limits are high enough
to let this run smoothly.  I have measured both in-Java time of two
steps, and wall-clock time of the entire process until completion.

Loading 110250 vectors from a .csv.gz file with

Java   8: 1837 ms
Java  11: 1955 ms
Java  12: 1946 ms
Graal EE: 4834 ms (ouch)

The difference between 8 and 11/12 is significant (this is within
Java, so it is not just a startup difference). The difference between
11 and 12 is random.  Graal is really bad here, but loading the data
is just 2-5 seconds total here anyway.

Running DBSCAN clustering on this data, using linear scans (I also
have results with index acceleration):

Java   8: 231677 ms
Java  11: 255017 ms
Java  12: 255266 ms
Graal EE: 261761 ms

Again, Java 11 and 12 are similar, within the usual measurement differences.
But they are both 10% worse than Java 8, which is significant. Graal is even
13% worse. In other experiments, I have seen differences of 15% (J11/12) and
20% (Graal).

For larger data sets, many iterations, etc. this runtime difference of 30
seconds quickly adds up to a lot of time...

Because of this, I currently stick to Java 8.

Thank you for the bug report and the detailed results.  Would you be
able to share a gist/pointer with more details about how you conducted
the benchmark?  I'm not familiar with ELKI but am interested in doing
this sort of benchmarking on an ongoing basis.

Thank you,
tony

Bug#934989: openjdk-11-jre: Performance of JDK11/12 is 10%-15% worse than JDK8

[Erich Schubert]

Subject: openjdk-11-jre: Performance of JDK11/12 is 10%-15% worse than JDK8
Package: openjdk-11-jre
Version: 11.0.4+11-1
Severity: normal
Tags: upstream

In my benchmarks, JDK 11 and 12 scores around 10%-20% worse runtime than 
JDK 8.


I also tried Oracle Graal CE and Graal EE, and they perform even worse. 
I also
tried AdoptOpenJDK packages, and these perform similar to the Debian 
versions.


The difference is substantial; this is not a toy microbenchmark that 
only tests
a single tiny code fragment. Instead, I run ELKI to benchmark DBSCAN 
clustering
on a dataset with over 100k points; a typical workload that I am 
interested in.

This code is well optimized, and requires very little garbage collection (5
young gen runs each, about 80 ms total GC time). Memory limits are high 
enough

to let this run smoothly.
I have measured both in-Java time of two steps, and wall-clock time of the
entire process until completion.

Loading 110250 vectors from a .csv.gz file with

Java   8: 1837 ms
Java  11: 1955 ms
Java  12: 1946 ms
Graal EE: 4834 ms (ouch)

The difference between 8 and 11/12 is significant (this is within Java, 
so it
is not just a startup difference). The difference between 11 and 12 is 
random.
Graal is really bad here, but loading the data is just 2-5 seconds total 
here

anyway.

Running DBSCAN clustering on this data, using linear scans (I also have 
results

with index acceleration):

Java   8: 231677 ms
Java  11: 255017 ms
Java  12: 255266 ms
Graal EE: 261761 ms

Again, Java 11 and 12 are similar, within the usual measurement differences.
But they are both 10% worse than Java 8, which is significant. Graal is even
13% worse. In other experiments, I have seen differences of 15% (J11/12) and
20% (Graal).

For larger data sets, many iterations, etc. this runtime difference of 30
seconds quickly adds up to a lot of time...

Because of this, I currently stick to Java 8.



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: 
LC_ALL set to de_DE.utf-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) 
(ignored: LC_ALL set to de_DE.utf-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openjdk-11-jre depends on:
ii  libc6    2.28-10
ii  libgif7  5.1.4-3
ii  libgl1   1.1.0-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libpng16-16  1.6.37-1
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  openjdk-11-jre-headless  11.0.4+11-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages openjdk-11-jre recommends:
ii  fonts-dejavu-extra   2.37-1
ii  libatk-wrapper-java-jni  0.35.0-2

openjdk-11-jre suggests no packages.

-- no debconf information

Bug#895695: elki FTBFS: java.base/jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to java.base/java.net.URLClassLoader

[Erich Schubert]

close 895695
thanks

Building with openjdk-8 is different issue. Maven was broken with Java 
11 back then within its dependencies (but #903769 is supposedly fixed 
now, so building with Java 11 should work) and Maven would NPE; the ELKI 
code was already made compatible with Java 11.


This precise bug has been fixed, as can be seen from the changelog and 
this patch:


https://sources.debian.org/src/elki/0.7.1-9/debian/patches/java9-classloader.patch/

Undoing the workaround for #903769 is a different issue, and simply 
means reverting the workaround from 0.7.1-8 and allow openjdk-11, not 
only java 8.


Regards,
Erich


Am 29.10.18 um 12:41 schrieb Emmanuel Bourg:

Control: reopen -1
Control: notfixed -1 0.7.1-7
Control: user debian-j...@lists.debian.org
Control: usertag -1 + default-java9
Control: tags -1 + sid buster fixed-upstream

I'm reopening the bug because the compatibility with Java 9 and later
wasn't really fixed, the JDK was just reverted to openjdk-8. openjdk-11
will be the default JDK in Buster, the upstream fix should be applied
instead, and the build dependency changed back to default-jdk.

Bug#911925: Latest OpenJDK breaks various builds

[Erich Schubert]

severity 911925 important
thanks

As the ant build error was unrelated (likely a version problem, 
eventually killing the "build" folder to force a clean rebuild helped), 
reducing to "important" again.


Nevertheless, several users have observed this build problem with Maven 
surefire. While it may well be an issue with surefire, this causes 
unexpected build problems in other Java programs and needs to be 
investigated.


Downgrading via 
http://snapshot.debian.org/package/openjdk-8/8u181-b13-1/ helped for 
surefire.


Regards,
Erich

Bug#911925: Latest OpenJDK breaks various builds

[Erich Schubert]

severity 911925 grave
thanks

Grave because this causes odd errors in various Java compilation tasks, 
and possibly in some Java applications, to make sure this version 
doesn't easily enter testing.



Apparently this upload causes various build problems in particular with 
Maven (surefire) but also ant.


Here is an ant error when trying to "ant compile" UMLgraph: 
https://github.com/dspinellis/UMLGraph

---

compile:
    [javac] Compiling 20 source files to 
/home/erich/workspace/UMLGraph/build
    [javac] 
/home/erich/workspace/UMLGraph/src/main/java/org/umlgraph/doclet/ClassGraph.java:323: 
error: cannot access ClassDoc
    [javac]         optionProvider.getOptionsFor(c instanceof ClassDoc 
? (ClassDoc) c : c.containingClass()) //

    [javac]           ^
    [javac]   class file for ClassDoc not found

---

Now tools.jar is on the classpath, it seems to be in the package (but 
possibly the binary is broken?)


With maven, I get a different failure:

---

[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ umlgraph ---
[INFO] Surefire report directory: 
/home/erich/workspace/UMLGraph/target/surefire-reports


---
 T E S T S
---
Error: Could not find or load main class 
org.apache.maven.surefire.booter.ForkedBooter


[...]

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test 
(default-test) on project umlgraph: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The 
forked VM terminated without saying properly goodbye. VM crash or 
System.exit called ? -> [Help 1]


---

The same surefire problem was also reported here: 
https://stackoverflow.com/questions/53010200/maven-surefire-could-not-find-forkedbooter-class/53016532#53016532


On other systems, the package builds fine, including on Travis CI.


It seems this only affects certain (system?) class loader scenarios - 
surefire adds a jar, and the ant build needs the tools.jar.


My guess is that the backport of the security fixes didn't completely 
work...


Regards,
Erich

Bug#910395: mediathekview with openjfx 11

[Erich Schubert]

Hi,

It seems the classpath is not set up correctly.

With Java 11 as my main java, the following works:

java -cp 
/usr/share/mediathekview/MediathekView.jar:/usr/share/java/javafx-base-11.jar:/usr/share/java/javafx-controls-11.jar:/usr/share/java/javafx-fxml-11.jar:/usr/share/java/javafx-graphics-11.jar:/usr/share/java/javafx-media-11.jar:/usr/share/java/javafx-swing-11.jar:/usr/share/java/javafx-web-11.jar 
mediathek.Main


Since this launches correctly (I haven't tried to load anything though) 
it seems the classpath / launch script is the problem.


(If your default java is 8, you may need to set JAVA_HOME or use the 
full path name).

Bug#903769: libcommons-lang3-java: NPE with OpenJDK11 and maven-javadoc

[Erich Schubert]

Hi,


Thank you for the report Erich. What version of OpenJDK 11 did you use?
Could you check the value of the java.specification.version system
property please?


As far as I can tell, this should fail with any Java 11...

Package version 11~22-2

openjdk version "11" 2018-09-25

OpenJDK Runtime Environment (build 11+22-Debian-2)

OpenJDK 64-Bit Server VM (build 11+22-Debian-2, mixed mode, sharing)

jshell> System.getProperty("java.specification.version")
$1 ==> "11"

Git commons-lang has a fallback for future version numbers > 10 (along 
with a hard-coded case for 11):


https://github.com/apache/commons-lang/blob/50ce8c44e1601acffa39f5568f0fc140aade0564/src/main/java/org/apache/commons/lang3/JavaVersion.java#L203-L205

Regards,
Erich

Bug#903774: libcommons-compress-java: Build incompatible with Java 8, without need?

[Erich Schubert]

Package: libcommons-compress-java
Version: 1.13-2
Severity: normal

Maven with Java 8 can no longer build jars.

Caused by: java.lang.NoSuchMethodError:
java.nio.ByteBuffer.rewind()Ljava/nio/ByteBuffer;
    at 
org.apache.commons.compress.archivers.zip.ZipFile.tryToLocateSignature

(ZipFile.java:969)
    at
org.apache.commons.compress.archivers.zip.ZipFile.positionAtEndOfCentralDirectoryRecord
(ZipFile.java:946)
    at
org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory
(ZipFile.java:874)
    at
org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory
(ZipFile.java:612)
    at org.apache.commons.compress.archivers.zip.ZipFile.
(ZipFile.java:294)
    at org.apache.commons.compress.archivers.zip.ZipFile.
(ZipFile.java:217)
    at org.apache.commons.compress.archivers.zip.ZipFile.
(ZipFile.java:186)
    at org.codehaus.plexus.archiver.jar.JarArchiver.grabFilesAndDirs
(JarArchiver.java:785)
    at org.codehaus.plexus.archiver.jar.JarArchiver.createIndexList
(JarArchiver.java:455)
    at org.codehaus.plexus.archiver.jar.JarArchiver.finalizeZipOutputStream
(JarArchiver.java:377)

This is caused by the following line:

https://sources.debian.org/src/libcommons-compress-
java/1.13-2/src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java/#L969

ByteBuffer used to inherit rewind() from Buffer.

Apparently in OpenJDK11, a new override for this method was added that 
returns

a ByteBuffer, which makes method chaining easier (in older JDK,
buf.rewind().something() would only work if something is defined on Buffer).
But this new signature cannot be found with earlier JDKs, and causes the
incompatibility seen above.

The root cause is in the JDK11, here:
http://hg.openjdk.java.net/jdk/jdk11/file/a602706ccaaa/src/java.base/share/classes/java/nio/X-Buffer.java.template#l1163
which specializes the rewind() method's return type.

This issue can *possibly* be resolved by casting wordBbuf to Buffer 
where possible (it will likely also apply to flip(), clear(), reset(), 
mark(), limit(), position(), and possibly some other methods), and that 
may or may not be enough to restore compatibility with older JDKs.


But supposedly the better approach is to compile commons-compress 
against Java

8 for now?



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

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libcommons-compress-java depends on:
ii  libcommons-parent-java  43-1

libcommons-compress-java recommends no packages.

Versions of packages libcommons-compress-java suggests:
ii  libxz-java  1.8-2

-- no debconf information

Bug#903769: libcommons-lang3-java: NPE with OpenJDK11 and maven-javadoc

[Erich Schubert]

Package: libcommons-lang3-java
Version: 3.7-1
Severity: important

When building a maven projects javadoc, I see the following NPE:

Execution attach-javadocs of goal org.apache.maven.plugins:maven-javadoc-
plugin:3.0.0:javadoc-no-fork failed.
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject

(LifecycleModuleBuilder.java:117)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject

(LifecycleModuleBuilder.java:81)
    at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:183)
    at org.debian.maven.Wrapper.main (Wrapper.java:89)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native 
Method)

    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard
(Launcher.java:330)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:238)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
attach-
javadocs of goal 
org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:javadoc-

no-fork failed.
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:148)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject

(LifecycleModuleBuilder.java:117)
    at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject

(LifecycleModuleBuilder.java:81)
    at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:183)
    at org.debian.maven.Wrapper.main (Wrapper.java:89)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native 
Method)

    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard
(Launcher.java:330)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:238)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: java.lang.NullPointerException
    at org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast
(SystemUtils.java:1654)
    at
org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getJavadocExecutable
(AbstractJavadocMojo.java:3703)
    at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
(AbstractJavadocMojo.java:2001)
    at org.apache.maven.plugins.javadoc.JavadocReport.generate
(JavadocReport.java:134)
    at org.apache.maven.plugins.javadoc.JavadocReport.doExecute
(JavadocReport.java:329)
    at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
(AbstractJavadocMojo.java:1909)
    

Bug#902855: ITA: enigma -- A game where you control a marble with

[Erich Schubert]

Hi,

I am working in the enigma package update (I am trying to adopt it). I 
see that this package don't have a VCS.

Yes, it doesn't have one yet.

Do you think that is a good idea add enigma to salsa?
If it is true, could anyone create a salsa repo to commit it and give 
me access?


As suggested, it would make most sense to do this in the larger debian 
games team project.


When looking into bug fixes, it may be desirable to get some fixes from 
github, and contribute back compile fixes there: 
https://github.com/Enigma-Game/Enigma


Because of fixes, it may be worth following git; there does not appear 
to be major development happening anymore, all fixes.


Please note that it depends on libzipios++, which is orphaned: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834214


I do not know if enigma can be made working with newer libzipios v2 
(which doesn't appear to be packaged anyway). Upstream includes an old 
copy of zipios 0.x; which is not desirable because of security issues 
(any bug in zipios then needs to be fixed in enigmas copy, too). Because 
of this, we have been using a dfsg tarball, with zipios and the "main 
menu music" removed (see changelog). If I recall correctly, it was not 
clear what the license of the music was; and as a mod file, it may 
contain copyrighted samples...


Regards,
Erich

Bug#900840: Bug#901471: Thunderbird should not be able to render the xserver unusable

[Erich Schubert]

Hi,

Oops, yes. This should have gone to #900840.


I am unsure where to clone the issue.
For obvious reasons, a client application like thunderbird should not be able to
break the xserver in a way that thunderbird does.
While extending the apparmor permissions makes thunderbird work again (and thus
solves this bug), there is an underlying issue with the xserver most likely.
When I try to use thunderbird with apparmor enabled, the xserver stops drawing 
except
for the mouse cursor; and even killing the thunderbird process does not fix the
xserver. That should be prevented on the xserver side.

Very good point, I wholeheartedly agree.

But I suspect you've followed up on the wrong bug: I can see no
indication that #901471 caused this much trouble. Maybe you're talking
about #900840 or one of its numerous clones? I'm not sure where that
problem should be tracked either. Perhaps you could ask
debia...@lists.debian.org?

FWIW I've not been affected by this bug on GNOME Wayland.

Cheers,

Bug#902855: RFA: enigma -- A game where you control a marble with the mouse

[Erich Schubert]

Package: wnpp
Severity: normal

The package should be updated to the latest release (from 2014) & git fixes.

It's by now at github: https://github.com/Enigma-Game/Enigma

Regards,
Erich

Bug#901471: Thunderbird should not be able to render the xserver unusable

[Erich Schubert]

I am unsure where to clone the issue.

For obvious reasons, a client application like thunderbird should not be 
able to break the xserver in a way that thunderbird does.


While extending the apparmor permissions makes thunderbird work again 
(and thus solves this bug), there is an underlying issue with the 
xserver most likely.


When I try to use thunderbird with apparmor enabled, the xserver stops 
drawing except for the mouse cursor; and even killing the thunderbird 
process does not fix the xserver. That should be prevented on the 
xserver side.


Regards,
Erich

Bug#895695: elki FTBFS: java.base/jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to java.base/java.net.URLClassLoader

[Erich Schubert]

Caused by Java 1.9, can probably be cherry-picked:

Fixed upstream, but no new release yet.

https://github.com/elki-project/elki/commit/92c96858616581c2109d36488e96c84c72d8bbc7




Am 14.04.2018 um 21:37 schrieb Adrian Bunk:

Source: elki
Version: 0.7.1-6
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/elki.html

...
[INFO] --- exec-maven-plugin:1.6.0:exec (generate-javadoc-parameters) @ elki ---
Exception in thread "main" java.lang.ExceptionInInitializerError
at 
de.lmu.ifi.dbs.elki.application.internal.DocumentParameters.buildParameterIndex(DocumentParameters.java:251)
at 
de.lmu.ifi.dbs.elki.application.internal.DocumentParameters.main(DocumentParameters.java:149)
Caused by: java.lang.ClassCastException: 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to 
java.base/java.net.URLClassLoader
at 
de.lmu.ifi.dbs.elki.utilities.ELKIServiceRegistry.(ELKIServiceRegistry.java:53)
... 2 more
[ERROR] Command execution failed.

Bug#882073: firefox: Disable Pocket by default: a non-free web service and privacy relevant that should require consent

[Erich Schubert]

Package: firefox
Version: 57.0~b9-1
Severity: normal
Tags: patch

The Debian package of firefox should disable Pocket by default, as this 
encourages the use
of a non-free web service, and sends privacy relevant information 
without prior agreement by the user.


The suggested change is simply to change the default setting in

/usr/lib/firefox/browser/defaults/preferences/firefox.js
pref("extensions.pocket.enabled", true);

to "false". Then users can enable pocket in their profile by setting 
this to true if desired; but by default it will not use this non-free 
service.


To by default disable the "Recommended by Pocket" part of the front 
page, also add this:


pref("browser.newtabpage.activity-stream.feeds.section.topstories", false);

There may be other privacy-relevant settings of firefox to fine tune.

Unfortunately, Mozilla keeps on adding new extensions all the time that 
transmit data.
But Debian should be a bit reluctant to enable such services by default, 
but rather leave the decision to the user of whether (or not!) to enable 
them.


With the current default, firefox will make requests to the Pocket API. 
The default should be to not do so.


-- Package-specific info:


-- Addons package information

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

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox depends on:
ii  debianutils   4.8.3
ii  fontconfig    2.12.3-0.2
ii  libatk1.0-0   2.26.1-1
ii  libc6 2.24-17
ii  libcairo-gobject2 1.15.8-2
ii  libcairo2 1.15.8-2
ii  libdbus-1-3   1.12.0-1
ii  libdbus-glib-1-2  0.108-3
ii  libevent-2.1-6    2.1.8-stable-4
ii  libffi6   3.2.1-6
ii  libfontconfig1    2.12.3-0.2
ii  libfreetype6  2.8.1-0.1
ii  libgcc1   1:7.2.0-14
ii  libgdk-pixbuf2.0-0    2.36.11-1
ii  libglib2.0-0  2.54.2-1
ii  libgtk-3-0    3.22.25-1
ii  libgtk2.0-0   2.24.31-2
ii  libhunspell-1.6-0 1.6.2-1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.16-1
ii  libnss3   2:3.33-1
ii  libpango-1.0-0    1.40.13-1
ii  libsqlite3-0  3.21.0-1
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++6    7.2.0-14
ii  libvpx4   1.6.1-3
ii  libx11-6  2:1.6.4-3
ii  libx11-xcb1   2:1.6.4-3
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite1    1:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes3    1:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt6    1:1.1.5-1
ii  procps    2:3.3.12-3
ii  zlib1g    1:1.2.8.dfsg-5

firefox recommends no packages.

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-3
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-4
ii  libgssapi-krb5-2   1.15.2-2
pn  mozplugger 

-- no debconf information

Bug#875322: Batik: make rhino and jython optional

[Erich Schubert]

Hi,

Please cherry-pick this patch:

http://svn.apache.org/viewvc?view=revision=1805148

Also note that upstream has a 1.9.1 release that apparently fixes the poms.

Regards,
Erich

Bug#875322: libbatik-java incorrect poms

[Erich Schubert]

reopen 875322

thanks

Two issues still persist:

1. A dependency on org.python:jython, that either should be optional, or 
that must be a debian dependency, too.


It appears to work (for ELKI) without Jython - but this dependency does 
exist in mavencentral, so it may be necessary to add a dependency onto 
jython for some parts to work; at the minimum to add a suggests/recommends?


c.f., 
https://mvnrepository.com/artifact/org.apache.xmlgraphics/batik-script/1.9.1


2. A dependency on org.apache.xmlgraphics:batik-svgrasterizer that does 
not exist in the Debian package.


Rasterization appears to work; so I can only assume the contents of 
svg-rasterizer are currently included in the batik-rasterizer package.


Regards,
Erich

Bug#863337: visualvm: Typos in launcher script - does not start anymore

[Erich Schubert]

Hi,
I will try to double-check this, but I'm constantly short on time these
days.
I didn't modify visualvm.conf

But by any means, by looking at the source don't you think it should be -J
rather than -L?

Even if e.g. the bug only appears because Java 9 fails to start with -L,
whereas maybe java 8 maybe silently ignored them?

To me, these appear to be obvious typos; independent of whether you can
reproduce them, or not...

Regards,
Erich

On Sun, May 28, 2017 at 10:58 AM, Chris Lamb  wrote:

> Hey Erich,
>
> > visualvm: Typos in launcher script - does not start anymore
>
> I can't seem to reproduce this on a fresh stretch or sid chroot. Can you
> paste your /etc/visualvm/visualvm.conf? Is this an upgrade? My chroots
> seem to be using OpenJDK if that helps.
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>

Bug#867084: elki: build-depends libmaven-antrun-plugin-java (< 1.8) but 1.8-1 is to be installed

[Erich Schubert]

The next version of ELKI will use Gradle for building, so the maven build
dependencies will disappear.

The current version should compile with 1.8 as well, but the maven plugin
version numbers in the pom.xml will need to be updated for offline
building, or the plugin will not be found offline.

Regards,
Erich

On Mon, Jul 3, 2017 at 9:43 PM, Adrian Bunk  wrote:

> Source: elki
> Version: 0.7.1-3
> Severity: serious
> Tags: buster sid
>
> # apt-get build-dep elki
> Reading package lists... Done
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  builddeps:elki : Depends: libmaven-antrun-plugin-java (< 1.8) but 1.8-1
> is to be installed
> E: Unable to correct problems, you have held broken packages.
> #
>

Bug#863337: visualvm: Typos in launcher script - does not start anymore

[Erich Schubert]

Package: visualvm
Version: 1.3.9-1
Severity: grave
Justification: renders package unusable

visualvm does not start anymore with the error:
Unknown option -L-XX:PermSize=32m

This is caused by a trivial typo in the start script, which supposedly
should use -J (like "Java options") instead of -L (two locations):

visualvm_default_options="-L-XX:PermSize=32m ${visualvm_default_options}"

should likely be

visualvm_default_options="-J-XX:PermSize=32m ${visualvm_default_options}"

In particular, note that the if statement reads 'if grep -v -- 
"-J-XX:MaxPermSize"'



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

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

Versions of packages visualvm depends on:
ii  default-jdk [java7-sdk]2:1.8-58
ii  libnb-platform18-java  8.2+dfsg1-1
ii  libvisualvm-jni1.3.9-1
ii  openjdk-8-jdk [java7-sdk]  8u131-b11-2
ii  openjdk-9-jdk [java7-sdk]  9~b170-2

visualvm recommends no packages.

visualvm suggests no packages.

-- no debconf information

Bug#843038: elki: FTBFS randomly (failing tests)

[Erich Schubert]

You can also do this as sponsored upload.

On Sun, Mar 12, 2017 at 12:24 AM, Santiago Vila <sanv...@unex.es> wrote:

> On Sat, Mar 11, 2017 at 11:38:44PM +0100, Erich Schubert wrote:
> > Hello,
> > Could you do a NMU with this version, and ask for a freeze exception,
> > please?
>
> I will gladly make a sponsored upload with the last patch "as is".
>
> (NMU would be 0.7.1-2.1 and would have my name on it, but this is not
> necessary at all since you are alive).
>
> THanks.
>

Bug#843038: elki: FTBFS randomly (failing tests)

[Erich Schubert]

Hello,
Could you do a NMU with this version, and ask for a freeze exception,
please?
There are no dependencies onto elki, so this cannot cause other packages to
become broken or uninstallable.
Thank you!
Erich

On Fri, Mar 10, 2017 at 12:07 AM, Santiago Vila <sanv...@unex.es> wrote:

> On Thu, Mar 09, 2017 at 07:09:22PM +0100, Erich Schubert wrote:
> > Looks good, thank you.
> > Maybe "Temporarily disable test suite.", as I do want to have it back
> > eventually; the latest when I prepare a new upstream.
>
> Ok, updated patch attached.
>
> Notes:
>
> If you don't have a sid chroot at hand, you can upload this with
> absolutely minimal fuss with "dpkg-buildpackage -S -d". That would
> create a source-only upload and it would also ignore build-dependencies
> (we can do that in this case because we just disable the test suite).
>
> If you lost your GPG key please ask for a sponsor in debian-mentors
> (eventually, if nobody shows, I could sponsor this upload).
>
> After this we would ask Release Managers for a freeze exception so
> that the package propagates to testing, I can do that if it helps.
>
> Thanks.
>

Bug#843038: elki: FTBFS randomly (failing tests)

[Erich Schubert]

Hi,
The CASHTest failure is interesting. Can you share the log? The others are
all time dependent.
CASH could depend on random, but the tests would all try to fix random
seeding.

On Wed, Mar 8, 2017 at 6:57 PM, Santiago Vila <sanv...@unex.es> wrote:

> On Wed, Mar 08, 2017 at 06:13:34PM +0100, Erich Schubert wrote:
>
> > Or you just add* e.g. the -*Dmaven.test.skip=true parameter, and it will
> > build fine.
>
> That would be the easy thing, indeed, but not necessarily the right
> thing to do.
>
> This is really a decision to be made by the maintainer: Either the
> tests fail because they are wrongly designed (in which case they
> should be disabled to fix the FTBFS bug) or the tests are ok and the
> fact that they fail means the package is not suitable to be released.
>
> Only in the first case we want to disable the tests. In the second
> case what we want is to keep the package out of testing.
>
> For the record, this is the number of times I've seen each test to
> fail in my environment:
>
>  201 de.lmu.ifi.dbs.elki.utilities.datastructures.arrays.
> IntegerArrayQuickSortTest
>   48 de.lmu.ifi.dbs.elki.database.SortingDuplicatesTest
>   25 de.lmu.ifi.dbs.elki.utilities.datastructures.arrays.
> DoubleIntegerArrayQuickSortTest
>1 de.lmu.ifi.dbs.elki.utilities.datastructures.heap.
> IntegerMinHeapPerformanceTest
>1 de.lmu.ifi.dbs.elki.algorithm.clustering.correlation.CASHTest
>
> I guess disabling the first three would make the failure rate to
> improve dramatically, but as I said before I don't really know if they
> fail because the program is wrong or because the tests are wrong.
>
> As much as I would like to investigate and help everybody to fix their
> FTBFS-randomly bugs, there are too much of them and I can't fix all
> the bugs I report myself. This is your package, not mine. In either
> case, if you still need help to reproduce the bug, please say so,
> but this one does not seem particularly difficult to reproduce.
>
> Thanks.
>

Bug#843038: elki: FTBFS randomly (failing tests)

[Erich Schubert]

Looks good, thank you.
Maybe "Temporarily disable test suite.", as I do want to have it back
eventually; the latest when I prepare a new upstream.

On Thu, Mar 9, 2017 at 5:13 PM, Santiago Vila  wrote:

> Ok, full patch for your consideration.
>
> Thanks.

Bug#843038: elki: FTBFS randomly (failing tests)

[Erich Schubert]

tag 843038 +patch
thanks

Hello,
Either of these two patches will fix this for now and is fine with me.

A nicer patch would be to replace all lines matching
@Test(timeout
with
//@Test(timeout
to disable only those tests that rely on a timeout (i.e. that will fail on
a too slow CPU).

These tests are very unlikely to detect build errors; but they are
regression tests to detect if someone replaces the sorting code with a
version that degrades to O(n^2) runtime on certain corner cases (e.g. all
identical).
Maybe they could eventually be replaced with a test that uses introspection
and counters rather than a timeout, but that requires much more work.

So for now, I would simply disable either all tests, or the problematic
timeout-based tests.

Regards,
Erich


On Wed, Mar 8, 2017 at 7:53 PM, Santiago Vila <sanv...@unex.es> wrote:

> On Wed, Mar 08, 2017 at 06:13:34PM +0100, Erich Schubert wrote:
>
> > Or you just add* e.g. the -*Dmaven.test.skip=true parameter, and it will
> > build fine.
>
> You probably mean the first attached patch.
>
> I've tested that and it still run tests (not sure if all of them or
> only some of them).
>
> The second attached patch seems to disable all the tests.
>
> If this is how you would really fix this FTBFS bug, please say so
> or better tag this bug as "patch".
>
> Thanks.
>

Bug#843038: elki: FTBFS randomly (failing tests)

[Erich Schubert]

Congratualtions!

Go ahead and annoy people.

That is exactly the way to build community!

---

Or you just add* e.g. the -*Dmaven.test.skip=true parameter, and it will
build fine.

But apparently you do not care about importance of bugs at all, only about
processes and your personal opinion.

Heck, it would have been much faster to fix the bug, than to bother me
again and again when I don't have time to waste, like you apparently have.


***
Stop wasting time. Fix bugs instead!
***

Thank you.


Regards,
Erich

On Wed, Mar 8, 2017 at 1:20 AM, Santiago Vila  wrote:

> severity 843038 serious
> thanks
>
> Dear maintainer:
>
> I expected a general guideline from Release Managers regarding
> packages which FTBFS randomly like this one, but that will most surely
> not happen for stretch.
>
> So, the only guideline I have left is the one expressed by Julien
> Cristau (one of the RMs) in Bug #844264:
>
> "if the failure rate is low enough I think a lower severity can make
> sense"
>
> I posted a list of bugs which FTBFS more than 10% of the time and
> several people agreed on -devel that they should be serious and
> maintainers should ask for stretch-ignore tag in case the bug should
> not be RC (most bugs are about failing tests so this should not be
> needed in general).
>
> In the latest tests I made, this package fails for me more than 55% of
> the time, and it also fails (always, apparently) in the reproducible
> builds autobuilders, in all architectures:
>
> https://tests.reproducible-builds.org/debian/rb-pkg/
> unstable/amd64/elki.html
>
> This may affect any user trying to build this package (for example,
> after making a change), our downstreams, and the Security Team once
> that stretch is stable.
>
> For this reason I'm raising this to serious again.
>
> Sorry for the long explanation.
>
> Thanks.
>

Bug#787955: openjdk-8-jre: crashes in GUI program when focussing widgets with

[Erich Schubert]

Hi,
I also just noticed another issue with the accessibility functionality.
ELKI (which uses Apache Batik), will not properly terminate when this
is enabled.
If the AtkWrapper is disabled, it quits just fine.

The only thread that involves non-OpenJDK code in the stack is this:
"Batik CleanerThread" #21 daemon prio=5 os_prio=0
tid=0x7f2a44131800 nid=0x3dd1 in Object.wait()
[0x7f2a651b5000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x870fd3e0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
- locked <0x870fd3e0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
at org.apache.batik.util.CleanerThread.run(Unknown Source)

If I disable AtkWrapper, everything is fine.
I haven't verified with Batik example if this also happens there.

Best regards,
Erich

On Mon, Jul 18, 2016 at 1:47 PM, Sebastian Humenda <shume...@gmx.de> wrote:
> found 787955 8u91-b14-3
> stop
>
> Erich Schubert schrieb am 17.07.2016, 11:30 +0200:
>>This seems to be fixed for me. I could not reproduce anymore.
> I'm still experiencing the same issue. I've uploaded a core dump on [^1]. It 
> is
> actually enough to start the application, in this case MediathekView, alt+tab
> out of the window and into it again. After a short while the application
> crashes. The crash did not produce a log file though. If there's anything I 
> can
> do to help, please let me know.
>
> Thanks
> Sebastian
> [^1]: http://wwwpub.zih.tu-dresden.de/~s7369555/mdv-core-8u91-b14-3.xz

Bug#787955: openjdk-8-jre: crashes in GUI program when focussing widgets with

[Erich Schubert]

Hi,
I do not have a screenreader.

Without disabling AtkWrapper, some programs do not shut down correctly.

On Sun, Nov 13, 2016 at 11:32 AM, Samuel Thibault 
wrote:

> Hello,
>
> Sebastian Humenda, on Sun 13 Nov 2016 09:07:55 +0100, wrote:
> > It's however not fixed yet for me, although 838778 is marked as closed
> and
> > 0.33.3-9 of libatk-wrapper is installed on my system.
> > Should I reopen 838778 and provide a full traceback there?
>
> Yes, please.
>
> Samuel
>

Bug#843038: elki: FTBFS (failing tests)

[Erich Schubert]

Hi,
The conditions that cause the failure are well known and easy to avoid:
overloaded VMs.
I can make almost any package autobuild with >50% failure by simply by
giving it way too little memory, I guess.
So can we build any package "without failure" then? What if I add in faulty
memory?

In my experience, Amazon t2.medium instances showed rare test failures with
Travis CI. So that is about the minimum CPU power you need to pass these
tests.
So to make any such policy well-defined, it would need to clearly specify
minimum requirements for CPU power and memory you can rely on.

But the key point is this: the test failure does not indicate the software
failed to build.
It's just a bad test, nothing serious. The tests will be disabled in the
next upload. Anything else is a waste of time better spent otherwise.

Regards,
Erich

On Thu, Nov 3, 2016 at 5:26 PM, Santiago Vila <sanv...@unex.es> wrote:

> On Thu, Nov 03, 2016 at 04:42:07PM +0100, Erich Schubert wrote:
> > retitle 843038 some build tests fail on slow CPUs, should be disabled
> > thanks
> >
> > Feel free to NMU with tests disabled, if you consider this to be a major
> > improvement...
> > You can modify the "excludeTests" property to also exclude all "*Sort*"
> > tests, that is a one-line change.
>
> Thanks a lot for the offer, but I don't like NMUs.
>
> I would be willing to make a sponsored upload if it helps,
> but definitely not if you downgrade this from "serious".
>
> > The policy does not say it must autobuild _every_ time IMHO.
>
> Ok, it does not contain the words "every time", but that's
> the usual interpretation.
>
> The exact wording is "packages must autobuild without failure [...]".
>
> If it fails more than 50% of the time, how could we call that "without
> failure"? That would be a very unorthodox interpretation indeed.
>
> Thanks.
>

Bug#843038: elki: FTBFS (failing tests)

[Erich Schubert]

retitle 843038 some build tests fail on slow CPUs, should be disabled
thanks

Feel free to NMU with tests disabled, if you consider this to be a major
improvement...
You can modify the "excludeTests" property to also exclude all "*Sort*"
tests, that is a one-line change.

The policy does not say it must autobuild _every_ time IMHO.

The package is autobuildable, and "buildable within the same release"; just
not every time on an overloaded virtual machine.

E.g.
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/elki_0.7.1-2.rbuild.log

I agree these tests should be eventually removed (and will disable these
tests in the next upload), as in particular ARM autobuilders will not be
fast enough to pass this test.
In particular, it supposedly is buildable with DEB_BUILD_OPTIONS="nocheck"
even on low-CPU machines (plus it is arch-independent).

So I do not consider this release critical, and I don't have the time to do
an upload right now just because of that.

Regards,
Erich

On Thu, Nov 3, 2016 at 3:48 PM, Santiago Vila  wrote:

> Note: The failing tests are not always the same.
>
> Here is a summary of all the "Tests in error" messages after the 50 builds.
>
> 
> ---
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:130 TestTimedOut test timed out
> after 500...
>
> Tests in error:
>   SortingDuplicatesTest.testDuplicateKeys:45 ?? TestTimedOut test timed
> out afte...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>   DoubleIntegerArrayQuickSortTest.testSorted:130 ?? TestTimedOut test
> timed out ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   SortingDuplicatesTest.testDuplicateKeys:50 ?? TestTimedOut test timed
> out afte...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   SortingDuplicatesTest.testDuplicateKeys:50 ?? TestTimedOut test timed
> out afte...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   SortingDuplicatesTest.testDuplicateKeys:50 ?? TestTimedOut test timed
> out afte...
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   SortingDuplicatesTest.testDuplicateKeys:47 TestTimedOut test timed out
> after 1...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   SortingDuplicatesTest.testDuplicateKeys:46 TestTimedOut test timed out
> after 1...
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   SortingDuplicatesTest.testDuplicateKeys:50 ?? TestTimedOut test timed
> out afte...
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   SortingDuplicatesTest.testDuplicateKeys:50 ?? TestTimedOut test timed
> out afte...
>   IntegerArrayQuickSortTest.testSorted:130 TestTimedOut test timed out
> after 500...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:122 ?? TestTimedOut test timed out
> after ...
>
> 

Bug#843038: elki: FTBFS (failing tests)

[Erich Schubert]

severity 843038 wishlist
thanks

Hi,
The test that failed is CPU sensitive.
Yes, it should probably be disabled, but does not any "serious" bug if it
fails on a heavily loaded machine.
In particular, the solution obviously is to just not run the test at all.
That is not really an improvement either...


On Thu, Nov 3, 2016 at 12:16 PM, Santiago Vila  wrote:

> Package: src:elki
> Version: 0.7.1-2
> Severity: serious
>
> Dear maintainer:
>
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
>
> 
> 
> [...]
>  debian/rules build-indep
> dh build-indep --buildsystem=maven
>dh_testdir -i -O--buildsystem=maven
>dh_update_autotools_config -i -O--buildsystem=maven
>debian/rules override_dh_auto_configure
> make[1]: Entering directory '/<>'
> # Remove unneded executable bits:
> find elki addons data -type f -executable -exec chmod -x {} \+
> dh_auto_configure -O--buildsystem=maven
> find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compiler/*/*.jar':
> No such file or directory
> find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compilers/*/*.jar':
> No such file or directory
> find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-containers/*/*.jar':
> No such file or directory
> mh_patchpoms -pelki --debian-build --keep-pom-version
> --maven-repo=/<>/debian/maven-repo
>
> [... snipped ...]
>
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> - in de.lmu.ifi.dbs.elki.evaluation.scores.ROCEvaluationTest
> Running de.lmu.ifi.dbs.elki.evaluation.scores.
> AveragePrecisionEvaluationTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> - in de.lmu.ifi.dbs.elki.evaluation.scores.AveragePrecisionEvaluationTest
> Running de.lmu.ifi.dbs.elki.evaluation.scores.MaximumF1EvaluationTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> - in de.lmu.ifi.dbs.elki.evaluation.scores.MaximumF1EvaluationTest
> Running de.lmu.ifi.dbs.elki.evaluation.paircounting.
> ClusterContingencyTableTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec
> - in de.lmu.ifi.dbs.elki.evaluation.paircounting.
> ClusterContingencyTableTest
>
> Results :
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:130 TestTimedOut test timed out
> after 500...
>
> Tests run: 348, Failures: 0, Errors: 1, Skipped: 1
>
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] ELKI Data Mining Framework - Parent Project  SUCCESS [
> 0.389 s]
> [INFO] ELKI Data Mining Framework . FAILURE [02:01
> min]
> [INFO] ELKI Data Mining Framework - Batik Visualization ... SKIPPED
> [INFO] ELKI Data Mining Framework - Tutorial Algorithms ... SKIPPED
> [INFO] ELKI Data Mining Framework - LibSVM based extensions SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 02:02 min
> [INFO] Finished at: 2016-11-02T00:48:31+01:00
> [INFO] Final Memory: 14M/36M
> [INFO] 
> 
> [ERROR] Failed to execute goal org.apache.maven.plugins:
> maven-surefire-plugin:2.17:test (default-test) on project elki: There are
> test failures.
> [ERROR]
> [ERROR] Please refer to /<>/elki/target/surefire-reports for
> the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/
> MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR]   mvn  -rf :elki
> dh_auto_test: /usr/lib/jvm/java-8-openjdk-amd64/bin/java -noverify -cp
> /usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/
> jvm/java-8-openjdk-amd64/lib/tools.jar -Dmaven.home=/usr/share/maven
> -Dmaven.multiModuleProjectDirectory=/<>
> -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/<<
> PKGBUILDDIR>>/debian/maven.properties 
> org.codehaus.plexus.classworlds.launcher.Launcher
> -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian
> -Dmaven.repo.local=/<>/debian/maven-repo test returned exit
> code 1
> debian/rules:10: recipe for target 'build-indep' failed
> make: *** [build-indep] Error 1
> dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
> 

Bug#811826: enigma: FTBFS with GCC 6: no match for

[Erich Schubert]

Thank you.
I did not get around to update engima yet, unfortunately. I was hoping
to do this this weekend, but I don't have a lot of time anymore.
There is also a newer upstream, 1.21, that should eventually be used.

Feel free to move the upload to non-delayed.

Best regards,
Erich

On Mon, Sep 26, 2016 at 12:30 AM, Markus Koschany  wrote:
> Control: tags -1 pending
>
> On Tue, 19 Jan 2016 18:21:45 -0800 Martin Michlmayr  wrote:
>> Package: enigma
>> Version: 1.20-dfsg.1-2
>> Severity: important
>> User: debian-...@lists.debian.org
>> Usertags: ftbfs-gcc-6 gcc-6-no-match
>>
>> This package fails to build with GCC 6.  GCC 6 has not been released
>> yet, but it's expected that GCC 6 will become the default compiler for
>> stretch.
>
> [...]
>
> Dear maintainer,
>
> I've prepared an NMU for enigma (versioned as 1.20-dfsg.1-2.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
>
> Please find attached the debdiff.
>
> Regards,
>
> Markus

Bug#834739: elki: FTBFS too much often (failing tests)

[Erich Schubert]

Thank you.
The full logs give a more precise location of the problem,
 de.lmu.ifi.dbs.elki.parallel.ParallelExecutor.run(ParallelExecutor.java:70)
which makes this clearly a bug happening exactly when there is only a
single core available.

It was already fixed in master (somehow I forgot that I had already
discovered this):
https://github.com/elki-project/elki/commit/48e82af606d4c6c133a50405a23a645391f55d80

so I can cherry-pick this change. Thank you.

Regards,
Erich

Bug#834739: elki: FTBFS too much often (failing tests)

[Erich Schubert]

close 834739
thanks

Hi,
According to 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/elki.html
the auto-builders succeed at building the package; there is only a
problem with openjdk-8/openjdk-9 differences in the JavaDoc.

I also tried "dpkg-buildpackage -A" and it worked.

Note that all tests that failed involved parallelism. I can imagine
this happening if "Runtime.getRuntime().availableProcessors()" returns
0, but the Java documentation says "never smaller than one". Could
there be any reason Java reported a wrong value on your test system?

I cannot reproduce your problems, sorry.

On Thu, Aug 18, 2016 at 4:22 PM, Santiago Vila  wrote:
> Package: src:elki
> Version: 0.7.1-1
> Severity: serious
>
> Dear maintainer:
>
> I tried to build this package with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
>
> 
> [...]
>  debian/rules build-indep
> dh build-indep --buildsystem=maven
>dh_testdir -i -O--buildsystem=maven
>dh_update_autotools_config -i -O--buildsystem=maven
>debian/rules override_dh_auto_configure
> make[1]: Entering directory '/<>'
> # Remove unneded executable bits:
> find elki addons data -type f -executable -exec chmod -x {} \+
> dh_auto_configure -O--buildsystem=maven
> find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compiler/*/*.jar': No 
> such file or directory
> find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compilers/*/*.jar': 
> No such file or directory
> find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-containers/*/*.jar': 
> No such file or directory
> mh_patchpoms -pelki --debian-build --keep-pom-version 
> --maven-repo=/<>/debian/maven-repo
>
> [... snipped ...]
>
> Running de.lmu.ifi.dbs.elki.evaluation.scores.MaximumF1EvaluationTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec - 
> in de.lmu.ifi.dbs.elki.evaluation.scores.MaximumF1EvaluationTest
> Running 
> de.lmu.ifi.dbs.elki.evaluation.paircounting.ClusterContingencyTableTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec - 
> in de.lmu.ifi.dbs.elki.evaluation.paircounting.ClusterContingencyTableTest
>
> Results :
>
> Tests in error:
>   ParallelLloydKMeansTest.testParallelKMeansLloyd:68 ?? Arithmetic / by zero
>   ParallelKNNOutlierTest.testKNNOutlier:57 ?? Arithmetic / by zero
>   ParallelKNNWeightOutlierTest.testKNNWeightOutlier:57 ?? Arithmetic / by zero
>   ParallelSimplifiedLOFTest.testParallelSimplifiedLOF:57 ?? Arithmetic / by 
> zero
>   ParallelLOFTest.testParallelLOF:57 ?? Arithmetic / by zero
>
> Tests run: 348, Failures: 0, Errors: 5, Skipped: 1
>
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] ELKI Data Mining Framework - Parent Project  SUCCESS [  0.274 
> s]
> [INFO] ELKI Data Mining Framework . FAILURE [01:39 
> min]
> [INFO] ELKI Data Mining Framework - Batik Visualization ... SKIPPED
> [INFO] ELKI Data Mining Framework - Tutorial Algorithms ... SKIPPED
> [INFO] ELKI Data Mining Framework - LibSVM based extensions SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 01:39 min
> [INFO] Finished at: 2016-08-16T17:39:50+02:00
> [INFO] Final Memory: 14M/35M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on 
> project elki: There are test failures.
> [ERROR]
> [ERROR] Please refer to /<>/elki/target/surefire-reports for the 
> individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :elki
> dh_auto_test: /usr/lib/jvm/java-8-openjdk-amd64/bin/java -noverify -cp 
> /usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar
>  -Dmaven.home=/usr/share/maven 
> -Dmaven.multiModuleProjectDirectory=/<> 
> -Dclassworlds.conf=/etc/maven/m2-debian.conf 
> -Dproperties.file.manual=/<>/debian/maven.properties 
> org.codehaus.plexus.classworlds.launcher.Launcher 
> -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian 
> -Dmaven.repo.local=/<>/debian/maven-repo test returned exit code 
> 1
> 

Bug#835059: Missing dependency on libglib2.0-bin - fails to start

[Erich Schubert]

Package: gnome-maps
Version: 3.20.2-1
Severity: normal

The menu entry relies on the "gapplication" command, which is in
libglib2.0-bin. But there is no dependency on this package, and you
cannot rely on e.g. gdm3 being installed.

Bug#787955: openjdk-8-jre: crashes in GUI program when focussing widgets with

[Erich Schubert]

This seems to be fixed for me. I could not reproduce anymore.

Regards,
Erich

On Sun, Jul 3, 2016 at 8:00 PM, Samuel Thibault  wrote:
> Hello,
>
> Sebastian Humenda, on Sat 06 Jun 2015 21:33:17 +0100, wrote:
>> Package: openjdk-8-jre
>> Version: 8u45-b14-3
>>
>> This crash occurred while executing mediathekview, although it seems to be a
>> jvm-related issue, hence reporting it here.
>>
>> After opening the application and using tab roughly 3-4 times to focus 
>> different UI widgets the application crashed. This happens reliably.
>
> Could you retry with the latest openjdk-8 package (8u91-b14-3)
> and latest libatk-wrapper-java (0.33.3-7)?  There have been
> various fixes there.  Without disabling accessibility from
> /etc/java-8-openjdk/accessibility.properties of course.
>
> Samuel

Bug#820694: python3-csvkit: Missing dependency onto python3-pkg-resources

[Erich Schubert]

Package: python3-csvkit
Version: 0.9.1-2
Severity: normal

> csvjoin
Traceback (most recent call last):
  File "/usr/bin/csvjoin", line 5, in 
from pkg_resources import load_entry_point
ImportError: No module named 'pkg_resources'

Installing python3-pkg-resources fixes this problem.

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

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

Versions of packages python3-csvkit depends on:
ii  python3 3.5.1-3
ii  python3-dateutil2.4.2-1
ii  python3-openpyxl2.3.0-1
ii  python3-six 1.10.0-3
ii  python3-sqlalchemy  1.0.12+ds1-1
ii  python3-xlrd0.9.4-1
pn  python3:any 

python3-csvkit recommends no packages.

Versions of packages python3-csvkit suggests:
pn  python3-dbf  

-- no debconf information

Bug#801925: [PATCH] SCSI: fix crashes in sd and sr runtime PM

[Erich Schubert]

Hello Alan,
Thank you:

The patch appears to work for me, too.

Applied on top of Debian kernel "4.4-1~exp1" I finally have a kernel boot again!
(And maybe this will also make the Intel ( i7-2677M IGP) video bugs
disappear...)

Best regards,
Erich

On Wed, Jan 20, 2016 at 5:26 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> Runtime suspend during driver probe and removal can cause problems.
> The driver's runtime_suspend or runtime_resume callbacks may invoked
> before the driver has finished binding to the device or after the
> driver has unbound from the device.
>
> This problem shows up with the sd and sr drivers, and can cause disk
> or CD/DVD drives to become unusable as a result.  The fix is simple.
> The drivers store a pointer to the scsi_disk or scsi_cd structure as
> their private device data when probing is finished, so we simply have
> to be sure to clear the private data during removal and test it during
> runtime suspend/resume.
>
> This fixes <https://bugs.debian.org/801925>.
>
> Signed-off-by: Alan Stern <st...@rowland.harvard.edu>
> Reported-by: Paul Menzel <paul.men...@giantmonkey.de>
> Reported-by: Erich Schubert <er...@debian.org>
> Reported-by: Alexandre Rossi <alexandre.ro...@gmail.com>
> Tested-by: Paul Menzel <paul.men...@giantmonkey.de>
> CC: "James E.J. Bottomley" <jbottom...@odin.com>
> CC: Ben Hutchings <b...@decadent.org.uk>
> CC: <sta...@vger.kernel.org>
>
> ---
>
>
> [as1795]
>
>
>  drivers/scsi/sd.c |7 +--
>  drivers/scsi/sr.c |4 
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> Index: usb-4.4/drivers/scsi/sd.c
> ===
> --- usb-4.4.orig/drivers/scsi/sd.c
> +++ usb-4.4/drivers/scsi/sd.c
> @@ -3275,8 +3275,8 @@ static int sd_suspend_common(struct devi
> struct scsi_disk *sdkp = dev_get_drvdata(dev);
> int ret = 0;
>
> -   if (!sdkp)
> -   return 0;   /* this can happen */
> +   if (!sdkp)  /* E.g.: runtime suspend following sd_remove() */
> +   return 0;
>
> if (sdkp->WCE && sdkp->media_present) {
> sd_printk(KERN_NOTICE, sdkp, "Synchronizing SCSI cache\n");
> @@ -3315,6 +3315,9 @@ static int sd_resume(struct device *dev)
>  {
> struct scsi_disk *sdkp = dev_get_drvdata(dev);
>
> +   if (!sdkp)  /* E.g.: runtime resume at the start of sd_probe() */
> +   return 0;
> +
> if (!sdkp->device->manage_start_stop)
> return 0;
>
> Index: usb-4.4/drivers/scsi/sr.c
> ===
> --- usb-4.4.orig/drivers/scsi/sr.c
> +++ usb-4.4/drivers/scsi/sr.c
> @@ -144,6 +144,9 @@ static int sr_runtime_suspend(struct dev
>  {
> struct scsi_cd *cd = dev_get_drvdata(dev);
>
> +   if (!cd)/* E.g.: runtime suspend following sr_remove() */
> +   return 0;
> +
> if (cd->media_present)
> return -EBUSY;
> else
> @@ -985,6 +988,7 @@ static int sr_remove(struct device *dev)
> scsi_autopm_get_device(cd->device);
>
> del_gendisk(cd->disk);
> +   dev_set_drvdata(dev, NULL);
>
> mutex_lock(_ref_mutex);
> kref_put(>kref, sr_kref_release);
>

Bug#801925: NULL pointer dereference: IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]

[Erich Schubert]

Hi all,
4.4-rc8 does not fix the problem for me.
Anything beyond 4.1.0 remains unable to boot this computer.

Unfortunately, because the error occurs during early early SCSI
initialization, I do not have easy access to the log - no disk, no
network.
It happens during SATA initialization: "scsi_runtime_resume".
So my back trace looks different than Alex in
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=42;filename=scsi-null-pointer-dereference.log;bug=801925;att=1
but like the one Paul is seeing:
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=20151020_006.jpg;bug=801925;att=3
I will try to do a photo next time, too.

Here is some dmesg output from a successful boot on 4.1.0:
Note there are some ACPI Errors there (but probably not related).
---
ahci :00:1f.2: version 3.0
ahci :00:1f.2: SSS flag set, parallel bus scan disabled
ahci :00:1f.2: AHCI 0001.0300 32 slots 6 ports 3 Gbps 0x1 impl SATA mode
ahci :00:1f.2: flags: 64bit ncq sntf stag pm led clo pio slum part ems apst
scsi host0: ahci
scsi host1: ahci
scsi host2: ahci
scsi host3: ahci
scsi host4: ahci
scsi host5: ahci
ata1: SATA max UDMA/133 abar m2048@0xc0728000 port 0xc0728100 irq 30
ata2: DUMMY
ata3: DUMMY
ata4: DUMMY
ata5: DUMMY
ata6: DUMMY
usb 3-1: new high-speed USB device number 2 using ehci-pci
usb 4-1: new high-speed USB device number 2 using ehci-pci
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ACPI Error: [GTF0] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.PRT0._SDD]
(Node 8802458b1608), AE_NOT_FOUND (20150410/psparse-536)
ACPI Error: [GTF0] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.PRT0._GTF]
(Node 8802458b15e0), AE_NOT_FOUND (20150410/psparse-536)
ata1.00: ATA-8: TOSHIBA THNSNS256GMCP, TA2ABBF0, max UDMA/133
ata1.00: 500118192 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
ACPI Error: [GTF0] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.PRT0._SDD]
(Node 8802458b1608), AE_NOT_FOUND (20150410/psparse-536)
ACPI Error: [GTF0] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.PRT0._GTF]
(Node 8802458b15e0), AE_NOT_FOUND (20150410/psparse-536)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA  TOSHIBA THNSNS25 BBF0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 500118192 512-byte logical blocks: (256 GB/238 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
sd 0:0:0:0: [sda] Attached SCSI disk
PM: Starting manual resume from disk
PM: Hibernation image partition 8:6 present
PM: Looking for hibernation image.
PM: Image not found (code -22)
PM: Hibernation image not present or could not be loaded.
---

On Sat, Jan 9, 2016 at 5:36 PM, Alan Stern  wrote:
> On Sat, 9 Jan 2016, Paul Menzel wrote:
>
>> Version: 4.4~rc8-1~exp1
>>
>> Dear Alan,
>>
>>
>> Thank you for your help!
>>
>> There were some follow-ups to the bug report [1], but I think you and I
>> were not in CC.
>
> I wasn't.
>
>> > http://marc.info/?l=linux-scsi=144185206825609=2
>> > http://marc.info/?l=linux-scsi=144185208525611=2
>
>> I can only say, that I am still unable to boot my system with Linux
>> 4.4-rc8 [2]. Are these patches included there?
>
> They are.  I don't see how they could cause a NULL pointer dereference
> in sd_resume(), though.  If you revert them, does the problem go away?
>
> Also, can you add some debugging statements to sd_resume() so we can
> see where the NULL pointer comes from?
>
> Alan Stern
>

Bug#809737: libsvm3-java: Please include pom metadata in /usr/share/maven-repo

[Erich Schubert]

Package: libsvm3-java
Version: 3.12-1.1
Severity: minor

It would make building packages using libsvm3-java easier,
if a pom file were installed in /usr/share/maven-repo
(maven-helper / maven-repo support)

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

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

libsvm3-java depends on no packages.

libsvm3-java recommends no packages.

Versions of packages libsvm3-java suggests:
pn  java-virtual-machine  

-- no debconf information

Bug#809736: maven-debian-helper: Does not recognize interval dependencies like junit [4.8, )

[Erich Schubert]

Package: maven-debian-helper
Version: 2.0.1
Severity: normal

Maven 3 allows specifying minimum and maximum version dependencies.
For example, it is possible to specify a junit dependency "[4.8,)" as
"4.8 and later".

maven-debian-helper does not appear to understand this syntax:
---
Resolving junit:junit:jar:[4.8,) of scope test...
[check dependency with bundle type]
> dpkg --search /usr/share/maven-repo/junit/junit/*/*
Found /usr/share/maven-repo/junit/junit/4.x/junit-4.x.pom in junit4
Found /usr/share/maven-repo/junit/junit/3.8.2/junit-3.8.2.pom in junit
Found /usr/share/maven-repo/junit/junit/3.x/junit-3.x.pom in junit
Found /usr/share/maven-repo/junit/junit/4.12/junit-4.12.pom in junit4
> dpkg --status junit4
[error] Package junit4 (4.12) is already installed and contains a
possible match,
but I cannot resolve library junit:junit:jar:[4.8,) in it.
[error] Please check manually that the library is up to date,
otherwise it may be necessary to package version [4.8,) in Debian.
Try again to resolve the dependency?
[Y/n] >
---
Clearly, 4.12 can satisfy the [4.8,) requirement.

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

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

Versions of packages maven-debian-helper depends on:
ii  default-jdk 2:1.8-53
ii  libmaven-clean-plugin-java  2.5-1
ii  libmaven-compiler-plugin-java   3.2-5
ii  libmaven-jar-plugin-java2.4-1
ii  libmaven-resources-plugin-java  2.6-1
ii  libmaven-site-plugin-java   2.1-3
ii  libplexus-velocity-java 1.1.8-1
ii  libsurefire-java2.17-2
ii  libxml2-utils   2.9.3+dfsg1-1
ii  maven   3.3.9-3
ii  maven-repo-helper   1.8.12
ii  unzip   6.0-20
ii  velocity1.7-4

maven-debian-helper recommends no packages.

Versions of packages maven-debian-helper suggests:
ii  apt-file  2.5.4
ii  devscripts2.15.10
ii  libmaven-javadoc-plugin-java  2.10.3-2
ii  subversion1.9.3-1+b1

-- no debconf information

Bug#809736: maven-debian-helper: Does not recognize interval dependencies like junit [4.8, )

[Erich Schubert]

Hello,
The substitutions work fine, but it would be nicer if it would
recognize that "[4.8,)" can be satisfied without substitution.

Right now, I have e.g.:
 
 net.sf.trove4j
 trove4j
-[3.0.3,)
+3.0.3
 
because maven-helper does not understand that [3.0.3,) accepts 3.0.3
(which is in Debian).
Of course I could "solve" this by removing the brackets in
substitution, but it should not be necessary in the first place.

The current substitution mechanism is a pain to use in general. :-(
For example, I currently have:

org.apache.maven.plugins maven-compiler-plugin * s/.*/3.2/ * *

Because 3.2 is the only version available in Debian. But as far as I
can tell, I have to hard-code this (the plugin does not ship a
"debian" meta-version). Which means, I get FTBFS whenever any plugin
is updated in Debian!

Not using maven-debian-helper, but I have not yet found a way to make
this work with maven-debian-helper either:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808856
is simply a consequence of the maven-source-plugin package update on
December 9th.

The substitution rule:
org.apache.maven.plugins maven-source-plugin * s/.*/2.4/ * *
is prone to the same problem. Now I'm not only using one plugin, but a
dozen. Whenever any of these is updated in Debian, I would have to
reupload the packages... there should be a "s/.*/ANY/" substitution.

Unfortunately, it appears that Maven itself supports above interval
versions only for dependencies, not for plugins. :-(
I tried substituting 's/.*/[2,)/' to only depend on the major version
of the plugin, but this does not appear to be allowed by Maven.
I assume that 's/.*/debian/' would work, if all the Maven plugins are
re-uploaded to include a "debian" version.

Best regards,
Erich

On Sun, Jan 3, 2016 at 4:31 PM, Emmanuel Bourg <ebo...@apache.org> wrote:
> Le 3/01/2016 15:51, Erich Schubert a écrit :
>
>> Maven 3 allows specifying minimum and maximum version dependencies.
>> For example, it is possible to specify a junit dependency "[4.8,)" as
>> "4.8 and later".
>
> Hi Erich,
>
> What substitution rule did you use for junit in debian/maven.rules? I
> suspect that the usual version rule s/4\..*/4.x/ doesn't work because
> the version starts with a bracket [ and not 4. Could you try s/.*/4.x/
> and see if it works?
>
> Emmanuel Bourg
>

Bug#801925: Linux Null Pointer Dereference on boot

[Erich Schubert]

Hi,
Both me and a colleague are bit by the same/a similar bug.
The Null Pointer Dereference here is at sd_resume during early boot,
but looks very much related to this issue.

The last kernel able to boot for me is 4.1.0-2-amd64
Anything later than that (including linux-image-4.3.0-trunk-amd64
4.3-1~exp1) does not work anymore.

So yes, it appears to be broken *since*
49718f0fb8c9 ("SCSI: Fix NULL pointer dereference in runtime PM")
and the patches from Ken Xue may be helpful (untested).

Regards,
Erich

Bug#802959: RM: elki/0.6.5~20141030-1 from testing

[Erich Schubert]

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

Please remove the "elki" package from _testing_ to unblock libbatik-java.

An API change in batik made the packages incompatible.
ELKI version 0.7.0 will be compatible with both batik version again,
but I'm slightly behing schedule for updating the package.

The problem does *not* exist in "stable" (which has the old batik).

Since "elki" has only a tiny user base, I believe it is reasonable to
temporarily remove it from testing and have it requalify again.

See also: #70  (FTBFS with new Batik)
and the discussion on the debian-java team list.

Thanks,
Erich

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

Bug#799990: Bug#794214: org.apache.batik.dom.svg.SVGDOMImplementation

[Erich Schubert]

Hello,
Sorry, I'm still very much overworked.
Packaging the next version requires some effort because the build
system was switched from ant to maven for the new version; furthermore
I don't keep the gpg key on my usual work machines but I have to power
up an older desktop instead.

So I figured the auto-removal is okay, requalification through testing
will not be hard.
As is, people should just get the .jar from the upstream download site instead.

I'm not sure why the autoremoval date was bounced. I have filed
#802959 to ask for removal from testing to speed up batik.

Regards,
Erich

On Sat, Oct 24, 2015 at 2:19 PM, Mathieu Malaterre <ma...@debian.org> wrote:
> On Sat, Oct 24, 2015 at 2:06 PM, Samuel Thibault <sthiba...@debian.org> wrote:
>> Hello,
>>
>> Erich Schubert, le Mon 17 Aug 2015 10:28:27 +0200, a écrit :
>>> I will take care of uploading a new ELKI package (probably end of the
>>> month, or beginning of september).
>>> It will have a version number of at least "0.7.0~20150817-1", which is
>>> > 0.6.5, so above breaks is okay.
>>> I assume that libfop-java 1:2.0+dfsg-1 in experimental is expecting
>>> the new Batik version.
>>
>> Ping?
>>
>> This is preventing the batik migration, and thus the fop and jaxe
>> migrations too, at least.
>
> I was sure elki would get removed today ? See my post:
>
> https://lists.debian.org/debian-java/2015/09/msg00092.html
>
> Someone must have change the auto-removal date :(

Bug#787955: Backtrace for OpenJDK8 deadlocks with GTK UIs.

[Erich Schubert]

Hi,
The workaround from https://bugs.debian.org/798131
seems to work for me:

Edit
/etc/java-8-openjdk/accessibility.properties
and comment (add # to) the GNOME Atk Wrapper line:
assistive_technologies=org.GNOME.Accessibility.AtkWrapper

Regards,
Erich

On Tue, Sep 22, 2015 at 5:41 PM, Erich Schubert <er...@debian.org> wrote:
> As you can see, the deadlock is somewhere in GTK native code:
>
> "AWT-EventQueue-1" #17 prio=6 os_prio=0 tid=0x7f53a85d9800
> nid=0x6e1e runnable [0x7f5376d98000]
>java.lang.Thread.State: RUNNABLE
> at com.sun.java.swing.plaf.gtk.GTKStyle.nativeGetClassValue(Native Method)
> at 
> com.sun.java.swing.plaf.gtk.GTKStyle.getClassSpecificValue(GTKStyle.java:603)
> - locked <0x0005ca601d88> (a java.lang.Object)
> at 
> com.sun.java.swing.plaf.gtk.GTKStyle.getClassSpecificIntValue(GTKStyle.java:620)
> at com.sun.java.swing.plaf.gtk.GTKStyle.get(GTKStyle.java:791)
> at 
> javax.swing.plaf.synth.SynthArrowButton$SynthArrowButtonUI.getPreferredSize(SynthArrowButton.java:106)
> at javax.swing.JComponent.getPreferredSize(JComponent.java:1662)
> at 
> javax.swing.plaf.basic.BasicScrollBarUI.layoutVScrollbar(BasicScrollBarUI.java:662)
> at 
> javax.swing.plaf.basic.BasicScrollBarUI.layoutContainer(BasicScrollBarUI.java:866)
> at 
> javax.swing.plaf.basic.BasicScrollBarUI$ModelListener.stateChanged(BasicScrollBarUI.java:1054)
> at 
> javax.swing.DefaultBoundedRangeModel.fireStateChanged(DefaultBoundedRangeModel.java:364)
> at 
> javax.swing.DefaultBoundedRangeModel.setRangeProperties(DefaultBoundedRangeModel.java:302)
> at javax.swing.JScrollBar.setValues(JScrollBar.java:623)
> at 
> javax.swing.plaf.basic.BasicScrollPaneUI.syncScrollPaneWithViewport(BasicScrollPaneUI.java:285)
> at 
> javax.swing.plaf.basic.BasicScrollPaneUI$Handler.stateChanged(BasicScrollPaneUI.java:1039)
> at javax.swing.JViewport.fireStateChanged(JViewport.java:1369)
> at javax.swing.JViewport.setViewSize(JViewport.java:1021)
> at javax.swing.ViewportLayout.layoutContainer(ViewportLayout.java:201)
> at java.awt.Container.layout(Container.java:1510)
> at java.awt.Container.doLayout(Container.java:1499)
> at java.awt.Container.validateTree(Container.java:1695)
> at java.awt.Container.validateTree(Container.java:1704)
> at java.awt.Container.validate(Container.java:1630)
> - locked <0x0005ca6018a0> (a java.awt.Component$AWTTreeLock)
> at javax.swing.JViewport.validateView(JViewport.java:482)
> at javax.swing.JViewport.scrollRectToVisible(JViewport.java:393)
> at javax.swing.JComponent.scrollRectToVisible(JComponent.java:3111)
> at javax.swing.JTable.changeSelection(JTable.java:2467)
> at 
> javax.swing.plaf.basic.BasicTableUI$Handler.adjustSelection(BasicTableUI.java:1115)
> at 
> javax.swing.plaf.basic.BasicTableUI$Handler.mousePressed(BasicTableUI.java:1038)
> at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:280)
> at java.awt.Component.processMouseEvent(Component.java:6532)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
> at java.awt.Component.processEvent(Component.java:6300)
> at java.awt.Container.processEvent(Container.java:2236)
> at java.awt.Component.dispatchEventImpl(Component.java:4891)
> at java.awt.Container.dispatchEventImpl(Container.java:2294)
> at java.awt.Component.dispatchEvent(Component.java:4713)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4522)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
> at java.awt.Container.dispatchEventImpl(Container.java:2280)
> at java.awt.Window.dispatchEventImpl(Window.java:2750)
> at java.awt.Component.dispatchEvent(Component.java:4713)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
> at java.awt.EventQueue.access$500(EventQueue.java:97)
> at java.awt.EventQueue$3.run(EventQueue.java:709)
> at java.awt.EventQueue$3.run(EventQueue.java:703)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
> at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
> at java.awt.EventQueue$4.run(EventQueue.java:731)
> at java.awt.EventQueue$4.run(EventQueue.java:729)
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Protection

Bug#787955: Backtrace for OpenJDK8 deadlocks with GTK UIs.

[Erich Schubert]

As you can see, the deadlock is somewhere in GTK native code:

"AWT-EventQueue-1" #17 prio=6 os_prio=0 tid=0x7f53a85d9800
nid=0x6e1e runnable [0x7f5376d98000]
   java.lang.Thread.State: RUNNABLE
at com.sun.java.swing.plaf.gtk.GTKStyle.nativeGetClassValue(Native Method)
at 
com.sun.java.swing.plaf.gtk.GTKStyle.getClassSpecificValue(GTKStyle.java:603)
- locked <0x0005ca601d88> (a java.lang.Object)
at 
com.sun.java.swing.plaf.gtk.GTKStyle.getClassSpecificIntValue(GTKStyle.java:620)
at com.sun.java.swing.plaf.gtk.GTKStyle.get(GTKStyle.java:791)
at 
javax.swing.plaf.synth.SynthArrowButton$SynthArrowButtonUI.getPreferredSize(SynthArrowButton.java:106)
at javax.swing.JComponent.getPreferredSize(JComponent.java:1662)
at 
javax.swing.plaf.basic.BasicScrollBarUI.layoutVScrollbar(BasicScrollBarUI.java:662)
at 
javax.swing.plaf.basic.BasicScrollBarUI.layoutContainer(BasicScrollBarUI.java:866)
at 
javax.swing.plaf.basic.BasicScrollBarUI$ModelListener.stateChanged(BasicScrollBarUI.java:1054)
at 
javax.swing.DefaultBoundedRangeModel.fireStateChanged(DefaultBoundedRangeModel.java:364)
at 
javax.swing.DefaultBoundedRangeModel.setRangeProperties(DefaultBoundedRangeModel.java:302)
at javax.swing.JScrollBar.setValues(JScrollBar.java:623)
at 
javax.swing.plaf.basic.BasicScrollPaneUI.syncScrollPaneWithViewport(BasicScrollPaneUI.java:285)
at 
javax.swing.plaf.basic.BasicScrollPaneUI$Handler.stateChanged(BasicScrollPaneUI.java:1039)
at javax.swing.JViewport.fireStateChanged(JViewport.java:1369)
at javax.swing.JViewport.setViewSize(JViewport.java:1021)
at javax.swing.ViewportLayout.layoutContainer(ViewportLayout.java:201)
at java.awt.Container.layout(Container.java:1510)
at java.awt.Container.doLayout(Container.java:1499)
at java.awt.Container.validateTree(Container.java:1695)
at java.awt.Container.validateTree(Container.java:1704)
at java.awt.Container.validate(Container.java:1630)
- locked <0x0005ca6018a0> (a java.awt.Component$AWTTreeLock)
at javax.swing.JViewport.validateView(JViewport.java:482)
at javax.swing.JViewport.scrollRectToVisible(JViewport.java:393)
at javax.swing.JComponent.scrollRectToVisible(JComponent.java:3111)
at javax.swing.JTable.changeSelection(JTable.java:2467)
at 
javax.swing.plaf.basic.BasicTableUI$Handler.adjustSelection(BasicTableUI.java:1115)
at 
javax.swing.plaf.basic.BasicTableUI$Handler.mousePressed(BasicTableUI.java:1038)
at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:280)
at java.awt.Component.processMouseEvent(Component.java:6532)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6300)
at java.awt.Container.processEvent(Container.java:2236)
at java.awt.Component.dispatchEventImpl(Component.java:4891)
at java.awt.Container.dispatchEventImpl(Container.java:2294)
at java.awt.Component.dispatchEvent(Component.java:4713)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4522)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
at java.awt.Container.dispatchEventImpl(Container.java:2280)
at java.awt.Window.dispatchEventImpl(Window.java:2750)
at java.awt.Component.dispatchEvent(Component.java:4713)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
at 
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.awt.EventQueue$4.run(EventQueue.java:731)
at java.awt.EventQueue$4.run(EventQueue.java:729)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
at org.GNOME.Accessibility.AtkWrapper$5.dispatchEvent(AtkWrapper.java:697)
at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

There is a second thread waiting for the AWTTreeLock:
"Thread-1" #21 prio=5 os_prio=0 tid=0x7f5304007000 

Bug#799652: mediathekview: Headless mode is not working

[Erich Schubert]

Package: mediathekview
Version: 10-1
Severity: normal

Headless operation is broken in release, fixed in git:

> DISPLAY= mediathekview -Djava.awt.headless=true -auto
.  Proxy Authentication: not configured
Exception in thread "main" java.awt.HeadlessException: 
No X11 DISPLAY variable was set, but this program performed an operation which 
requires it.
at java.awt.SplashScreen.getSplashScreen(SplashScreen.java:117)
at mediathek.MediathekAuto.(MediathekAuto.java:53)
at mediathek.Main.main(Main.java:145)

According to this thread:
http://zdfmediathk.sourceforge.net/forum/viewtopic.php?f=2=1661=9455
it is fixed in git.

Probably this commit fixes the problem:
https://github.com/xaverW/MediathekView/commit/a074e69e613a9c1c54df339fedf19015bce2085f

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

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

Versions of packages mediathekview depends on:
ii  default-jre [java7-runtime]2:1.8-53
ii  java-wrappers  0.1.28
ii  libcommons-compress-java   1.10-1
ii  libcommons-lang3-java  3.4-1
ii  libjackson2-core-java  2.4.2-2
ii  libjchart2d-java   3.2.2+dfsg-1
ii  libjgoodies-forms-java 1.6.0-4
ii  libjide-oss-java   3.6.10+dfsg-1
ii  libmac-widgets-java0.10.0+svn416-dfsg1-1
ii  libswingx-java 1:1.6.2-2
ii  libtimingframework-java1.0-1
ii  libxz-java 1.5-1
ii  openjdk-7-jre [java7-runtime]  7u85-2.6.1-3
ii  openjdk-8-jre [java7-runtime]  8u66-b01-4

Versions of packages mediathekview recommends:
ii  flvstreamer  2.1c1-1
ii  mplayer  2:1.1.1+svn37434-1
ii  mpv  0.10.0-1
ii  vlc  2.2.1-4

Versions of packages mediathekview suggests:
ii  libav-tools  7:2.7.2-2

-- no debconf information

Bug#787955: Deadlocks in Java GUIs

[Erich Schubert]

Hi,
I'm seeing the same thing; it worked with earlier java versions, and
it continues to work with the Oracle JRE.
There is a bug in the Debian OpenJDK8 package, that is triggered in
particular when tab-switching from input fields.
But also my application seem to no longer properly quit when the
window is closed.

Regards,
Erich

Bug#794214: org.apache.batik.dom.svg.SVGDOMImplementation

[Erich Schubert]

Hello Mathieu,
The annoying part is that even the Batik documentation still contains
the old package name:
https://xmlgraphics.apache.org/batik/using/dom-api.html

It is well possible that many of the dependencies do not use this
class. I'm not sure if there might be indirect dependencies that rely
on one of these direct dependencies to pull in Batik... they could
still use that class; although many will not build a SVG document on
their own. Loading a document from a file should not be a problem, I
believe this class is only needed to be able to manipulate the SVG
documents e.g. for animation and interaction.

According to
find -type f -name *.jar -print | while read l; do unzip -c $l |
grep -q SVGDOMImplementation  echo $l; done
the only packages I have installed that use this class are Batik, FOP and ELKI.
It may well be that the other reverse dependencies do not use this class.
Scilab for example seems to use GenericDOMImplementation, which was
not moved to a different package.

I suggest to add these for the unstable upload:
Breaks: elki (= 0.6.5)
Breaks: libfop-java ( 2.0)
+ add a notice to the README that the class has moved, since this is
not well documented.

I will take care of uploading a new ELKI package (probably end of the
month, or beginning of september).
It will have a version number of at least 0.7.0~20150817-1, which is
 0.6.5, so above breaks is okay.
I assume that libfop-java 1:2.0+dfsg-1 in experimental is expecting
the new Batik version.

Regards,
Erich

On Sun, Aug 16, 2015 at 1:33 PM, Mathieu Malaterre ma...@debian.org wrote:
 Erich,

 Thanks for the report about batik API compat. Could you be a little more
 verbose on what was needed to fix ELKI ? I see that that

 import org.apache.batik.dom.svg.SVGDOMImplementation;

 is still used in the ELKI (from sid).

 I am trying to understand if this is possible to upload 1.8 to sid with a
 debian-specific fix, then progressively upgrade dependencies to match
 upstream (removing reference to SVGDOMImplementation).

 Thanks much,

Bug#794214: Batik 1.8 transition

[Erich Schubert]

Hello,
The next ELKI version will be compatible with Batik 1.8 and 1.7.
Please, if uploading batik to unstable, add a

Breaks: elki (= 0.6.5)

to the control file. ELKI 0.7.0 will be compatible with both batik versions.

Regards,
Erich


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

Bug#792175: Batik 1.8 is out, but incompatible!

[Erich Schubert]

Unfortunately, Batik 1.8 appears to be incomatible to Batik 1.7

Therefore, upgrading the package without bumping the name will cause
many applications to break.

E.g. for ELKI I had to limit Batik to the latest 1.7 version in the pom.

See:
http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/201503.mbox/%3c55157c80.4030...@ptc.com%3E

Please consider:
- careful testing of packages that depend on Batik
- either bouncing the package name of batik,
- or setting up appropriate Breaks dependencies

It seems that upgrading to 1.8 should not be hard, but since a class
was moved to a different package, it may require touching every
package that depends on Batik.

I'm not a big fan of keeping around many older versions, so maybe
setting versioned Breaks: for those 15-16 packages that depend on
batik, and working with the affected maintainers to provide packages
working with Batik 1.8 instead, is an alternative to ensure a smooth
upgrade?

Regards,
Erich


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

Bug#789023: gnome-tweak-tool: Missing dependency on gnome-settings-daemon

[Erich Schubert]

Package: gnome-tweak-tool
Version: 3.16.2-1
Severity: normal

Dear Maintainer,

When gnome-settings-daemon is not installed, gnome-tweak-tool crashes:

GLib-GIO-ERROR **: Settings schema 
'org.gnome.settings-daemon.plugins.xsettings' is not installed

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

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

Versions of packages gnome-tweak-tool depends on:
ii  gir1.2-glib-2.01.44.0-1+b1
ii  gir1.2-gnomedesktop-3.03.16.2-2
ii  gir1.2-gtk-3.0 3.16.4-2
ii  gir1.2-notify-0.7  0.7.6-2
ii  gir1.2-pango-1.0   1.36.8-3
ii  gir1.2-soup-2.42.50.0-2
ii  gnome-shell-common 3.16.2-4
ii  gsettings-desktop-schemas  3.16.1-1
ii  mutter-common  3.16.2-2
ii  python 2.7.9-1
ii  python-gi  3.14.0-1

gnome-tweak-tool recommends no packages.

gnome-tweak-tool 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#776788: Golang or docker error?

[Erich Schubert]

 I tried to nail it down, it seems to be hidden in the gzip module of golang.

In this case, the error should probably be reported against golang?

But I would be very much surprised to see a gzip error go undetected...
Plus, if alternate means of downloading work (and the data probably
needs to be extracted the same way), I would expect a different kind
of data corruption to happen.

Regards,
Erich


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

Bug#774745: Maven 3.0 fails to build some software

[Erich Schubert]

severity 774745 important
thanks

According to
https://issues.apache.org/jira/browse/BIGTOP-1476
Maven 3.0 cannot build Hadoop. Maven 3.2 is reported to fix the issues.
It seems maven 3.0 fails to correctly resolve some dependencies?

Regards,
Erich


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

Bug#763155: Bug#764528: Cross-referencing i915 kernel bugs on EEEpc

[Erich Schubert]

tag 764528 + patch jessie
tag 763155 + patch jessie
thanks

An improved patch has been posted, by Daniel Vetter of Intel:
https://freedesktop.org/patch/42259/

It has also been discussed on the LKML, and I hope it will be included
in the next round of pull requests of drm-next.

On Sat, Feb 7, 2015 at 3:22 PM, Erich Schubert er...@debian.org wrote:
 tag 764528 + patch jessie
 tag 763155 + patch jessie
 thanks

 There appears to be a rather easy patch available:
 http://patchwork.freedesktop.org/patch/38659/
 Quietly reject attempts to create non-pagealigned stolen objects

 Judging from the discussion, it is not a real bug. It is an
 unexpected behavior (Bios using non-aligned video buffer, supported by
 the hardware, but not aligned to the driver requirements). The patch
 essentially replaces the BUG_ON with a log statement and then returns
 null, which is supposed to reliably work. (Without reusing the memory
 the bios used.)

 This probably won't be the final fix. There is some discussion here:
 http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/52613
 which suggests that instead it may be desirable to reuse the bios
 allocation, and just align it as desired.

 But since this causes boot issues on some eeePC models (apparently, it
 depends on the bios and CPU), and the patch is quite simple, it should
 be considered for jessie, even if the patch isn't the long-term
 solution yet. Thank you.

 Regards,
 Erich

 On Sun, Nov 30, 2014 at 10:59 PM, Erich Schubert er...@debian.org wrote:
 https://bugs.freedesktop.org/show_bug.cgi?id=86883

 Not sure if kernel bugzilla wouldn't have been the better address,
 given that the BUG_ON clearly is in kernel code. But I guess it's the
 same developers anyway.

 Regards,
 Erich


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

Bug#763155: Bug#764528: Cross-referencing i915 kernel bugs on EEEpc

[Erich Schubert]

tag 764528 + patch jessie
tag 763155 + patch jessie
thanks

There appears to be a rather easy patch available:
http://patchwork.freedesktop.org/patch/38659/
Quietly reject attempts to create non-pagealigned stolen objects

Judging from the discussion, it is not a real bug. It is an
unexpected behavior (Bios using non-aligned video buffer, supported by
the hardware, but not aligned to the driver requirements). The patch
essentially replaces the BUG_ON with a log statement and then returns
null, which is supposed to reliably work. (Without reusing the memory
the bios used.)

This probably won't be the final fix. There is some discussion here:
http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/52613
which suggests that instead it may be desirable to reuse the bios
allocation, and just align it as desired.

But since this causes boot issues on some eeePC models (apparently, it
depends on the bios and CPU), and the patch is quite simple, it should
be considered for jessie, even if the patch isn't the long-term
solution yet. Thank you.

Regards,
Erich

On Sun, Nov 30, 2014 at 10:59 PM, Erich Schubert er...@debian.org wrote:
 https://bugs.freedesktop.org/show_bug.cgi?id=86883

 Not sure if kernel bugzilla wouldn't have been the better address,
 given that the BUG_ON clearly is in kernel code. But I guess it's the
 same developers anyway.

 Regards,
 Erich


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

Bug#763155: Cross-referencing i915 kernel bugs on EEEpc

[Erich Schubert]

severity 764528 important
tag 764528 +jessie +sid +experimental
tag 771227 +jessie +sid +experimental
block 764528 763155
block 771227 763155
merge 764528 771227
thanks

All of these are probably the same bug, rendering current kernels
(jessie onward) unusable on EEEpc with older (?) Atom CPUs.

As far as I can tell, the bug may be in the kernel, not the xorg
driver (xorg shouldn't lock up the kernel; and the kernel itself
reports a BUG after all...)

 kernel BUG at 
 /build/linux-Lep8DD/linux-3.16.3/drivers/gpu/drm/i915/i915_gem_stolen.c:431!

IMHO, it may be reasonable to upgrade this regression to serious
instead of important.

Regards,
Erich


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

Bug#763155: Bug#764528: Cross-referencing i915 kernel bugs on EEEpc

[Erich Schubert]

https://bugs.freedesktop.org/show_bug.cgi?id=86883

Not sure if kernel bugzilla wouldn't have been the better address,
given that the BUG_ON clearly is in kernel code. But I guess it's the
same developers anyway.

Regards,
Erich


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

Bug#770812: tasksel: task-sysvinit to allow easy installation of non-systemd systems

[Erich Schubert]

HI,
 Besides: I'm not sure where you got the impression I owe you anything.

Any user writing a reasonable bug report deserves to be treated with
respect, and deserves a useful answer (spam and duplicate reports are
an obvious exception).
Not just a no (which is an unwritten f... off)

Otherwise, our users will stop reporting bugs at all, if you treat
them this way.

It's bad enough that you won't even consider our current #1 installer
feature request as future wishlist item. This itself is already highly
disrespectful, and I'm not surprised that some people are annoyed, if
all they get in return are  shut up messages.
I guess we'll see a forked installer sooner or later because of that.
(But I won't be doing that, I do use systemd myself)

Regards,
Erich


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

Bug#770812: tasksel: task-sysvinit to allow easy installation of non-systemd systems

[Erich Schubert]

Package: tasksel
Version: 3.29
Severity: wishlist

Hello,
It has been argued that late changes to the debian installer should be
avoided, and the maintainers have clearly expressed that they do not want
to add another debconf question:
https://lists.debian.org/debian-boot/2014/11/msg00408.html

My proposal is not to forcibly have users answer this question and decide
on an init system upon install. But there seems to be a larger userbase
that does want to keep sysvinit (in fact, I have switched all my systems
to systemd; but I do have an interest to have the noise eventually stop).

Can maybe the tasks system help here?
Can we have a task-sysvinit which depends on sysvinit-core, and which
conflicts systemd-sysv, and does installing such a task achieve the
desired results at installation time?

IMHO, adding a task package is a minimally invasive change to the install
process, and given the many requests for a sysvinit install option, this
may well be acceptable to the release managers. It's just not entirely
clear to me whether this works (i.e. when tasks are considered during
the installation phase, and whether this allows overriding the package
providing init), and the procedure necessary to get such a change
accepted into tasksel, the installation media, and jessie.

(And yes, I'm aware of the preseeding option to pass
  preseed/late_command=in-target apt-get install -y sysvinit-core
to the installer. Essentially, I'm thinking of minimally invasive ways
to make this easier to access by end users - this is a pretty long
boot option to type, without the option of doing copypaste when installing
a physical system...)

In the end, Switch boot process to sysvinit is a task that will end up
on the TODO list of many sysadmins (e.g. where because of some compatibility
or policy issue, they want to have all their servers on sysvinit)

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

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

Versions of packages tasksel depends on:
ii  apt 1.0.9.3
ii  debconf [debconf-2.0]   1.5.53
ii  liblocale-gettext-perl  1.05-8+b1
ii  perl-base   5.20.1-3
ii  tasksel-data3.29

tasksel recommends no packages.

tasksel suggests no packages.

-- debconf information excluded


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

Bug#770812: tasksel: task-sysvinit to allow easy installation of non-systemd systems

[Erich Schubert]

Please DISCUSS, don't just turn down.

You owe this to me, and others, that want to make our users happy.

This is a frequently requested feature, and you don't even want to
discuss whether the suggested approach is possible...

Your behavior is nothing short of rude.
Did you even read the mail?

On Mon, Nov 24, 2014 at 2:06 PM, Cyril Brulebois k...@debian.org wrote:
 Erich Schubert er...@debian.org (2014-11-24):
 Package: tasksel
 Version: 3.29
 Severity: wishlist

 Hello,
 It has been argued that late changes to the debian installer should be
 avoided, and the maintainers have clearly expressed that they do not want
 to add another debconf question:
 https://lists.debian.org/debian-boot/2014/11/msg00408.html

 My proposal is not to forcibly have users answer this question and decide
 on an init system upon install. But there seems to be a larger userbase
 that does want to keep sysvinit (in fact, I have switched all my systems
 to systemd; but I do have an interest to have the noise eventually stop).

 Can maybe the tasks system help here?
 Can we have a task-sysvinit which depends on sysvinit-core, and which
 conflicts systemd-sysv, and does installing such a task achieve the
 desired results at installation time?

 IMHO, adding a task package is a minimally invasive change to the install
 process, and given the many requests for a sysvinit install option, this
 may well be acceptable to the release managers. It's just not entirely
 clear to me whether this works (i.e. when tasks are considered during
 the installation phase, and whether this allows overriding the package
 providing init), and the procedure necessary to get such a change
 accepted into tasksel, the installation media, and jessie.

 (And yes, I'm aware of the preseeding option to pass
   preseed/late_command=in-target apt-get install -y sysvinit-core
 to the installer. Essentially, I'm thinking of minimally invasive ways
 to make this easier to access by end users - this is a pretty long
 boot option to type, without the option of doing copypaste when installing
 a physical system...)

 In the end, Switch boot process to sysvinit is a task that will end up
 on the TODO list of many sysadmins (e.g. where because of some compatibility
 or policy issue, they want to have all their servers on sysvinit)

 Again, no.

 Mraw,
 KiBi.


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

Bug#770812: tasksel: task-sysvinit to allow easy installation of non-systemd systems

[Erich Schubert]

reopen 770812
thanks

Hello,
Read the QUESTION.
Not only the word systemd.

You are still not listening to my actual question, only raising your
sysvinit-shields.


I'm asking if a TASK can solve this maybe more nicely than the other
proposed approaches.

Bug #668001 does not mention this possibility as far as I can tell:
The word task is NEVER discussed there.
And the late_command solution is not userfriendly at all.

Therefore, this is a different wishlist item, against a different
package, too...
There is a reason why I filed this bug against *tasksel*, and not debootstrap!

I WILL accept a closing for this (non-RC, wishlist) bug IF you can
point out a thread e.g. on debian-boot where the option of a
task-sysvinit package to make the users happy is discussed.
The tech-ctte discussion you cited also does NOT discuss this option...
Because adding a task to the tasksel list IS something else than
adding a whole new bootstrap option...

The only mentioning of tasksel in the tech-ctte thread is this:
1. The TC encourages a team (probably debian-boot) to provide a
package (similar to tasksel), let's call it initsel,
Making a similar mechanism clearly is much more invasive than trying
to use the existing tasksel mechanism, isn't it?


But apparently you didn't read my question, only systemd and
sysvinit install.
I begin to understand what the systemd opponents complain about...
You don't actually discuss the technical aspect (can a task package
solve this), but instead you try to silence me by 1.) closing the bug
without discussion, now 2) closing it with a totally different
argument and the Tech-CTTE and GR have decided hammer and don't
bring up the bug count?!?


We had a GR about making it *mandatory* to support sysvinit.
The GR does allow to use the traditional Debian way of developing
features and improving portability.
Reporting a specific wishlist bug for an *optional* functionality IS
THE PROPER PROCEDURE, isn't it?

Don't come with absurd we're in freeze, so don't open wishlist bugs
arguments...
That's not what a freeze is, and the wishlist bug does not
 - Debian is frozen, we're trying to get the RC count down
Seriously. A wishlist bug is not RC, is it?


Back to the topic, would you PLEASE bother to discuss the option of
adding a task to tasksel for sysvinit installation?
Is it possible (at all), and how much testing is needed, can get this
tested in time for jessie?

Regards,
Erich


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

Bug#770812: Patch to add a sysvinit task to tasksel (untested)

[Erich Schubert]

Control: tag -1 +patch

Attached is a patch that adds a sysvinit task to tasksel.
It's fairly light (11 lines total in two files: control and task
description) but it means translations need to be updated.
Plus I haven't tested it, as I don't intend to use sysvinit myself anyway.

IMHO, it should be considered for Debian 8.1 (Next Jessie refresh) or
maybe even the first Jessie release, given the amount of user interest
on this functionality.
Main stopper is the freeze, as this should be tested (fortunately it
is really light) and translated.
Nevertheless, the freeze managers may consider a freeze exception for
this: we've all seen the amount of discussion on how to avoid
installing with systemd.
If this patch can make a non-systemd installation easy, it is worth
consideration, isn't it?

Regards,
Erich
From 4499a0a4ffe884e9da65f05b85ec0d5ee2ca8ef3 Mon Sep 17 00:00:00 2001
From: Erich Schubert er...@debian.org
Date: Mon, 24 Nov 2014 20:54:54 +0100
Subject: [PATCH] add sysvinit task

---
 debian/control | 6 ++
 tasks/sysvinit | 5 +
 2 files changed, 11 insertions(+)
 create mode 100644 tasks/sysvinit

diff --git a/debian/control b/debian/control
index bca654f..0794d21 100644
--- a/debian/control
+++ b/debian/control
@@ -2473,3 +2473,9 @@ Description: Cyrillic KDE desktop
 Depends: ${misc:Depends}, 
 Recommends:
 
+Package: task-sysvinit
+Architecture: all
+Description: SysV system init instead of systemd
+ This task installes sysvinit-core instead of systemd-sysv
+Depends: ${misc:Depends}, sysvinit-core
+Conflicts: systemd-sysv
diff --git a/tasks/sysvinit b/tasks/sysvinit
new file mode 100644
index 000..db9a268
--- /dev/null
+++ b/tasks/sysvinit
@@ -0,0 +1,5 @@
+Task: sysvinit
+Relevance: 5
+Section: server
+Key:
+  task-sysvinit
-- 
2.1.3

Bug#763155: linux-image-3.16.0-4-686-pae: Bad news, only working sometimes

[Erich Schubert]

Package: src:linux
Version: 3.16.7-2
Followup-For: Bug #763155
Control: found 3.16.7-2

Unfortunately, the problems still persist. Today, 3.16.0-4 did not boot 
correctly either; nor did 3.17.
The last kernel working reliably was and continues to be 3.14. :-(

Hardware name: ASUSTeK Computer INC. 1016P/1015PE, BIOS 080110/06/2010

Nov 10 09:42:37 kleinphi kernel: ACPI: AC Adapter [AC0] (on-line)
Nov 10 09:42:37 kleinphi kernel: wmi: Mapper loaded
Nov 10 09:42:37 kleinphi kernel: [drm] Initialized drm 1.1.0 20060810
Nov 10 09:42:37 kleinphi kernel: ACPI: Battery Slot [BAT0] (battery present)
Nov 10 09:42:37 kleinphi kernel: ACPI Warning: SystemIO range 
0x0828-0x082f conflicts with OpRegion 0x0800-0x087f (\PMIO) 
(20140424/utaddress-258)
Nov 10 09:42:37 kleinphi kernel: ACPI Warning: SystemIO range 
0x0828-0x082f conflicts with OpRegion 0x0828-0x082f 
(\_SB_.PCI0.SBRG.IELK.GPSE) (20140424/utaddress-258)
Nov 10 09:42:37 kleinphi kernel: ACPI: If an ACPI driver is available for this 
device, you should use it instead of the native driver
Nov 10 09:42:37 kleinphi kernel: ACPI Warning: SystemIO range 
0x04b0-0x04bf conflicts with OpRegion 0x0480-0x04bf 
(\_SB_.PCI0.SBRG.GPBX) (20140424/utaddress-258)
Nov 10 09:42:37 kleinphi kernel: ACPI: If an ACPI driver is available for this 
device, you should use it instead of the native driver
Nov 10 09:42:37 kleinphi kernel: ACPI Warning: SystemIO range 
0x0480-0x04af conflicts with OpRegion 0x0480-0x04bf 
(\_SB_.PCI0.SBRG.GPBX) (20140424/utaddress-258)
Nov 10 09:42:37 kleinphi kernel: ACPI: If an ACPI driver is available for this 
device, you should use it instead of the native driver
Nov 10 09:42:37 kleinphi kernel: lpc_ich: Resource conflict(s) found affecting 
gpio_ich
Nov 10 09:42:37 kleinphi kernel: shpchp: Standard Hot Plug PCI Controller 
Driver version: 0.4
Nov 10 09:42:37 kleinphi kernel: media: Linux media interface: v0.10
Nov 10 09:42:37 kleinphi kernel: bcma: bus0: Found chip with id 0x4313, rev 
0x01 and package 0x08
Nov 10 09:42:37 kleinphi kernel: bcma: bus0: Core 0 found: ChipCommon (manuf 
0x4BF, id 0x800, rev 0x24, class 0x0)
Nov 10 09:42:37 kleinphi kernel: bcma: bus0: Core 1 found: IEEE 802.11 (manuf 
0x4BF, id 0x812, rev 0x18, class 0x0)
Nov 10 09:42:37 kleinphi kernel: bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, 
id 0x820, rev 0x11, class 0x0)
Nov 10 09:42:37 kleinphi kernel: bcma: bus0: Bus registered
Nov 10 09:42:37 kleinphi kernel: i915: unknown parameter 'i915_enable_rc6' 
ignored
Nov 10 09:42:37 kleinphi kernel: i915: unknown parameter 'i915_enable_fbc' 
ignored
Nov 10 09:42:37 kleinphi kernel: Linux video capture interface: v2.00
Nov 10 09:42:37 kleinphi kernel: [drm] Memory usable by graphics device = 512M
Nov 10 09:42:37 kleinphi kernel: [drm] Replacing VGA console driver
Nov 10 09:42:37 kleinphi kernel: Console: switching to colour dummy device 80x25
Nov 10 09:42:37 kleinphi kernel: i915 :00:02.0: irq 44 for MSI/MSI-X
Nov 10 09:42:37 kleinphi kernel: [drm] Supports vblank timestamp caching Rev 2 
(21.10.2013).
Nov 10 09:42:37 kleinphi kernel: [drm] Driver supports precise vblank timestamp 
query.
Nov 10 09:42:37 kleinphi kernel: vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
Nov 10 09:42:37 kleinphi kernel: [ cut here ]
Nov 10 09:42:37 kleinphi kernel: kernel BUG at 
/build/linux-cizhNw/linux-3.16.7/drivers/gpu/drm/i915/i915_gem_stolen.c:431!
Nov 10 09:42:37 kleinphi kernel: invalid opcode:  [#1] SMP 
Nov 10 09:42:37 kleinphi kernel: Modules linked in: snd_hda_codec videodev 
i915(+) bcma media evdev snd_hwdep snd_pcm shpchp lpc_ich psmouse serio_raw 
mfd_core snd_timer snd battery drm_kms_helper drm i2c_algo_bit soundcore 
i2c_core wmi video ac sparse_keymap rfkill button acpi_cpufreq processor 
coretemp loop fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 
sg sd_mod crc_t10dif crct10dif_generic crct10dif_common ahci libahci uhci_hcd 
ehci_pci libata ehci_hcd scsi_mod usbcore usb_common thermal atl1c thermal_sys
Nov 10 09:42:37 kleinphi kernel: CPU: 1 PID: 225 Comm: systemd-udevd Not 
tainted 3.16.0-4-686-pae #1 Debian 3.16.7-2
Nov 10 09:42:38 kleinphi kernel: Hardware name: ASUSTeK Computer INC. 
1016P/1015PE, BIOS 080110/06/2010
Nov 10 09:42:39 kleinphi kernel: task: f6c73560 ti: f4cce000 task.ti: f4cce000
Nov 10 09:42:39 kleinphi kernel: EIP: 0060:[f842813b] EFLAGS: 00010206 CPU: 1
Nov 10 09:42:39 kleinphi kernel: EIP is at 
i915_gem_object_create_stolen_for_preallocated+0x20b/0x280 [i915]
Nov 10 09:42:39 kleinphi kernel: EAX: f6d27400 EBX: f443c150 ECX: 001d4c00 EDX: 
001d4c00
Nov 10 09:42:39 kleinphi kernel: ESI: f4438000 EDI: 001d4c00 EBP: f4ccfb60 ESP: 
f4ccfb38
Nov 10 09:42:39 kleinphi kernel:  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Nov 10 09:42:39 kleinphi kernel: CR0: 80050033 CR2: b76e298e CR3: 34f77000 CR4: 
07f0
Nov 10 09:42:39 kleinphi kernel: 

Bug#763155: linux-image-3.16.0-4-686-pae: Probably resolved in 3.16.0-4-686

[Erich Schubert]

Package: src:linux
Followup-For: Bug #763155

Hello,
Successfully running 3.16.0-4-686-pae right now.
Either the problem is gone, or it doesn't occur on every boot.
(Different EEEpc model, though)

-- Package-specific info:
** Version:
Linux version 3.16.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version 
4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-2 (2014-11-06)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-686-pae 
root=UUID=aa89f4fe-2436-40c9-b83b-1feb9e644084 ro quiet splash 
pciehp.pciehp_force=1 resume=UUID=afcf3a0f-4df7-4a4a-b221-73709c3dbd27 
i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.semaphores=1 
video.use_native_backlight=0

** Not tainted

** Kernel log:
[ 2921.017954] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: 
disassociated
[ 2921.017974] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 
addresses (implement)
[ 2921.017983] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false 
(implement)
[ 2921.032449] cfg80211: Calling CRDA to update world regulatory domain
[ 2921.104218] cfg80211: World regulatory domain updated:
[ 2921.104230] cfg80211:  DFS Master region: unset
[ 2921.104237] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[ 2921.104248] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[ 2921.104257] cfg80211:   (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[ 2921.104265] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 
mBm), (N/A)
[ 2921.104274] cfg80211:   (517 KHz - 525 KHz @ 16 KHz), (N/A, 2000 
mBm), (N/A)
[ 2921.104284] cfg80211:   (525 KHz - 533 KHz @ 16 KHz), (N/A, 2000 
mBm), (0 s)
[ 2921.104293] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 
mBm), (0 s)
[ 2921.104301] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 
mBm), (N/A)
[ 2921.104310] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 
mBm), (N/A)
[ 2921.148124] wlan0: authenticate with 00:03:52:e4:31:54
[ 2921.148297] wlan0: send auth to 00:03:52:e4:31:54 (try 1/3)
[ 2921.149565] wlan0: authenticated
[ 2921.152087] wlan0: associate with 00:03:52:e4:31:54 (try 1/3)
[ 2921.153909] wlan0: RX AssocResp from 00:03:52:e4:31:54 (capab=0xc31 status=0 
aid=3)
[ 2921.154466] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: 
associated
[ 2921.154488] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 
addresses (implement)
[ 2921.154503] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true 
(implement)
[ 2921.154547] wlan0: associated
[ 2921.154765] cfg80211: Calling CRDA for country: DE
[ 2921.176122] cfg80211: Regulatory domain changed to country: DE
[ 2921.176131] cfg80211:  DFS Master region: ETSI
[ 2921.176136] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[ 2921.176145] cfg80211:   (240 KHz - 2483500 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[ 2921.176153] cfg80211:   (515 KHz - 525 KHz @ 8 KHz), (N/A, 2000 
mBm), (N/A)
[ 2921.176161] cfg80211:   (525 KHz - 535 KHz @ 8 KHz), (N/A, 2000 
mBm), (0 s)
[ 2921.176169] cfg80211:   (547 KHz - 5725000 KHz @ 8 KHz), (N/A, 2698 
mBm), (0 s)
[ 2921.176176] cfg80211:   (5724 KHz - 6588 KHz @ 216 KHz), (N/A, 
4000 mBm), (N/A)
[ 2934.028136] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: 
disassociated
[ 2934.028157] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 
addresses (implement)
[ 2934.028166] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false 
(implement)
[ 2934.041662] cfg80211: Calling CRDA to update world regulatory domain
[ 2934.143891] cfg80211: World regulatory domain updated:
[ 2934.143902] cfg80211:  DFS Master region: unset
[ 2934.143907] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[ 2934.143916] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[ 2934.143924] cfg80211:   (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[ 2934.143931] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 
mBm), (N/A)
[ 2934.143939] cfg80211:   (517 KHz - 525 KHz @ 16 KHz), (N/A, 2000 
mBm), (N/A)
[ 2934.143946] cfg80211:   (525 KHz - 533 KHz @ 16 KHz), (N/A, 2000 
mBm), (0 s)
[ 2934.143954] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 
mBm), (0 s)
[ 2934.143962] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 
mBm), (N/A)
[ 2934.143969] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 
mBm), (N/A)
[ 2934.750435] wlan0: authenticate with 00:03:52:e4:30:f4
[ 2934.752361] wlan0: send auth to 00:03:52:e4:30:f4 (try 1/3)
[ 2934.756115] wlan0: authenticated
[ 2934.760082] wlan0: associate with 00:03:52:e4:30:f4 (try 1/3)
[ 2934.762131] wlan0: RX AssocResp from 00:03:52:e4:30:f4 (capab=0xc31 status=0 
aid=1)
[ 

Bug#768027: linux-image-3.16-3-686-pae: kernel BUG at linux-3.16.5/drivers/gpu/drm/i915/i915_gem_stolen.c:431!

[Erich Schubert]

Package: src:linux
Version: 3.16.5-1
Severity: important

Booting a 3.16.5 leads to a locked up system. Login manager fails to start, and 
the console is dead.

This renders this kernel UNUSABLE on my Netbook.
Kernel 3.14 works fine.

This appears to be specific to the earlier Intel Atom CPUs?

Nov 04 11:02:14 kleinphi kernel: kernel BUG at 
/build/linux-I5YRU_/linux-3.16.5/drivers/gpu/drm/i915/i915_gem_stolen.c:431!
Nov 04 11:02:14 kleinphi kernel: invalid opcode:  [#1] SMP 
Nov 04 11:02:14 kleinphi kernel: Modules linked in: media i915(+) lpc_ich bcma 
mfd_core drm_kms_helper shpchp wmi drm ac batt
Nov 04 11:02:14 kleinphi kernel: CPU: 1 PID: 226 Comm: systemd-udevd Not 
tainted 3.16-3-686-pae #1 Debian 3.16.5-1
Nov 04 11:02:15 kleinphi kernel: Hardware name: ASUSTeK Computer INC. 
1016P/1015PE, BIOS 080110/06/2010
Nov 04 11:02:15 kleinphi kernel: task: f6cfe010 ti: f42de000 task.ti: f42de000
Nov 04 11:02:16 kleinphi kernel: EIP: 0060:[f835413b] EFLAGS: 00010206 CPU: 1
Nov 04 11:02:16 kleinphi kernel: EIP is at 
i915_gem_object_create_stolen_for_preallocated+0x20b/0x280 [i915]
Nov 04 11:02:16 kleinphi kernel: EAX: f4347800 EBX: f4274150 ECX: 001d4c00 EDX: 
001d4c00
Nov 04 11:02:16 kleinphi kernel: ESI: f427 EDI: 001d4c00 EBP: f42dfb60 ESP: 
f42dfb38
Nov 04 11:02:16 kleinphi kernel:  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Nov 04 11:02:16 kleinphi kernel: CR0: 80050033 CR2: b75d0740 CR3: 36f6c000 CR4: 
07f0
Nov 04 11:02:16 kleinphi kernel: Stack:
Nov 04 11:02:16 kleinphi kernel:  f43479e4 0286 f4270004 0001 0001 
f4347800 001d4c00 f4cf8000
Nov 04 11:02:16 kleinphi kernel:  f4347800 f42dfbd4 f42dfbe0 f83833ab 00139000 
00071024 f42dfba8 f835ceab
Nov 04 11:02:16 kleinphi kernel:  0001 f4347800 f427 f43479e4 0002 
f4347a00  
Nov 04 11:02:16 kleinphi kernel: Call Trace:
Nov 04 11:02:17 kleinphi kernel:  [f83833ab] ? 
intel_modeset_init+0x82b/0x1210 [i915]
Nov 04 11:02:17 kleinphi kernel:  [f835ceab] ? 
i915_enable_pipestat+0xab/0x120 [i915]
Nov 04 11:02:17 kleinphi kernel:  [f83acbc5] ? i915_driver_load+0xae5/0xed0 
[i915]
Nov 04 11:02:17 kleinphi kernel:  [f83a9f40] ? 
i915_switcheroo_set_state+0x90/0x90 [i915]
Nov 04 11:02:17 kleinphi kernel:  [c137fa60] ? 
powercap_register_control_type+0x1c0/0x1c0
Nov 04 11:02:17 kleinphi kernel:  [c12515f0] ? cleanup_uevent_env+0x10/0x10
Nov 04 11:02:17 kleinphi kernel:  [c133acc4] ? get_device+0x14/0x30
Nov 04 11:02:17 kleinphi kernel:  [c146ea6b] ? klist_node_init+0x2b/0x40
Nov 04 11:02:17 kleinphi kernel:  [c146ead6] ? klist_add_tail+0x16/0x30
Nov 04 11:02:17 kleinphi kernel:  [c133c076] ? device_add+0x1d6/0x5a0
Nov 04 11:02:17 kleinphi kernel:  [f81f15ae] ? drm_dev_register+0x8e/0xe0 
[drm]
Nov 04 11:02:17 kleinphi kernel:  [f81f3b79] ? drm_get_pci_dev+0x79/0x1c0 
[drm]
Nov 04 11:02:17 kleinphi kernel:  [c1284c5f] ? pci_device_probe+0x6f/0xc0
Nov 04 11:02:17 kleinphi kernel:  [c11ca735] ? sysfs_create_link+0x25/0x40
Nov 04 11:02:17 kleinphi kernel:  [c133eb03] ? driver_probe_device+0x93/0x3a0
Nov 04 11:02:17 kleinphi kernel:  [c11ca467] ? sysfs_create_dir_ns+0x37/0x80
Nov 04 11:02:17 kleinphi kernel:  [c133eb03] ? driver_probe_device+0x93/0x3a0
Nov 04 11:02:17 kleinphi kernel:  [c11ca467] ? sysfs_create_dir_ns+0x37/0x80
Nov 04 11:02:17 kleinphi kernel:  [c1284ba1] ? pci_match_device+0xc1/0xe0
Nov 04 11:02:17 kleinphi kernel:  [c133eec1] ? __driver_attach+0x71/0x80
Nov 04 11:02:17 kleinphi kernel:  [c133ee50] ? __device_attach+0x40/0x40
Nov 04 11:02:17 kleinphi kernel:  [c133cfd7] ? bus_for_each_dev+0x47/0x80
Nov 04 11:02:17 kleinphi kernel:  [c133e60e] ? driver_attach+0x1e/0x20
Nov 04 11:02:17 kleinphi kernel:  [c133ee50] ? __device_attach+0x40/0x40
Nov 04 11:02:17 kleinphi kernel:  [c133e267] ? bus_add_driver+0x157/0x230
Nov 04 11:02:17 kleinphi kernel:  [f83ea000] ? 0xf83e9fff
Nov 04 11:02:17 kleinphi kernel:  [c133f589] ? driver_register+0x59/0xe0
Nov 04 11:02:17 kleinphi kernel:  [c1002132] ? do_one_initcall+0xc2/0x1f0
Nov 04 11:02:17 kleinphi kernel:  [f83ea000] ? 0xf83e9fff
Nov 04 11:02:17 kleinphi kernel:  [f832e000] ? 0xf832dfff
Nov 04 11:02:17 kleinphi kernel:  [c11492c8] ? __vunmap+0x88/0xf0
Nov 04 11:02:17 kleinphi kernel:  [c11492c8] ? __vunmap+0x88/0xf0
Nov 04 11:02:17 kleinphi kernel:  [c10c0f5b] ? load_module+0x1cbb/0x2390
Nov 04 11:02:17 kleinphi kernel:  [c10c1795] ? SyS_finit_module+0x75/0xc0
Nov 04 11:02:17 kleinphi kernel:  [c112ef5b] ? vm_mmap_pgoff+0x7b/0xa0
Nov 04 11:02:17 kleinphi kernel:  [c1479c9f] ? sysenter_do_call+0x12/0x12
Nov 04 11:02:17 kleinphi kernel: Code: 08 89 54 24 08 c7 44 24 04 80 3f 3c f8 
c7 04 24 a0 62 3b f8 89 44 24 10 8b 45 f0 89 44
Nov 04 11:02:18 kleinphi kernel: EIP: [f835413b] 
i915_gem_object_create_stolen_for_preallocated+0x20b/0x280 [i915] SS:ESP 0
Nov 04 11:02:20 kleinphi kernel: ---[ end trace 981ffc8e744747f8 ]---


** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Atom Processor 
D4xx/D5xx/N4xx/N5xx DMI Bridge [8086:a010]

Bug#763155: linux-image-3.16-2-686-pae: linux 3.16-2-686-pae: i915 module crashes on Eeepc 1001p

[Erich Schubert]

Package: src:linux
Version: 3.14.15-2
Followup-For: Bug #763155

Same thing here:
kernel BUG at 
/build/linux-Lep8DD/linux-3.16.3/drivers/gpu/drm/i915/i915_gem_stolen.c:431!
invalid opcode:  [#1] SMP
EIP is at i915_gem_object_create_stolen_for_preallocated+0x20b/0x280 [i915]

and resulting in a black screen. Today at least SysRq worked, last night that 
didn't work either.

Hardware: ASUS eeePC, similar model, 10something.
Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics 
Controller

Kernel package 3.16-1 works, and so does 3.14-2.

-- Package-specific info:
** Kernel log: boot messages should be attached
** Model information
not available

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Atom Processor 
D4xx/D5xx/N4xx/N5xx DMI Bridge [8086:a010]
Subsystem: ASUSTeK Computer Inc. Device [1043:83ac]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort+ SERR- PERR- INTx-
Latency: 0
Capabilities: access denied
Kernel driver in use: agpgart-intel

00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor 
D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller [8086:a011] (prog-if 00 [VGA 
controller])
Subsystem: ASUSTeK Computer Inc. Device [1043:83ac]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 44
Region 0: Memory at f7e0 (32-bit, non-prefetchable) [size=512K]
Region 1: I/O ports at dc00 [size=8]
Region 2: Memory at d000 (32-bit, prefetchable) [size=256M]
Region 3: Memory at f7d0 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915

00:02.1 Display controller [0380]: Intel Corporation Atom Processor 
D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller [8086:a012]
Subsystem: ASUSTeK Computer Inc. Device [1043:83ac]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Region 0: Memory at f7e8 (32-bit, non-prefetchable) [size=512K]
Capabilities: access denied

00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition 
Audio Controller [8086:27d8] (rev 02)
Subsystem: ASUSTeK Computer Inc. Device [1043:841c]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 45
Region 0: Memory at f7cf8000 (64-bit, non-prefetchable) [size=16K]
Capabilities: access denied
Kernel driver in use: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 
1 [8086:27d0] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
I/O behind bridge: 1000-1fff
Memory behind bridge: 8000-801f
Prefetchable memory behind bridge: 8020-803f
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort+ SERR- PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: access denied
Kernel driver in use: pcieport

00:1c.1 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 
2 [8086:27d2] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=02, subordinate=03, sec-latency=0
I/O behind bridge: 2000-2fff
Memory behind bridge: f800-fbff
Prefetchable memory behind bridge: f000-f6ff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort+ SERR- PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- Reset- FastB2B-
   

Bug#761163: libgl1-mesa-dri: DRI3 causes error messages on i915 driver

[Erich Schubert]

Package: libgl1-mesa-dri
Version: 10.3.0~rc3-1
Severity: minor

Any application using libGL will report the following errors to stderr:

libGL error: Version 4 or later of flush extension not found
libGL error: failed to load driver: i915

The reason is that the i915 driver does not support DRI3 (yet?)
as per upstream bug report:
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=81601

See also:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754297
(Ealier version of this bug, which caused crashes)

The best fix would of course be to add version 4 flush extension to the i915 
driver.
But if this isn't easily possible, there should be some flag indicating that 
this driver
is not DRI3 compatible, and DRI3 should then be disabled without an error (that
sounds as if OpenGL does not work at all).
Maybe DRI3 is only supported for 2D on this graphics board? After all the log 
reports:
 intel(0): direct rendering: DRI2 DRI3 enabled
But the mesa libGL will fail at DRI3.

Setting LIBGL_DRI3_DISABLE=1 makes the error message disappear.

-- Package-specific info:
glxinfo:

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) IGD x86/MMX/SSE2
OpenGL version string: 2.1 Mesa 10.3.0-rc3
OpenGL shading language version string: 1.20
OpenGL extensions:
GL_3DFX_texture_compression_FXT1, GL_AMD_shader_trinary_minmax, 
GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5, 
GL_APPLE_object_purgeable, GL_APPLE_packed_pixels, 
GL_APPLE_vertex_array_object, GL_ARB_ES2_compatibility, 
GL_ARB_clear_buffer_object, GL_ARB_compressed_texture_pixel_storage, 
GL_ARB_copy_buffer, GL_ARB_debug_output, GL_ARB_depth_texture, 
GL_ARB_draw_buffers, GL_ARB_draw_elements_base_vertex, 
GL_ARB_explicit_attrib_location, GL_ARB_explicit_uniform_location, 
GL_ARB_fragment_program, GL_ARB_fragment_shader, 
GL_ARB_framebuffer_object, GL_ARB_get_program_binary, 
GL_ARB_half_float_pixel, GL_ARB_internalformat_query, 
GL_ARB_invalidate_subdata, GL_ARB_map_buffer_alignment, 
GL_ARB_map_buffer_range, GL_ARB_multi_bind, GL_ARB_multisample, 
GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, 
GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_provoking_vertex, 
GL_ARB_robustness, GL_ARB_sampler_objects, GL_ARB_separate_shader_objects, 
GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow, 
GL_ARB_sync, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, 
GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 
GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, 
GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, 

Bug#755065: graphviz: No output formats available - missing /usr/lib/graphviz/config6

[Erich Schubert]

Package: graphviz
Version: 2.38.0-1
Severity: important

dot -Tpng
Format: png not recognized. Use one of:

Apparently, no output formats are available in the current version,
rendering many programs in the package largely useless.

See also:
https://bugs.launchpad.net/ubuntu/+source/graphviz/+bug/1289063

The file /usr/lib/graphviz/config6 does not exist. It should either
be generated during package build, or at postinst time AFAICT.

Indeed: after running dot -c as root, this files was created,
and graphviz works again.

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

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

Versions of packages graphviz depends on:
ii  libc6   2.19-7
ii  libcdt5 2.38.0-1
ii  libcgraph6  2.38.0-1
ii  libexpat1   2.1.0-6
ii  libgcc1 1:4.9.0-9
ii  libgd3  2.1.0-3+b1
ii  libgvc6 2.38.0-1
ii  libgvpr22.38.0-1
ii  libqtcore4  4:4.8.6+dfsg-2
ii  libqtgui4   4:4.8.6+dfsg-2
ii  libstdc++6  4.9.0-9
ii  libx11-62:1.6.2-2
ii  libxaw7 2:1.0.12-2
ii  libxmu6 2:1.1.2-1
ii  libxt6  1:1.1.4-1

Versions of packages graphviz recommends:
pn  fonts-liberation  none

Versions of packages graphviz suggests:
pn  graphviz-doc  none
ii  gsfonts   1:8.11+urwcyr1.0.7~pre44-4.2

-- 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#748519: pepperflashplugin-nonfree: Pepperflash and new chrome

[Erich Schubert]

Package: pepperflashplugin-nonfree
Version: 1.3
Followup-For: Bug #748519

New chrome seems to source /etc/chrome.d/, so adding the same contents to a file
such as /etc/chrome.d/pepperflashplugin-nonfree.sh seems to do the trick.

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

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

Versions of packages pepperflashplugin-nonfree depends on:
ii  binutils   2.24.51.20140604-3
ii  debconf [debconf-2.0]  1.5.53
ii  gnupg  1.4.16-1.1
ii  libatk1.0-02.12.0-1
ii  libcairo2  1.12.16-2
ii  libcurl3-gnutls7.37.0-1+b1
ii  libfontconfig1 2.11.0-5
ii  libfreetype6   2.5.2-1
ii  libgcc11:4.9.0-6
ii  libglib2.0-0   2.41.0-1
ii  libgtk2.0-02.24.23-1
ii  libnspr4   2:4.10.6-1
ii  libnss32:3.16.1-1
ii  libpango-1.0-0 1.36.3-1
ii  libpango1.0-0  1.36.3-1
ii  libstdc++6 4.9.0-6
ii  libx11-6   2:1.6.2-2
ii  libxext6   2:1.3.2-1
ii  libxt6 1:1.1.4-1
ii  wget   1.15-1+b1

pepperflashplugin-nonfree recommends no packages.

Versions of packages pepperflashplugin-nonfree suggests:
ii  chromium   36.0.1985.49-1
pn  halnone
ii  ttf-dejavu 2.34-1
ii  ttf-mscorefonts-installer  3.5
pn  ttf-xfree86-nonfreenone

-- 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#746587: Increasing severity, as this renders systems with NFS unbootable.

[Erich Schubert]

severity 746587 grave
thanks

grave: makes the system deadlock badly on boot.

Patch is available, and should be applied as soon as possible for the
affected versions.

RECOVERY INSTRUCTIONS for other bitten by the same bug:
---
1. in the boot manager, append emergency to your kernel command line
(usually, after ro quiet or similar)
2. log in with the root password
3. run mount -o remount,rw / to make your file system writable
4. edit /etc/network/if-up.d/mountnfs and insert exit 0 early on,
or move the file to a different directory.
5. reboot.
---
I have not re-tested this procedure, but it is supposed to break the deadlock:
Step 4 disables the non-systemd way of automounting NFS.
The provided patch in #746587 is much cleaner, but harder to apply
from the recovery console.


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

Bug#472516: #472516 - gnome-settings-daemon: Should not suggest to load .xmodmaprc~ (backup file)

[Erich Schubert]

Hi,
I don't use Gnome anymore, but I have become a XFCE user, after Gnome
became less and less usable for me.

Feel free to close the bug if you can't reproduce it.
Given that it was reported against gnome 2, don't waste much effort on it.

Bug#740459: Infinite loop reloading dbus service

[Erich Schubert]

Hello Petter,
I can install the 1.16.0-5 package without running into that infinite loop.

I'm really short on time today, so I couldn't check the bug tracker,
if this is already reported. There is another issue with insserv. I
couldn't upgrade initscripts to 2.88dsf-54, because of insserv:
FATAL: service smbd is missed in the runlevels 2 3 4 5 to use service
samba.
This was caused by samba being uninstalled but not purged. Manually
removing /etc/init.d/samba* resolved this installation issue.

insserv should probably be more robust to old/leftover/broken init
scripts and not prevent the installation of unrelated packages.
Maybe this is what triggered the problem the first place, with the
previous version: having an old/outdated init script in /etc/init.d?

Regards,
Erich


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

Bug#548723: gvfs: Crashes in GTK file selectors

[Erich Schubert]

Hello,
It's been so long that I don't remember details about this bug anymore.
I doubt it will be easy to reproduce, as it likely involves uprading
gvfs without restarting.

Feel free to close the bug report.

On Wed, Mar 12, 2014 at 10:05 PM, althaser altha...@gmail.com wrote:
 Hey Erich,

 Could you please still reproduce this issue with newer version like 1.12.3-4
 or 1.16.3-2 ?

 thanks
 regards
 althaser



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

Bug#740459: Infinite loop reloading dbus service

[Erich Schubert]

Package: sysv-rc
Version: 2.88dsf-51
Severity: important

Hi,
Todays upgrade to unstable went into an infinite loop.
It may be related to the libc upgrade, but I can't tell for sure.
The system runs into an infinite loop reloading services, also
on dpkg --configure -a:

insserv: Note: sysvinit service dbus is shadowed by systemd dbus.service,
Forwarding request to '/bin/systemctl --quiet --no-reload enable dbus.service'.
Synchronizing state for dbus.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d dbus defaults
insserv: Note: sysvinit service dbus is shadowed by systemd dbus.service,
Forwarding request to '/bin/systemctl --quiet --no-reload enable dbus.service'.
Synchronizing state for dbus.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d dbus defaults
... repeat.

It appears as if update-rc.d decided to call into insserv, insserv into
systemd, and systemd to call back into update-rc.d; repeat.

By adding an exit 0 into the insserv_updatercd function of update-rc.d,
I was able to break this loop, and run dpkg --configure -a successfully.

Please add a safeguard against cyclic invocation of update-rc.d. Thanks.

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

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

Versions of packages sysv-rc depends on:
ii  debconf [debconf-2.0]  1.5.52
ii  insserv1.16.0-3
ii  sysvinit-utils 2.88dsf-51

Versions of packages sysv-rc recommends:
ii  lsb-base  4.1+Debian12

Versions of packages sysv-rc suggests:
pn  bum   none
pn  sysv-rc-conf  none

-- debconf information:
* sysv-rc/unable-to-convert:
* sysv-rc/convert-legacy: true


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

Bug#740459: Infinite loop reloading dbus service

[Erich Schubert]

Yes, I'm giving systemd a try; so it makes sense to synchronize state
of insserv and systemd.
I tried upgrading packages such as insserv and systemd; I would need
to check the logs if they were already on experimental before the
problem occurred.
Today I only updated to unstable; but I have upgraded packages to
experimental before.

Maybe insserv is the better place to prevent this from happening than
in the shell script.
The shell script was just easier for me to break the cycle. There may
also be an issue involved with cyclic dependencies in insserv; but I
was unable to pinpoint them. insserv output was completely useless in
trying to figure out where the cycle might be, and the additional
tools (visualizing with dotty etc.) also did not yield anything
corresponding to the error messages. In fact, some of the related
services were missing from the dotty plot; I can only assume that
insserv gets some data from systemd, but the visualization tools do
not.


On Sat, Mar 1, 2014 at 10:04 PM, Petter Reinholdtsen p...@hungry.com wrote:
 Control: reassign -1 insserv
 Control: found -1 1.16.0-3

 [Erich Schubert]
 insserv: Note: sysvinit service dbus is shadowed by systemd dbus.service,
 Forwarding request to '/bin/systemctl --quiet --no-reload enable 
 dbus.service'.
 Synchronizing state for dbus.service with sysvinit using update-rc.d...
 Executing /usr/sbin/update-rc.d dbus defaults

 This tell me that you are not using the insserv version in unstable,
 but the one in experimental with systemd integration support.  Are you
 using systemd, or only have it installed?

 Please add a safeguard against cyclic invocation of update-rc.d. Thanks.

 I suspect this should be fixed in insserv, not in update-rc.d.
 Reassigning there.

 --
 Happy hacking
 Petter Reinholdtsen


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

Bug#625762: --geometry causes additional characters in terminal

[Erich Schubert]

notfound 625762 3.10.1-1
thanks

Seems to be gone now. I don't really use gnome-terminal anymore
though. I have become a XFCE user.

On Mon, Feb 17, 2014 at 3:45 PM, althaser altha...@gmail.com wrote:
 Hey,

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

 I couldn't reproduce it with 3.10.1-1.

 thanks
 regards
 althaser



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

Bug#721721: libpostgis-java: Installs incorrect symlink

[Erich Schubert]

Package: libpostgis-java
Version: 2.1.0-1
Severity: normal

libpostgis-java installs the symlink:
/usr/share/java/postgis.jar - postgis-jdbc-2.1.0.jar

but the actual package installed is:
/usr/share/java/postgis-jdbc-2.1.0~rc1.jar

causing a dangling symlink.

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

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

Versions of packages libpostgis-java depends on:
ii  libpostgresql-jdbc-java  9.2-1002-1

libpostgis-java recommends no packages.

Versions of packages libpostgis-java suggests:
pn  postgresql-9.1-postgis-2.1  none

-- 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#720032: grub-probe misdetects filesystem and UUID

[Erich Schubert]

Package: grub-pc
Version: 2.00-17
Severity: important

Grub since version 2.00 is unable to boot (goes to resuce prompt only).
Downgrading to 1.99-27+deb7u1 resolves the problem, so this is a regression.

I've noticed that grub seems to misdetect the filesystem and UUID:
It reports the UUID as 07D6-0A0F, and detects it as fat:

-- grub-probe -vv
... trying various fs, but not ext2/3/4 yet ...
grub-core/kern/fs.c:55: Detecting fat...
07D6-0A0F
--

I believe this bug is another instance of #505137
but I have no idea why this wasn't a problem before.
Maybe grub previously was running the ext2/3/4 test before FAT?

hexdump -Cn 512 /dev/sda1
--
  eb 63 90 00 65 6c 6c 20  38 2e 30 00 02 04 01 00  |.c..ell 8.0.|
0010  02 00 02 00 00 f8 5e 00  3f 00 ff 00 3f 00 00 00  |..^.?...?...|
0020  47 78 01 00 80 00 29 0f  0a d6 07 44 65 6c 6c 55  |Gx)DellU|
0030  74 69 6c 69 74 79 00 41  54 31 36 20 20 20 00 00  |tility.AT16   ..|
0040  00 00 00 00 00 00 00 00  00 00 00 30 33 c0 8e d0  |...03...|
0050  bc 00 07 fc b9 80 00 8e  d8 be 00 80 1d 0d 02 00  ||
0060  00 00 00 00 ff fa 90 90  f6 c2 80 74 05 f6 c2 70  |...t...p|
0070  74 02 b2 80 ea 79 7c 00  00 31 c0 8e d8 8e d0 bc  |ty|..1..|
0080  00 20 fb a0 64 7c 3c ff  74 02 88 c2 52 be 80 7d  |. ..d|.t...R..}|
0090  e8 17 01 be 05 7c b4 41  bb aa 55 cd 13 5a 52 72  |.|.A..U..ZRr|
00a0  3d 81 fb 55 aa 75 37 83  e1 01 74 32 31 c0 89 44  |=..U.u7...t21..D|
00b0  04 40 88 44 ff 89 44 02  c7 04 10 00 66 8b 1e 5c  |.@.D..D.f..\|
00c0  7c 66 89 5c 08 66 8b 1e  60 7c 66 89 5c 0c c7 44  ||f.\.f..`|f.\..D|
00d0  06 00 70 b4 42 cd 13 72  05 bb 00 70 eb 76 b4 08  |..p.B..r...p.v..|
00e0  cd 13 73 0d f6 c2 80 0f  84 d8 00 be 8b 7d e9 82  |..s..}..|
00f0  00 66 0f b6 c6 88 64 ff  40 66 89 44 04 0f b6 d1  |.fd.@f.D|
0100  c1 e2 02 88 e8 88 f4 40  89 44 08 0f b6 c2 c0 e8  |...@.D..|
0110  02 66 89 04 66 a1 60 7c  66 09 c0 75 4e 66 a1 5c  |.f..f.`|f..uNf.\|
0120  7c 66 31 d2 66 f7 34 88  d1 31 d2 66 f7 74 04 3b  ||f1.f.4..1.f.t.;|
0130  44 08 7d 37 fe c1 88 c5  30 c0 c1 e8 02 08 c1 88  |D.}70...|
0140  d0 5a 88 c6 bb 00 70 8e  c3 31 db b8 01 02 cd 13  |.Zp..1..|
0150  72 1e 8c c3 60 1e b9 00  01 8e db 31 f6 bf 00 80  |r...`..1|
0160  8e c6 fc f3 a5 1f 61 ff  26 5a 7c be 86 7d eb 03  |..a.Z|..}..|
0170  be 95 7d e8 34 00 be 9a  7d e8 2e 00 cd 18 eb fe  |..}.4...}...|
0180  47 52 55 42 20 00 47 65  6f 6d 00 48 61 72 64 20  |GRUB .Geom.Hard |
0190  44 69 73 6b 00 52 65 61  64 00 20 45 72 72 6f 72  |Disk.Read. Error|
01a0  0d 0a 00 bb 01 00 b4 0e  cd 10 ac 3c 00 75 f4 c3  |u..|
01b0  00 00 00 00 00 00 00 00  00 c4 1e 48 00 cd 13 72  |...H...r|
01c0  a1 66 ff 06 3e 00 81 06  48 00 00 02 75 06 81 06  |.f.H...u...|
01d0  4a 00 00 10 c3 44 69 73  6b 20 65 72 72 6f 72 00  |JDisk error.|
01e0  4e 6f 20 6c 6f 61 64 65  72 00 44 45 4c 4c 42 49  |No loader.DELLBI|
01f0  4f 20 42 49 4e 00 00 00  00 00 00 00 00 00 55 aa  |O BIN.U.|
0200
--

As you can see, there is some data remaining from the original Dell restore
partition that wasn't properly reset (it is a valid ext2 filesystem though)
The laptop was installed a long time ago (2004?) so I don't remember the
exact details of how I installed Debian then.

Reformatting the partition zeroed out the sector and fixes the detection.
I havn't rebooted yet, so I don't know if this resolved the overall problem
(non-bootable system). For reference, I kept a partition image, if more
information is needed / useful than above sector dump.

-- Package-specific info:

*** WARNING grub-setup left core.img in filesystem

*** BEGIN /proc/mounts
/dev/mapper/cryptroot / ext3 
rw,noatime,errors=remount-ro,barrier=1,data=ordered 0 0
/dev/sda1 /boot ext2 rw,noatime,errors=continue 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-Hitachi_HTS721060G9SA00_MPCCN8Y3H28ZGL
(hd1)   /dev/disk/by-id/usb-Generic_Flash_Disk_17033EBC-0:0
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  load_env
fi
set default=0

if [ x${feature_menuentry_id} = xy ]; then
  menuentry_id_option=--id
else
  menuentry_id_option=
fi

export menuentry_id_option

if [ ${prev_saved_entry} ]; then
  set saved_entry=${prev_saved_entry}
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
  fi
}

Bug#719054: pyroman: Support IPSec protocols (ESP and AH)

[Erich Schubert]

Hello,
Thank your for your patch.
It looks good (and I've already committed it to SVN), however I do get
a warning message when using it:

Warning: never matched protocol: ah. use extension match instead.

As far as I can tell, this happens in ip6tables only, i.e. IPv6.

From a relevant mailing list post:
 -p uses the first non-extension header (which can never
 be AH), while -m ah matches on AH extension headers.

So at least for IPv6 it seems as if -p ah apparently will not have an effect?
From what I've figured out so far, AH will never occur alone. It will
always be ah+esp, and then the protocol match will be for esp?

Could you try if -p esp actually is sufficient to make IPSec work?

Do you know if default ISAKMP will be UDP and source port 500, too?
Right now, I've committed it as dport=isakmp/udp, but if the source
port will also be 500/udp, I would prefer to make the rule tighter by
default.

Regards,
Erich


On Thu, Aug 8, 2013 at 6:06 AM, Wil Tan w...@nivlea.net wrote:
 Package: pyroman
 Version: 0.4.6-4
 Severity: important
 Tags: upstream patch


 There is currently no easy way to add esp and ah protocols in a rule 
 because the
 protocols are not recognized by pyroman.

 This patch allows the following add_service definition:

 add_service(ipsec, dports=esp ah)

 and if used in a rule like:

 allow(client=host1, server=vpnhost, service=ipsec)

 will generate the rules properly.

 I'm reporting the bug against what's installed on this system, but it should
 apply to the latest version in SVN.


 -- System Information:
 Debian Release: 6.0.1
   APT prefers oldstable-updates
   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
 Architecture: i386 (i686)

 Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)

 Versions of packages pyroman depends on:
 ii  iptables1.4.8-3  administration tools for packet 
 fi
 ii  python  2.6.6-3+squeeze7 interactive high-level 
 object-orie
 ii  python-support  1.0.10   automated rebuilding support for 
 P

 pyroman recommends no packages.

 pyroman 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#276545: .xsession-errors is a potential DoS issue?

[Erich Schubert]

Every now and then (e.g. when upgrading the nvidia driver), some
application (e.g. chrome browser) starts misbehaving.
And yes, of course that is the individual applications fault.

However, applications have bugs.

And any such bug - e.g. one that causes a web browser to log a warning
to stderr - can currently be trivially exploited to fill the users
disk.

In my opinion, we need to:
- treat this file like a true log file, in particular:
- allow rotation without having to restart the complete X session
- allow for duplicate filtering ala syslog (the last message repeated
1000 times)
- track for such misbehaviour, and assist the user in cleaning up
before his disk fills.

Xsession shouldn't just blame the applications.

IMHO, the handling of .xsession-errors is a bad misconception in the
first place; passing the descriptor of a single file to every process
in the session is actually quite a bad idea. Xsession *must not*
assume that all these applications are well-behaved, bug-free and
don't write crap to stderr; in particular not without giving the user
an obvious way of clearing the mess at runtime (apparently, you can
recover by doing a
truncate --size 0 $HOME/.xsession-errors
which I havn't tried yet. If you delete the file instead of
truncating, you have to log out and restart your whole Xsession)

And that is the whole point:
While Xsession cannot fix all the broken applications out there, it
should at least have an easy way to recover from a misbehaving
application. Ideally, it would also have some protection (such as:
duplicate detection, rate control) in place against such misbehaving
applications, so this cannot be exploited.

Maybe, instead of passing a file descriptor to the log file to each
application, instead pass a file descriptor of a logger process that
supports SIGUSR1 to reopen the log file and/or pausing the log and/or
duplicate detection.

Regards,
Erich


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

Bug#712569: git-svn should allow working on a subdirectory only

[Erich Schubert]

Package: git-svn
Version: 1:1.8.3.1-1
Severity: wishlist

Essentially, I'd like to be able to sync only a particular folder
with subversion, allowing for a directory layout like this:

project/ --- not synced
project/module-from-svn  --- synced with SVN

It seems as if this should be fairly easy to add for git-svn, and ideally
it could then even allow syncing from multiple SVN modules, and then
eventually allow full svn:externals support (#619584)

For my simple use case, it would be sufficient to checkout SVN into
the specified folder, and only push commits to this folder back to SVN.

I have also seen githelper, which somewhat tries to achieve this:
http://liyanage.github.io/git-tools/

and of course, git subtree is related, but apparently not available in
the Debian package?

Also it seems as if I can try to use a read-tree merge to achieve the
desired results, or filter-branch if I end up doing a one-time migration
only. But overall, I'd prefer a simple option to git-svn that chooses a
different checkout folder...



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

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

Versions of packages git-svn depends on:
ii  git   1:1.8.3.1-1
ii  libsvn-perl   1.7.9-1+nmu2
ii  libterm-readkey-perl  2.30-4+b2
ii  libyaml-perl  0.84-1

git-svn recommends no packages.

Versions of packages git-svn suggests:
pn  git-doc none
ii  subversion  1.7.9-1+nmu2

-- 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#712569: git-svn should allow working on a subdirectory only

[Erich Schubert]

Hello Jonathan,
No, --trunk works the wrong way (but it essentially is the same functionality).
It can be used to strip a prefix off the path of the subversion
repository, but I'd like to add a prefix.
I.e. the module-from-svn is located in /trunk of the SVN, and I'd like
to map it to a subdirectory in git.

Yes, submodules would work, but I want to migrate everything into a
git repository on the long run, and consolidate repositories; not add
in more fragmentation.

Regards,
Erich

On Mon, Jun 17, 2013 at 4:23 PM, Jonathan Nieder jrnie...@gmail.com wrote:
 Hi Erich,

 Erich Schubert wrote:

 Essentially, I'd like to be able to sync only a particular folder
 with subversion, allowing for a directory layout like this:

 project/ --- not synced
 project/module-from-svn  --- synced with SVN

 Do the --trunk/--branches/--tags options help?  Does your git
 repository contains files outside the module-from-svn directory, too?

 In the latter case, I would suggest maintaining the directory from
 svn as a separate git repository, for example as a submodule.  (I
 realize that might be an unsatisfying suggestion when commands like
 git checkout --recurse-submodules and
 git pull --recurse-submodules don't work yet).

 Curious,
 Jonathan


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

Bug#707653: Grub 2.00-14 broken upgrade

[Erich Schubert]

Package: grub-pc
Version: 2.00-14
Followup-For: Bug #707653

Hi,
I believe I was bitten by the same bug. At least I have the same symptoms:
grub in rescue mode, unable to load even the normal module.

I tried grub-install and upgrade-grub, but they did *not* resolve the issue
for me. I now tried dpkg-reconfigure grub-pc as suggested. Judging from
tar --compare with my backup, the files in boot/grub/i386-pc were touched
but not changed, so most likely my next boot still will not work.
But maybe the boot sector was now updated.

For recovery, I had to create a USB boot stick with grub, which would allow
me to boot the system again. Note that I use cryptroot, so maybe it also is
related to the RAID bug report.

One thing that strikes me as odd:
search --no-floppy --fs-uuid --set=root 07D6-0A0F

This number is the output of:
 grub-probe -d -t fs_uuid /dev/sda1
whereas
 tune2fs -l /dev/sda1
reports the UUID 03422ef5-491c-4b05-b0fe-0a22e04e0fd0

So maybe grub has problems with my partition table / mtab?
OTOH, it doesn't actually get that far, it fails to load the normal
module already...

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/disk/by-uuid/9d4d069c-cff2-4568-bcbd-5b0a187b1dda / ext3 
rw,noatime,errors=remount-ro,barrier=1,data=ordered 0 0
/dev/sda1 /boot ext2 rw,noatime,errors=continue 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-Hitachi_HTS721060G9SA00_MPCCN8Y3H28ZGL
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  load_env
fi
set default=0

if [ x${feature_menuentry_id} = xy ]; then
  menuentry_id_option=--id
else
  menuentry_id_option=
fi

export menuentry_id_option

if [ ${prev_saved_entry} ]; then
  set saved_entry=${prev_saved_entry}
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
  fi
}

function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod fat
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  
07D6-0A0F
else
  search --no-floppy --fs-uuid --set=root 07D6-0A0F
fi
font=/grub/unicode.pf2
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=de_DE
  insmod gettext
fi
terminal_output gfxterm
set timeout=5
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod fat
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  
07D6-0A0F
else
  search --no-floppy --fs-uuid --set=root 07D6-0A0F
fi
insmod png
if background_image /grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-9d4d069c-cff2-4568-bcbd-5b0a187b1dda' {
load_video
insmod gzio
insmod part_msdos
insmod fat
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  
07D6-0A0F
else
  search --no-floppy --fs-uuid --set=root 07D6-0A0F
fi
echo'Linux 3.8-1-686-pae wird geladen …'
linux   /vmlinuz-3.8-1-686-pae 
root=UUID=9d4d069c-cff2-4568-bcbd-5b0a187b1dda ro vga=ext i915.modeset=1 
i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 quiet resume=/dev/mapper/cryptswap
echo'Initiale Ramdisk wird geladen …'
initrd  /initrd.img-3.8-1-686-pae
}
submenu 'Erweiterte Optionen für Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-9d4d069c-cff2-4568-bcbd-5b0a187b1dda' {
menuentry 'Debian GNU/Linux, mit Linux 3.8-1-686-pae' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option