Bug#1076370: fortunes: Symbol Lookup Error for rpl_malloc

[Max Görner]

Package: fortunes
Version: 1:1.99.1-7.3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

today I ran a full upgrade of my Debian Testing as part of my daily
routine.

Since then, I cannot run `fortune` anymore. The error message I get is

fortune: symbol lookup error: /lib/x86_64-linux-gnu/librecode.so.0: 
undefined symbol: rpl_malloc

I tried to uninstall and then reinstall `fortunes` and `fortunes-de`,
but to no avail.

Obviously, I'd expect fortunes to work. In particular, I am worried
about the lookup error.

I wouldn't be surprised if the issue belongs to a different package, but
I did not know which.

Best


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

Kernel: Linux 6.9.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fortunes depends on:
ii  fortunes-min  1:1.99.1-7.3

Versions of packages fortunes recommends:
ii  fortune-mod  1:1.99.1-7.3

fortunes suggests no packages.

-- no debconf information

Bug#1074137: org-link-expand-abbrev: Do not evaluate arbitrary unsafe Elisp code (CVE-2024-39331)

[Max Nikulin]

On Wed, 26 Jun 2024 17:24:25 +0700 Max Nikulin wrote:

On Sun, 23 Jun 2024 18:16:27 +0200 Salvatore Bonaccorso wrote:
> 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f4cc61636947b5c2f0afc67174dd369fe3277aa8

Will the fix be backported to bookworm emacs-28 package?


Sorry, I have missed fix for CVE-2024-39331
https://tracker.debian.org/news/1539939/accepted-emacs-12821-15deb12u3-source-into-stable-security/
"Accepted emacs 1:28.2+1-15+deb12u3 (source) into stable-security"


I am surprised by a conclusion for
https://security-tracker.debian.org/tracker/CVE-2024-30202
> [bookworm] - emacs  (Minor issue, will be fixed via point release)


that includes fixes
https://tracker.debian.org/news/1537392/accepted-emacs-12821-15deb12u2-source-into-proposed-updates/
"Accepted emacs 1:28.2+1-15+deb12u2 (source) into proposed-updates"

CVE-2024-30202, CVE-2024-30203, CVE-2024-30204 & CVE-2024-30205

Thank you for this work.

Bug#1074137: org-link-expand-abbrev: Do not evaluate arbitrary unsafe Elisp code (CVE-2024-39331)

[Max Nikulin]

On Sun, 23 Jun 2024 18:16:27 +0200 Salvatore Bonaccorso wrote:

https://www.openwall.com/lists/oss-security/2024/06/23/1

Upstream fix (in org-mode);

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f4cc61636947b5c2f0afc67174dd369fe3277aa8


Will the fix be backported to bookworm emacs-28 package? The change is
local, so risk of unexpected consequences due to the patch should be low.

Severity of the vulnerability should not be lower than for
https://nvd.nist.gov/vuln/detail/CVE-2023-28617


Base Score:  7.8 HIGH
Vector:  CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H


However to exploit that vulnerability a user must invoke an inherently
insecure action. In the case of CVE-2024-39331 it is enough to open a
crafted file or a mail message.

I am surprised by a conclusion for
https://security-tracker.debian.org/tracker/CVE-2024-30202

[bookworm] - emacs  (Minor issue, will be fixed via point release)

that is arbitrary code execution on opening a file or a mail message as
well.

A file may have an almost arbitrary suffix, e.g. a valid python code, so 
activation of Org mode may be unexpected for a user opening some file:


cve-2024-39331.py
 8< 
#!/usr/bin/env python3
# -*- mode: org; -*-
#+link: vuln %(shell-command)
"[[vuln:emacs -Q]]"
#+begin_src python
if __name__ == '__main__':
print("Hello, Org!")
#+end_src
 >8 

It should launch another emacs instance.

I expect that this message is enough to demonstrate the issue since
Gnus calls Org mode preview for any "#+keyword:" and next line in a
text/plain message.

#+link: vuln %(shell-command)
[[vuln:emacs -Q]]

Bug#1069353: plantuml: Re: nncp: FTBFS on arm64: make[1]: *** [debian/rules:21: override_dh_auto_build] Error 1

[Max Nikulin]

On 07/06/2024 18:24, Andrej Shadura wrote:

That was totally a bug in plantuml. My fault that I forgot to merge it
with another bug report for the same issue.


Thanks, Andrej. I see that the package have returned to testing.

I am sorry that I missed https://bugs.debian.org/1068999 I was surprised 
that a working version suddenly disappeared from trixie.

Bug#1069353: plantuml: Re: nncp: FTBFS on arm64: make[1]: *** [debian/rules:21: override_dh_auto_build] Error 1

[Max Nikulin]

On Sat, 20 Apr 2024 14:09:44 +0200 Lucas Nussbaum wrote:

Source: nncp
Severity: serious
Justification: FTBFS

[...]

Caused by: java.lang.RuntimeException: Fontconfig head is null, check your 
fonts or fonts configuration


John, for nncp it was certainly a high priority bug, but why severity is 
the same for plantuml?


Perhaps fonts were missed in nncp build environment, but I am not sure 
that it is a plantuml failure. From my point of view, it should not be a 
reason to remove the package from testing.

Bug#1067630: fixed in emacs 1:29.3+1-1

[Max Nikulin]

On 25/03/2024 15:47, Sean Whitton wrote:

On Mon 25 Mar 2024 at 10:21am +07, Max Nikulin wrote:


On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote:

Source: emacs
Source-Version: 1:29.3+1-1
Done: Rob Browning


Should this issue be reopened or be cloned to backport fixes to Emacs-28 in
Debian stable?


Neither are necessary.


Do you mean that somebody is working on backporting changes to 28.2 in 
bookworm already? This bug is closed. Have I missed other ones for 
elpa-org in unstable and for emacs in stable?

Bug#1067630: fixed in emacs 1:29.3+1-1

[Max Nikulin]

On Mon, 25 Mar 2024 01:13:54 + Debian FTP Masters wrote:

Source: emacs
Source-Version: 1:29.3+1-1
Done: Rob Browning


Should this issue be reopened or be cloned to backport fixes to Emacs-28 
in Debian stable?

Bug#1067630: emacs: release 29.3 fixes "several security vulnerabilities"

[Max Nikulin]

Control: found -1 1:28.2+1-15

On Sun, 24 Mar 2024 16:53:55 -0300 David Bremner wrote:

** Arbitrary Lisp code is no longer evaluated as part of turning on Org mode.
This is for security reasons, to avoid evaluating malicious Lisp code.


Emacs-28 in Debian 12 bookworm requires the fix as well.

Source: org-mode
versions 9.5 and 9.6 till 9.6.23 are affected as well.


** LaTeX preview is now by default disabled for email attachments.
To get back previous insecure behavior, set the variable
'org--latex-preview-when-risky' to a non-nil value.


This one is rather old, so almost certainly even Emacs-26 is affected.
On the other hand its severity is not so high and only users having 
latex packages installed are affected.


See also
Ihor Radchenko to emacs-orgmode… [ANN] Emergency bugfix release: Org 
mode 9.6.23. Sun, 24 Mar 2024 17:16:50 +. 
https://list.orgmode.org/871q7zbldp.fsf@localhost



The fix for LaTeX evaluation requires Emacs 29.3 and will not work for
the earlier Emacs versions. If upgrading Emacs is not viable, as a
workaround, you can set `org-preview-latex-default-process' to 'verbatim
- this will disable LaTeX previews and avoid the vulnerability.

Bug#1056303: pg_createcluster destroys data directory under certain conditions

[Max Kellermann]

Package: postgresql-common
Version: 248
Severity: critical

When I tried to use "pg_createcluster" to configure my pre-existing
PostgreSQL data directory with a new Debian install, it deleted the
whole cluster with all databases instead.  (This serious data loss
justifies "severity critical" according to
https://www.debian.org/Bugs/Developer#severities)

Steps to reproduce:

 pg_createcluster 15 test
 cp /etc/postgresql/15/test/postgresql.conf /var/lib/postgresql/15/test/
 rm -r /etc/postgresql/15/test
 pg_createcluster 15 test

This creates a new cluster just for the demo, then deletes the
configuration directory, after copying the postgresql.conf to the data
directory.

I expect the second "pg_createcluster" call to find the existing data
directory and configure it; and it tries to do so indeed:

 Configuring already existing cluster (configuration: /etc/postgresql/15/test, 
data: /var/lib/postgresql/15/test, owner: 103:111)

After it finds and moves a "postgresql.conf", it however fails to find
"pg_hba.conf"

 Error: move_conffile: required configuration file 
/var/lib/postgresql/15/test/pg_hba.conf does not exist

This fails the whole operation, and apparently, "pg_createcluster"
tries to roll back by invoking "pg_dropcluster 15 test 2>/dev/null",
destroying all pre-existing data.

If "postgresql.conf" does not exist (or is empty), "pg_dropcluster" is
not invoked.

Bug#1042415: ruby-aws-partitions: Package missing partitions.json

[Max Maton]

Package: ruby-aws-partitions
Version: 1.653.0-1
Followup-For: Bug #1042415

This also occurs on bookworm. After manually creating the file I also
had to manually create partitions-metadata.json for the package to work.

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

Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=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 ruby-aws-partitions depends on:
ii  ruby  1:3.1

ruby-aws-partitions recommends no packages.

ruby-aws-partitions suggests no packages.

-- no debconf information

Bug#1035650: elpa-org version older than built-in Org in bookworm

[Max Nikulin]

On 09/05/2023 05:00, Nicholas D Steeves wrote:

It's what at least two users want


Intention of my bug report is to ensure that it was a conscious decision 
to keep a bit outdated Org version. I hope, only a small part of users 
will really notice the difference with built-in version. I consider 
Org-9.6 as desired, but unrealistic, a dummy package as a compromise.



Release notes can
advise the former to remove elpa-org, but we shouldn't advise
elpa-org-contrib users to use 'equivs' to make emacs Provide a virtual
elpa-org.


If you are against equivs then elpa-org dependency must be dropped from 
elpa-org-contrib. Unfortunately the latter requires a change of a 
package in testing.



You're describing the "dummy package" approach.  I was advocating for
the "virtual package" approach (with version-qualified Provides <- this
is key)


There is a minor issue with the dummy package approach. Some (I hope 
rare) users may try to install emacs-27 from bullseye and dummy elpa-org 
(if it would be uploaded to bookworm at all of course) getting Org 
version (emacs built-in) significantly less than they may expect from 
the version of the elpa-org Debian package.


The following consideration are mostly concerning trixie, but still 
might affect current decision.


Adding Org version to emacs-el "Provides" is a reasonable idea since 
org-contrib, at least formally, does not require latest Org release, 
however it is possible that Package-Requires inside the .el file was not 
up to date. So likely org-contrib may be run with built-in Org.


However I think "elpa-org" is a bit confusing name for virtual package. 
Something like emacs-pkg-org in both emacs-el and elpa-org may be better.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033400#25

suggests to not ship Org in the emacs-el Debian package. Certainly it is 
possible to split built-in Org into a separate package and to add it to 
"Recommends" of emacs-el. However it increases maintenance cost while 
benefits are not clear to me. Perhaps it is better to discuss splitting 
in #1033400.


I think, users who relies on latest Org features and fixes, stick to 
other methods than elpa-org Debian package (and sometimes are bitten by 
e.g. package.el bugs). It is another reason to respect Debian release 
policy, but be more carefully with updates in future.

Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Max Kellermann]

On 2023/04/11 17:40, Andreas Henriksson  wrote:
> I think 2 is better myself and I'm attaching a proof of concept
> debdiff to implement it. (You might want to make a cleaner version.)

Agree.  I think your patch looks quite clean, and if it were submitted
to me, I'd merge it (the same would probably be necessary for the user
units).

Maybe I'd go as far and remove the Meson options; they should never
have been there in the first place.  When those options were authored
and submitted to me long ago (in 2011 by commit 83f6498aac), I didn't
know systemd exposes those directories in its pkg-config file.

Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Max Kellermann]

On 2023/04/11 15:11, Andreas Henriksson  wrote:
> The culprit seems to be that mpd falls back on hard-coded path (instead
> of failing) when systemd.pc is not found!

What does this have to do with systemd.pc?  It isn't used anywhere.

Bug#1017164: mpd: FTBFS: ./obj-x86_64-linux-gnu/../src/decoder/plugins/FfmpegIo.cxx:102: undefined reference to `av_malloc(unsigned long)'

[Max Kellermann]

On 2022/08/14 09:16, Lucas Nussbaum  wrote:
> Relevant part (hopefully):
> > /usr/bin/ld: src/decoder/plugins/libdecoder_plugins.a.p/FfmpegIo.cxx.o: in 
> > function `AvioStream::Open()':
> > ./obj-x86_64-linux-gnu/../src/decoder/plugins/FfmpegIo.cxx:102: undefined 
> > reference to `av_malloc(unsigned long)'
> > collect2: error: ld returned 1 exit status

Upstream bug report: https://github.com/MusicPlayerDaemon/MPD/issues/1582

Upstream fix: 
https://github.com/MusicPlayerDaemon/MPD/commit/59792cb0b801854ee41be72d33db9542735df754

Will soon be released as 0.23.9.

Bug#1016363: libx11-6 1.8.1 also breaks glxinfo

[Max Bell]

Why isn't the bug being fixed? That is obviously the correct solution.

On 8/3/22, Richard B. Kreckel  wrote:
> This is issue 157 upstream:
> https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/157
> Apparently, they do not want to revert it.
>
> So, should Debian build with --disable-thread-safety-constructor, at
> least for a while?
>
> (Remember that this bug will soon block other packages from migrating,
> e.g. thunderbird 102.)
>
>   -richy.
> --
> Richard B. Kreckel
> 
>
>

Bug#1016363: More info about the fvwm deadlock with libx11-6 1.8.1

[Max Bell]

Assuming this issue effects only one app is defective. Fix the broken
compatibly with legacy code as this solves it for all programs. And
does not require rewriting an unknown number of apps, that probably
don't have maintainers to fix things, to keep working vs. being
rendered unusable.

On 7/30/22, Jed Davis  wrote:
> FVWM's problem here appears to be that it calls XCheckIfEvent with a
> callback that ends up trying to call XFlush; XCheckIfEvent holds the display
> lock while calling the callback and XFlush also locks the display, causing a
> self-deadlock.  I provoked this by iconifying a window with a key bind, and
> in this case it seems to have something to do with the resulting expose
> events (see stack below).  This reentrancy may not be ideal behavior on
> FVWM's part, but this is code which has (seemingly) worked for a long time.
>
> I also came up with a different workaround: instead of rebuilding libx11, I
> rebuilt FVWM with the following definition added:
>
> Status XInitThreads(void)
> {
> return 0;
> }
>
> The executable precedes its libraries in the symbol search path, so this
> turns off X11 thread safety entirely, but only for fvwm; it doesn't appear
> to use threading, either directly or indirectly, and I'm assuming that
> situation isn't likely to change in the immediate future.  This isn't a
> great solution, but it works for me for now.
>
> If it helps, here's the interesting part of the stack trace from the
> deadlock:
>
> #3  0x7f01a975a968 in _XLockDisplay (dpy=0x55ca735f4090) at
> ../../src/locking.c:466
> #4  0x7f01a974e5c2 in XFlush (dpy=0x55ca735f4090) at
> ../../src/Flush.c:38
> #5  0x55ca7248be1b in dispatch_event (e=0x55ca736ec2f8) at
> events.c:4105
> #6  0x55ca7248c0cc in _pred_weed_handle_expose (display=,
> event=, arg=) at events.c:266
> #7  0x55ca724ff3b9 in _fev_pred_weed_if (display=,
> event=0x55ca736ec2f8, arg=0x7ffebc6870a0 "\260\300Hr\312U") at FEvent.c:176
> #8  0x55ca724ff43f in _fev_pred_check_peek (display=,
> event=0x55ca736ec2f8, arg=0x7ffebc686fb0 "p\363Or\312U") at FEvent.c:144
> #9  0x7f01a97489aa in XCheckIfEvent (dpy=0x55ca735f4090,
> event=event@entry=0x7ffebc686ef0, predicate=predicate@entry=0x55ca724ff420
> <_fev_pred_check_peek>, arg=arg@entry=0x7ffebc686fb0 "p\363Or\312U") at
> ../../src/ChkIfEv.c:59
> #10 0x55ca724ffdc0 in FCheckPeekIfEvent (display=,
> event_return=event_return@entry=0x7ffebc6870e0,
> predicate=predicate@entry=0x55ca724ff370 <_fev_pred_weed_if>,
> arg=arg@entry=0x7ffebc6870a0 "\260\300Hr\312U") at FEvent.c:590
> #11 0x55ca724fff17 in FWeedIfEvents (display=,
> weed_predicate=weed_predicate@entry=0x55ca7248c0b0
> <_pred_weed_handle_expose>, arg=arg@entry=0x0) at FEvent.c:527
> #12 0x55ca7248cfba in handle_all_expose () at events.c:4545
> #13 0x55ca724be911 in __raise_or_lower_window (t=t@entry=0x55ca7361c250,
> mode=mode@entry=SM_RAISE, allow_recursion=allow_recursion@entry=1,
> is_new_window=is_new_window@entry=0,
> is_client_request=is_client_request@entry=0) at stack.c:1141
>
> --Jed
>
>

Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid

