Bug#954334: gnome-music: Gnome music crashes at launch

[Aurelien Jacobs]

Package: gnome-music
Version: 3.36.0-1
Severity: normal

I'm on unstable and gnome-music crashes at launch with the following traceback
:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gnomemusic/window.py", line 215, in 
_on_songs_available
self._switch_to_player_view()
  File "/usr/lib/python3/dist-packages/gnomemusic/window.py", line 261, in 
_switch_to_player_view
self.views[View.SONG] = SongsView(self._app)
  File "/usr/lib/python3/dist-packages/gnomemusic/views/songsview.py", line 54, 
in __init__
self._add_list_renderers()
  File "/usr/lib/python3/dist-packages/gnomemusic/views/songsview.py", line 
121, in _add_list_renderers
attrs.insert(Pango.AttrFontFeatures.new("tnum=1"))
AttributeError: type object 'AttrFontFeatures' has no attribute 'new'

It seems to be due to libpango-1.0-0 1.42.4-8.
I was able to fix the issue by upgrading libpango-1.0-0 to experimental
1.44.7-2.



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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages gnome-music depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  gir1.2-dazzle-1.03.36.0-1
ii  gir1.2-glib-2.0  1.62.0-5+b1
ii  gir1.2-goa-1.0   3.36.0-1
ii  gir1.2-grilo-0.3 0.3.12-1
ii  gir1.2-gst-plugins-base-1.0  1.16.2-2
ii  gir1.2-gstreamer-1.0 1.16.2-2
ii  gir1.2-gtk-3.0   3.24.14-1
ii  gir1.2-mediaart-2.0  1.9.4-2
ii  gir1.2-soup-2.4  2.70.0-1
ii  gir1.2-totemplparser-1.0 3.26.5-1
ii  gir1.2-tracker-2.0   2.3.4-1
ii  gnome-settings-daemon3.36.0-1
ii  grilo-plugins-0.30.3.11-1
ii  libc62.30-2
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-3
ii  libglib2.0-0 2.64.1-1
ii  libgtk-3-0   3.24.14-1
ii  libpango-1.0-0   1.44.7-2
ii  libpangocairo-1.0-0  1.44.7-2
ii  python3  3.8.2-1
ii  python3-gi   3.36.0-1
ii  python3-gi-cairo 3.36.0-1
ii  python3-requests 2.22.0-2
ii  tracker  2.3.4-1

gnome-music recommends no packages.

gnome-music suggests no packages.

-- no debconf information

Bug#895008: kicad: can't start pcbnew

[Aurelien Jacobs]

On Sun, Apr 08, 2018 at 08:00:52AM +0200, Carsten Schoenert wrote:
> Hello Aurelien,
> 
> On Sat, Apr 07, 2018 at 11:37:25PM +0200, Aurelien Jacobs wrote:
> ... 
> > I've tested this new build, and I can now start pcbnew including with
> > latest version python-wxgtk3.0, so this seems to fix the issue. Thanks !
> 
> excellent, thanks for testing, I also experienced no segfaulting issues
> any more while starting.
> 
> > Now this has uncovered another GTK+3 related issue for me in pcbnew.
> > If I enable "Modern Toolset (Accelerated)" in the Preferences menu,
> > pcbnew segfaults. It looks like it might be related to using
> > wxGLCanvasX11 (ie. calling libGLX and libX11) even though this GTK+3
> > build is now using Wayland instead of X11.
> 
> Hmm, I've no deeper knowledge about the internals of wayland vs. X11 so
> I probably can't help much here.
> It's known that pcbnew will crash under Wayland and the Modern Toolset
> in some cases. Please note the information on
> 
> http://kicad-pcb.org/help/known-system-related-issues/#_wayland
> 
> As you got a informative backtrace it mayed be a good idea to add this
> to the bug report mentioned on the above linked section. As this is now
> a different problem to the original bug report here I'd like close this
> report by a upload of this rebuilded version of src:kicad and create
> later a new report with the backtrace information from you.

Sure, this is the way to go.

> If you could spend some time to dig into this new issue under wayland
> I'd really appreciate this!

This is an upstream issue. It is tracked here for kicad:
https://bugs.launchpad.net/kicad/+bug/1755360

But the issue is actually in wxWidgets and is tracked here:
https://trac.wxwidgets.org/ticket/17702

This is not easy to fix, so we will probably have to live with it for
quite some time. It might be good to document this limitation in the
README.Debian the same way kicad just documented it here:
https://github.com/KiCad/kicad-website/pull/276/commits/f1adadb744819ff8fd164ef0446a140f7fd23586
And maybe also document the solution of running:
  GDK_BACKEND=x11 kicad