[Max Kellermann]

On 2021/11/05 08:09, Max Kellermann  wrote:
> I gave this a second thought, and I fear that changes like this one
> break even more setups, which should be avoided in a stable branch.
> 
> I'll rather revert the "RuntimeDirectory" addition for now in the
> 0.23.x stable branch.

And this is the result of my third thought:

 
https://github.com/MusicPlayerDaemon/MPD/commit/a4e42172045f62583cbf97a6a94c3d2b9de77a6c

This keeps RuntimeDirectory, but "fixes" the pid_file problem (by
ignoring the useless pid_file setting).

Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid

[Max Kellermann]

On 2021/11/05 06:10, Max Kellermann  wrote:
> On 2021/11/05 05:55, Florian Schlichting  wrote:
> > However, Max: behind this hides another problem, which is why I asked
> > Ryan to delete the pid_file configuration: as part of 0.23.3 you added
> > the "RuntimeDirectory=mpd" directive to both mpd.service units. In the
> > absence of User and Group directives, this causes /run/mpd to change
> > ownership from mpd:audio (as created by our
> > /usr/lib/tmpfiles.d/mpd.conf) to root:root, which means that mpd would
> > have to be run as root in order to be able to create a socket or a
> > pidfile (yes, legacy) there. I think that's broken from an upstream
> > perspective as well, and only works when running mpd as user.
> 
> True, and the real fix would be to finally cease launching MPD as
> root, which is an anachronism.

I gave this a second thought, and I fear that changes like this one
break even more setups, which should be avoided in a stable branch.

I'll rather revert the "RuntimeDirectory" addition for now in the
0.23.x stable branch.

The RuntimeDirectory will be re-added to the to-become-0.24 branch,
together with lots of other changes to modernize MPD with systemd (no
root startup, a StateDirectory for the state file, CacheDirectory for
the database file etc.)

Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid

[Max Kellermann]

On 2021/11/05 05:55, Florian Schlichting  wrote:
> However, Max: behind this hides another problem, which is why I asked
> Ryan to delete the pid_file configuration: as part of 0.23.3 you added
> the "RuntimeDirectory=mpd" directive to both mpd.service units. In the
> absence of User and Group directives, this causes /run/mpd to change
> ownership from mpd:audio (as created by our
> /usr/lib/tmpfiles.d/mpd.conf) to root:root, which means that mpd would
> have to be run as root in order to be able to create a socket or a
> pidfile (yes, legacy) there. I think that's broken from an upstream
> perspective as well, and only works when running mpd as user.

True, and the real fix would be to finally cease launching MPD as
root, which is an anachronism.

> I suppose the best way forward is to specify User=mpd and Group=audio
> in the system unit, however this immediately hits a snag when mpd tries
> to open its log file /var/log/mpd/mpd.log, which up to now is created as
> root. This we could probably work around in Debian, and defaulting to
> log to syslog/journal also feels sensible, but I'm not sure if there may
> be other things that mpd might want to be root for when starting up as a
> system service?

The right way to have a writable /var/log/mpd is "LogsDirectory=mpd",
but I don't want to do that.  Per-daemon log files are an anachronism,
too.  Just like starting daemons as root, PID files, per-daemon
daemonization code and so on ... all the good stuff that systemd can
do for us, stuff which in ancient times every daemon had unnecessary
duplicate code for.

Another thing that MPD could fail if we don't launch MPD as root is
binding to "privileged ports" (another anachronism).  For example, a
httpd streaming output could be bound to a low port.  People who do
that could add a drop-in with
"AmbientCapabilities=CAP_NET_BIND_SERVICE" to give MPD permission for
that.

Bug#994033: mpd: Fails to find ldd libraries from libraspberrypi0 that have moved

[Max Kellermann]

On 2021/09/10 11:43, Tim Phipps  wrote:
> AN upgrade to rasbian stable ahs moved some ldd files included in the 
> libraspberrypi0 packages and now mpd fails to start.

MPD doesn't use any of these libraries.  These are indirect
dependencies, maybe via FFmpeg?  In any case, this is not a MPD
packaging problem.

Bug#990263: podman sets oom_score_adj to -1000 for processes inside the

[Max Bruckner]

I just found the bug and the fix! It's not in podman but in conmon!

See https://github.com/containers/conmon/releases/tag/v2.0.29 and
https://github.com/containers/conmon/commit/b033cb5dfde6de05e63408fc839f1bb641cddd85


On Tue, 29 Jun 2021 00:08:48 +0900 Hideki Yamane  wrote:
>  Well, I've tested it too with bullseye on KVM and reproduced it, however,
>  it's only under root privilege. Just run "$ podman run -it --rm debian sh"
>  via normal user and it returns 0.

Yes, when running as normal user it just doesn't have the permissions to set 
negative OOM score adjustments, that's why
it's 0.

>  And also tested with my daily driver unstable system I cannot reproduce it.
>  (But sid on KVM can reproduce it, hmm...)

Probably because it's the conmon version that matters. I can reproduce it on 
Archlinux as well by downgrading conmon to
2.0.28
 
>  It may be better to downgrade as important if it's only root privilege, IMO.

I'm new to debian bug reports and only saw the "breaks the whole system" 
criterium in the list that "reportbug" printed.
So feel free to downgrade. Not sure if I have the permission to do so as the 
bug reporter, but if so I don't even know
how to.

Bug#990263: podman sets oom_score_adj to -1000 for processes inside the container so the system breaks in OOM situations

[Max Bruckner]

Package: podman
X-Debbugs-Cc: m...@doo.shop
Version: 3.0.1+dfsg1-2+b2
Severity: critical
Justification: breaks the whole system
Tags: newcomer

Dear Maintainer,

when processes inside a podman container consume all the available
memory, system processes start to get killed instead of the process
inside of the container. This is because podman in this version seems to
set an oom_score_adj value of -1000 for all processes inside the
container.

Marked as critical because what would normally just result in a process
being killed by the OOM reaper now affects the entire system to the
point that it isn't accessible via SSH anymore.

This seems to be fixed at least in podman 3.2.1 (tested on Archlinux) but I 
haven't found a
respective entry in the upstream release notes, so I don't know what version
actually made the fix. I also don't know if the problem is in podman
itself or one of it's dependencies or if it is in the upstream version at all.

How to reproduce:

```
# podman run -it --rm debian sh
# cat /proc/$$/oom_score_adj
-1000
```

I would expect this to show 0 for the oom_score_adj value.

I tried to work around this problem, by passing --oom-score-adj=0 to the
podman command, but with no effect (this might be the same bug or
related to a different one.

```
# podman run -it --rm --oom-score-adj=0 debian sh
# cat /proc/$$/oom_score_adj
-1000
```

What DOES work however is setting a nonzero value:

```
# podman run -it --rm --oom-score-adj=1 debian sh
# cat /proc/$$/oom_score_adj
1
```

This is probably related to a typical golang programming error where 0
values are interpreted as "absence of a value" and a default fallback is
used, but this is just a guess.


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages podman depends on:
ii  conmon   2.0.25+ds1-1
ii  containernetworking-plugins  0.9.0-1+b5
ii  crun 0.17+dfsg-1
ii  golang-github-containers-common  0.33.4+ds1-1
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.31-12
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libgpgme11   1.14.0-1+b2
ii  libseccomp2  2.5.1-1

Versions of packages podman recommends:
pn  buildah   
pn  catatonit | tini | dumb-init  
pn  fuse-overlayfs
pn  golang-github-containernetworking-plugin-dnsname  
pn  slirp4netns   
pn  uidmap

Versions of packages podman suggests:
pn  containers-storage  
pn  docker-compose  

-- no debconf information

Bug#984520: Having the same issue

[Max Resnick]

Hello - I also had this issue with a recent update. I had to boot to rescue and 
force install grub and bootloader.  

It's a laptop with single NVMe hard drive with lvm and luks setup by the 
default debian install. 

I think this previously happened in the past year.

What can I do to help? I didn't keep logs. 

Bug#977890: libcinnamon-menu-3-0: Upgrade

[Max Minenko]

I have the same issue. Only Alt + F2 and keyboard shortcuts work.
The (cinnamon) menu doesn't do anything.

-- 
Regards,
Max Minenko

Bug#969436: Fixing wrong changelog entry

[Keith Max]

Hi guys, This small mess has been existing couple of days now. Is it possible to fix this package please? There are a bunch of packages stuck in unstable because of this situation this package is in. If I'm correct, the changelog of -2 closed the wrong bug number. Then the wrong changelog entry was fixed on the source repo, but no new upload was made to unstable with the actual corrected changelog. So based on the previous upload inlcuding the wrong changelog the BTS has determined that this serious bug is still applicable to current upload. Is it possible to do a corrected upload please to correct the changelog also in the actual package, not just in the source repo? Thanks,Keith

Bug#939937: Acknowledgement (Remotely exploitable null pointer dereference bug)

[Max Kellermann]

I committed my patch to libapreq's Subversion repository:

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

Bug#939937: Remotely exploitable null pointer dereference bug

[Max Kellermann]

Package: libapreq2-3
Version: 2.13-5+b3
Severity: grave

libapreq's multipart parser can be made dereference the null pointer
by issuing a simple CURL command:

 curl http://a/b -F 'foo=bar;type=multipart/dummy'

This POSTs a "multipart/form-data" body where one part has the
Content-Type "multipart/dummy" (i.e. a nested "multipart"), which
enables this branch:

 if (ct != NULL && strncmp(ct, "multipart/", 10) == 0) {

 https://github.com/apache/apreq/blob/v2_13/library/parser_multipart.c#L401

Later, this calls create_multipart_context() and dereferences the
returned pointer (without checking it):

 next_ctx = create_multipart_context(...
 next_ctx->param_name = "";

 https://github.com/apache/apreq/blob/v2_13/library/parser_multipart.c#L409-L414

The function create_multipart_context() however can return NULL if
there is no "boundary" attribute.  And omitting "boundary" is what my
CURL command does.

With this simple exploit, I can remotely crash any process which uses
libapreq2 only by issuing an invalid nested "multipart" body.  Since
this bug is remotely exploitable, I decided to set "grave" severity.

This bug affects all libapreq2 versions ever shipped in Debian, and
was introduced by SVN commit 227276 in 2005.  Prior to this commit,
there was a NULL check, but the commit removed it:

 
http://svn.apache.org/viewvc/httpd/apreq/trunk/library/parser_multipart.c?r1=227276=227275=227276

The attached patch fixes the bug by re-adding the NULL check.
commit f27d15e47000b0442e8071ab0fd76b82df9f2d2f
Author: Max Kellermann 
Date:   Tue Sep 10 12:15:07 2019 +0200

parser_multipart: fix NULL pointer dereference in nested multipart

create_multipart_context() can return NULL if the given Content-Type
was not recognized (if there is no "boundary" attribute).  This
crashes libapreq2.

This bug was introduced by SVN commit 227276.  Prior to this commit,
there was a NULL check, but the commit removed it:

 http://svn.apache.org/viewvc/httpd/apreq/trunk/library/parser_multipart.c?r1=227276=227275=227276

diff --git a/library/parser_multipart.c b/library/parser_multipart.c
index 60b5bad..4242b7e 100644
--- a/library/parser_multipart.c
+++ b/library/parser_multipart.c
@@ -410,6 +410,10 @@ APREQ_DECLARE_PARSER(apreq_parse_multipart)
 parser->brigade_limit,
 parser->temp_dir,
 ctx->level + 1);
+if (next_ctx == NULL) {
+ctx->status = MFD_ERROR;
+goto mfd_parse_brigade;
+}
 
 next_ctx->param_name = "";
 

Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found

[Max Hofer]

Am Dienstag, 30. Juli 2019, 01:21:43 CEST schrieb Jiri Palecek:
> On 29. 07. 19 22:12, Max Hofer wrote:
> >> I was also hit by this bug after upgrading yesterday (it has been few
> >> weeks since I updated the machine). Just like others, I also had to
> >> downgrade the following packages to 2.02 to get it working.
> >> 
> >> 1. grub-common
> >> 2. grub2-common
> >> 3. grub-efi-amd64-bin
> >> 4. grub-efi-amd64
> >> 5. grub-pc-bin
> > 
> > I hit the same problem today. Could you please provide the information,
> > how you downgraded the packages on a non bootable system?
> 
> You gotta find something that boots. Either installation pendrive or CD,
> or live CD or another disc. Then mount your regular disk as in
> somedirectory, mount /proc, /sys, /dev in somedirectory, chroot into
> somedirectory and then it is a simple matter for apt. (You may have to
> edit sources.list)
> 
> I went through it with my qemu images.
> 
> Regards
> 
>  Jiri Palecek
Thx for pointing me in the right direction, I was able to fix my problem.

It seems my system broke because the install_devices was configured to the 
partition and not the device.

$ lsblk --output NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT,PTTYPE,MODEL
NAME   TYPE   SIZE FSTYPE MOUNTPOINT PTTYPE MODEL
sdadisk 232.9G   dosSamsung_SSD_840_EVO_250GB
├─sda1 part   333M ext4   /  dos
├─sda2 part 1K   dos
├─sda5 part   8.4G btrfs  /usr   dos
├─sda6 part   2.8G btrfs  /var   dos
├─sda7 part  27.7G swap   [SWAP] dos
├─sda8 part   380M btrfs  /tmp   dos
└─sda9 part 193.4G btrfs  /home  dos

# Configuration which broke my system with the upgrade from 2.02 to 2.04
$ sudo debconf-show grub-pc|grep install_devices:
* grub-pc/install_devices: /dev/disk/by-id/ata-
Samsung_SSD_840_EVO_250GB_S1DBNSADC65873B-part1

# Configuration which worked when I upgraded from 2.02 to 2.04
$ sudo debconf-show grub-pc|grep install_devices:
* grub-pc/install_devices: /dev/disk/by-id/ata-
Samsung_SSD_840_EVO_250GB_S1DBNSADC65873B

I vaguely remember that one of the grub upgrades (a long time ago) asked me if 
I would like to change the installation location but as far as I remember I 
never changed it.

Regards
Max

Bug#931896: grub-efi-amd64: symbol `grub_file_filters` not found

[Max Hofer]

> I was also hit by this bug after upgrading yesterday (it has been few
> weeks since I updated the machine). Just like others, I also had to
> downgrade the following packages to 2.02 to get it working.
>
> 1. grub-common
> 2. grub2-common
> 3. grub-efi-amd64-bin
> 4. grub-efi-amd64
> 5. grub-pc-bin

I hit the same problem today. Could you please provide the information, how you 
downgraded the packages
on a non bootable system?

Regards
Max

Bug#917593: mpd: FTBFS ('_IO_off64_t' has not been declared)

[Max Kellermann]

On 2018/12/29 01:25, Santiago Vila  wrote:
> In file included from /usr/include/libroar/libroar.h:173,
>  from /usr/include/roaraudio.h:133,
>  from src/output/plugins/RoarOutputPlugin.cxx:36:
> /usr/include/libroar/vio_stdio.h:50:46: error: '_IO_off64_t' has not been 
> declared
>  int roar_vio_to_stdio_lseek (void *__cookie, _IO_off64_t *__pos, int __w);

This is clearly a libroar bug and has nothing to do with MPD.

Upstream bug report (for MPD):
https://github.com/MusicPlayerDaemon/MPD/issues/377

See https://github.com/MusicPlayerDaemon/MPD/commit/06ca08ce555 for my
opinion on this bug.

Bug#914457: icingacli: any command issued to icingacli rise an exception

[Max]

Package: icingacli
Version: 2.6.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

an example: 

icingacli --help

Fatal error: Uncaught ErrorException: "continue" targeting switch is equivalent 
to "break". Did you mean to use "continue 2"? in 
/usr/share/php/Icinga/File/Ini/IniParser.php:67
Stack trace:
#0 /usr/share/php/Icinga/Application/ClassLoader.php(303): 
Icinga\Application\ApplicationBootstrap->Icinga\Application\{closure}(2, 
'"continue" targ...', '/usr/share/php/...', 67, Array)
#1 /usr/share/php/Icinga/Application/ClassLoader.php(303): require()
#2 [internal function]: 
Icinga\Application\ClassLoader->loadClass('Icinga\\File\\Ini...')
#3 /usr/share/php/Icinga/Application/Config.php(326): 
spl_autoload_call('Icinga\\File\\Ini...')
#4 /usr/share/php/Icinga/Application/Config.php(397): 
Icinga\Application\Config::fromIni('/etc/icingaweb2...')
#5 /usr/share/php/Icinga/Application/ApplicationBootstrap.php(522): 
Icinga\Application\Config::app()
#6 /usr/share/php/Icinga/Application/Cli.php(39): 
Icinga\Application\ApplicationBootstrap->loadConfig()
#7 /usr/share/php/Icinga/Application/ApplicationBootstrap.php(369): 
Icinga\Application\Cl in /usr/share/php/Icinga/File/Ini/IniParser.php on line 67


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

Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages icingacli depends on:
ii  adduser 3.118
ii  php-icinga  2.6.1-1

Versions of packages icingacli recommends:
ii  php7.2-cli [php-cli]  7.2.9-1
ii  php7.3-cli [php-cli]  7.3.0~rc4-1

Versions of packages icingacli suggests:
ii  icingaweb2-module-monitoring  2.6.1-1

-- no debconf information

Bug#912600: glibc-source: spin-lock.h not found when building

[Max]

Package: glibc-source
Version: 2.24-11+deb9u3
Severity: serious
Justification: fails to build from source (but built successfully in the past)



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

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

glibc-source depends on no packages.

Versions of packages glibc-source recommends:
ii  xz-utils  5.2.2-1.2+b1

glibc-source suggests no packages.

-- no debconf information

I've followed the instructions in the INSTALL file, at the step when I run make 
in the build directory, I got this problem:

In file included from libpthread/include/pthread/pthreadtypes.h:95:0,
 from libpthread/sysdeps/pthread/bits/pthreadtypes.h:27,
 from ./posix/sys/types.h:270,
 from include/sys/types.h:1,
 from misc/sys/uio.h:23,
 from :3:
libpthread/sysdeps/pthread/bits/condition.h:23:28: fatal error: 
bits/spin-lock.h: No such file or directory
 #include 

Bug#810295: WARNING: Serious error when reading debug info

[Max Dmitrichenko]

Package: valgrind
Version: 1:3.11.0-1
Followup-For: Bug #810295

Please find a debdiff in attachment. Backported from the upstream.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages valgrind depends on:
ii  libc6  2.22-11
ii  libc6-dbg  2.22-11

Versions of packages valgrind recommends:
ii  gdb   7.10-1.1
ii  valgrind-dbg  1:3.11.0-1

Versions of packages valgrind suggests:
pn  alleyoop  
pn  kcachegrind   
pn  valgrind-mpi  
pn  valkyrie  

-- no debconf information
diff -Nru valgrind-3.11.0/debian/changelog valgrind-3.11.0/debian/changelog
--- valgrind-3.11.0/debian/changelog	2015-09-25 11:41:20.0 +
+++ valgrind-3.11.0/debian/changelog	2016-06-19 00:01:35.0 +
@@ -1,3 +1,10 @@
+valgrind (1:3.11.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add 15_compressed.patch - support compressed debug info (closes: #810295)
+
+ -- Max Dmitrichenko <dmitr...@gmail.com>  Sat, 18 Jun 2016 23:32:04 +
+
 valgrind (1:3.11.0-1) unstable; urgency=medium
 
   * New upstream release (Closes: #800013)
diff -Nru valgrind-3.11.0/debian/patches/15_compressed.patch valgrind-3.11.0/debian/patches/15_compressed.patch
--- valgrind-3.11.0/debian/patches/15_compressed.patch	1970-01-01 00:00:00.0 +
+++ valgrind-3.11.0/debian/patches/15_compressed.patch	2016-06-19 00:19:52.0 +
@@ -0,0 +1,1990 @@
+--- a/NEWS
 b/NEWS
+@@ -36,6 +36,10 @@
+ * Intel AVX2 support is more complete (64 bit targets only).  On AVX2
+   capable hosts, the simulated CPUID will now indicate AVX2 support.
+ 
++* Valgrind is able to read compressed debuginfo sections in two formats:
++  - zlib ELF gABI format with SHF_COMPRESSED flag (gcc option -gz=zlib)
++  - zlib GNU format with .zdebug sections (gcc option -gz=zlib-gnu)
++
+ *  TOOL CHANGES 
+ 
+ * Memcheck:
+@@ -197,6 +201,7 @@
+ 269360  s390x: Fix addressing mode selection for compare-and-swap
+ 302630  Memcheck: Assertion failed: 'sizeof(UWord) == sizeof(UInt)'
+ == 326797
++303877  valgrind doesn't support compressed debuginfo sections
+ 312989  ioctl handling needs to do POST handling on generic ioctls and [..]
+ 319274  Fix unhandled syscall: unix:410 (sigsuspend_nocancel) on OS X
+ 324181  mmap does not handle MAP_32BIT (handle it now, rather than fail it)
+--- a/configure.ac
 b/configure.ac
+@@ -1202,6 +1202,11 @@
+ ])
+ 
+ 
++# Check for ELF32/64_CHDR
++ 
++AC_CHECK_TYPES([Elf32_Chdr, Elf64_Chdr], [], [], [[#include ]])
++
++
+ # Check for PTHREAD_RWLOCK_T
+ 
+ AC_MSG_CHECKING([for pthread_rwlock_t])
+@@ -2076,6 +2081,45 @@
+ CFLAGS=$safe_CFLAGS
+ 
+ 
++# does this compiler support -g -gz=zlib ?
++
++AC_MSG_CHECKING([if gcc accepts -g -gz=zlib])
++
++safe_CFLAGS=$CFLAGS
++CFLAGS="-g -gz=zlib"
++
++AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ ]], [[
++  return 0;
++]])], [
++ac_have_gz_zlib=yes
++AC_MSG_RESULT([yes])
++], [
++ac_have_gz_zlib=no
++AC_MSG_RESULT([no])
++])
++AM_CONDITIONAL(GZ_ZLIB, test x$ac_have_gz_zlib = xyes)
++CFLAGS=$safe_CFLAGS
++
++
++# does this compiler support -g -gz=zlib-gnu ?
++
++AC_MSG_CHECKING([if gcc accepts -g -gz=zlib-gnu])
++
++safe_CFLAGS=$CFLAGS
++CFLAGS="-g -gz=zlib-gnu"
++
++AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ ]], [[
++  return 0;
++]])], [
++ac_have_gz_zlib_gnu=yes
++AC_MSG_RESULT([yes])
++], [
++ac_have_gz_zlib_gnu=no
++AC_MSG_RESULT([no])
++])
++AM_CONDITIONAL(GZ_ZLIB_GNU, test x$ac_have_gz_zlib_gnu = xyes)
++CFLAGS=$safe_CFLAGS
++
+ # does this compiler support nested functions ?
+ 
+ AC_MSG_CHECKING([if gcc accepts nested functions])
+@@ -3386,6 +3430,9 @@
+ ])
+ AM_CONDITIONAL(SOLARIS_RESERVE_SYSSTAT_ZONE_ADDR, test x$solaris_reserve_sysstat_zone_addr = xyes)
+ 
++AC_CHECK_TYPES([Elf32_Chdr, Elf64_Chdr], [], [], [[#include ]])
++
++
+ else
+ AM_CONDITIONAL(SOLARIS_SUN_STUDIO_AS, false)
+ AM_CONDITIONAL(SOLARIS_XPG_SYMBOLS_PRESENT, false)
+--- a/coregrind/Makefile.am
 b/coregrind/Makefile.am
+@@ -348,6 +348,7 @@
+ 	m_debuginfo/readmacho.c \
+ 	m_debuginfo/readpdb.c \
+ 	m_debuginfo/storage.c \
++	m_debuginfo/tinfl.c \
+ 	m_debuginfo/tytypes.c \
+ 	m_demangle/cp-demangle.c \
+ 	m_demangle/cplus-dem.c \
+--- a/coregrind/m_debuginfo/image.c
 b/coregrind/m_debuginfo/image.c
+@@ -45,6 +45,8 @@
+ #include "priv_image.h"/* self */
+ 
+ #include "minilzo.h"
++#define TINFL_HEADER_FILE_ONLY
++#include "tinfl.c"
+ 
+ /* These values (1024 entries of 8192 bytes each) gives a cache
+size of 8MB. */
+@@ -53,15 +55,29 @@
+ 
+ #define CACHE_ENTRY_SIZE  (1 << CACHE_ENTRY_SIZE_BITS)
+ 
++#define COMMPRESSED_SLICE_ARRAY_GROW_SIZE 64
++
+ /* An entry in the cache. */
+ typedef
+struct 

Bug#822401: [mpd-devel] [Pkg-mpd-maintainers] Bug#822401: mpd: FTBFS: error: 'uint8_t' was not declared in this scope

[Max Kellermann]

On 2016/04/24 22:00, Florian Schlichting  wrote:
> This seems to be caused by a lacking include, fixed by the below patch.

Merged.

Bug#800462: sddm-theme-maui: updating results in WHITE SCREEN and beeing unable to login

[Max Görner]

Package: sddm-theme-maui
Version: 0.12.0-4
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

today I updated my version of sddm-theme-maui. After logging off and
after rebooting the monitor is all white and I can't login anymore. I
tried to login blindly which wasn't sucessful.

   * What led up to the situation?
 I updated from 0.11.0-6 (or something alike) to 0.12.0-4 (or
 something alike).
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I can't login anymore, therefore I couldn't do anything.

Please contact me if you need more information.

sincerely,
Max Görner

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

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

sddm-theme-maui depends on no packages.

Versions of packages sddm-theme-maui recommends:
ii  sddm  0.11.0-3

sddm-theme-maui suggests no packages.

-- no debconf information

Bug#767504: [Pkg-mpd-maintainers] Bug#767504: mpd: licence clash with libmp4v2 (MPL) and mpd GPL-+2

[Max Kellermann]

On 2014/11/02 21:16, Max Kellermann m...@duempel.org wrote:
 This copyright problem must be resolved by a license change of
 libmp4v2.  If no solution appears possible on their side, the plugin
 will be removed from the next MPD release.

The plugin has been removed from MPD 0.19.5, because no solution was
in sight.


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

Bug#767504: [Pkg-mpd-maintainers] Bug#767504: mpd: licence clash with libmp4v2 (MPL) and mpd GPL-+2

[Max Kellermann]

On 2014/11/02 21:10, Florian Schlichting f...@debian.org wrote:
 or the mpd authors would need to give permission to link mpd against
 libmp4v2

That will not work.  It would require permission from each and every
MPD contributor, which is nearly 200 people.

This copyright problem must be resolved by a license change of
libmp4v2.  If no solution appears possible on their side, the plugin
will be removed from the next MPD release.

(I was not aware of this licensing problem when I merged the plugin.)

Max


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

Bug#759939: makepp: FTBFS: tests failed

[Max Vozeler]

Hi everyone,

I can reproduce the failure and confirmed that tests succeed with the
new upstream release, which I'll upload shortly.

Thanks,

Max


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

Bug#739410: mpd: new version fails to update with apt-get update

[Max Kellermann]

On 2014/02/18 12:31, Sharon Kimble boudic...@talktalk.net wrote:
 Tried to update to version 0.18.8-1 today and it fails to install giving a 
 dpkg
 error code of 1.

It appears your /etc/default/mpd contains garbage that belongs in
/etc/mpd.conf, but I don't see anything in the new package that would
cause garbage to be added to /etc/default/mpd.  Are you sure this was
added by the package and not by yourself?  What does your
/etc/default/mpd look like?


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

Bug#739410: mpd: new version fails to update with apt-get update

[Max Kellermann]

On 2014/02/18 13:06, Sharon Kimble boudic...@talktalk.net wrote:
 On Tue, 18 Feb 2014 12:40:23 +0100
 Max Kellermann m...@duempel.org wrote:
 
  On 2014/02/18 12:31, Sharon Kimble boudic...@talktalk.net wrote:
   Tried to update to version 0.18.8-1 today and it fails to install
   giving a dpkg error code of 1.
  
  It appears your /etc/default/mpd contains garbage that belongs in
  /etc/mpd.conf, but I don't see anything in the new package that would
  cause garbage to be added to /etc/default/mpd.  Are you sure this was
  added by the package and not by yourself?  What does your
  /etc/default/mpd look like?
 
 I've attached my /etc/default/mpd = blank, not used, /etc/mpd.conf =
 blank, not used, and /home/$USER/cron/conf/mpd.conf = which is used. 

Not true.  Your /etc/default/mpd is not blank.  It contains the same
data as your mpd.conf, which is a mistake.  This cannot work.

This bug report is bogus, unless you can demonstrate the the package
has wrongfully copied your /etc/mpd.conf to /etc/default/mpd.


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

Bug#728186: (no subject)

[Max]

Hi, I don't have this problem on debian 7 stable

Max


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

Bug#735261: (no subject)

[max]

Hi, I'm not sure if your problem is like mine

using kmail with imap, I see coming new messages and suddenly disappear 
it.. so I lost messages...


this keep kmail useless

thanks for help

--
Max


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

Bug#689205: STILL app-install-data and goldendict: error when trying to install together

[Max Ramirez]

Hi,

I've tried yesterday and today to update this package and the bug persist:

Unpacking replacement goldendict ...
dpkg: error processing
/var/cache/apt/archives/goldendict_1.0.2~git20120929-2_amd64.deb (--unpack):
 trying to overwrite '/usr/share/app-install/desktop/goldendict.desktop',
which is also in package app-install-data 2012.06.16.1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for menu ...
Processing triggers for packagekit-backend-aptcc ...
Errors were encountered while processing:
 /var/cache/apt/archives/goldendict_1.0.2~git20120929-2_amd64.deb


-- 
Cheers,
Max Ramirez G.

Bug#555168: Unclear license situation for (e)glibc locales provided by you

[Max Kutny]

Definitely I'm ok with the new license.

-- Max


On Tue, Jul 3, 2012 at 12:30 AM, Volodymyr M. Lisivka
vlisi...@gmail.com wrote:
 I relicensed locale under LGPL2.1+. Anybody can collect all necessary
 information from public sources anyway. I also updated my email.

 Max - are you agree with change of license?

 У сб, 2012-06-30 у 15:20 +0200, Helge Kreutzmann пише:
 Hello,
 you are listed as contact person/author of the following locale:

 uk_UA

 This locale comes with a statement

 % Distribution and use is free, also
 % for commercial purposes.

 Thus it does not allow modification; it is unclear, however, if this
 statement was meant as a license.

 As discussed in
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555168 this
 locale could strictly speaking not be part of Debian which would be a
 great loss. (Currently it is allowed pending investigation).

 To properly resolve this, I would like to ask you the following
 question:

 Would you be willing to relicense this locale to a proper license,
 e.g. (L)GPL v2 or higher or another free software license of your choice?

 If you have any questions regarding this issue, do not hesitate to
 contact me (via the reply-to address set).

 Thanks for helping to resolve this!

 Helge





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

Bug#679021: rtorrent does not start (symbol lookup error undefined symbol)

[Max Power]

Package: rtorrent
Version: 0.9.2-1
Severity: grave
Justification: renders package unusable


After uprading from rtorrent 0.8.9 (previous unstable version) rtorrent is not 
able to start again with the error message:

rtorrent: symbol lookup error: rtorrent: undefined symbol: 
_ZN7torrent11thread_base8m_globalE

I have no clue what this means or what I could do against it.

-- System Information:
Debian Release: 6.0.5
  APT prefers stable
  APT policy: (500, 'stable'), (300, 'testing'), (200, 'unstable'), (100, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38.2-grsec--grs-ipv6-64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages rtorrent depends on:
ii  libc62.13-33 Embedded GNU C Library: Shared lib
ii  libcurl3 7.24.0-1easy-to-use client-side URL transf
ii  libgcc1  1:4.7.0-8   GCC support library
ii  libncursesw5 5.9-9   shared libraries for terminal hand
ii  libsigc++-2.0-0c2a   2.2.10-0.1  type-safe Signal Framework for C++
ii  libstdc++6   4.7.0-8 GNU Standard C++ Library v3
ii  libtinfo55.9-9   shared low-level terminfo library 
ii  libtorrent14 0.13.2-1C++ BitTorrent library by Rakshasa
ii  libxmlrpc-core-c31.16.33-3.1 lightweight RPC library based on X

rtorrent recommends no packages.

Versions of packages rtorrent suggests:
ii  screen4.0.3-14   terminal multiplexor with VT100/AN

-- no debconf information



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

Bug#679021: rtorrent does not start (symbol lookup error undefined symbol)

[Max Power]

Hi Benoît!

Output from ldd $(which rtorrent)

linux-vdso.so.1 =  (0x7fff54fe5000)
libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5
(0x7f0fccb28000)
libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5
(0x7f0fcc8ff000)
libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0x7f0fcc6f9000)
libcurl.so.4 = /usr/lib/x86_64-linux-gnu/libcurl.so.4
(0x7f0fcc48e000)
libtorrent.so.14 = /usr/local/lib/libtorrent.so.14
(0x7f0fcc1b2000)
libxmlrpc_server.so.3 = /usr/local/lib/libxmlrpc_server.so.3
(0x7f0fcbfab000)
libxmlrpc.so.3 = /usr/local/lib/libxmlrpc.so.3 (0x7f0fcbd94000)
libxmlrpc_util.so.3 = /usr/local/lib/libxmlrpc_util.so.3
(0x7f0fcbb9)
libxmlrpc_xmlparse.so.3 = /usr/local/lib/libxmlrpc_xmlparse.so.3
(0x7f0fcb983000)
libxmlrpc_xmltok.so.3 = /usr/local/lib/libxmlrpc_xmltok.so.3
(0x7f0fcb767000)
libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f0fcb46)
libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f0fcb1dd000)
libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f0fcafc7000)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f0fcadab000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f0fcaa23000)
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0fca81f000)
libidn.so.11 = /usr/lib/x86_64-linux-gnu/libidn.so.11
(0x7f0fca5eb000)
libssh2.so.1 = /usr/lib/x86_64-linux-gnu/libssh2.so.1
(0x7f0fca3c1000)
liblber-2.4.so.2 = /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
(0x7f0fca1b2000)
libldap_r-2.4.so.2 = /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
(0x7f0fc9f62000)
librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f0fc9d59000)
libgssapi_krb5.so.2 =
/usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f0fc9b1a000)
libssl.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
(0x7f0fc98c8000)
libcrypto.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(0x7f0fc9501000)
librtmp.so.0 = /usr/lib/x86_64-linux-gnu/librtmp.so.0
(0x7f0fc92e7000)
libz.so.1 = /usr/lib/libz.so.1 (0x7f0fc90d)
libgnutls.so.26 = /usr/lib/x86_64-linux-gnu/libgnutls.so.26
(0x7f0fc8e0f000)
/lib64/ld-linux-x86-64.so.2 (0x7f0fccd62000)
libgcrypt.so.11 = /lib/x86_64-linux-gnu/libgcrypt.so.11
(0x7f0fc8b91000)
libresolv.so.2 = /lib/x86_64-linux-gnu/libresolv.so.2
(0x7f0fc897a000)
libsasl2.so.2 = /usr/lib/libsasl2.so.2 (0x7f0fc8761000)
libkrb5.so.3 = /usr/lib/x86_64-linux-gnu/libkrb5.so.3
(0x7f0fc848d000)
libk5crypto.so.3 = /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
(0x7f0fc8263000)
libcom_err.so.2 = /lib/x86_64-linux-gnu/libcom_err.so.2
(0x7f0fc805f000)
libkrb5support.so.0 =
/usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f0fc7e56000)
libkeyutils.so.1 = /lib/libkeyutils.so.1 (0x7f0fc7c53000)
libtasn1.so.3 = /usr/lib/x86_64-linux-gnu/libtasn1.so.3
(0x7f0fc7a42000)
libp11-kit.so.0 = /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
(0x7f0fc782f000)
libgpg-error.so.0 = /lib/x86_64-linux-gnu/libgpg-error.so.0
(0x7f0fc762c000)