for those who really want accelerated backend.

> Back to the origin of this report.
> Upstream is planning to release a RC2 of KiCad 5 with a string freeze.
> The feature freeze was done with RC1 so only bugfixing will be done on
> KiCad. I plan to upload these RC2 related version to unstable to get a
> broader base for testing. 
> I don't have plans to upload a rebuild for KiCad 4.0.7 in unstable.

Sounds OK to me, but it might be good in the meantime to upload your
build using libwxgtk3.0-gtk3-dev in experimental (it all depends if
RC2 will be released in just a few days, or several weeks).

Thanks agains.
--
Aurel

Bug#895008: kicad: can't start pcbnew

[Aurelien Jacobs]

On Sat, Apr 07, 2018 at 09:33:08PM +0200, Carsten Schoenert wrote:
> Hi,
> 
> please test a rebuild of KiCad 5.0.05.0.0~rc1+dfsg1+20180318 which is
> using libwxgtk3.0-gtk3-dev to get a proper GTK3 bindings.

I've tested this new build, and I can now start pcbnew including with
latest version python-wxgtk3.0, so this seems to fix the issue. Thanks !

Now this has uncovered another GTK+3 related issue for me in pcbnew.
If I enable "Modern Toolset (Accelerated)" in the Preferences menu,
pcbnew segfaults. It looks like it might be related to using
wxGLCanvasX11 (ie. calling libGLX and libX11) even though this GTK+3
build is now using Wayland instead of X11.

Here is the backtrace I got:

Thread 1 "kicad" received signal SIGSEGV, Segmentation fault.
0x723aac49 in XQueryExtension () from 
/usr/lib/x86_64-linux-gnu/libX11.so.6
(gdb) disassemble $pc-32,$pc+32
Dump of assembler code from 0x723aac29 to 0x723aac69:
   0x723aac29 : sub$0x38,%rsp
   0x723aac2d : mov%fs:0x28,%rax
   0x723aac36 : mov%rax,0x28(%rsp)
   0x723aac3b : xor%eax,%eax
   0x723aac3d : mov0x968(%rdi),%rax
   0x723aac44 : test   %rax,%rax
   0x723aac47 : je 0x723aac4b 

=> 0x723aac49 : callq  *(%rax)
   0x723aac4b : mov$0x8,%edx
   0x723aac50 : mov$0x62,%esi
   0x723aac55 : mov%rbx,%rdi
   0x723aac58 : callq  0x7238db90 
<_XGetRequest@plt>
   0x723aac5d : test   %rbp,%rbp
   0x723aac60 : mov%rax,%r15
   0x723aac63 : je 0x723aad10 