As you can see it points to /usr/local/lib/libtorrent.so.14 which point to
/usr/local/lib/libtorrent.so.14.0.1 in the same directory.

I have /usr/lib/x86_64-linux-gnu/libtorrent.so.14 and it's pointing to
/usr/lib/x86_64-linux-gnu/libtorrent.so.14.0.4 but for an unknown reason
it's not linked correctly. Any idea on how to fix this?

Many thanks
Max

On Mon, Jun 25, 2012 at 11:38 PM, Benoît Knecht benoit.kne...@fsfe.orgwrote:

 Hi Max,

 Max Power wrote:
  After uprading from rtorrent 0.8.9 (previous unstable version)
  rtorrent is not able to start again with the error message:
 
  rtorrent: symbol lookup error: rtorrent: undefined symbol:
 _ZN7torrent11thread_base8m_globalE
 
  I have no clue what this means or what I could do against it.

 Can you please post the output of

  ldd $(which rtorrent)

 and see if it lists libtorrent.so.14? It should point to
 /usr/lib/x86_64-linux-gnu/libtorrent.so.14, so can you check if it
 exists on your system and links to libtorrent.so.14.0.4 in the same
 directory (and that the latter is readable)?

 Also, do you have multiarch-support installed?

 Cheers,

 --
 Benoît Knecht

Bug#679021: rtorrent does not start (symbol lookup error undefined symbol)

[Max Power]

Omfg everything is working again. Where can I donate to you directly
Benoît? Thanks so much! :D

Regards
Max

On Tue, Jun 26, 2012 at 12:08 AM, Benoît Knecht benoit.kne...@fsfe.orgwrote:

 Max Power wrote:
  Output from ldd $(which rtorrent)
 
  linux-vdso.so.1 =  (0x7fff54fe5000)
  libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5
  (0x7f0fccb28000)
  libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5
  (0x7f0fcc8ff000)
  libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0
 (0x7f0fcc6f9000)
  libcurl.so.4 = /usr/lib/x86_64-linux-gnu/libcurl.so.4
  (0x7f0fcc48e000)
  libtorrent.so.14 = /usr/local/lib/libtorrent.so.14
  (0x7f0fcc1b2000)
  libxmlrpc_server.so.3 = /usr/local/lib/libxmlrpc_server.so.3
  (0x7f0fcbfab000)
  libxmlrpc.so.3 = /usr/local/lib/libxmlrpc.so.3
 (0x7f0fcbd94000)
  libxmlrpc_util.so.3 = /usr/local/lib/libxmlrpc_util.so.3
  (0x7f0fcbb9)
  libxmlrpc_xmlparse.so.3 = /usr/local/lib/libxmlrpc_xmlparse.so.3
  (0x7f0fcb983000)
  libxmlrpc_xmltok.so.3 = /usr/local/lib/libxmlrpc_xmltok.so.3
  (0x7f0fcb767000)
  libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6
  (0x7f0fcb46)
  libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f0fcb1dd000)
  libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1
  (0x7f0fcafc7000)
  libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0
  (0x7f0fcadab000)
  libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f0fcaa23000)
  libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2
 (0x7f0fca81f000)
  libidn.so.11 = /usr/lib/x86_64-linux-gnu/libidn.so.11
  (0x7f0fca5eb000)
  libssh2.so.1 = /usr/lib/x86_64-linux-gnu/libssh2.so.1
  (0x7f0fca3c1000)
  liblber-2.4.so.2 = /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
  (0x7f0fca1b2000)
  libldap_r-2.4.so.2 =
 /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
  (0x7f0fc9f62000)
  librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1
 (0x7f0fc9d59000)
  libgssapi_krb5.so.2 =
  /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f0fc9b1a000)
  libssl.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
  (0x7f0fc98c8000)
  libcrypto.so.1.0.0 =
 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
  (0x7f0fc9501000)
  librtmp.so.0 = /usr/lib/x86_64-linux-gnu/librtmp.so.0
  (0x7f0fc92e7000)
  libz.so.1 = /usr/lib/libz.so.1 (0x7f0fc90d)
  libgnutls.so.26 = /usr/lib/x86_64-linux-gnu/libgnutls.so.26
  (0x7f0fc8e0f000)
  /lib64/ld-linux-x86-64.so.2 (0x7f0fccd62000)
  libgcrypt.so.11 = /lib/x86_64-linux-gnu/libgcrypt.so.11
  (0x7f0fc8b91000)
  libresolv.so.2 = /lib/x86_64-linux-gnu/libresolv.so.2
  (0x7f0fc897a000)
  libsasl2.so.2 = /usr/lib/libsasl2.so.2 (0x7f0fc8761000)
  libkrb5.so.3 = /usr/lib/x86_64-linux-gnu/libkrb5.so.3
  (0x7f0fc848d000)
  libk5crypto.so.3 = /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
  (0x7f0fc8263000)
  libcom_err.so.2 = /lib/x86_64-linux-gnu/libcom_err.so.2
  (0x7f0fc805f000)
  libkrb5support.so.0 =
  /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f0fc7e56000)
  libkeyutils.so.1 = /lib/libkeyutils.so.1 (0x7f0fc7c53000)
  libtasn1.so.3 = /usr/lib/x86_64-linux-gnu/libtasn1.so.3
  (0x7f0fc7a42000)
  libp11-kit.so.0 = /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
  (0x7f0fc782f000)
  libgpg-error.so.0 = /lib/x86_64-linux-gnu/libgpg-error.so.0
  (0x7f0fc762c000)
 
  As you can see it points to /usr/local/lib/libtorrent.so.14 which point
 to
  /usr/local/lib/libtorrent.so.14.0.1 in the same directory.
 
  I have /usr/lib/x86_64-linux-gnu/libtorrent.so.14 and it's pointing to
  /usr/lib/x86_64-linux-gnu/libtorrent.so.14.0.4 but for an unknown reason
  it's not linked correctly. Any idea on how to fix this?

 Just try removing /usr/local/lib/libtorrent.so.14{,.0.1}, which I guess
 you compiled and installed there yourself at some point.

 Cheers,

 --
 Benoît Knecht

Bug#679021: rtorrent does not start (symbol lookup error undefined symbol)

[Max Power]

Already did so, I assumed that this is the case. I compiled rtorrent once
myself (long time ago) to test the latest version because all Debian
packages back then were outdated.
Thanks again mate!

On Tue, Jun 26, 2012 at 12:17 AM, Benoît Knecht benoit.kne...@fsfe.orgwrote:

 Benoît Knecht wrote:
  Max Power wrote:
   Output from ldd $(which rtorrent)
  
   linux-vdso.so.1 =  (0x7fff54fe5000)
   libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5
   (0x7f0fccb28000)
   libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5
   (0x7f0fcc8ff000)
   libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0
 (0x7f0fcc6f9000)
   libcurl.so.4 = /usr/lib/x86_64-linux-gnu/libcurl.so.4
   (0x7f0fcc48e000)
   libtorrent.so.14 = /usr/local/lib/libtorrent.so.14
   (0x7f0fcc1b2000)
   libxmlrpc_server.so.3 = /usr/local/lib/libxmlrpc_server.so.3
   (0x7f0fcbfab000)
   libxmlrpc.so.3 = /usr/local/lib/libxmlrpc.so.3
 (0x7f0fcbd94000)
   libxmlrpc_util.so.3 = /usr/local/lib/libxmlrpc_util.so.3
   (0x7f0fcbb9)
   libxmlrpc_xmlparse.so.3 =
 /usr/local/lib/libxmlrpc_xmlparse.so.3
   (0x7f0fcb983000)
   libxmlrpc_xmltok.so.3 = /usr/local/lib/libxmlrpc_xmltok.so.3
   (0x7f0fcb767000)
   libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6
   (0x7f0fcb46)
   libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6
 (0x7f0fcb1dd000)
   libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1
   (0x7f0fcafc7000)
   libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0
   (0x7f0fcadab000)
   libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6
 (0x7f0fcaa23000)
   libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2
 (0x7f0fca81f000)
   libidn.so.11 = /usr/lib/x86_64-linux-gnu/libidn.so.11
   (0x7f0fca5eb000)
   libssh2.so.1 = /usr/lib/x86_64-linux-gnu/libssh2.so.1
   (0x7f0fca3c1000)
   liblber-2.4.so.2 = /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
   (0x7f0fca1b2000)
   libldap_r-2.4.so.2 =
 /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
   (0x7f0fc9f62000)
   librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1
 (0x7f0fc9d59000)
   libgssapi_krb5.so.2 =
   /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f0fc9b1a000)
   libssl.so.1.0.0 = /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
   (0x7f0fc98c8000)
   libcrypto.so.1.0.0 =
 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
   (0x7f0fc9501000)
   librtmp.so.0 = /usr/lib/x86_64-linux-gnu/librtmp.so.0
   (0x7f0fc92e7000)
   libz.so.1 = /usr/lib/libz.so.1 (0x7f0fc90d)
   libgnutls.so.26 = /usr/lib/x86_64-linux-gnu/libgnutls.so.26
   (0x7f0fc8e0f000)
   /lib64/ld-linux-x86-64.so.2 (0x7f0fccd62000)
   libgcrypt.so.11 = /lib/x86_64-linux-gnu/libgcrypt.so.11
   (0x7f0fc8b91000)
   libresolv.so.2 = /lib/x86_64-linux-gnu/libresolv.so.2
   (0x7f0fc897a000)
   libsasl2.so.2 = /usr/lib/libsasl2.so.2 (0x7f0fc8761000)
   libkrb5.so.3 = /usr/lib/x86_64-linux-gnu/libkrb5.so.3
   (0x7f0fc848d000)
   libk5crypto.so.3 = /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
   (0x7f0fc8263000)
   libcom_err.so.2 = /lib/x86_64-linux-gnu/libcom_err.so.2
   (0x7f0fc805f000)
   libkrb5support.so.0 =
   /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f0fc7e56000)
   libkeyutils.so.1 = /lib/libkeyutils.so.1 (0x7f0fc7c53000)
   libtasn1.so.3 = /usr/lib/x86_64-linux-gnu/libtasn1.so.3
   (0x7f0fc7a42000)
   libp11-kit.so.0 = /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
   (0x7f0fc782f000)
   libgpg-error.so.0 = /lib/x86_64-linux-gnu/libgpg-error.so.0
   (0x7f0fc762c000)
  
   As you can see it points to /usr/local/lib/libtorrent.so.14 which
 point to
   /usr/local/lib/libtorrent.so.14.0.1 in the same directory.
  
   I have /usr/lib/x86_64-linux-gnu/libtorrent.so.14 and it's pointing to
   /usr/lib/x86_64-linux-gnu/libtorrent.so.14.0.4 but for an unknown
 reason
   it's not linked correctly. Any idea on how to fix this?
 
  Just try removing /usr/local/lib/libtorrent.so.14{,.0.1}, which I guess
  you compiled and installed there yourself at some point.

 Actually, you should remove all of the files listed in the output of ldd
 that are in /usr/local/lib, as otherwise they will be used instead of
 the versions shipped in Debian and eventually cause issues like this
 one.

 --
 Benoît Knecht

Bug#670676: pithos: Pandora v34 API Update Required

[Max Sadrieh]

Package: pithos
Version: 0.3.14-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Pandora changed the protocol used so far and Pithos does not play anything.

See:

https://bugs.launchpad.net/pithos/+bug/988395

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




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

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

Versions of packages pithos depends on:
ii  gstreamer0.10-plugins-bad   0.10.23-2
ii  gstreamer0.10-plugins-good  0.10.31-2
ii  python  2.7.2-10
ii  python-dbus 0.84.0-3
ii  python-gobject  3.2.0-3
ii  python-gst0.10  0.10.22-3
ii  python-gtk2 2.24.0-3
ii  python-notify   0.1.1-3
ii  python-xdg  0.19-4
ii  python2.6   2.6.7-4
ii  python2.7   2.7.3~rc2-2.1

pithos recommends no packages.

pithos suggests no packages.

-- no debconf information



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

Bug#667764: strongswan-starter: package must not include /var/lock/subsys

[Aristov Max]

Package: strongswan-starter
Version: 4.5.2-1.3
Severity: serious
Justification: Policy 9.1.4

According to DP /run is cleared at boot, so some changes should be made to 
the upstream code, for example strongswan could keep files directly in 
/run/lock directory.
I noticed the problem, when configuration of base-files failed in multistrapped 
environment: its postinst script assumes /var/lock to be empty.

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

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



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

Bug#661069: installation-reports: first boot fails on HP 635 (AMD Zacate) seeing only colourful snow

[Max Sievers]

Today I tried again to install Debian GNU/Linux Wheezy on a HP 635. I used the 
netinst image on a DVD (of March 19, 2012). The graphical installation doesn't 
work this time. After the boot messages the screen gets blank and stays this 
way.

The normal installation worked but the reported error remains. The black and 
white stripes only appear for a few seconds then there comes the colored snow 
on the whole screen whith the mouse cursor visible as a ligther tile.

This time I tried to switch to a virtual console. Blindly I logged in as root 
and typed init 0 -- which worked.

I also tried to add radeon.modeset=0 to the GRUB boot options. It didn't 
make a difference.



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

Bug#664142: installation-reports: Boot selection screen freezes with testing amd64 on hd-media

[Max Sievers]

Package: installation-reports
Justification: breaks the whole system
Severity: critical
Tags: d-i

Dear Maintainer,

the initial boot only shows the selection screen and then freezes. This was 
also the case with older Debian Wheezy versions on this machine. That's why I 
use CDs for intallation attempts (see bug #661069).

-- Package-specific info:

Boot method: hd-media (usb stick)
Image version: http://d-i.debian.org/daily-images/amd64/20120315-00:19/hd-
media/boot.img.gz
Date: Thu, 15 Mar 2012 19:24:08 +

Machine: HP 635
Partitions: none yet

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[E]

Comments/Problems:

I can't show you the hardware information because reportbug runs on another 
machine. It's an AMD Fusion platform, Zacate (E-350 or E-450).



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

Bug#661069: installation-reports: first boot fails on HP 635 (AMD Zacate) seeing only colourful snow

[Max Sievers]

The problem is still there with testing from February 25, 2012. There is no 
mouse cursor any more and the top and bottom of the screen is checkered with 
black and white stripes and stripes of the snow mosaic which still is in the 
center of the screen.

The error occurs also if I don't install the desktop-task.

I repeat that a graphical installation is possible (which means without non-
free firmware). There must be a weird error.



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

Bug#661069: installation-reports: first boot fails on HP 635 (AMD Zacate) seeing only colourful snow

[Max Sievers]

Package: installation-reports
Justification: breaks the whole system
Severity: critical
Tags: d-i

Dear Maintainer,

the graphical installer works fine on this notebook. The error occurs only at 
the attempt to boot the installation. GRUB passes fine, than Linux loads and 
I'm asked for the password of the LVM. Shortly after I entered the password 
the mode switches and I see a bright (white and light colours) snow (a 
mosaic). The mouse cursor is visible and can be moved (its a tile of snow). 
But nothing more happens. There is no console I could switch to.

I couldn't load the common firmware packages from the (extracted) tarball 
during the installation but I chose to use non-free software. I hoped that the 
installer would fetch the needed firmware. Even in expert mode I didn't find an 
option to select this task.

Boot method: CD
Image version: debian-testing-amd64-netinst.iso from February 12, 2012
Boot method: CD
Machine: HP 635
Partitions: whole disk, encrypted LVM with seperate home partition
Configure network: [O]
Detect CD: [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives: [O]
Install base system: [O]
Clock/timezone setup: [O]
User/password setup: [O]
Install tasks: [O]
Install boot loader: [O]
Overall install: [E]



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

Bug#659579: fglrx-source: Building kernel module conficts with binutils-gold package

[Max Dmitrichenko]

): Option DPMS true
(==) fglrx(0): RGB weight 888
(II) fglrx(0): Using 8 bits per RGB 
(==) fglrx(0): Buffer Tiling is ON
(II) Loading sub module fglrxdrm
(II) LoadModule: fglrxdrm
(II) Reloading /usr/lib/xorg/modules/linux/libfglrxdrm.so
ukiDynamicMajor: found major device number 250
ukiDynamicMajor: found major device number 250
ukiOpenByBusid: Searching for BusID PCI:1:0:0
ukiOpenDevice: node name is /dev/ati/card0
ukiOpenDevice: open result is 10, (OK)
ukiOpenByBusid: ukiOpenMinor returns 10
ukiOpenByBusid: ukiGetBusid reports PCI:1:0:0
(==) fglrx(0): NoAccel = NO
(==) fglrx(0): ATI 2D Acceleration Architecture enabled
(--) fglrx(0): Chipset: AMD Radeon HD 6700 Series  (Chipset = 0x68ba)
(--) fglrx(0): (PciSubVendor = 0x174b, PciSubDevice = 0x1484)
(==) fglrx(0): board vendor info: third party graphics adapter - NOT original 
ATI
(--) fglrx(0): Linear framebuffer (phys) at 0xd000
(--) fglrx(0): MMIO registers at 0xfdec
(--) fglrx(0): I/O port at 0xde00
(==) fglrx(0): ROM-BIOS at 0x000c
(II) fglrx(0): AC Adapter is used
(II) fglrx(0): Primary V_BIOS segment is: 0xc000
(II) Loading sub module vbe
(II) LoadModule: vbe
(II) Loading /usr/lib/xorg/modules/libvbe.so
(II) Module vbe: vendor=X.Org Foundation
compiled for 1.7.7, module version = 1.1.0
ABI class: X.Org Video Driver, version 6.0
(II) fglrx(0): VESA BIOS detected
(II) fglrx(0): VESA VBE Version 3.0
(II) fglrx(0): VESA VBE Total Mem: 16384 kB
(II) fglrx(0): VESA VBE OEM: ATI ATOMBIOS
(II) fglrx(0): VESA VBE OEM Software Rev: 12.20
(II) fglrx(0): VESA VBE OEM Vendor: (C) 1988-2005, ATI Technologies Inc. 
(II) fglrx(0): VESA VBE OEM Product: JUNIPER
(II) fglrx(0): VESA VBE OEM Product Rev: 01.00
(II) fglrx(0): ATI Video BIOS revision 9 or later detected
(--) fglrx(0): Video RAM: 1048576 kByte, Type: GDDR5
(II) fglrx(0): PCIE card detected
(--) fglrx(0): Using per-process page tables (PPPT) as GART.
(WW) fglrx(0): board is an unknown third party board, chipset is supported
(II) fglrx(0): Using adapter: 1:0.0.
(II) fglrx(0): [FB] MC range(MCFBBase = 0xf, MCFBSize = 0x4000)
(II) fglrx(0): Interrupt handler installed at IRQ 26.
(II) fglrx(0): RandR 1.2 support is enabled!
(II) fglrx(0): RandR 1.2 rotation support is enabled!
(==) fglrx(0): Center Mode is disabled 
(II) Loading sub module fb
(II) LoadModule: fb
(II) Loading /usr/lib/xorg/modules/libfb.so
(II) Module fb: vendor=X.Org Foundation
compiled for 1.7.7, module version = 1.0.0
ABI class: X.Org ANSI C Emulation, version 0.4
(II) Loading sub module ddc
(II) LoadModule: ddc
(II) Module ddc already built-in
(II) fglrx(0): Finished Initialize PPLIB!
(II) fglrx(0): Output DFP1 using monitor section aticonfig-Monitor[0]-0
(II) fglrx(0): Output DFP2 has no monitor section
(II) fglrx(0): Output DFP3 has no monitor section
(II) fglrx(0): Output DFP4 has no monitor section
(II) fglrx(0): Output CRT1 has no monitor section
(II) Loading sub module ddc
(II) LoadModule: ddc
(II) Module ddc already built-in
(II) fglrx(0): Connected Display0: DFP4
(II) fglrx(0): Display0 EDID data ---
(II) fglrx(0): Manufacturer: NEC  Model: 66b0  Serial#: 16843009
(II) fglrx(0): Year: 2007  Week: 41
(II) fglrx(0): EDID Version: 1.3
(II) fglrx(0): Digital Display Input
(II) fglrx(0): Max Image Size [cm]: horiz.: 41  vert.: 31
(II) fglrx(0): Gamma: 2.20
(II) fglrx(0): DPMS capabilities: StandBy Suspend Off
(II) fglrx(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 
(II) fglrx(0): First detailed timing is preferred mode
(II) fglrx(0): redX: 0.639 redY: 0.342   greenX: 0.290 greenY: 0.615
(II) fglrx(0): blueX: 0.146 blueY: 0.072   whiteX: 0.313 whiteY: 0.329
(II) fglrx(0): Supported established timings:
(II) fglrx(0): 720x400@70Hz
(II) fglrx(0): 640x480@60Hz
(II) fglrx(0): 640x480@67Hz
(II) fglrx(0): 640x480@72Hz
(II) fglrx(0): 640x480@75Hz
(II) fglrx(0): 800x600@56Hz
(II) fglrx(0): 800x600@60Hz
(II) fglrx(0): 800x600@72Hz
(II) fglrx(0): 800x600@75Hz
(II) fglrx(0): 832x624@75Hz
(II) fglrx(0): 1024x768@60Hz
(II) fglrx(0): 1024x768@70Hz
(II) fglrx(0): 1024x768@75Hz
(II) fglrx(0): 1280x1024@75Hz
(II) fglrx(0): 1152x864@75Hz
(II) fglrx(0): Manufacturer's mask: 0
(II) fglrx(0): Supported standard timings:
(II) fglrx(0): #0: hsize: 640  vsize 480  refresh: 85  vid: 22833
(II) fglrx(0): #1: hsize: 800  vsize 600  refresh: 85  vid: 22853
(II) fglrx(0): #2: hsize: 1024  vsize 768  refresh: 85  vid: 22881
(II) fglrx(0): #3: hsize: 1152  vsize 864  refresh: 75  vid: 20337
(II) fglrx(0): #4: hsize: 1280  vsize 960  refresh: 85  vid: 22913
(II) fglrx(0): #5: hsize: 1280  vsize 1024  refresh: 85  vid: 39297
(II) fglrx(0): #6: hsize: 1600  vsize 1200  refresh: 60  vid: 16553
(II) fglrx(0): Supported detailed timing:
(II) fglrx(0): clock: 162.0 MHz   Image Size:  408 x 306 mm
(II) fglrx(0): h_active: 1600  h_sync: 1664  h_sync_end 1856 h_blank_end 2160 
h_border: 0
(II) fglrx(0): v_active: 1200  v_sync: 1201  v_sync_end 1204 v_blanking: 1250 
v_border: 0
(II) fglrx(0

Bug#642454: Re: Bug#642454: dpkg-deb: file [file] contains ununderstood data member data.tar.xz, giving up

[Max maria Wacholder]

Hello,

this bug can be closed. I had dpkg pinned at an old version. After updating 
dpkg, it now works. I'm sorry for the inconvenience caused.

Regards,
M.

PS: I used an anonymous mailbin for the original bugreport. I'm the original 
bug reporter, this time from a proper e-mail address.

Bug#636305: texlive-base: Texlive-base not set up

[Max Ramirez G.]

Hi, I can confirm the solution given by Tomassino Ferrauto 
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636305#15).


--
Regards,
Max Ramirez G.




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

Bug#635399: mpd segfaults when building the database

[Max Kellermann]

On 2011/07/25 20:51, Michael Gibbs upsilon.al...@gmail.com wrote:
 Package: mpd
 Version: 0.16.2-1
 Severity: grave
 Justification: renders package unusable
 
 When attempting to rebuild the database mpd segfaults and gives the following
 message in 'dmesg':
 
 mpd[15439]: segfault at 805aebf ip b75ce7a5 sp b37b0be0 error 7 in 
 libavformat.so.52.110.0[b750a000+ff000]

Obviously not a MPD bug.  Should be moved to package libavformat52.



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

Bug#628323: (no subject)

[Max Bowsher]

This FTBFS is the result of the python-subunit package not being
properly built for all current Python versions.




signature.asc
Description: OpenPGP digital signature

Bug#613736: mpd: postinst script returned non-zero

[Max Kellermann]

On 2011/02/16 22:56, Serafeim Zanikolas s...@debian.org wrote:
 mpd's postinst script returns non-zero because of the error_file directive in
 /etc/mpd.conf (which was deprecated in v0.16).

It was deprecated (ignored) in 0.15, and removed in 0.16.

 Starting Music Player Daemon: mpdunrecognized parameter in config file at
 line 12: error_file failed!
  invoke-rc.d: initscript mpd, action restart failed.

What do you expect the script to do?

You are using a (now-)invalid configuration file which you did not
migrate during upgrade, and you set START_MPD=true in
/etc/default/mpd.

Do you want the postinst script to ignore such a configuration error?

Max



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

Bug#601657: libffado2 thread crashes with assertion failure

[Max Kellermann]

Package: libffado2   
Version: 2.0.1+svn1856-5
   
Severity: serious

The attached test program can trigger a (timing?) bug in libffado2,
which causes an assertion failure (i.e. crash of the whole
application).
#include libffado/ffado.h
#include stdbool.h
#include string.h
#include assert.h
#include stdio.h

enum {
MAX_STREAMS = 16,
PERIOD_SIZE = 1024,
NB_BUFFERS = 3,
};

static float buffer[PERIOD_SIZE];

static bool
configure_stream(ffado_device_t *dev, int number)
{
return ffado_streaming_set_playback_stream_buffer(dev, number, (char *)buffer) == 0 
ffado_streaming_playback_stream_onoff(dev, number, 1) == 0;
}

int main(int argc, char **argv) {
ffado_device_t *dev;

ffado_device_info_t device_info;
memset(device_info, 0, sizeof(device_info));
ffado_options_t options;
memset(options, 0, sizeof(options));
options.sample_rate = 44100;
options.period_size = PERIOD_SIZE;
options.nb_buffers = NB_BUFFERS;
options.verbose = 4;

dev = ffado_streaming_init(device_info, options);
assert(dev != NULL);

ffado_streaming_set_audio_datatype(dev, ffado_audio_datatype_float);

int num_streams = ffado_streaming_get_nb_playback_streams(dev);
assert(num_streams  0);

int streams[MAX_STREAMS], configured_streams = 0;
for (int i = 0; i  num_streams; ++i) {
if (configured_streams = 2)
break;

char name[256];
ffado_streaming_get_playback_stream_name(dev, i, name,
 sizeof(name) - 1);

ffado_streaming_stream_type type =
ffado_streaming_get_playback_stream_type(dev, i);
if (type != ffado_stream_type_audio)
continue;

printf(stream %d name='%s'\n, i, name);

streams[configured_streams++] = i;
configure_stream(dev, i);
}

if (ffado_streaming_prepare(dev) != 0) {
fprintf(stderr, ffado_streaming_prepare() failed\n);
return 1;
}

if (ffado_streaming_start(dev) != 0) {
fprintf(stderr, ffado_streaming_start() failed\n);
return 1;
}

getchar();

return 0;
}
Cannot create thread 1 Operation not permitted
ERROR: messagebuffer not initialized: 1250338856552:  (ffado.cpp)[  92] 
ffado_streaming_init: libffado 2.999.0- built Oct 16 2010 22:29:48
ERROR: messagebuffer not initialized: 1250338856611: Warning (ffado.cpp)[ 
121] ffado_streaming_init: Realtime scheduling is not enabled. This will cause 
significant reliability issues.
ERROR: messagebuffer not initialized: 1250339089620: Debug 
(devicemanager.cpp)[ 358] discover: Starting discovery...
ERROR: messagebuffer not initialized: 1250339197751: Debug (Configuration.cpp)[ 
163] showSetting:   Group: (null)
ERROR: messagebuffer not initialized: 1250339197771: Debug (Configuration.cpp)[ 
185] showSetting: vendorid = 3436 (0x0D6C)
ERROR: messagebuffer not initialized: 125033919: Debug (Configuration.cpp)[ 
185] showSetting: modelid = 65634 (0x00010062)
ERROR: messagebuffer not initialized: 1250339197783: Debug (Configuration.cpp)[ 
209] showSetting: vendorname = M-Audio
ERROR: messagebuffer not initialized: 1250339197787: Debug (Configuration.cpp)[ 
209] showSetting: modelname = FW Solo
ERROR: messagebuffer not initialized: 1250339197791: Debug (Configuration.cpp)[ 
185] showSetting: driver = 1 (0x0001)
ERROR: messagebuffer not initialized: 1250339197796: Debug (Configuration.cpp)[ 
185] showSetting: xmit_max_cycles_early_transmit = 4 (0x0004)
ERROR: messagebuffer not initialized: 1250339197885: Debug (devicemanager.cpp)[ 
620] discover: driver found for device 0
ERROR: messagebuffer not initialized: 1250339218779: Debug 
(bebob_avdevice.cpp)[ 734] loadFromCache: filename 
/home/max/.ffado/cache/000d6c0b0076ee12/006001040403.xml
ERROR: messagebuffer not initialized: 1250339224945: Debug 
(serialize_libxml.cpp)[ 230] checkVersion: Cache version: 2.999.0-, expected: 
2.999.0-.
ERROR: messagebuffer not initialized: 1250339374980: Debug (avc_unit.cpp)[ 489] 
discoverPlugConnections: Discovering PCR plug connections...
ERROR: messagebuffer not initialized: 1250339412532: Debug (avc_unit.cpp)[ 500] 
discoverPlugConnections: Discovering External plug connections...
ERROR: messagebuffer not initialized: 1250339451864: Debug 
(bebob_avdevice_subunit.cpp)[ 102] discoverConnections: Discovering 
connections...
ERROR: messagebuffer not initialized: 1250339451876: Debug (avc_subunit.cpp)[ 
148] discoverConnections: Discovering connections...
ERROR: messagebuffer not initialized: 1250339451882: Debug (avc_subunit.cpp)[ 
148] discoverConnections: Discovering connections...
ERROR: messagebuffer not initialized: 1250339451885: Debug 
(bebob_avdevice_subunit.cpp)[ 102] discoverConnections: Discovering 
connections...
ERROR: messagebuffer

Bug#601659: Double free bug in libffado2

[Max Kellermann]

Package: libffado2 
Version: 2.0.1+svn1856-5   
Severity: serious   

While trying to write a ffado output plugin, MPD crashed with the
following double free bug (backtrace shows it's inside libraw1394, but
my guess is that libffado calls libraw1394 with an invalid pointer):

ERROR: messagebuffer not initialized: 1250648744531: Error 
(IsoHandlerManager.cpp)[1289] ~IsoHandler: BUG: Handler still running!
ERROR: messagebuffer not initialized: 1250648744570: Error 
(IsoHandlerManager.cpp)[1289] ~IsoHandler: BUG: Handler still running!
*** glibc detected *** /usr/src/squeeze-mpd/src/mpd: double free or corruption 
(!prev): 0x01736870 ***
[...]
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffdcabd710 (LWP 5297)]
0x7fffefedc165 in *__GI_raise (sig=value optimized out) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x7fffefedc165 in *__GI_raise (sig=value optimized out) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x7fffefedef70 in *__GI_abort () at abort.c:92
#2  0x7fffeff1227b in __libc_message (do_abort=value optimized out, 
fmt=value optimized out)
at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#3  0x7fffeff1bad6 in malloc_printerr (action=3, str=0x7fffeffd2ac8 double 
free or corruption (!prev), 
ptr=value optimized out) at malloc.c:6267
#4  0x7fffeff2084c in *__GI___libc_free (mem=value optimized out) at 
malloc.c:3739
#5  0x7fffed587ff1 in raw1394_destroy_handle () from 
/usr/lib/libraw1394.so.11
#6  0x71a79a75 in IsoHandlerManager::IsoHandler::disable() () from 
/usr/lib/libffado.so.2
#7  0x71a7b99b in IsoHandlerManager::IsoTask::updateShadowMapHelper() 
() from /usr/lib/libffado.so.2
#8  0x71a7bed2 in IsoHandlerManager::IsoTask::Execute() () from 
/usr/lib/libffado.so.2
#9  0x71a9b82a in Util::PosixThread::ThreadHandler(void*) () from 
/usr/lib/libffado.so.2
#10 0x715848ba in start_thread (arg=value optimized out) at 
pthread_create.c:300
#11 0x7fffeff7902d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#12 0x in ?? ()



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