End of assembler dump.
(gdb) bt
#0  0x723aac49 in XQueryExtension () at 
/usr/lib/x86_64-linux-gnu/libX11.so.6
#1  0x7fffef2ea3b2 in  () at /usr/lib/x86_64-linux-gnu/libGLX.so.0
#2  0x7fffef2e6415 in glXQueryVersion () at 
/usr/lib/x86_64-linux-gnu/libGLX.so.0
#3  0x77bcfe95 in wxGLCanvasX11::GetGLXVersion() () at 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#4  0x77bd0535 in wxGLCanvasX11::ConvertWXAttrsToGL(int const*, int*, 
unsigned long) () at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#5  0x77bd0d68 in wxGLCanvasX11::InitXVisualInfo(int const*, 
__GLXFBConfigRec***, XVisualInfo**) () at 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#6  0x77bd1e70 in wxGLCanvas::Create(wxWindow*, int, wxPoint const&, 
wxSize const&, long, wxString const&, int const*, wxPalette const&) () at 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#7  0x77bd2013 in wxGLCanvas::wxGLCanvas(wxWindow*, int, int const*, 
wxPoint const&, wxSize const&, long, wxString const&, wxPalette const&) () at 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#8  0x7fffd1aedbd9 in HIDPI_GL_CANVAS::HIDPI_GL_CANVAS(wxWindow*, int, int 
const*, wxPoint const&, wxSize const&, long, wxString const&, wxPalette const&) 
(this=0x585c4ea0, parent=, id=, 
attribList=, pos=..., size=..., style=8192, name=..., 
palette=...) at ./common/gal/hidpi_gl_canvas.cpp:38
#9  0x7fffd1b09285 in 
KIGFX::OPENGL_GAL::OPENGL_GAL(KIGFX::GAL_DISPLAY_OPTIONS&, wxWindow*, 
wxEvtHandler*, wxEvtHandler*, wxString const&) (this=0x585c4bb0, 
aDisplayOptions=..., aParent=0x57d7f120, aMouseListener=0x57d7f120, 
aPaintListener=0x57d7f120, aName=...) at 
./common/gal/opengl/opengl_gal.cpp:74
#10 0x7fffd1ae4b84 in 
EDA_DRAW_PANEL_GAL::SwitchBackend(EDA_DRAW_PANEL_GAL::GAL_TYPE) 
(this=this@entry=0x57d7f120, aGalType=EDA_DRAW_PANEL_GAL::GAL_TYPE_OPENGL) 
at ./common/draw_panel_gal.cpp:350
#11 0x7fffd189a01e in 
PCB_DRAW_PANEL_GAL::SwitchBackend(EDA_DRAW_PANEL_GAL::GAL_TYPE) 
(this=0x57d7f120, aGalType=) at 
./pcbnew/pcb_draw_panel_gal.cpp:396
#12 0x7fffd19e997f in 
EDA_DRAW_FRAME::SwitchCanvas(EDA_DRAW_PANEL_GAL::GAL_TYPE) 
(this=0x57d652b0, aCanvasType=EDA_DRAW_PANEL_GAL::GAL_TYPE_OPENGL) at 
./common/draw_frame.cpp:1195
#13 0x7fffd147d249 in PCB_EDIT_FRAME::OnSwitchCanvas(wxCommandEvent&) 
(this=0x57d652b0, aEvent=...) at ./pcbnew/pcb_edit_frame.cpp:1215
#14 0x7654a8ce in 
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#15 0x7654a9d3 in wxEventHashTable::HandleEvent(wxEvent&, 
wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#16 0x7654ad9b in wxEvtHandler::TryHereOnly(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#17 0x7fffd1a0e1eb in EDA_BASE_FRAME::ProcessEvent(wxEvent&) 
(this=0x57d652b0, aEvent=...) at 

Bug#895008: kicad: can't start pcbnew

[Aurelien Jacobs]

Hello,

I can confirm this issue.

Since I upgraded my sid install today, pcbnew fails to start with those
kind of messages :

../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxCommandEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxNotifyEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxScrollEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" 
failed in Register(): Class "wxScrollWinEvent" already in RTTI table - have you 
used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
.

I reproduced this issue on 2 different machines (both updated to latest
sid today).

It seems to be realted to latest version of python-wxgtk3.0.
When I downgrade this package to 3.0.2.0+dfsg-6 (from buster) pcbnew
starts working again.

--
Aurel

Bug#868246: gitlab: broken after upgrade on sid due to new ruby-asana

[Aurelien Jacobs]

Package: gitlab
Version: 8.13.11+dfsg1-8

I have a working gitlab instance running on sid.
After my latest apt upgrade, gitlab stopped working.

Here are the messages I got during the upgrade:

Preparing to unpack .../097-ruby-asana_0.6.0-1_all.deb ...
Unpacking ruby-asana (0.6.0-1) over (0.4.0-1) ...
[...]
Processing triggers for gitlab (8.13.11+dfsg1-8) ...
Creating/updating gitlab user account...
Making gitlab owner of /var/lib/gitlab...
Could not find gem 'asana (~> 0.4.0)' in any of the gem sources listed in your
Gemfile.
#
# Failed to detect gitlab dependencies; if you are in the middle of an #
# upgrade, this is probably fine, there will be another attempt later.  #
#   #
# If you are NOT in the middle of an upgrade, there is probably a real  #
# issue. Please report a bug.   #
#

So ruby-asana was upgraded to 0.6.0 while gitlab requires 0.4.0.
The actual gitlab dependency is ruby-asana (>= 0.4.0~).

After the upgrade, here is what I get in the log:

juil. 13 16:25:43 gitlab systemd[1]: Dependency failed for GitLab Services.
juil. 13 16:25:43 gitlab systemd[1]: gitlab.service: Job gitlab.service/start 
failed with result 'dependency'.

I downgraded ruby-asana to version 0.4.0-1 from stretch, and gitlab
started working again.

I guess the dependency should be updated in some way in gitlab, or at
worst gitlab should Conflict with ruby-asana > 0.4.0-1.

--
Aurel

Bug#805414: gdm3: disable pulseaudio to prevent capturing A2DP sink on session start

[Aurelien Jacobs]

Package: gdm3
Version: 3.22.3-3
Followup-For: Bug #805414