Bug#601663: libffado2 reads from freed memory

[Max Kellermann]

Package: libffado2
Version: 2.0.1+svn1856-5
Severity: serious

libffado2 reads a lot of values from freed or uninitialized memory.
That is obviously a crash waiting to happen.  See attached valgrind
log file.

Thread 10:
Conditional jump or move depends on uninitialised value(s)
   at 0xAEE9C75: CycleTimerHelper::getCycleTimerTicks(unsigned long) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xAEEB8A9: CycleTimerHelper::Execute() (in /usr/lib/libffado.so.2.999.0)
   by 0xAF15829: Util::PosixThread::ThreadHandler(void*) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)
 Uninitialised value was created by a heap allocation
   at 0x4C24DFA: operator new(unsigned long) (vg_replace_malloc.c:261)
   by 0xAEF0D8B: Ieee1394Service::Ieee1394Service() (in 
/usr/lib/libffado.so.2.999.0)
   by 0xAED67B0: DeviceManager::initialize() (in /usr/lib/libffado.so.2.999.0)
   by 0xAEDCC4A: ffado_streaming_init (in /usr/lib/libffado.so.2.999.0)
   by 0x431A65: ffado_open (ffado_output_plugin.c:240)
   by 0x42CAB2: ao_plugin_open (output_plugin.h:196)
   by 0x42D384: ao_open (output_thread.c:164)
   by 0x42E269: audio_output_task (output_thread.c:549)
   by 0x7A40783: g_thread_create_proxy (gthread.c:1893)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)

Conditional jump or move depends on uninitialised value(s)
   at 0xAEE9C7A: CycleTimerHelper::getCycleTimerTicks(unsigned long) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xAEEB8A9: CycleTimerHelper::Execute() (in /usr/lib/libffado.so.2.999.0)
   by 0xAF15829: Util::PosixThread::ThreadHandler(void*) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)
 Uninitialised value was created by a heap allocation
   at 0x4C24DFA: operator new(unsigned long) (vg_replace_malloc.c:261)
   by 0xAEF0D8B: Ieee1394Service::Ieee1394Service() (in 
/usr/lib/libffado.so.2.999.0)
   by 0xAED67B0: DeviceManager::initialize() (in /usr/lib/libffado.so.2.999.0)
   by 0xAEDCC4A: ffado_streaming_init (in /usr/lib/libffado.so.2.999.0)
   by 0x431A65: ffado_open (ffado_output_plugin.c:240)
   by 0x42CAB2: ao_plugin_open (output_plugin.h:196)
   by 0x42D384: ao_open (output_thread.c:164)
   by 0x42E269: audio_output_task (output_thread.c:549)
   by 0x7A40783: g_thread_create_proxy (gthread.c:1893)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)

Conditional jump or move depends on uninitialised value(s)
   at 0xAEEB8DA: CycleTimerHelper::Execute() (in /usr/lib/libffado.so.2.999.0)
   by 0xAF15829: Util::PosixThread::ThreadHandler(void*) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)
 Uninitialised value was created by a heap allocation
   at 0x4C24DFA: operator new(unsigned long) (vg_replace_malloc.c:261)
   by 0xAEF0D8B: Ieee1394Service::Ieee1394Service() (in 
/usr/lib/libffado.so.2.999.0)
   by 0xAED67B0: DeviceManager::initialize() (in /usr/lib/libffado.so.2.999.0)
   by 0xAEDCC4A: ffado_streaming_init (in /usr/lib/libffado.so.2.999.0)
   by 0x431A65: ffado_open (ffado_output_plugin.c:240)
   by 0x42CAB2: ao_plugin_open (output_plugin.h:196)
   by 0x42D384: ao_open (output_thread.c:164)
   by 0x42E269: audio_output_task (output_thread.c:549)
   by 0x7A40783: g_thread_create_proxy (gthread.c:1893)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)

Conditional jump or move depends on uninitialised value(s)
   at 0xAEEB8F7: CycleTimerHelper::Execute() (in /usr/lib/libffado.so.2.999.0)
   by 0xAF15829: Util::PosixThread::ThreadHandler(void*) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)
 Uninitialised value was created by a heap allocation
   at 0x4C24DFA: operator new(unsigned long) (vg_replace_malloc.c:261)
   by 0xAEF0D8B: Ieee1394Service::Ieee1394Service() (in 
/usr/lib/libffado.so.2.999.0)
   by 0xAED67B0: DeviceManager::initialize() (in /usr/lib/libffado.so.2.999.0)
   by 0xAEDCC4A: ffado_streaming_init (in /usr/lib/libffado.so.2.999.0)
   by 0x431A65: ffado_open (ffado_output_plugin.c:240)
   by 0x42CAB2: ao_plugin_open (output_plugin.h:196)
   by 0x42D384: ao_open (output_thread.c:164)
   by 0x42E269: audio_output_task (output_thread.c:549)
   by 0x7A40783: g_thread_create_proxy (gthread.c:1893)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)

Conditional jump or move depends on uninitialised value(s)
   at 0xAEEB96F: CycleTimerHelper::Execute() (in /usr/lib/libffado.so.2.999.0)
   by 0xAF15829: Util::PosixThread::ThreadHandler(void*) (in 
/usr/lib/libffado.so.2.999.0)
   by 0xB4748B9: start_thread (pthread_create.c:300)
   by 0xCACC02C: clone (clone.S:112)
 Uninitialised value was created by a heap allocation
   at 0x4C24DFA: operator 

Bug#601657: libffado2 thread crashes with assertion failure

[Max Kellermann]

reopen 601657
thanks

On 2010/10/28 11:08, Adrian Knoth a...@drcomp.erfurt.thur.de wrote:
 On Thu, Oct 28, 2010 at 09:31:48AM +0200, Max Kellermann wrote:
 
  The attached test program can trigger a (timing?) bug in libffado2,
 
 Welcome to userlevel device drivers. For some reasons, the packets were
 not delivered or received in time.
 
 Might be a combination of period-size (lower is sometimes better),
 firewire controllers and so on.
 
 As always, svn trunk might have a fix if it's really a device specific
 error, i.e. misunderstanding of the samplerate in use.
 
  ERROR: messagebuffer not initialized: 1250338856611: Warning
  (ffado.cpp)[ 121] ffado_streaming_init: Realtime scheduling is not
  enabled. This will cause significant reliability issues.
 
 You're running it without realtime priorities? Now I see why you get
 the timing issues mentioned above.

You seem to be misunderstanding the problem here.  This is not about a
buffer xrun because the application didn't submit enough PCM samples
in time; this is about a crash due to an assertion failure, i.e. a bug
in libffado2.

Please do not close this bug report until there is a new Debian
revision which does not crash (or until there is evidence that my test
program is bugged, indirectly causing the crash).

Max



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

Bug#597731: Bug#562568: 562568: Symbol conflict with libcdio10

[Max Kellermann]

On 2010/09/22 18:03, Matthias Klose d...@debian.org wrote:
 clone 562568 -2
 reassign -2 libmpd

How is this bug related to libmpd?  Did you mean mpd instead?



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

Bug#563742: aespipe: Missing dependency for uuencode (e.g. sharutils)

[Max Vozeler]

On Mon, Jan 04, 2010 at 07:10:12AM -0500, Daniel Dickinson wrote:
 Package: aespipe
 Version: 2.3d-2
 Severity: serious
 Justification: required dependences must be listed

 aespipe with a Standard system emits warnings that uuencode is missing (line 
 84)
 sharutils supplies uuencode.

I'm confused. There is no way I can see aespipe needing 
uuencode or showing such a warning.

Can you please describe what exactly you are trying to do?
Please quote the error messages you are seeing.

Max



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

Bug#563192: libportaudio.so.2 overrides the libasound2 error handler

[Max Kellermann]

Package: libportaudio2
Version: 19+svn20071022-3
Severity: grave

Upon initialization. libportaudio2 (function PaAlsa_Initialize()) sets
a new global libasound2 error handler by invoking
snd_lib_error_set_handler().  It is bad style for a library to do
this, because this may overwrite the application's custom error
handler.

Now the real critical problem: when loaded with OpenAL (libopenal1
1:1.10.622-1 in this case), libportaudio2 sets the error handler, but
gets unloaded later, rendering the memory address of
AlsaErrorHandler() invalid.  This results in a crash of the
application on the next ALSA error.

(I have submitted this bug for libportaudio2 instead of libopenal1,
because I think libportaudio2 is really doing the wrong thing by
overwriting another library's global variable; you could argue that
unloading the library is wrong in the first place)

Practical example: the Music Player Daemon, which has plugins for
OpenAL as well as for native ALSA.  Here is a crash backtrace:


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe2ab6910 (LWP 31128)]
0x77e73d08 in ?? ()
(gdb) bt
#0  0x77e73d08 in ?? ()
#1  0x723fb9a6 in snd_pcm_hw_open (pcmp=0x513178, name=0x5130d0 hw:0, 
card=0, device=0, subdevice=-1, 
stream=SND_PCM_STREAM_PLAYBACK, mode=327681, mmap_emulation=0, 
sync_ptr_ioctl=0) at pcm_hw.c:1325
#2  0x723fc05e in _snd_pcm_hw_open (pcmp=0x513178, name=0x5130d0 
hw:0, root=0x538960, conf=0x55e290, 
stream=SND_PCM_STREAM_PLAYBACK, mode=327680) at pcm_hw.c:1505
#3  0x723ea527 in snd_pcm_open_conf (pcmp=0x513178, name=0x5130d0 
hw:0, pcm_root=0x538960, pcm_conf=0x55e290, 
stream=SND_PCM_STREAM_PLAYBACK, mode=327680) at pcm.c:2181
#4  0x723ea6aa in snd_pcm_open_noupdate (pcmp=0x513178, root=0x538960, 
name=0x5130d0 hw:0, 
stream=SND_PCM_STREAM_PLAYBACK, mode=327680, hop=0) at pcm.c:2219
#5  0x723ea740 in snd_pcm_open (pcmp=0x513178, name=0x5130d0 hw:0, 
stream=SND_PCM_STREAM_PLAYBACK, mode=327680)
at pcm.c:2241
#6  0x0042b34a in alsa_open (data=0x513160, audio_format=0x512d20, 
error=0x7fffe2ab6008)
at /home/max/git/mpd/src/output/alsa_plugin.c:471
#7  0x00428153 in ao_plugin_open (plugin=0x4678c0, data=0x513160, 
audio_format=0x512d20, error=0x7fffe2ab6008)
at /home/max/git/mpd/src/output_plugin.h:196
[...]


Severity grave because this allows an attacker to make MPD crash
remotely.  It might also be possible to inject and execute code this
way, if the address happens to be memory mapped later.



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

Bug#560533: mpd: FTBFS: wavpack_plugin.c:75: error: 'uchar' undeclared (first use in this function)

[Max Kellermann]

On 2009/12/11 09:30, Lucas Nussbaum lu...@lucas-nussbaum.net wrote:
 Source: mpd
 Version: 0.15.6-1
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20091210 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.

Upstream patch scheduled for 0.15.7:

 
http://git.musicpd.org/cgit/master/mpd.git/patch/?id=8f7bc70bf5e47da66e57e5606b978ba3ee975d89



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

Bug#560433: Package is empty

[Max Kellermann]

Package: libv8-2.0.3
Version: 2.0.3-1
Severity: grave

Contrary to the package description, there is no shared library.
There is nothing except /usr/share/doc/libv8-2.0.3.  Same is true for
the -dbg package.  The symlink /usr/lib/libv8.so in the -dev package
points to a non-existing path.



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

Bug#551932: mpd and mpich2: error when trying to install together

[Max Kellermann]

On 2009/10/22 13:35, Lucas Nussbaum lu...@lucas-nussbaum.net wrote:
 Decklin, what are your thoughts on this? Would it make sense to move the
 Music Playing Daemon's mpd binary to /usr/sbin/, and the manpage to
 section 8? I have the impression (perhaps wrongly) that mpd is mainly
 start via an init script, so it wouldn't hurt too badly.

Yes, I know a whole lot of users who run MPD as a regular user.  It is
perfectly possible to run MPD on login in ~/.xsession, and there are
good reasons for doing so.

Besides that, your suggestion isn't a solution at all, because it does
not address the real problem: that there are two binaries with the
same name.  It's just an attempt to hide the symptom (path name
conflict).

 The problem is that mpd is a key binary in the mpich2 package,
 referenced all over the place, and it would really be confusing for
 users to rename it to (say) mpich2-mpd.

It would be confusing for users if /usr/bin/mpd doesn't start the
Music Player Daemon anymore, after more than 6 years.  Same thing.

There are more problems to come: mpd.py references files named
/etc/mpd.conf and ~/.mpd.conf.  Music Player Daemon uses /etc/mpd.conf
and ~/.mpdconf.  Talk about confusion.

Max



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

Bug#547525: NMU

[Max Kellermann]

On 2009/10/01 12:06, Christophe Mutricy xto...@chewa.net wrote:
 I attend to upload a 0-day NMU to fix this FTBFS as soon as I find a
 sponsor.
 
 Debdiff and diif.gz can be found at
 http://people.videolan.org/~xtophe/debian

Not sure if it's worth it.  We will release MPD 0.15.4 on the upcoming
weekend, which includes the revert commit.



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

Bug#547525: FTBFS on armel: 'OV_CALLBACKS_STREAMONLY' undeclared

[Max Kellermann]

On 2009/09/20 16:00, Luk Claes l...@debian.org wrote:
 mpd fails to build on armel with the following message (more info in
 the full build log on buildd.d.o). This is currently one of the
 blockers for the faad2 transition.

This fails on older libvorbis versions.  For 0.15.4, we have reverted
the patch which uses the new API; will be released soon.

 
http://git.musicpd.org/cgit/master/mpd.git/commit/?h=v0.15.xid=a99202a8a4ebda1fcbedb3b024cab3b25c63adad



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

Bug#545146: upgrade Debian 4-5 fails with tzdata: error 10 in post-install

[Euer Max]

Package: tzdata
Version: 2009g-0lenny1
Severity: critical
Justification: breaks the whole system

When upgrading from Debian 4 to 5(Lenny) by use of dselect/update/install,
the installation will fail in the middle of the upgrade, leaving the whole
system (possibly unable to reboot, since) only partially upgraded,with 
the msg:

tzdata: post-installation failed with error 10;
Package tzdata will remain in an unconfigured state.
There is no way to get around this and to continue the rest of the 
upgrade/installation.
I finally managed (before even trying to reboot) to take a look at the 
post-installation script,
took a wild guess, removed the file /etc/timezone ( contained only the 
word 'Factory' since the year 2000),
then resumed dselect/install and the tzdata configuration continued 
successfully, so did the rest of the upgrade.

Today, /etc/timezone is still missing, and honestly, I don't care.
Yours truly

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

Kernel: Linux 2.6.18.7
Locale: LANG=POSIX, LC_CTYPE=POSIX (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0] 1.5.24 Debian configuration 
management sy


tzdata recommends no packages.

tzdata suggests no packages.

-- debconf information excluded


--
Euer Max - Oud Lemiers 18 - NL6295AT Lemiers -  T (NL 06)1840 3128
F (NL 084)716 4118- E m.e...@planet.nl




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

Bug#542695: cannot use crypto loop aes

[Max Vozeler]

severity 542695 important
thanks

Hello,

On Thu, Aug 20, 2009 at 10:14:46PM +0200, J.M.Roth wrote:
 # aptitude install loop-aes-modules-2.6.26-2-686
 # modprobe loop-aes
 # lsmod | grep loop
 loop   55372  0
 # dmesg | tail -3
 [ 4457.015307] loop: module loaded
 [ 4521.947610] loop: AES key scrubbing enabled
 [ 4521.948506] loop: loaded (max 8 devices)
 # losetup -v -e aes /dev/loop0 /dev/md0
 Password: 123123123123123123123123123123123123
 ioctl: LOOP_SET_STATUS: Invalid argument
 # losetup -v -e AES256 /dev/loop0 /dev/md0
 Password: 123123123123123123123123123123123123
 ioctl: LOOP_SET_STATUS: Invalid argument
 # losetup -v -e aes-256 /dev/loop0 /dev/md0
 Password: 123123123123123123123123123123123123
 ioctl: LOOP_SET_STATUS: Invalid argument
 # losetup -v -e aes256 /dev/loop0 /dev/md0
 Password: 123123123123123123123123123123123123
 ioctl: LOOP_SET_STATUS: Invalid argument
 
 Please tell me I'm doing sth wrong and this is not all broken.
 
Can you verify that you have the package loop-aes-utils 
installed? This looks like it is not installed.

Also, I suggest to read through the README if you have not
already done so. The commands you showed, while they are 
expected to work, don't match the recommended setup.

Max



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

Bug#542102: mpd: audio skips once per second

[Max Kellermann]

On 2009/08/18 19:45, Peter Colberg pe...@colberg.org wrote:
 Both the workaround and the patch resolve the skipping playback.
 
 (Btw, the release-0.15.2 tag is missing in the git repository.)

Thanks again for the feedback.  I must have forgot to merge the
release tag from our release manager's repository...

Max




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

Bug#542102: mpd: audio skips once per second

[Max Kellermann]

On 2009/08/17 22:15, Peter Colberg pe...@colberg.org wrote:
 with the new version of mpd, I experience skipping audio about once per
 second, where a skip could be described as a crackling noise followed by
 a fast forward of a fraction of a second. I verified this behaviour for
 FLAC, Ogg and MP3 files.

Please enable verbose mode and watch the log file for related
messages.  Then try switching to an OSS output, and see if the same
problem occurs.

Max



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

Bug#542102: mpd: audio skips once per second

[Max Kellermann]

On 2009/08/17 22:53, Peter Colberg pe...@colberg.org wrote:
 Aug 17 22:41 : playlist: queue song 1:Miles Davis/Kind of Blue 
 (1997)/Miles Davis - Kind of Blue - 02 - Freddie Freeloader.flac

Nothing to see here, no underruns.. :(

  Then try switching to an OSS output, and see if the same
  problem occurs.
 
 A restart of mpd results in the following messages:

So does the problem occur with OSS?

Can you make a git bisect from release-0.15.1 to release-0.15.2 to
isolate the commit which broke playback for you?  It's very difficult
for me to find the cause, because I don't hear that problem over here.

Max



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

Bug#542102: mpd: audio skips once per second

[Max Kellermann]

On 2009/08/18 01:51, Peter Colberg pe...@colberg.org wrote:
 Reverting commit 7133f56 fixes the audio skips :-).

Thanks for the bisect!

I suspect this is an uninitialized variable.  Please try two
approaches at working around it:

1. mpc toggle twice (enter pause, leave pause) - this should
   initialize the pause flag retroactively

2. try the attached patch

If the patch fixes the problem, we'll release 0.15.3 soon.