The workaround from https://wiki.debian.org/BluetoothUser/a2dp used to
work, but starting with gdm3 3.22.3-2, it is not enough anymore.
I found out that I now need the following additional step to really
prevent gdm3 to start pulseaudio:

rm /var/lib/gdm3/.config/systemd/user/sockets.target.wants/pulseaudio.socket

This, along with the /var/lib/gdm3/.config/pulse/client.conf file, got
my bluetooth headset working again.

Bug#773133: scan-build: error: Cannot find an executable 'clang'

[Aurelien Jacobs]

Package: clang-3.5
Version: 1:3.5-8

Dear Maintainer,

scan-build is not able to find the clang executable, and is thus not
functional.
Here is the output of scan-build:

$ scan-build-3.5 make
scan-build: error: Cannot find an executable 'clang' relative to scan-build.  
Consider using --use-analyzer to pick a version of 'clang' to use for static 
analysis.

The debian source package contains a patch to fix this issue
(scan-build-clang-path.diff) but it is commented out in the series file.

On the other hand, scan-build from the clang-3.6 version is working
fine, because the clang-3.6 package has the exact same patch, and it is
actually enabled.

I suggest to simply enable the scan-build-clang-path.diff patch in
clang-3.5.

Regards.

Aurélien Jacobs


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

Bug#758998: scan-build does not default to the compiler it ships with

[Aurelien Jacobs]

Package: clang-3.5
Version: 1:3.5-3
Followup-For: Bug #758998

I can confirm this issue with clang-3.5, as well as with clang-3.6.
scan-build search for a clang executable in the same directory as the
actual scan-build executable (/usr/share/clang/scan-build-3.5/) and
does not find any.

There is an easy fix for this. The clang package should contain a
symlink to the clang executable in the scan-build directory.

As a temporary fix, creating this symlink manually is enough:
ln -s /usr/bin/clang-3.5 /usr/share/clang/scan-build-3.5/clang

Just for the record, there is a similar bug repport for archlinux:
https://bugs.archlinux.org/task/33358

Aurel


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

Bug#757219: clang-3.5: scan-build --use-cc broken

[Aurelien Jacobs]

Package: clang-3.5
Version: 1:3.5~+rc1-2

Dear Maintainer,

Bug #748777 was re-intrduced in latest clang-3.5 package.

The following invokation does not work anymore:
  scan-build --use-cc=arm-none-eabi-gcc -o out make -e

It seems that the patch from bug #748777 was dropped from latest package.

Attached is an rebased version of the patch that apply cleanly on latest
clang-3.5 and that fixes the problem again.

Regards.

Aurélien Jacobsdiff -Naur llvm-toolchain-3.5-3.5~+rc1.orig/clang/tools/scan-build/ccc-analyzer llvm-toolchain-3.5-3.5~+rc1/clang/tools/scan-build/ccc-analyzer
--- llvm-toolchain-3.5-3.5~+rc1.orig/clang/tools/scan-build/ccc-analyzer	2014-08-06 10:29:51.990552103 +0200
+++ llvm-toolchain-3.5-3.5~+rc1/clang/tools/scan-build/ccc-analyzer	2014-08-06 10:35:05.016567533 +0200
@@ -25,6 +25,17 @@
 # Compiler command setup.
 ##===--===##
 
+# Search in the PATH if the compiler exists
+sub SearchInPath {
+my $file = shift;
+foreach my $dir (split (':', $ENV{PATH})) {
+if (-x $dir/$file) {
+return 1;
+}
+}
+return 0;
+}
+
 my $Compiler;
 my $Clang;
 my $DefaultCCompiler;