Max
diff --git a/src/output_init.c b/src/output_init.c
index 04609bb..9274243 100644
--- a/src/output_init.c
+++ b/src/output_init.c
@@ -109,6 +109,7 @@ audio_output_init(struct audio_output *ao, const struct config_param *param,
 	ao-plugin = plugin;
 	ao-enabled = config_get_block_bool(param, enabled, true);
 	ao-open = false;
+	ao-pause = false;
 	ao-fail_timer = NULL;
 
 	pcm_convert_init(ao-convert_state);

Bug#541115: busybox: No longer creates tty[1-4] devices on s390

[Max Vozeler]

On Tue, Aug 11, 2009 at 09:56:43PM +0200, Frans Pop wrote:
 It looks like busybox also causes a failure on i386.
 
 If I boot a daily mini.iso, the boot hangs when executing the last line 
 from /sbin/init:
 exec /usr/sbin/chroot . /bin/busybox init /dev/console /dev/console 21

I'm seeing this also on amd64.

Replacing busybox-udeb with the older 1.13.3-1 results in a
working installer.

Max



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

Bug#539228: partman freezes with encrypted partitions

[Max Vozeler]

severity 539228 important
thanks

Hello,

On Thu, Jul 30, 2009 at 12:43:04AM +0200, da jedall wrote:
 When i try to install debian squeeze on usb key (netinstall)
 and when i try to create installation over encrypted fs in partman,partman
 reload and freeze at 52% of loading.
 The installation is in french ,partman works in french until the bug occurs.
 
 Next partman crashes,and i have a message saying loading partman 52%
 (in english this time!!) and all stay freezed at this point.

I will try to reproduce this and figure out what happens.

For the moment I'm lowering severity to important because 
the partitioning (with and without crypto) seems to be working
fine in general for the setups I tested today.

Max



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

Bug#515249: installation-reports: Various issues on IBM Power5 (lvm, multipath, yaboot.conf)

[Max Vozeler]

severity 515249 normal
clone 515249 -1
retitle -1 manual: Mention console=hvc0 for ppc?
reassign -1 installation-guide
thanks

On Sun, Feb 15, 2009 at 10:49:36AM +, Paul McEnery wrote:
 Comments/Problems:
 
 Initial boot: Maybe not soe much an error, I had to specify the
   console at the boot prompt console=hvc0,38400

There is no mention of hvc0 in the powerpc installation guide,
so it might be useful to add a mention there.

Is it common to have hvc0 on ppc? I know it only wrt. XEN.

Max



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

Bug#520285: netcfg fails to configure dhcp, segfault in libresolv

[Max Vozeler]

unarchive 517231
reassign 520285 debian-installer
forcemerge 517231 520285
archive 517231
thanks

This bug was another instance of the problem described
in #517231 and should no longer occur in current images.

Thanks for your bug report.

Max



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

Bug#529725: (no subject)

[Max Zimmermann]

I can confirm this, same here on SID amd64.

Cheers,

Max



signature.asc
Description: OpenPGP digital signature

Bug#527504: #527504: Patch fixing FTBFS

[Max Bowsher]

FTBFS is due to incompatible changes in cdbs

Attached is a patch I am successfully using to build PPA packages in
Ubuntu Karmic.

Max.
--- a/debian/rules  Fri Apr 17 00:33:15 2009 +0100
+++ b/debian/rules  Mon May 11 00:15:27 2009 +0100
@@ -66,3 +66,13 @@
@echo Restore it from sources before building the package
@echo Aborting.
exit 1
+
+# Fairly arcane and slightly dodgy hack to make the build work with cdbs = 0.4.53.
+# The problem is essentially that before, cdbs bound the 'setup.py install'
+# phase to common-install-{arch,indep}, but now it binds it to the install/%
+# target of one specific binary package... which is a bit of a nasty assumption
+# to make, and breaks us, since we split the installed python-stuff over two
+# binary packages.  Hence, we make installation of our secondary binary package
+# depend on installation of the primary one on which cdbs actually hangs the
+# install commands:
+install/mercurial-common:: install/mercurial


signature.asc
Description: OpenPGP digital signature

Bug#525403: See other bugs

[Max Bowsher]

http://bugs.debian.org/522426 - wishlist new upstream version

http://bugs.debian.org/527504 - FTBFS that has been blocking new
uploads, *with patch*



signature.asc
Description: OpenPGP digital signature

Bug#521672: FTBFS with linux-image 2.6.29

[Max Vozeler]

reassign linux-2.6 2.6.29-1
merge 521472 521672
thanks

Hi Dmitry,

On Sun, Mar 29, 2009 at 02:45:05PM +0400, Dmitry E. Oboukhov wrote:
 Usually I use the command like as
 
 module-assistant -l 2.6.29-1-686 a-i loop-aes-source
 
 but with 2.6.29 (sid) kernel build has failed.

This is caused by #521472.

All module builds for -686 are affected, as far
as I can tell.

Thanks for your bug report,

Max



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

Bug#521672: FTBFS with linux-image 2.6.29

[Max Vozeler]

Hi Dmitry,

On Sun, Mar 29, 2009 at 01:41:47PM +0200, Max Vozeler wrote:
 On Sun, Mar 29, 2009 at 02:45:05PM +0400, Dmitry E. Oboukhov wrote:
  Usually I use the command like as
  
  module-assistant -l 2.6.29-1-686 a-i loop-aes-source
  
  but with 2.6.29 (sid) kernel build has failed.
 
 This is caused by #521472.
 
 All module builds for -686 are affected, as far
 as I can tell.

Btw, as workaround until #521472 is fixed:

I took arch/x86/Makefile_32.cpu from vanilla 2.6.29,
copied into /usr/src/linux-headers-2.6.29-1-686.

Max



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

Bug#476376: Bug#476377: Please port to new libmpcdec API

[Max Kellermann]

On 2009/03/21 08:57, Sebastian Dröge sl...@circular-chaos.org wrote:
 libmpc will be uploaded to unstable in the next days. Please port your
 package to the new API ASAP, it will most probably fail to build after
 the upload to unstable.

I do not understand the hurry.  Do you plan to remove the old libmpc
package?  The Debian shared library policy guarantees that older
package continue to work/build (with older SO versions) even when a
new API of a library gets uploaded.  Please explain how this bug
report relates to the Debian shared library policy.

Max



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

Bug#512841: Segmentation fault on startup

[Max Kellermann]

Package: smc
Version: 1.6-1
Severity: grave

When I start smc, the screen flickers black, then the process crashes
immediately.

Backtrace:

#0  0x7fd929df003d in iGetIntegervImage () from /usr/lib/libIL.so.1
#1  0x7fd92a0fc283 in iluGetImageInfo () from /usr/lib/libILU.so.1
#2  0x7fd92a300364 in CEGUI::DevILImageCodec::load () from 
/usr/lib/libCEGUIDevILImageCodec.so
#3  0x7fd93762e7f5 in CEGUI::OpenGLTexture::loadFromFile () from 
/usr/lib/libCEGUIOpenGLRenderer.so.0
#4  0x7fd93762ccc8 in CEGUI::OpenGLRenderer::createTexture () from 
/usr/lib/libCEGUIOpenGLRenderer.so.0
#5  0x7fd937913bd6 in CEGUI::Imageset_xmlHandler::elementImagesetStart () 
from /usr/lib/libCEGUIBase.so.1
#6  0x7fd93791430b in CEGUI::Imageset_xmlHandler::elementStart () from 
/usr/lib/libCEGUIBase.so.1
#7  0x7fd929813b25 in CEGUI::XercesHandler::startElement () from 
/usr/lib/libCEGUIXercesParser.so
#8  0x7fd932d549f6 in xercesc_2_8::SAX2XMLReaderImpl::startElement () from 
/usr/lib/libxerces-c.so.28
#9  0x7fd932d147b1 in xercesc_2_8::IGXMLScanner::scanStartTagNS () from 
/usr/lib/libxerces-c.so.28
#10 0x7fd932d16f9d in xercesc_2_8::IGXMLScanner::scanContent () from 
/usr/lib/libxerces-c.so.28
#11 0x7fd932d171a8 in xercesc_2_8::IGXMLScanner::scanDocument () from 
/usr/lib/libxerces-c.so.28
#12 0x7fd932d53fea in xercesc_2_8::SAX2XMLReaderImpl::parse () from 
/usr/lib/libxerces-c.so.28
#13 0x7fd929811caa in CEGUI::XercesParser::doParse () from 
/usr/lib/libCEGUIXercesParser.so
#14 0x7fd9298127e8 in CEGUI::XercesParser::parseXMLFile () from 
/usr/lib/libCEGUIXercesParser.so
#15 0x7fd93790e0f9 in CEGUI::Imageset::load () from 
/usr/lib/libCEGUIBase.so.1
#16 0x7fd93790e387 in CEGUI::Imageset::Imageset () from 
/usr/lib/libCEGUIBase.so.1
#17 0x7fd937911a63 in CEGUI::ImagesetManager::createImageset () from 
/usr/lib/libCEGUIBase.so.1
#18 0x7fd93791e846 in CEGUI::Scheme::loadXMLImagesets () from 
/usr/lib/libCEGUIBase.so.1
#19 0x7fd937921ecd in CEGUI::Scheme::loadResources () from 
/usr/lib/libCEGUIBase.so.1
#20 0x7fd937922452 in CEGUI::Scheme::Scheme () from 
/usr/lib/libCEGUIBase.so.1
#21 0x7fd937924763 in CEGUI::SchemeManager::loadScheme () from 
/usr/lib/libCEGUIBase.so.1
#22 0x00533ac6 in ?? ()
#23 0x0043500e in ?? ()
#24 0x00439415 in ?? ()
#25 0x7fd936b4c1a6 in __libc_start_main () from /lib/libc.so.6
#26 0x0040eec9 in ?? ()
#27 0x7fff41083ab8 in ?? ()
#28 0x001c in ?? ()
#29 0x0001 in ?? ()
#30 0x7fff41084ca8 in ?? ()
#31 0x in ?? ()

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.28-woodpecker (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages smc depends on:
ii  libboost-filesystem1.34.11.34.1-14   filesystem operations (portable pa
ii  libc62.7-18  GNU C Library: Shared libraries
ii  libcegui-mk2-1   0.5.0-4.1   Crazy Eddie's GUI (libraries)
ii  libcegui-mk2-dev 0.5.0-4.1   Crazy Eddie's GUI (development fil
ii  libgcc1  1:4.3.2-1.1 GCC support library
ii  libgl1-mesa-glx [libgl1] 7.0.3-7 A free implementation of the OpenG
ii  libglu1-mesa [libglu1]   7.0.3-7 The OpenGL utility library (GLU)
ii  libpng12-0   1.2.27-2PNG library - runtime
ii  libsdl-image1.2  1.2.6-3 image loading library for Simple D
ii  libsdl-mixer1.2  1.2.8-4 mixer library for Simple DirectMed
ii  libsdl-ttf2.0-0  2.0.9-1 ttf library for Simple DirectMedia
ii  libsdl1.2debian  1.2.13-2Simple DirectMedia Layer
ii  libstdc++6   4.3.2-1.1   The GNU Standard C++ Library v3
ii  libx11-6 2:1.1.5-2   X11 client-side library
ii  smc-data 1.6-1   levels and game data for Secret Ma

smc recommends no packages.

smc suggests no packages.

-- no debconf information



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

Bug#510205: buffer overflow in libaudiofile

[Max Kellermann]

Package: libaudiofile0
Version: 0.2.6-6
Severity: critical

Today, the Music Player Daemon project received a bug report from
Anton Khirnov: MPD crashed when attempting to play a WAV file.  file
says:

 RIFF (little-endian) data, WAVE audio, Microsoft ADPCM, stereo 44100
 Hz

The MPD bug report: http://musicpd.org/mantis/view.php?id=1915

The test file: http://filebin.ca/meqmyu/max_theme.wav

Turns out that this is a bug in libaudiofile.  When attempting to
decode the file, libaudiofile writes past the buffer in msadpcm.c:194

  code = *encoded  4;
  newSample = ms_adpcm_decode_sample(state[0], code,
  coefficient[0]);
  *decoded++ = newSample;

Valgrind output:

 ==4680== Invalid write of size 2
 ==4680==at 0x8CF0478: ms_adpcm_run_pull (msadpcm.c:194)
 ==4680==by 0x8CEAF75: _AFpull (modules.c:111)
 ==4680==by 0x8CF11A3: int2rebufferf2vrun_pull (rebuffer.template:409)
 ==4680==by 0x8CDE4ED: afReadFrames (data.c:228)
 ==4680==by 0x435EBA: audiofile_streamdecode (audiofile_plugin.c:159)
 ==4680==by 0x4145A2: decoder_stream_decode (decoder_thread.c:49)
 ==4680==by 0x414A5C: decoder_run (decoder_thread.c:189)
 ==4680==by 0x414B7B: decoder_task (decoder_thread.c:214)
 ==4680==by 0x72E0453: g_thread_create_proxy (gthread.c:635)
 ==4680==by 0x62CBFC6: start_thread (pthread_create.c:297)
 ==4680==by 0xAA595AC: clone (in /usr/lib/debug/libc-2.7.so)
 ==4680==  Address 0x15a66de8 is 0 bytes after a block of size 4,096 alloc'd
 ==4680==at 0x4C2260E: malloc (vg_replace_malloc.c:207)
 ==4680==by 0x8CDF96A: _af_malloc (util.c:122)
 ==4680==by 0x8CEEEBA: _AFsetupmodules (modules.c:2539)
 ==4680==by 0x8CDE151: afGetFrameCount (format.c:218)
 ==4680==by 0x435CDD: audiofile_streamdecode (audiofile_plugin.c:141)
 ==4680==by 0x4145A2: decoder_stream_decode (decoder_thread.c:49)
 ==4680==by 0x414A5C: decoder_run (decoder_thread.c:189)
 ==4680==by 0x414B7B: decoder_task (decoder_thread.c:214)
 ==4680==by 0x72E0453: g_thread_create_proxy (gthread.c:635)
 ==4680==by 0x62CBFC6: start_thread (pthread_create.c:297)
 ==4680==by 0xAA595AC: clone (in /usr/lib/debug/libc-2.7.so)

A quick look at the code revealed that the allocated buffer size
depended on the following formula:

  bufsize = outc-nframes * _af_format_frame_size(outc-f, AF_TRUE);

outc-nframes basically comes from _AF_ATOMIC_NVFRAMES (1024), because
the msadpcm module does not implement the max_pull callback.  This
results in a 4096 byte allocation in modules.c:2539 (frame size is 4).

In ms_adpcm_decode_block(), msadpcm-samplesPerBlock is set to 2036
(unverified value from the input file header).  outputLength is 8144,
which obviously does not fit into the allocated 4096 byte buffer.

I could reproduce the same crash with normalize-audio max_theme.wav.
The real crash happens after closing the file, probably due to heap
corruption.  valgrind notices the problem before the crash actually
occurs.

Severity critical because this is may be used for a remote DoS
attack on software like MPD.  I did not investigate whether it is
possible to inject code this way.  Chances are good, since arbitrary
amounts of heap can be overwritten.

Both Debian Etch and Lenny are affected.

Solution: don't use libaudiofile.  Change libaudiofile to allocate the
correct buffer size.  Add buffer size checks to libaudiofile.

Regards,
Max Kellermann



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

Bug#506713: Will the fix go to lenny?

[Max Dmitrichenko]

Ok. Seems that bug is fixed in experimental. Two questions.

1) Will this version be uploaded to unstable and then to testing
before lenny is released?

2) According to Ben, any library on SPARC is a subject to this bug. I
think it is rather hard to create a list of libraries which have
functions which return structures and refer to the global data. So,
potentially every library can suffer from this. Will all libraries be
recompiled due to this bug?

P.S.: Please add me on the CC-list for further messages.



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

Bug#490999:

[Max Dmitrichenko]

 * When a newer compiler package is available for a distribution, is
   everything rebuilt with it?


No.

But this is definitely non-sense. IIRC potentially every library is a
subject to be affected by the compiler's bug. The fact that other libs
don't cause such a destructive behavior (as Qt with kicker) is just a
matter of luck.

Personally I noticed that Konqueror on sparc is also VERY unstable.
Every third site opened by it crashes the Konqueror (or KJS). This is
not reproducable on i386. So, IMHO, this is somehow related to this
bug.

I think that investigate weather each crash is related to compiler's
bug or not is quite expensive an ineffective task. I think that
everything should be recompiled.

--
  Max



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#508133: audacity: munmap_chunk(): invalid pointer: 0x00000000026f4eb0

[Max Kellermann]

/de156ccd2eddbdc19d37a45b8b2aac9c-x86-64.cache-2
7f4c0e5e6000-7f4c0e5e8000 r--s  fd:00 893480949  
/home/max/.fontconfig/ddd4086aec35a5275babba44bb759c3c-x86-64.cache-2
7f4c0e5e8000-7f4c0e5e9000 r--s  08:03 228529 
/var/cache/fontconfig/4794a0821666d79190d59a36cb4f44b5-x86-64.cache-2
7f4c0e5e9000-7f4c0e5eb000 r--s  08:03 228527 
/var/cache/fontconfig/2c5ba8142dffc8bf0377700342b8ca1a-x86-64.cache-2
7f4c0e5eb000-7f4c0e5ed000 r--s  08:03 228504 
/var/cache/fontconfig/7ef2298fde41cc6eeb7af42e48b7d293-x86-64.cache-2
7f4c0e5ed000-7f4c0e5ef000 r--s  fd:00 893480942  
/home/max/.fontconfig/dc1cca2ace21a62240d4a8c4ecd7549a-x86-64.cache-2
7f4c0e5ef000-7f4c0e5f6000 r--s  08:02 27059700   
/usr/lib/gconv/gconv-modules.cache
7f4c0e5f6000-7f4c0e5f9000 rw-p 7f4c0e5f6000 00:00 0 
7f4c0e5f9000-7f4c0e5fb000 rw-p 0001b000 08:02 26818599   
/lib/ld-2.7.so
7fff165e5000-7fff165fa000 rw-p 7ffea000 00:00 0  [stack]
7fff165fe000-7fff165ff000 r-xp 7fff165fe000 00:00 0  [vdso]
ff60-ff601000 r-xp  00:00 0  
[vsyscall]
Aborted



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#505901: ABI breakage due to 02_public-headers.dpatch

[Max Kellermann]

Package: libfaad-dev
Version: 2.6.1-3.1
Severity: grave

The patch debian/patches/02_public-headers.dpatch breaks both the faad
API and ABI.  When compiling code against the Debian package
libfaad-dev, gcc emits the following error messages (with -Werror):

decoder/aac_plugin.c: In function 'getAacFloatTotalTime':
decoder/aac_plugin.c:275: error: passing argument 4 of 'NeAACDecInit'
from incompatible pointer type
decoder/aac_plugin.c: In function 'aac_stream_decode':
decoder/aac_plugin.c:346: error: passing argument 4 of 'NeAACDecInit'
from incompatible pointer type

Upstream has unsigned long arguments where the Debian package has
uint32_t.  Code which tries to pass an unsigned long pointer here
will break both on the ABI and the API level, and this may result in
corrupted data (when copying a binary compiled with upstream, the
upper 32 bit of the long are undefined), or in a buffer overflow (when
running a Debian binary on a non-Debian machine with unmodified
libfaad, which writes 64 bit when there is room only for 32 bit).

Severity grave because Debian introduces a dangerous ABI
incompatibility with this patch, which may result in buffer overflows
(AMD64 or other platforms with a 64 bit long).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#505901: libfaad and uint32_t....

[Max Kellermann]

severity 505901 minor
thanks

Sorry for the traffic - after some more research, I found that the
libfaad headers are inconsistent: internally, it uses uint32_t*.  This
is a very unfortante situation, since even non-bugged software will
break on Debian, assuming that passing a long pointer is correct.

There is no documentation on that issue in the Debian package - no
README.Debian, and no documentation in the patch file.  Would you mind
to add it?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#504656: xserver-xorg-input-synaptics: Stops working after logoff

[Max Dmitrichenko]

2008/11/6, Julien Cristau [EMAIL PROTECTED]:
 Actually, it works just fine here, so that justification seems wrong.
 You didn't send your config or log, though, so it's hard to tell.

Indeed. It works. This behavior seems to be linked with similar evdev
bug because now with new evdev driver synaptics works well.

I think bug can be closed now.

--
  Max



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#504536:

[Max Dmitrichenko]

Synaptics driver on my laptop also has the same bug. In this light, I
suspect that X server input layer introduces some change which breaks
input drivers.

Can someone with more detailed knowledge of X investigate this problem?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#504656: xserver-xorg-input-synaptics: Stops working after logoff

[Max Dmitrichenko]

Package: xserver-xorg-input-synaptics
Version: 0.14.7~git20070706-4~dmitrmax.1
Severity: grave
Tags: patch
Justification: renders package unusable


Driver forgets to ungrab the event device so the next time it is grabbed EBUSY 
is returned.
This happens e.g. when I logoff from KDE session and return to KDM screen. Only 
restarting
the X server helps.

Bellow patch that fixes the problem.

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

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

Versions of packages xserver-xorg-input-synaptics depends on:
ii  libc6 2.7-15 GNU C Library: Shared libraries
ii  libx11-6  2:1.1.5-2  X11 client-side library
ii  libxext6  2:1.0.4-1  X11 miscellaneous extension librar
ii  libxi62:1.1.3-1  X11 Input extension library
ii  xserver-xorg-core 2:1.4.2-7  Xorg X server - core server

xserver-xorg-input-synaptics recommends no packages.

Versions of packages xserver-xorg-input-synaptics suggests:
pn  gsynaptics | ksynaptics | qsy none (no description available)

-- no debconf information


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

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

Versions of packages xserver-xorg-input-synaptics depends on:
ii  libc6 2.7-15 GNU C Library: Shared libraries
ii  libx11-6  2:1.1.5-2  X11 client-side library
ii  libxext6  2:1.0.4-1  X11 miscellaneous extension librar
ii  libxi62:1.1.3-1  X11 Input extension library
ii  xserver-xorg-core 2:1.4.2-7  Xorg X server - core server

xserver-xorg-input-synaptics recommends no packages.

Versions of packages xserver-xorg-input-synaptics suggests:
pn  gsynaptics | ksynaptics | qsy none (no description available)

-- no debconf information
--- xfree86-driver-synaptics-0.14.7~git20070706.orig/eventcomm.c
+++ xfree86-driver-synaptics-0.14.7~git20070706/eventcomm.c
@@ -58,6 +58,16 @@
 static void
 EventDeviceOffHook(LocalDevicePtr local)
 {
+SynapticsPrivate *priv = (SynapticsPrivate *) (local-private);
+
+if (priv-synpara-grab_event_device) {
+   int ret;
+   SYSCALL(ret = ioctl(local-fd, EVIOCGRAB, (pointer)0));
+   if (ret  0) {
+   xf86Msg(X_WARNING, %s can't ungrab event device, errno=%d\n,
+   local-name, errno);
+   }
+}
 }
 
 static void

Bug#490999: kicker: Confirmed

[Max Dmitrichenko]

Thanks Modestas!

Running kicker --nofork under gdb produces the same crash with SIGBUS.
Tested several times - backtrace doesn't differ except for object
addresses. GDB's backtrace is attached.

What's next? Is there a way to build only kicker from sources? Not
necessary to build a package. Rebuilding the whole kdebase on my sparc
will last 6-10 hours :(

--
  Max



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#490999: Ответ: Bug#490999: kicker: Confirmed

[Max Dmitrichenko]

2008/11/5, Modestas Vainius [EMAIL PROTECTED]:
 Hello,

 antradienis 04 Lapkritis 2008, Max Dmitrichenko rašė:
 addresses. GDB's backtrace is attached.
 Is it? I don't see an attachment.

Oops... Another try :)

 What's next? Is there a way to build only kicker from sources?
 I'm afraid there is no supported way to do this. You can try the following
 though. Run ./configure and then cd to kicker build directory and run
 'make'.
Ok, I'll try.

--
  Max
(gdb) bt
#0  0xf7fa4168 in ?? () from /lib/ld-linux.so.2
#1  0xf7faaa34 in ?? () from /lib/ld-linux.so.2
#2  0xf5a7e9bc in DigitalClock::updateClock (this=0x19c8b8) at 
/build/buildd/kdebase-3.5.9.dfsg.1/./kicker/applets/clock/clock.cpp:316
#3  0xf5a83900 in ClockApplet::reconfigure (this=0x17e9f0) at 
/build/buildd/kdebase-3.5.9.dfsg.1/./kicker/applets/clock/clock.cpp:1179
#4  0xf5a84038 in ClockApplet (this=0x17e9f0, [EMAIL PROTECTED], 
t=KPanelApplet::Normal, actions=4, parent=value optimized out,
name=value optimized out) at 
/build/buildd/kdebase-3.5.9.dfsg.1/./kicker/applets/clock/clock.cpp:902
#5  0xf5a84224 in init (parent=0x17ae80, [EMAIL PROTECTED]) at 
/build/buildd/kdebase-3.5.9.dfsg.1/./kicker/applets/clock/clock.cpp:75
#6  0xf7eff710 in PluginManager::loadApplet (this=0x38c88, [EMAIL PROTECTED], 
parent=0x17ae80)
at 
/build/buildd/kdebase-3.5.9.dfsg.1/./kicker/kicker/core/pluginmanager.cpp:158
#7  0xf7f06698 in AppletContainer (this=0x17aa08, [EMAIL PROTECTED], 
opMenu=value optimized out, immutable=false,
parent=value optimized out) at 
/build/buildd/kdebase-3.5.9.dfsg.1/./kicker/kicker/core/container_applet.cpp:102
#8  0xf7f06f94 in PluginManager::createAppletContainer (this=0x38c88, [EMAIL 
PROTECTED], isStartup=true,
configFile=value optimized out, opMenu=0xcc218, parent=0xd1f60, 
isImmutable=value optimized out)
at 
/build/buildd/kdebase-3.5.9.dfsg.1/./kicker/kicker/core/pluginmanager.cpp:290
#9  0xf7f0f3b8 in ContainerArea::loadContainers (this=0xcf240, 
containers=value optimized out)
at 
/build/buildd/kdebase-3.5.9.dfsg.1/./kicker/kicker/core/containerarea.cpp:333
#10 0xf7f0f5e8 in ContainerArea::initialize (this=0xcf240, 
useDefaultConfig=true)
at 
/build/buildd/kdebase-3.5.9.dfsg.1/./kicker/kicker/core/containerarea.cpp:132
#11 0xf7f0f770 in PanelExtension::populateContainerArea (this=0xb2560)
at 
/build/buildd/kdebase-3.5.9.dfsg.1/./kicker/kicker/core/panelextension.cpp:107
#12 0xf7f01b14 in PanelExtension::qt_invoke (this=value optimized out, 
_id=50, _o=0xffb30438) at ./panelextension.moc:99
#13 0xf714f194 in QObject::activate_signal (this=0xbb818, clist=0xd28b0, 
o=0xffb30438) at kernel/qobject.cpp:2359
#14 0xf748f668 in QSignal::signal (this=0xbb818, t0=value optimized out) at 
.moc/release-shared-mt/moc_qsignal.cpp:100
#15 0xf7169f44 in QSignal::activate (this=0xbb818) at kernel/qsignal.cpp:215
#16 0xf7171344 in QSingleShotTimer::event (this=0xbb7f0) at 
kernel/qtimer.cpp:289
#17 0xf70ebea8 in QApplication::internalNotify (this=0x65800, receiver=0xbb7f0, 
e=0xffb30860) at kernel/qapplication.cpp:2638
#18 0xf70ecde8 in QApplication::notify (this=0x2f470, receiver=0xbb7f0, 
e=0xffb30860) at kernel/qapplication.cpp:2526
#19 0xf6dc64f0 in KApplication::notify (this=0x2f470, receiver=0xbb7f0, 
event=0xffb30860)
at /build/buildd/kdelibs-3.5.9.dfsg.1/./kdecore/kapplication.cpp:550
#20 0xf70e0494 in QEventLoop::activateTimers (this=value optimized out) at 
kernel/qapplication.h:523
#21 0xf7096ef4 in QEventLoop::processEvents (this=0x56828, flags=0) at 
kernel/qeventloop_x11.cpp:392
#22 0xf71044f4 in QEventLoop::processEvents (this=0x56828, flags=value 
optimized out, maxTime=3000) at kernel/qeventloop.cpp:261
#23 0xf7f10814 in ExtensionManager::initialize (this=0x786e0)
at 
/build/buildd/kdebase-3.5.9.dfsg.1/./kicker/kicker/core/extensionmanager.cpp:129
#24 0xf7f11224 in ExtensionManager::qt_invoke (this=0x786e0, _id=3, 
_o=0xffb30d00) at ./extensionmanager.moc:122
#25 0xf714f194 in QObject::activate_signal (this=0x38bf8, clist=0x38db8, 
o=0xffb30d00) at kernel/qobject.cpp:2359
#26 0xf748f668 in QSignal::signal (this=0x38bf8, t0=value optimized out) at 
.moc/release-shared-mt/moc_qsignal.cpp:100
#27 0xf7169f44 in QSignal::activate (this=0x38bf8) at kernel/qsignal.cpp:215
#28 0xf7171344 in QSingleShotTimer::event (this=0x38bd0) at 
kernel/qtimer.cpp:289
#29 0xf70ebea8 in QApplication::internalNotify (this=0x65800, receiver=0x38bd0, 
e=0xffb31128) at kernel/qapplication.cpp:2638
#30 0xf70ecde8 in QApplication::notify (this=0x2f470, receiver=0x38bd0, 
e=0xffb31128) at kernel/qapplication.cpp:2526
#31 0xf6dc64f0 in KApplication::notify (this=0x2f470, receiver=0x38bd0, 
event=0xffb31128)
at /build/buildd/kdelibs-3.5.9.dfsg.1/./kdecore/kapplication.cpp:550
#32 0xf70e0494 in QEventLoop::activateTimers (this=value optimized out) at 
kernel/qapplication.h:523
#33 0xf7096ef4 in QEventLoop::processEvents (this=0x56828, flags=4) at 
kernel/qeventloop_x11.cpp:392
---Type return to continue, or q return