@@ -41,7 +52,7 @@
 
 if ($FindBin::Script =~ /c\+\+-analyzer/) {
   $Compiler = $ENV{'CCC_CXX'};
-  if (!defined $Compiler || ! -x $Compiler) { $Compiler = $DefaultCXXCompiler; }
+  if (!defined $Compiler || (! -x $Compiler  ! SearchInPath($Compiler))) { $Compiler = $DefaultCXXCompiler; }
 
   $Clang = $ENV{'CLANG_CXX'};
   if (!defined $Clang || ! -x $Clang) { $Clang = 'clang++'; }
@@ -50,7 +61,7 @@
 }
 else {
   $Compiler = $ENV{'CCC_CC'};
-  if (!defined $Compiler || ! -x $Compiler) { $Compiler = $DefaultCCompiler; }
+  if (!defined $Compiler || (! -x $Compiler  ! SearchInPath($Compiler))) { $Compiler = $DefaultCCompiler; }
 
   $Clang = $ENV{'CLANG'};
   if (!defined $Clang || ! -x $Clang) { $Clang = 'clang'; }

Bug#748777: clang-3.4: scan-build --use-cc broken

[Aurelien Jacobs]

On Sun, Jun 22, 2014 at 08:54:24AM -0700, Sylvestre Ledru wrote:
 On 20/05/2014 09:58, Aurelien Jacobs wrote:
  Package: clang-3.4
  Version: 1:3.4.1-3
 
  Dear Maintainer,
 
  scan-build stopped working for me since you added the following patch in
  version 1:3.4.1-1:
scan-build-fix-clang-detection.diff
 
  I use scan-build in a cross-compilation environement so I call it
  with --use-cc:
scan-build --use-cc=arm-none-eabi-gcc -o out make -e
 
 The attached patch seems to fix it.
 
 If you are happy about it, let me know and I will push that upstream too.

Great ! Well, it works for me (not using c++), but I think there is a
small mistake in the CXX compiler check, where you used a || instead of
a . It also seems more logical to me with parenthesis around the 
part of the check. I'm not sure I'm really clear, so attached is a very
slightly modified version of your patch, which I tested as well and
which works fine for me.

 Thanks for this interesting bug report

Thanks for taking care of it !

Aurel
Index: llvm-toolchain-3.4-3.4.2/clang/tools/scan-build/ccc-analyzer
===
--- llvm-toolchain-3.4-3.4.2.orig/clang/tools/scan-build/ccc-analyzer	2014-06-22 08:51:25.452950214 -0700
+++ llvm-toolchain-3.4-3.4.2/clang/tools/scan-build/ccc-analyzer	2014-06-22 08:52:17.602331808 -0700
@@ -25,6 +25,17 @@
 # Compiler command setup.
 ##===--===##
 
+# Search in the PATH if the compiler exists
+sub SearchInPath {
+my $file = shift;
+foreach my $dir (split (':', $ENV{PATH})) {
+if (-x $dir/$file) {
+return 1;
+}
+}
+return 0;
+}
+
 my $Compiler;
 my $Clang;
 my $DefaultCCompiler;
@@ -40,14 +51,14 @@
 
 if ($FindBin::Script =~ /c\+\+-analyzer/) {
   $Compiler = $ENV{'CCC_CXX'};
-  if (!defined $Compiler || ! -x $Compiler) { $Compiler = $DefaultCXXCompiler; }
+  if (!defined $Compiler || (! -x $Compiler  ! SearchInPath($Compiler))) { $Compiler = $DefaultCXXCompiler; }
   
   $Clang = $ENV{'CLANG_CXX'};
   if (!defined $Clang || ! -x $Clang) { $Clang = 'clang++'; }
 }
 else {
   $Compiler = $ENV{'CCC_CC'};
-  if (!defined $Compiler || ! -x $Compiler) { $Compiler = $DefaultCCompiler; }
+  if (!defined $Compiler || (! -x $Compiler  ! SearchInPath($Compiler))) { $Compiler = $DefaultCCompiler; }
 
   $Clang = $ENV{'CLANG'};
   if (!defined $Clang || ! -x $Clang) { $Clang = 'clang'; }

Bug#748777: clang-3.4: scan-build --use-cc broken

[Aurelien Jacobs]

Package: clang-3.4
Version: 1:3.4.1-3

Dear Maintainer,

scan-build stopped working for me since you added the following patch in
version 1:3.4.1-1:
  scan-build-fix-clang-detection.diff

I use scan-build in a cross-compilation environement so I call it
with --use-cc:
  scan-build --use-cc=arm-none-eabi-gcc -o out make -e

It used to work great, but it now spits errors such as:
  error: bad value (arm7tdmi) for -mtune= switch
(this comes from my cross-compilation related CFLAGS)

I traced the problem to the following test which was added in ccc-analyzer:
  if (. || ! -x $Compiler)
Problem is that -x does not lookup into $PATH and thus it fails to find
my arm-none-eabi-gcc executable and silently defaults back to native
gcc. If I give the full path with --use-cc=/opt/x-tools/bin/arm-none-eabi-gcc
then scan-build works again. If I remove the -x $Compiler check it also
works.

I suggest that ccc-analyzer should do a full $PATH search on $Compiler
instead of a simple -x check.

Regards.

Aurélien Jacobs


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

Bug#637909: support for atmega48p/pa, atmega88p/pa and atmega168p/pa is missing

[Aurelien Jacobs]

Hi,

It seems that the atmega48p is now supported in version 6.0.1 (released
today).
It would be nice to get this new version packaged.


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

Bug#663912: linux-image-3.3.0-rc6-amd64: please enable CONFIG_RTS5139 for SDcard support

[Aurelien Jacobs]

Package: linux-2.6
Severity: wishlist

Hi,

Simply enabling CONFIG_RTS5139 as a module would add support for SDcard
in some laptop such as the Asus Zenbook (UX31E). So it would be nice to
have it enabled by default instead of having to recompile the kernel
myself every time.

Thanks.

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

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



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

Bug#663912: please enable CONFIG_RTS5139 for SDcard support

[Aurelien Jacobs]

On Wed, Mar 14, 2012 at 05:17:16PM -0500, Jonathan Nieder wrote:
 Hi,
 
 Aurelien Jacobs wrote:
 
  Simply enabling CONFIG_RTS5139 as a module would add support for SDcard
  in some laptop such as the Asus Zenbook (UX31E).
 
 Sounds reasonable.  The driver seems to have been merged in the 3.2 merge
 window, which is barely in time for us not to have to backport it for
 support in wheezy.
 
 Am I correct in assuming these card readers are only available as a
 built-in chip on x86 laptops, and not as a USB gadget that could be
 plugged in on machines with other processor architectures?

It seems mostly used in recent laptops, but some desktops also features
this chip.
I don't know of any USB gadget with this chip, but as the chip is
connected on the USB bus, it would be quite easy to conceive a
USB gadget with it. Anyway, I guess it is better to enable it only
on i386/amd64 until we discover some actual USB gadget using it.

Thanks for the patch !

Aurel



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

Bug#655394: Indeed still borken

[Aurelien Jacobs]

Hi,

I can confirm that this bug is still not fixed for me.

With gnome-shell run from GDM3, I have no gnome-session process running,
so the DBusSend is not doing anything.

I also confirm that applying the DBusSend to gnome-settings-daemon
instead of gnome-session properly fix the bug for me.

Aurel



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

Bug#531432: outdated copyright file

[Aurelien Jacobs]

Package: unrar
Version: 3.8.5-2

The copyright file [1] contains an outdated version of unrar license.
Especially point 3 of the license has changed in the source tarball of
version 3.8.5.

Debian copyright file:
   3. The unRAR utility may be freely distributed. No person or company 
  may charge a fee for the distribution of unRAR without written
  permission from the copyright holder.

Upstream tarball:
   3. The UnRAR utility may be freely distributed. It is allowed
  to distribute UnRAR inside of other software packages.

I guess this could be modified at the same time as upgrading the Debian
package to latest available upstream version (3.9.3).

Aurel

[1] /usr/share/doc/unrar/copyright



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

Bug#454839: FTBFS with GCC 4.3: missing #includes

[Aurelien Jacobs]

Tags: patch

The following patch fixes this issue.

--- common/apt-watch-common.cc.orig 2008-01-28 10:35:00.0 +0100
+++ common/apt-watch-common.cc  2008-01-28 10:34:25.0 +0100
@@ -5,6 +5,7 @@
 #include apt-watch-common.h
 
 #include cstdlib
+#include cstring
 #include errno.h
 
 using namespace std;
--- common/fileutl.cc.orig  2008-01-28 10:39:22.0 +0100
+++ common/fileutl.cc   2008-01-28 10:38:49.0 +0100
@@ -4,6 +4,7 @@
 
 #include fileutl.h
 
+#include cstring
 #include dirent.h
 #include errno.h
 #include stdlib.h
--- backend/apt-watch-auth-helper.cc.orig   2008-01-28 10:40:52.0 
+0100
+++ backend/apt-watch-auth-helper.cc2008-01-28 10:40:14.0 +0100
@@ -16,6 +16,7 @@
 
 #include security/pam_appl.h
 
+#include cstring
 #include stdlib.h
 #include signal.h
 #include sys/types.h
--- ui-gnome/prefs-package-manager.cc.orig  2008-01-28 10:42:14.0 
+0100
+++ ui-gnome/prefs-package-manager.cc   2008-01-28 10:41:34.0 +0100
@@ -10,6 +10,7 @@
 
 #include common/fileutl.h
 
+#include cstring
 #include cctype
 #include string
 



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

Bug#454833: FTBFS with GCC 4.3: missing #includes

[Aurelien Jacobs]

Tags: patch

The following patch fixes the issue.

--- sample_progs/cam_menu.hh.orig   2008-01-28 10:23:53.0 +0100
+++ sample_progs/cam_menu.hh2008-01-28 10:22:55.0 +0100
@@ -2,6 +2,7 @@
  * cam_menu.hh
  *
  */
+#include cstring
 #include sys/types.h
 #include sys/socket.h
 



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

Bug#450888: initramfs-tools: should depend on findutils = 4.2.24

[Aurelien Jacobs]

Package: initramfs-tools
Version: 0.90a

mkinitramfs uses the -regextype option of find. This options was introduced
in findutils 4.2.24.
I've tried to use a recent version of initramfs-tools on an old sarge
powerpc install. Here is the result:

# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.22-2-powerpc
find: invalid predicate `-regextype'
find: invalid predicate `-regextype'

This generated a non bootable system (kernel panic: init killed).

Updating findutils and re-generating the initramfs, fixed my system.

I'm not sure if such a hackish update from sarge to lenny is supported,
but simply adding a dependency on findutils = 4.2.24 would solve this
issue.



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

Bug#439418: syslinux: FTBFS with nasm 0.99.01-0

[Aurelien Jacobs]

Package: syslinux
Version: 1:3.51-1
Severity: important

With nasm 0.99.01-0 (newly introduced in sid) syslinux FTBFS.
Compilation ends with the following messages:

# Building package
/usr/bin/make DATE=Debian-2007-08-24 VERSION=3.51
make[1]: Entering directory `/data/build/syslinux-3.51'
Makefile:255: .depend: No such file or directory
rm -f .depend
for csrc in syslxmod.c gethostip.c ; do gcc  -MM $csrc  .depend ; done
for nsrc in copybs.asm extlinux.asm isolinux.asm isolinux-debug.asm ldlinux.asm 
pxelinux.asm ; do nasm -DDEPEND  -o `echo $nsrc | sed -e 's/\.asm/\.bin/'` -M 
$nsrc  .depend ; done
make[1]: Leaving directory `/data/build/syslinux-3.51'
make[1]: Entering directory `/data/build/syslinux-3.51'
set -e ; for i in mbr  ; do /usr/bin/make DATE=Debian-2007-08-24 
HEXDATE=0x466c807b -C $i all ; done
make[2]: Entering directory `/data/build/syslinux-3.51/mbr'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/data/build/syslinux-3.51/mbr'
/usr/bin/make DATE=Debian-2007-08-24 HEXDATE=0x466c807b all-local
make[2]: Entering directory `/data/build/syslinux-3.51'
nasm -O99 -f bin -DDATE_STR='Debian-2007-08-24' -DHEXDATE=0x466c807b \
-DMAP=pxelinux.map -l pxelinux.lsr -o pxelinux.bin pxelinux.asm
pxelinux.asm:1225: error: short jump is out of range
make[2]: *** [pxelinux.bin] Error 1
make[2]: Leaving directory `/data/build/syslinux-3.51'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/data/build/syslinux-3.51'
make: *** [build-stamp] Error 2


Downgrading nasm to 0.98.38-1.2 fixes this issue.
I'm not sure if syslinux sources should be fixed or if the bug is in nasm ?


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

Kernel: Linux 2.6.22-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages syslinux depends on:
ii  libc6 2.6.1-1GNU C Library: Shared libraries

Versions of packages syslinux recommends:
ii  mtools3.9.11-0   Tools for manipulating MSDOS files

-- no debconf information


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

Bug#403893: mplayer: typo in the README.Debian

[Aurelien Jacobs]

Package: mplayer
Version: 1.0~rc1-10
Severity: minor
Tags: patch

The attached patch fix a small typo in the README file (AVN vs. SVN).

Aurel
diff -Naur mplayer-1.0~rc1.orig/debian/README.Debian.free mplayer-1.0~rc1/debian/README.Debian.free
--- mplayer-1.0~rc1.orig/debian/README.Debian.free	2006-12-20 14:01:22.0 +0100
+++ mplayer-1.0~rc1/debian/README.Debian.free	2006-12-20 14:01:48.0 +0100
@@ -59,6 +59,6 @@
 to comply with this request.
 
 Moreover all changes to the code are documented
-in the AVN public repository of MPlayer (that is publicly accessible).
+in the SVN public repository of MPlayer (that is publicly accessible).
 
 A. Mennucc

Bug#402750: genisoimage: missing mkzftree binary

[Aurelien Jacobs]

Package: genisoimage
Version: 9:1.1.0-1
Severity: important
Tags: patch

Once again, genisoimage package is missing the mkzftree binary (last time
it was in the mkisofs package, see #387927).
The attached patch fixes the issue.
I didn't set this bug severity to RC because I was not sure, but I think
it's important to get it fixed for etch.

Aurel
--- genisoimage.install.orig	2006-12-12 13:54:27.0 +0100
+++ genisoimage.install	2006-12-12 13:50:38.0 +0100
@@ -4,6 +4,7 @@
 debian/tmp/usr/bin/isodump
 debian/tmp/usr/bin/isovfy
 debian/tmp/usr/bin/dirsplit
+debian/tmp/usr/bin/mkzftree
 debian/tmp/usr/share/man/man8/genisoimage.8
 debian/tmp/usr/share/man/man8/isoinfo.8
 debian/tmp/usr/share/man/man1/dirsplit.1

Bug#395829: mplayer: Strange contents of default config file

[Aurelien Jacobs]

I confirm, I see the same strange mplayer.conf here.
Here is what it looks like:

### mplayer DEBCONF AREA. DO NOT EDIT THIS AREA OR INSERT TEXT BEFORE IT.
#video output driver
vo=Unsupported
#device for dvd
dvd-device=xv_X11/Xv 
#truetype font
font=/dev/cdrom
#enable RTC (Real Time Clock) access
rtc=1
### END OF DEBCONF AREA.  PLACE YOUR EDITS BELOW; THEY WILL BE PRESERVED.

It seems values are mixed with different config name.
xv_X11/Xv should be assigned to vo instead of dvd-device, etc...

I tried a dpkg-reconfigure mplayer and got the exact same thing.

Aurel


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

Bug#387927: [PATCH] missing mkzftree binary

[Aurelien Jacobs]

Package: mkisofs
Version: 5:1.0~pre4-1
Severity: important
Tags: patch

Current mkisofs package is missing the mkzftree binary (but still contains
the corresponding man page).
The attached patch fixes the issue.

Aurel
--- mkisofs.install.orig	2006-09-17 16:00:57.0 +0200
+++ mkisofs.install	2006-09-17 15:57:18.0 +0200
@@ -4,6 +4,7 @@
 debian/tmp/usr/bin/isodump
 debian/tmp/usr/bin/isovfy
 debian/tmp/usr/bin/dirsplit
+debian/tmp/usr/bin/mkzftree
 debian/tmp/usr/share/man/man8/mkisofs.8
 debian/tmp/usr/share/man/man8/isoinfo.8
 debian/tmp/usr/share/man/man1/dirsplit.1

Bug#318645: No firefox window in fvwm, but ok in gnome(metacity)

[Aurelien Jacobs]

This was a 64bits specific fvwm bug (#318504) fixed in latest fvwm upload.


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

Bug#318031: segfault on amd64

[Aurelien Jacobs]

Package: libgksu1.2
Version: 1.3.1-1
Severity: important
Tags: patch

Currently, libgksu defines a callback function (keyring_create_item_cb)
inside another function. The problem is that this callback function
is stored on the stack (like any other local variable). amd64 has this
famous NX flag which prevent execution of the stack. So when the
callback stored on the stack is called, it simply segfault.
The fix is very simple: move keyring_create_item_cb callback definition
outside of the function.
The attached patch fix this issue.

BTW: this patch should also close #307975

Aurel--- libgksu/gksu-context.c.orig 2005-07-13 01:29:24.0 +0200
+++ libgksu/gksu-context.c  2005-07-13 01:30:36.0 +0200
@@ -784,6 +784,13 @@
   return TRUE;
 }
 
+static void
+keyring_create_item_cb (GnomeKeyringResult result,
+guint32 id, gpointer keyring_loop)
+{
+  g_main_loop_quit (keyring_loop);
+}
+
 /**
  * gksu_context_run:
  * @context: a #GksuContext
@@ -989,20 +996,14 @@
   
  keyring_loop = g_main_loop_new (NULL, FALSE);
 
- void
-   keyring_create_item_cb (GnomeKeyringResult result,
-   guint32 id, gpointer data)
-   {
- g_main_loop_quit (keyring_loop);
-   }
-
  gnome_keyring_item_create (NULL,
 
GNOME_KEYRING_ITEM_GENERIC_SECRET,
 key_name,
 attributes,
 gksu_context_get_password 
(context),
 TRUE,
-keyring_create_item_cb, NULL, 
NULL);
+keyring_create_item_cb,
+keyring_loop, NULL);
  gnome_keyring_attribute_list_free (attributes);
  g_main_loop_run (keyring_loop);
}