Bug#1042968: emacs: Gnus unusable after upgrading to Emacs 29

[Florent Rougon]

Hi David,

David Bremner  wrote:

> Please try to duplicate the problem with "emacs -q". I suspect there is
> either some obsolete/broken third party package or just some personal
> configuration causing this problem.

You're right, the problem was in my .gnus.el which had a
(gnus-add-configuration …) call where the passed-in value came in part
from an old default value of `gnus-buffer-configuration' (that is where
the `gnus-carpal' stuff came from). I did that setting once long ago and
didn't remember the details. Sorry I had grepped my ~/.emacs.d and
~/lisp but completely forgot to do it on ~/.gnus.el!

[ BTW, I misunderstood part of the *Backtrace* buffer when I wrote that
  “clicking on the gnus-configure-frame “button” in the backtrace shows
  (defun gnus-configure-frame ...) in
  /usr/share/emacs/29.1/lisp/gnus/gnus-win.el.gz with *different code*”.
  The line of that buffer where I used RET was:

  gnus-configure-frame((cond (gnus-use-trees '(vertical 1.0 (article 1.0) 
(summary 0.25 point) (tree 0.25))) (t '(vertical 1.0 (article 1.0) (summary 
0.25 point) (if gnus-carpal '(summary-carpal 4))

  and I now understand that the big (cond (gnus-use-trees …)) is the
  `split' argument — a callable here — that was passed to
  `gnus-configure-frame'. ]

So, the problem is solved and was actually a PEBKAC case. Many thanks
for your help and sorry for the noise!

Regards

-- 
Florent

Bug#1042968: emacs: Gnus unusable after upgrading to Emacs 29

[Florent Rougon]

Package: emacs
Version: 1:29.1+1-2
Severity: normal

Dear maintainer,

This morning, I performed the following upgrade:

[UPGRADE] emacs:amd64 1:28.2+1-16 -> 1:29.1+1-2
[UPGRADE] emacs-bin-common:amd64 1:28.2+1-16 -> 1:29.1+1-2
[UPGRADE] emacs-common:amd64 1:28.2+1-16 -> 1:29.1+1-2
[UPGRADE] emacs-common-non-dfsg:amd64 1:28.2+1-2 -> 1:29.1+1-1
[UPGRADE] emacs-el:amd64 1:28.2+1-16 -> 1:29.1+1-2
[UPGRADE] emacs-gtk:amd64 1:28.2+1-16 -> 1:29.1+1-2

and rebooted because the kernel was also upgraded at the same time.
Since then, Gnus (the version shipped with Emacs) has become unusable
for me because every time I hit RET in the *Summary* buffer in order to
read a message, I get the following error:

gnus-configure-frame: Symbol’s value as variable is void: gnus-carpal

Redoing RET after `toggle-debug-on-error' yields the following
backtrace:

Debugger entered--Lisp error: (void-variable gnus-carpal)
  (if gnus-carpal '(summary-carpal 4))
  gnus-configure-frame((cond (gnus-use-trees '(vertical 1.0 (article 1.0) 
(summary 0.25 point) (tree 0.25))) (t '(vertical 1.0 (article 1.0) (summary 
0.25 point) (if gnus-carpal '(summary-carpal 4))
  gnus-configure-windows(article)
  gnus-summary-scroll-up(1)
  funcall-interactively(gnus-summary-scroll-up 1)
  command-execute(gnus-summary-scroll-up)

Surprisingly, clicking on the gnus-configure-frame “button” in the
backtrace shows (defun gnus-configure-frame ...) in
/usr/share/emacs/29.1/lisp/gnus/gnus-win.el.gz with *different code*:
there are a few (cond ...) forms but none that starts as
(cond (gnus-use-trees...).

$ ls -l /usr/share/emacs/29.1/lisp/gnus/gnus-win.el.gz 
/usr/share/emacs/29.1/lisp/gnus/gnus-win.elc
-rw-r--r-- 1 root root 11128 Aug  1 20:24 
/usr/share/emacs/29.1/lisp/gnus/gnus-win.elc
-rw-r--r-- 1 root root  5006 Jul 30 17:32 
/usr/share/emacs/29.1/lisp/gnus/gnus-win.el.gz
$ sha512sum /usr/share/emacs/29.1/lisp/gnus/gnus-win.el.gz
2fd828896c493913dd63586d39d559df679cda673c154ec5bbf421ff5ddc465815d830495c4aefaad5d306d0b4792bbd1b23754830a8cee83591006fe1ea6ceb
  /usr/share/emacs/29.1/lisp/gnus/gnus-win.el.gz

According to `C-h N', the `gnus-carpal' variable has been obsolete since
Emacs 24 and was removed in Emacs 29.1. If I evaluate
(setq gnus-carpal nil) in the *scratch* buffer, the problem doesn't
happen anymore — until Emacs is restarted, of course.

I tried 'aptitude reinstall emacs-el emacs-common' but this didn't
change anything to the problem.

Thanks for your work and help!

Regards

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

Kernel: Linux 6.4.0-1-amd64 (SMP w/20 CPU threads; PREEMPT)
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)
LSM: AppArmor: enabled

Versions of packages emacs depends on:
ii  emacs-gtk  1:29.1+1-2

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#1042817: doesn't apply MODE="0664" action to uinput upon boot anymore

[Florent Rougon]

Package: udev
Version: 254-1
Severity: normal

Dear maintainer,

The computer this report is sent from runs sid and is upgraded almost
daily. The problem described here appeared on the first boot of
2023-07-20 and is still present today.

This computer has the following rule in
/etc/udev/rules.d/90-local-uinput.rules (and no other rule in that
file):

  SUBSYSTEM=="misc", KERNEL=="uinput", GROUP="a_user_group", MODE="0664"

This has been working fine for years, until 2023-07-20. Now, after
booting, one sees that the MODE="0664" action either hasn't been
applied, or has been cancelled by something else:

  # ls -l /dev/uinput
  crw--- 1 root a_user_group 10, 223 Jul 30 11:04 /dev/uinput
  #

(which causes failures in a program that relies on /dev/uinput being
writable by a_user_group).

If, after boot, I manually run as root:

  udevadm control --reload-rules && udevadm trigger'

then the rule is properly applied:

  # ls -l /dev/uinput
  crw-rw-r-- 1 root a_user_group 10, 223 Jul 30 11:09 /dev/uinput
  #

Many thanks in advance for your help. Regards

Florent

-- Package-specific info:

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

Kernel: Linux 6.4.0-1-amd64 (SMP w/20 CPU threads; PREEMPT)
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)
LSM: AppArmor: enabled

Versions of packages udev depends on:
ii  adduser  3.137
ii  libacl1  2.3.1-3
ii  libblkid12.39.1-3
ii  libc62.37-6
ii  libcap2  1:2.66-4
ii  libkmod2 30+20230519-1
ii  libselinux1  3.5-1
ii  libudev1 254-1
ii  systemd-dev  254-1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  254-1

-- debconf information:
  udev/new_kernel_needed: false
  udev/title/upgrade:
  udev/sysfs_deprecated_incompatibility:
  udev/reboot_needed:

Bug#1017757: Same error with emacs 28.1+1-2

[Florent Rougon]

Since #1017739 is filed on emacs-lucid and I use emacs-gtk, not
emacs-lucid, I don't know how to reassign this bug to merge it with
#1017739; will let this to the Emacs maintainer.

Thanks & regards :-)

-- 
Florent

Bug#1017757: Same error with emacs 28.1+1-2

[Florent Rougon]

Thanks for your input, Luis!

TL;DR: this is the same bug as #1017739:

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

While trying what you suggested, I had again the same error after:
  - quitting Emacs;
  - deleting ~/.emacs.d;
  - upgrading again to the current version of the Emacs packages in sid;
  - restarting Emacs as normal user.

Then I realized I had root-owned files in ~/.emacs.d/eln-cache such as
subr--trampoline-6d616b652d73706172736. I pass you some details like
trying an 'strace -f' and looking if any of the Emacs packages ships
suid binaries... in the end, I understood that it was the *upgrade* to
Emacs 28 that created these files under my home dir, not the emacs
binary run as normal user (yes, I used 'su' without '-'). Pheew! :)

Regards

-- 
Florent

Bug#1017757: emacs: early error: no suitable directory for output in 'comp-native-load-path'

[Florent Rougon]

After downgrading to 1:27.1+1-3, the error is gone.

Regards

-- 
Florent

Bug#1017757: emacs: early error: no suitable directory for output in 'comp-native-load-path'

[Florent Rougon]

Package: emacs
Version: 1:28.1+1-1
Severity: normal

Dear maintainer,

After performing the following upgrades today on sid:

[UPGRADE] emacs:amd64 1:27.1+1-3.1 -> 1:28.1+1-1
[UPGRADE] emacs-bin-common:amd64 1:27.1+1-3.1+b1 -> 1:28.1+1-1
[UPGRADE] emacs-bin-common-dbgsym:amd64 1:27.1+1-3.1+b1 -> 1:28.1+1-1
[UPGRADE] emacs-common:amd64 1:27.1+1-3.1 -> 1:28.1+1-1
[UPGRADE] emacs-el:amd64 1:27.1+1-3.1 -> 1:28.1+1-1
[UPGRADE] emacs-gtk:amd64 1:27.1+1-3.1+b1 -> 1:28.1+1-1
[UPGRADE] emacs-gtk-dbgsym:amd64 1:27.1+1-3.1+b1 -> 1:28.1+1-1

starting Emacs, even with the -q option, stops very early with a beep
and the following in the *Messages* buffer:

  defalias: Cannot find suitable directory for output in 
'comp-native-load-path'.

Therefore, it is impossible to execute my initialization files
(I would put severity at least serious, but reportbug wants me to
quote Policy sections in this case, so...).

With 'emacs -q --no-site-file', there is no error.

Thanks!

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
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)
LSM: AppArmor: enabled

Versions of packages emacs depends on:
ii  emacs-gtk  1:28.1+1-1

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#1007697: xserver-xorg-input-wacom: New release completely breaks Intuos5 touch S

[Florent Rougon]

Package: xserver-xorg-input-wacom
Version: 1.0.0-1
Severity: important

Hello,

Yesterday, my xserver-xorg-input-wacom:amd64 package was upgraded from
version 0.34.99.1-1+b1 to 1.0.0-1, which rendered my Wacom Intuos5
touch S tablet completely unusable: moving the finger over the touch pad
has no effect whatsoever on the mouse pointer.

After downgrading from 1.0.0-1 to 0.34.99.1-1+b1 this morning, my tablet
is usable again (the version info below is after the downgrade; the test
of xserver-xorg-input-wacom version 1.0.0-1 was done on a fully
up-to-date sid).

When I was trying to get the tablet to work under
xserver-xorg-input-wacom 1.0.0-1 via unplugging and replugging the USB
cable, I saved the Xorg.log file. It has errors like so:

[46.195] (II) config/udev: Adding input device Wacom Intuos Pro S Pen (/dev/
input/event6)
[46.195] (**) Wacom Intuos Pro S Pen: Applying InputClass "evdev tablet catc
hall"
[46.195] (**) Wacom Intuos Pro S Pen: Applying InputClass "Wacom USB tablet 
class"
[46.195] (**) Wacom Intuos Pro S Pen: Applying InputClass "Wacom tablet clas
s"
[46.195] (II) LoadModule: "wacom"
[46.196] (WW) Warning, couldn't open module wacom
[46.196] (EE) Failed to load module "wacom" (module does not exist, 0)
[46.196] (EE) No input driver matching `wacom'
[46.196] (II) Falling back to input driver `libinput'
[46.196] (II) LoadModule: "libinput"
[46.196] (WW) Warning, couldn't open module libinput
[46.196] (EE) Failed to load module "libinput" (module does not exist, 0)

This is very important to me, as I (have to) use the tablet as my mouse!

Thanks

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

Kernel: Linux 5.16.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
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)
LSM: AppArmor: enabled

Versions of packages xserver-xorg-input-wacom depends on:
ii  libc6  2.33-7
ii  libudev1   250.3-2
ii  libx11-6   2:1.7.2-2+b1
ii  libxext6   2:1.3.4-1
ii  libxi6 2:1.8-1
ii  libxinerama1   2:1.1.4-3
ii  libxrandr2 2:1.5.2-1
ii  xserver-xorg-core [xorg-input-abi-24]  2:21.1.3-2+b1

xserver-xorg-input-wacom recommends no packages.

Versions of packages xserver-xorg-input-wacom suggests:
ii  xinput  1.6.3-1

-- no debconf information

Bug#1005102: sane-utils.postinst: 65: [: /var/lib/saned: unexpected operator

[Florent Rougon]

Package: sane-utils
Version: 1.1.1-1
Severity: normal

Hello,

There is a syntax error in /var/lib/dpkg/info/sane-utils.postinst which
causes the following message to be printed:

/var/lib/dpkg/info/sane-utils.postinst: 65: [: /var/lib/saned: unexpected 
operator

I could suggest a fix, however I'm not quite sure of the intent
(regarding the test). The problematic code is the first line of:

if [ ! -d /var/lib/saned saned ] ; then
usermod -d /var/lib/saned saned
fi

AFAIK:

1) The -d test operator takes only one argument.

2) The negation operator '!' should be before ' [' in POSIX shell (note
   the space).

3) I'm not sure you want the '!' at all here (but haven't read the rest
   of this postinst).

Thanks.

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

Kernel: Linux 5.15.0-3-amd64 (SMP w/8 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)
LSM: AppArmor: enabled

Versions of packages sane-utils depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.79
ii  init-system-helpers1.61
ii  libavahi-client3   0.8-5
ii  libavahi-common3   0.8-5
ii  libc6  2.33-5
ii  libieee1284-3  0.2.11-14
ii  libjpeg62-turbo1:2.1.2-1
ii  libpng16-161.6.37-3
ii  libsane1   1.1.1-1
ii  libsystemd0250.3-2
ii  libusb-1.0-0   2:1.0.25-1
ii  libxml22.9.12+dfsg-5+b1
ii  lsb-base   11.1.0
ii  update-inetd   4.51

sane-utils recommends no packages.

Versions of packages sane-utils suggests:
ii  avahi-daemon  0.8-5
ii  unpaper   6.1-2+b2

-- debconf information:
* sane-utils/saned_run: false
* sane-utils/saned_scanner_group: true

Bug#990331: reportbug: cups-browsed printing fails due to apparmor config with message 'No destination host name supplied by cups-browsed for printer'

[Florent Rougon]

Hello Brian,

As I wrote in my previous message, the two lines I quoted from my
/var/log/syslog are from **before the fix** (i.e., before I purged
cups-browsed).

Regards

-- 
Florent

Bug#990331: reportbug: cups-browsed printing fails due to apparmor config with message 'No destination host name supplied by cups-browsed for printer'

[Florent Rougon]

Hello,

I also had the not-very-helpful message from CUPS:

  No destination host name supplied by cups-browsed for printer, is
  cups-browsed running?

Of course, cups-browsed was well running and I even tried to restart it,
also cups.service, etc. The solution I found, before reading this
report, was inspired by this answer:

  https://askubuntu.com/a/1128869

Here it is. First some context: the printer is connected to 
and printing from  first worked, then failed for the *very
same document* in the *very same Okular instance*---I simply wanted to
print two sets of pages from the same document, oh my...

Solution (everything done on ):

1) I purged the cups-browsed package, even though cups-daemon recommends
   it.

2) Then I figured out I needed to do “Delete Printer” from the CUPS web
   administration page for the printer (otherwise, trying to do step 3
   would fail with the incomprehensible error message “Unable to add
   printer:Cannot change printer-is-shared for remote queues.”—that,
   regardless of whether “Share printer” was being checked).

3) From the CUPS web administration page:

   Administration → Add Printer → Discovered Network Printers: Brother
   DCP-L2550DN (driverless) @  (DCP-L2550DN DCP-L2550DN
   series) → ... → Add Printer (the button).

Finally, I was able to print from .

Even though this solution is quite different from that proposed by
Gabriel, this may very well be the same issue, because now that I've
found this report, I see that my /var/log/syslog on  from
before the fix has entries like:

Sep 11 13:39:09 localhost kernel: [15658.624326] audit: type=1400 audit(...): 
apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=6811 
comm="cupsd" capability=12  capname="net_admin"
Sep 11 13:39:09 localhost kernel: [15658.718083] audit: type=1400 audit(...): 
apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=6814 
comm="cups-browsed" capability=23  capname="sys_nice"

Hope this helps other people. Regards,

-- 
Florent

Bug#980144: mailutils: movemail does not remove start mailbox when moving

[Florent Rougon]

Hello,

This appears to be a duplicate of #980042:

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

Regards

-- 
Florent

Bug#980042: mailutils: does not remove extracted emails

[Florent Rougon]

Package: mailutils
Version: 1:3.11.1-4
Severity: important

Dear maintainer,

Since I upgraded mailutils from 1:3.10-3+b1 to 1:3.11.1-2 a couple of
days ago, movemail doesn't remove extracted emails anymore from the
source mbox file (I do *not* use option --keep-messages).

Example:

  1) Verify that /var/mail/$USER is empty.

  2) echo Bla | mail -s "Test movemail" $USER

  3) 'ls -l /var/mail/$USER' now reports size 573 bytes (it contains the
 test email sent in step 2).

  4) /usr/bin/movemail.mailutils /var/mail/$USER /tmp/extracted-mail

  5) No error reported, test email was properly extracted to
 /tmp/extracted-mail, but /var/mail/$USER is still 573 bytes long.

This has the following consequence when I use my mail client (Gnus,
which can use movemail to read mbox files): since the upgrade to
mailutils 1:3.11.1-2, *every time I check my mail box*, new copies of
every email stored in /var/mail/$USER are retrieved. A nightmare...

I verified yesterday that the following downgrade of mailutils fixes the
problem:

  [REMOVE, NOT USED] libmailutils8:amd64 1:3.11.1-2
  [INSTALL, DEPENDENCIES] libmailutils7:amd64 1:3.10-3+b1
  [DOWNGRADE] mailutils:amd64 1:3.11.1-2 -> 1:3.10-3+b1
  [DOWNGRADE] mailutils-common:amd64 1:3.11.1-2 -> 1:3.10-3

Today, I upgraded to the latest version in unstable (1:3.11.1-4).
Unfortunately, this caused the problem to reappear, hence this report.

Thanks for your work, kind regards.

Florent

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mailutils depends on:
ii  libc6 2.31-9
ii  libcrypt1 1:4.4.17-1
ii  libfribidi0   1.0.8-2
ii  libgnutls30   3.7.0-5
ii  libgsasl7 1.10.0-3
ii  libldap-2.4-2 2.4.56+dfsg-1
ii  libmailutils8 1:3.11.1-4
ii  libncurses6   6.2+20201114-2
ii  libpam0g  1.4.0-2
ii  libreadline8  8.1-1
ii  libtinfo6 6.2+20201114-2
ii  libunistring2 0.9.10-4
ii  mailutils-common  1:3.11.1-4

Versions of packages mailutils recommends:
ii  postfix [mail-transport-agent]  3.5.6-1

Versions of packages mailutils suggests:
pn  mailutils-doc  
pn  mailutils-mh   

-- no debconf information

Bug#975919: okular: Back and Forward navigation functions are broken

[Florent Rougon]

Package: okular
Version: 4:20.08.3-1
Severity: important
Tags: upstream patch

Dear maintainers,

Recent updates to okular have completely broken its Back and Forward
navigation functions (those found in the Go menu and bound to
Alt-Shift-Left and Alt-Shift-Right by default). This has been reported
upstream at [1] and fixed in commit 585340cef[2] (link found in this
comment[3] by Nate Graham on the bug report page[1]).

I have rebuilt okular 4:20.08.3-1 with the attached debdiff, which
merely applies the patch corresponding to [2]. This fixes the issue for
me. Hope this helps other users.

Thanks & regards

[1] https://bugs.kde.org/show_bug.cgi?id=414701
[2] 
https://invent.kde.org/graphics/okular/commit/585340cef5ca4dd1e26fe3baea1cf396f8de6469
[3] https://bugs.kde.org/show_bug.cgi?id=414701#c24

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

Kernel: Linux 5.9.0-3-amd64 (SMP w/8 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages okular depends on:
ii  kinit 5.74.0-2
ii  kio   5.74.0-2
ii  libc6 2.31-4
ii  libfreetype6  2.10.2+dfsg-4
ii  libjpeg62-turbo   1:2.0.5-1.1
ii  libkf5activities5 5.74.0-2
ii  libkf5archive55.74.0-2
ii  libkf5bookmarks5  5.74.0-2
ii  libkf5codecs5 5.74.0-2
ii  libkf5completion5 5.74.0-2
ii  libkf5configcore5 5.74.0-2
ii  libkf5configgui5  5.74.0-2
ii  libkf5configwidgets5  5.74.0-2
ii  libkf5coreaddons5 5.74.0-2
ii  libkf5crash5  5.74.0-2
ii  libkf5i18n5   5.74.0-3
ii  libkf5iconthemes5 5.74.0-2
ii  libkf5itemviews5  5.74.0-2
ii  libkf5jobwidgets5 5.74.0-2
ii  libkf5kexiv2-15.0.0   20.04.3-1
ii  libkf5kiocore55.74.0-2
ii  libkf5kiowidgets5 5.74.0-2
ii  libkf5parts5  5.74.0-2
ii  libkf5pty55.74.0-2
ii  libkf5purpose-bin 5.74.0-2
ii  libkf5purpose55.74.0-2
ii  libkf5service-bin 5.74.0-2
ii  libkf5service55.74.0-2
ii  libkf5textwidgets55.74.0-2
ii  libkf5wallet-bin  5.74.0-2
ii  libkf5wallet5 5.74.0-2
ii  libkf5widgetsaddons5  5.74.0-3
ii  libkf5windowsystem5   5.74.0-2
ii  libkf5xmlgui5 5.74.0-2+b1
ii  libokular5core9   4:20.08.3-1
ii  libphonon4qt5-4   4:4.11.1-3
ii  libpoppler-qt5-1  20.09.0-3
ii  libqca-qt5-2  2.3.1-1
ii  libqmobipocket2   4:20.04.3-1
ii  libqt5core5a  5.15.1+dfsg-4
ii  libqt5dbus5   5.15.1+dfsg-4
ii  libqt5gui55.15.1+dfsg-4
ii  libqt5printsupport5   5.15.1+dfsg-4
ii  libqt5svg55.15.1-2
ii  libqt5texttospeech5   5.15.1-2
ii  libqt5widgets55.15.1+dfsg-4
ii  libqt5xml55.15.1+dfsg-4
ii  libspectre1   0.2.9-1
ii  libstdc++610.2.0-19
ii  phonon4qt54:4.11.1-3
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages okular recommends:
ii  cups-bsd  2.3.3-4

Versions of packages okular suggests:
ii  ghostscript9.53.3~dfsg-5
ii  okular-extra-backends  4:20.08.3-1
ii  poppler-data   0.4.10-1
ii  texlive-binaries   2020.20200327.54578-5
ii  unrar  1:5.9.4-1

-- no debconf information
diff -Nru okular-20.08.3/debian/changelog okular-20.08.3/debian/changelog
--- okular-20.08.3/debian/changelog 2020-11-08 13:41:37.0 +0100
+++ okular-20.08.3/debian/changelog 2020-11-25 22:25:47.0 +0100
@@ -1,3 +1,9 @@
+okular (4:20.08.3-2~frougon.0) unstable; urgency=medium
+
+  * Add patch debian/patches/fix-back-and-forward-navigation.patch, which 
corresponds to 
<https://invent.kde.org/graphics/okular/commit/585340cef5ca4dd1e26fe3baea1cf396f8de6469>.
+
+ -- Florent Rougon   Wed, 25 Nov 2020 22:25:47 +0100
+
 okular (4:20.08.3-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru okular-20.08.3/debian/patches/fix-back-and-forward-navigation.patch 
okular-20.08.3/debian/patches/fix-back-and-forward-navigation.patch
--- okular-20.08.3/debian/patches/fix-back-and-forward-navigation.patch 
1970-01-01 01:00:00.0 +0100
+++ okular-20.08.3/debian/patches/fix-back-and-forward-navigation.patch 
2020-11-25 22:24:14.0 +0100
@@ -0,0 +1,11 @@
+--- a/ui/pageview.cpp
 b/ui/pageview.cpp
+@@ -4509,7 +4509,7 @@
+ newViewport.rePos.normalizedY = focusedY;
+ // set the viewport to other observers
+ // do not update history if the viewport is autoscrolling
+-d->document->setViewportWithHistory(newViewport, this, false, 
d->scroller->state() == QScroller::Scrolling);
++d->document->setViewportWithHistory(newViewport, this, false, 
d->scroller->state() != QScroller::Scrolling);
+ }
+ d->document->setVisiblePageRects(visibleRects, this);
+ }

Bug#972885: emacs: Bundled Gnus unable to enter any group

[Florent Rougon]

tags 972885 + upstream
thanks

Hi Rob, thanks for your reply.

Rob Browning  wrote:

> Nice catch.  Have you, or are you already planning to post this
> upstream?

Well, I haven't done so but could certainly do it. I assume the Gnus
development list ("ding") would be more appropriate than an Emacs dev
list or Emacs bug report?

Regards

-- 
Florent

Bug#972885: emacs: Bundled Gnus unable to enter any group

[Florent Rougon]

retitle 972885 Lexical binding causes regression for gnus-summary-highlight
thanks

The problem appears to be due to the (presumably recent) use of lexical
binding in /usr/share/emacs/27.1/lisp/gnus/gnus-sum.el.gz
(cf. lexical-binding:t on the first line).

It is triggered by this piece of configuration from my .gnus.el:

(eval-after-load "gnus-sum"
  '(add-to-list
'gnus-summary-highlight
'((memq article gnus-newsgroup-processable)
  . flo-gnus-summary-processable-face)))

This code nicely highlights lines in the *Summary* buffer corresponding
to articles that have the process mark set. It has worked perfectly for
years until the aforementioned Emacs upgrade.

The problem can be solved either by me not using the above configuration
bit anymore (which is of course a regression), or by making the
`article' variable use dynamic binding before the failing `funcall' in
`gnus-summary-highlight-line' (see the attached patch; the change could
probably be done earlier in the function, along with the other similar
defvar's, but I've only tested the attached patch).

Regards

-- 
Florent
--- patch/gnus-sum.el.orig	2020-10-26 02:19:24.938566201 +0100
+++ patch/gnus-sum.el	2020-10-26 02:20:18.062310644 +0100
@@ -12834,6 +12834,7 @@
 	 (uncached (and gnus-summary-use-undownloaded-faces
 (memq article gnus-newsgroup-undownloaded)
 (not (memq article gnus-newsgroup-cached)
+(defvar article)
 (let ((face (funcall (gnus-summary-highlight-line-0
   (unless (eq face (gnus-get-text-property-excluding-characters-with-faces beg 'face))
 	(gnus-put-text-property-excluding-characters-with-faces

Bug#972885: emacs: Bundled Gnus unable to enter any group

[Florent Rougon]

Package: emacs
Version: 1:27.1+1-2
Severity: normal

Hello,

After upgrading my emacs packages today:

   [UPGRADE] emacs:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-bin-common:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-bin-common-dbgsym:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-common:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-el:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-gtk:amd64 1:26.3+1-2 -> 1:27.1+1-2
   [UPGRADE] emacs-gtk-dbgsym:amd64 1:26.3+1-2 -> 1:27.1+1-2

Gnus bundled with Emacs 27 can't enter any group anymore (from the
*Group* buffer). If I try to enter a group, I get the following error:

  Symbol's value as variable is void: article

Here is a backtrace of the error:

Debugger entered--Lisp error: (void-variable article)
  #f(compiled-function () #)()
  funcall(#f(compiled-function () #))
  (let ((face (funcall (gnus-summary-highlight-line-0 (if (eq face 
(gnus-get-text-property-excluding-characters-with-faces beg 'face)) nil 
(gnus-put-text-property-excluding-characters-with-faces beg (point-at-eol) 
'face (setq face (if (boundp face) (symbol-value face) face))) (if 
gnus-summary-highlight-line-function (progn (funcall 
gnus-summary-highlight-line-function article face)
  (let* ((beg (point-at-bol)) (article (or (gnus-summary-article-number) 
gnus-current-article)) (score (or (cdr (assq article gnus-newsgroup-scored)) 
gnus-summary-default-score 0)) (mark (or (let ((cl-x (gnus-data-find-in ... 
gnus-newsgroup-data))) (progn (progn (nth 1 cl-x gnus-unread-mark)) 
(inhibit-read-only t) (default gnus-summary-default-score) (default-high 
gnus-summary-default-high-score) (default-low gnus-summary-default-low-score) 
(uncached (and gnus-summary-use-undownloaded-faces (memq article 
gnus-newsgroup-undownloaded) (not (memq article gnus-newsgroup-cached) (let 
((face (funcall (gnus-summary-highlight-line-0 (if (eq face 
(gnus-get-text-property-excluding-characters-with-faces beg 'face)) nil 
(gnus-put-text-property-excluding-characters-with-faces beg (point-at-eol) 
'face (setq face (if (boundp face) (symbol-value face) face))) (if 
gnus-summary-highlight-line-function (progn (funcall 
gnus-summary-highlight-line-function article face))
  gnus-summary-highlight-line()
  gnus-summary-insert-line([0 "" "" "05 Apr 2001 23:33:09 +0400" "" "" 0 0 "" 
nil] 0 nil t 90 t nil "" nil 1)
  gnus-update-summary-mark-positions()
  gnus-summary-setup-buffer("nnml+mail:AUCTeX")
  gnus-summary-read-group-1("nnml+mail:AUCTeX" nil t nil nil nil)
  gnus-summary-read-group("nnml+mail:AUCTeX" nil t nil nil nil nil)
  gnus-group-read-group(nil t)
  gnus-group-select-group(nil)
  gnus-topic-select-group(nil)
  funcall-interactively(gnus-topic-select-group nil)
  call-interactively(gnus-topic-select-group nil nil)
  command-execute(gnus-topic-select-group)

This happens when `gnus-summary-highlight-line' from
/usr/share/emacs/27.1/lisp/gnus/gnus-sum.el.gz calls the byte-compiled
function that `gnus-summary-highlight-line-0' evaluates to. I've used my
nnml+mail:AUCTeX group as an example here, but this happens with all
groups I've tried. Hence, I can't read any mail with this version of the
emacs package. :-|

Thanks for your work!

Regards

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs depends on:
ii  emacs-gtk  1:27.1+1-2

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#965193: policykit-1: fails to install: chown error on /usr/lib/policykit-1/polkit-agent-helper-1

[Florent Rougon]

Hello,

Same problem here, please provide a fix. Thanks.

-- 
Florent

Bug#852108: usbguard: fails to start after installation: "ERROR: Configuration: /etc/usbguard/rules.conf: usbguard::Exception"

[Florent Rougon]

Hello,

Thanks for your work on this package! This bug has the 'pending' tag
since January 24, 2017. Maybe the fix is not pending anymore?

Thanks & regards

-- 
Florent

Bug#918358: libsane:amd64: Missing permissions for scanner group on usb device

[Florent Rougon]

Hello,

Same problem for me as well as for other people at [1]. This happened
after upgrading to 'buster' the machine where the scanner is plugged.
Adding the udev rule fixes the issue. This regression is annoying, it
would be nice for other users if our dear maintainers could fix it. :-)

Thanks & regards

[1] https://www.raspberrypi.org/forums/viewtopic.php?t=243513

-- 
Florent

Bug#921598: No METAR available since noaa.gov switched to https

[Florent Rougon]

Hi again Gabriel, hi Tobias,

"Dr. Tobias Quathamer"  wrote:

> Hi Gabriel and Florent,
>
> thanks for reporting this bug and pointing to the commits! I'm currently
> preparing a new upload of simgear which should still be in time for buster.

The partial revert I foresaw has happened. :)

  
https://sourceforge.net/p/flightgear/flightgear/ci/c2fb01ccb7df6fc893ab79850654cb39153cea3d/

Regards

-- 
Florent

Bug#921598: No METAR available since noaa.gov switched to https

[Florent Rougon]

Hello,

"Gabriel F. T. Gomes"  wrote:

> I updated the merge request.
>
> When I first wrote the merge request, upstream did not have a fix for
> the METAR problem.  Now they do [1].  So, I removed the simple patch I
> wrote, and replaced it with this upstream fix.

(...)

> [1]
> https://sourceforge.net/p/flightgear/flightgear/ci/2fdc24c1097955c5d2c88a9cc0be66069b22eebe/

As has been discussed on flightgear-devel and despite the commit
message, commit [1] is not a proper fix and will probably be reverted (I
mean, the "if( responseCode() >= 400 )" part, not the http to https URL
change which is okay though unnecessary now that redirection is fixed in
SimGear's HTTP::Client).

The correct fix is [a]. [b] is also a bug fix in this area, but doesn't
solve the particular METAR fetching problem.

[a] 
https://sourceforge.net/p/flightgear/simgear/ci/34b3c52a288d62779073fc7694344d0658755645/
[b] 
https://sourceforge.net/p/flightgear/simgear/ci/6197098541eceecdb0dcfe8a58b15f0d0773c391/

-- 
Florent

Bug#887411: [pkg-fgfs-crew] Bug#887411: fgfs: segfaults when receiving UDP data too early

[Florent Rougon]

Hello,

Frank Heckenbach  wrote:

> When receiving UDP data too early, fgfs segfaults after giving the
> message:
>
>   AI error: updating aircraft without traffic record at ...
>
> I've traced the segfault to trafficcontrol.cxx:984
>
> At this point, "current" is uninitialized, so UB.

Thanks for you report. There was a fix applied in May 2017 that seems to
address the problem you found:

  
https://sourceforge.net/p/flightgear/flightgear/ci/9a64150d57ef2b7a72a3b704e97a0abbaeb10a32/

This fix is present in FlightGear 2017.2.1 and all versions >= 2017.3.0.

Regards

-- 
Florent

Bug#870806: Also fails with 2.1.22

[Florent Rougon]

Hi,

The workaround I've found is to put:

  disable-ipv6

in ~/.gnupg/dirmngr.conf. It's a pity that IPv4 isn't supported by
default anymore, because some people disable IPv6 on their boxes
*precisely* for security reasons---following the same logic that leads
one to only install the server software one needs, and only open the
needed ports on a firewall, no more.

Regards

-- 
Florent

Bug#873439: [pkg-fgfs-crew] Bug#873439: flightgear: CVE-2017-13709: Incorrect access control

[Florent Rougon]

Hi,

For stretch, the last two commits of upstream branch release/2016.4:

  https://sourceforge.net/p/flightgear/flightgear/ci/release/2016.4/~/tree/

should do the job (as already said in other mails, and ditto for
unstable with the release/2017.2 branch).

For jessie (it's also affected), I successfully built FG in a
jessie-amd64 pbuilder chroot with the attached source debdiff. You'll
certainly want to make the patch headers DEP-3-compliant and arrange
debian/changelog (at least the version number), but the C++ side should
be fine with these changes. I only tested the build in this old version:
no runtime test, but I don't expect any particular problem. :)

Regards

-- 
Florent
diff -Nru flightgear-3.0.0/debian/changelog flightgear-3.0.0/debian/changelog
--- flightgear-3.0.0/debian/changelog	2017-07-02 14:39:08.0 +0200
+++ flightgear-3.0.0/debian/changelog	2017-08-28 18:07:28.0 +0200
@@ -1,3 +1,13 @@
+flightgear (3.0.0-5+deb8u3+frougon0) jessie; urgency=high
+
+  * Add two patches for CVE-2017-13709:
+  - call-fgInitAllowedPaths-earlier-c7a2ae.patch (required by the next
+patch)
+  - CVE-2017-13709-FGLogger-2a5e3d.patch
+  * The patch headers are not in the Debian DEP-3 format, this needs fixing.
+
+ -- Florent Rougon <f.rou...@free.fr>  Mon, 28 Aug 2017 18:07:28 +0200
+
 flightgear (3.0.0-5+deb8u2) jessie; urgency=high
 
   * Add patch restrict-save-flightplan-secu-fix-faf872.patch: prevent
diff -Nru flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch
--- flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch	1970-01-01 01:00:00.0 +0100
+++ flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch	2017-08-28 18:07:28.0 +0200
@@ -0,0 +1,55 @@
+Author: Florent Rougon <f.rou...@free.fr>
+
+Call fgInitAllowedPaths() earlier: after Options::processOptions()
+
+Call fgInitAllowedPaths() right after Options::processOptions() (which,
+among other things, determines $FG_ROOT and processes
+--allow-nasal-read). This way, fgInitAllowedPaths() can be used in much
+more code, such as when initializing subsystems.
+
+(cherry picked from commit c7a2aef59979af3e9ff22daabb37bdaadb91cd75)
+
+--- a/src/Main/fg_init.cxx
 b/src/Main/fg_init.cxx
+@@ -1023,7 +1023,12 @@
+ fgGetNode("/sim")->removeChild("aircraft-dir");
+ fgInitAircraft(true);
+ flightgear::Options::sharedInstance()->processOptions();
+-
++
++// Rebuild the lists of allowed paths for cases where a path comes from an
++// untrusted source, such as the global property tree (this uses $FG_HOME
++// and other paths set by Options::processOptions()).
++fgInitAllowedPaths();
++
+ render = new FGRenderer;
+ render->setEventHandler(eventHandler);
+ globals->set_renderer(render);
+--- a/src/Main/main.cxx
 b/src/Main/main.cxx
+@@ -461,7 +461,12 @@
+ } else if (configResult == flightgear::FG_OPTIONS_EXIT) {
+ return EXIT_SUCCESS;
+ }
+-
++
++// Set the lists of allowed paths for cases where a path comes from an
++// untrusted source, such as the global property tree (this uses $FG_HOME
++// and other paths set by Options::processOptions()).
++fgInitAllowedPaths();
++
+ // Initialize the Window/Graphics environment.
+ fgOSInit(, argv);
+ _bootstrap_OSInit++;
+--- a/src/Scripting/NasalSys.cxx
 b/src/Scripting/NasalSys.cxx
+@@ -800,9 +800,6 @@
+   .member("singleShot", ::isSingleShot, ::setSingleShot)
+   .member("isRunning", ::isRunning);
+ 
+-// Set allowed paths for Nasal I/O
+-fgInitAllowedPaths();
+-
+ // Now load the various source files in the Nasal directory
+ simgear::Dir nasalDir(SGPath(globals->get_fg_root(), "Nasal"));
+ loadScriptDirectory(nasalDir);
diff -Nru flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch
--- flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch	1970-01-01 01:00:00.0 +0100
+++ flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch	2017-08-28 18:07:28.0 +0200
@@ -0,0 +1,69 @@
+Author: Florent Rougon <f.rou...@free.fr>
+
+Security: don't allow FGLogger to overwrite arbitrary files
+
+Since the paths of files written by FGLogger come from the property
+tree[1], they must be validated before we decide to write to these
+files.
+
+[1] Except for the "empty" case, which uses the default name
+'fg_log.csv'.
+
+This fixes CVE-2017-13709.
+
+(cherry picked from commit 2a5e3d06b2c0d9f831063afe7e7260bca456d679)
+
+--- a/src/Main/logger.cxx
 b/src/Main/logger.cxx
+@@ -11,10 +11,14 @@
+ 
+ #include 
+ #include 
++#include 
+ 
+ #include 
++#in

Bug#869309: [pkg-fgfs-crew] Bug#869309: Bug#869309: Updating the fgo Uploaders list

[Florent Rougon]

Hi,

Tobias Frost  wrote:

> It's your decission; close the bug, you will be kept as Uploader, 
> keep it open -> you will eventually be removed. (I gues this decission
> should not be delegated to the maintainer, but thats just my 2ct)

This bug is fixed in the Git repository on alioth (I removed myself from
Uploaders).

Regards

-- 
Florent

Bug#869310: Updating the pythondialog Uploaders list

[Florent Rougon]

Hallo Tobias,

Tobias Frost <t...@debian.org> wrote:

> Source: pythondialog
> Version: 3.4.0-1
> Severity: minor
> User: m...@qa.debian.org
> Usertags: mia-teammaint
>
> Florent Rougon <f...@debian.org> has retired, so can't work on
> the pythondialog package anymore (at least with this address).
>
> We are tracking their status in the MIA team and would like to ask you
> to remove them from the Uploaders list of the package so we can close
> that part of the file.

As explained in another mail, I announced my retirement from DD status
six years *before* my work on this Debian packaging, so in some way I
semi-resumed after this retirement. Even though I lack time to work on
Debian stuff, I'd like to update the package in the future if RL
permits. If someone wants to actively take over, that is fine with me
and I can get out, otherwise maybe it is okay to stay this way.

Regards

-- 
Florent

Bug#869309: [pkg-fgfs-crew] Bug#869309: Bug#869309: Updating the fgo Uploaders list

[Florent Rougon]

Hallo Tobias,

Tobias Frost  wrote:

> The database told me you've retired. If that is not the case or you've
> resumed (e.g using your @free.frp email) please appologize and just
> close the "Remove from uploaders" bugs. I absolutly do not want that
> you're being removed from any package as long as you're active!

I retired from DD status in 2008 and semi-resumed in 2014 (semi: without
asking to get this DD status back, because I can't spend enough time to
make it meaningful). It is true I don't have enough time for Debian work
at the moment due to RL difficulties... but I haven't completely given
up.

>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787464
>
> package overhauled & uploaded, including your fix. Many thanks for it
> (however I could not test your fix as lacking a joystick)

Very good, thank you! Too bad this came after the stretch release...

As for this bug, I'll let Markus decide. I am not interested in the
software anymore (having myself forked the upstream project years ago
because I couldn't reach the upstream author anymore, and there wasn't
any update either), but since the package is still in the archive, I
*might* be able to help if needed for a specific problem...

To be clear: I won't feel offended if removed from Uploaders.

Regards

-- 
Florent

Bug#869309: [pkg-fgfs-crew] Bug#869309: Updating the fgo Uploaders list

[Florent Rougon]

Hello,

Tobias Frost <t...@debian.org> wrote:

> Florent Rougon <f...@debian.org> has retired, so can't work on
> the fgo package anymore (at least with this address).
>
> We are tracking their status in the MIA team and would like to ask you
> to remove them from the Uploaders list of the package so we can close
> that part of the file.

I don't mind being removed from the Uploaders list (FGo! being obsolete
IMHO), but if you want to do useful QA work for the FlightGear ecosystem
that will also benefit any package using libplibjs, I'd rather suggest
to do a QA upload of plib as I suggested (with patch) at:

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

That was more than two years ago---I agree it is not much if you
consider the upstream bug's honorable age, namely 13 years.

Regards

-- 
Florent

Bug#857050: firefox no longer plays sound without pulseaudio daemon

[Florent Rougon]

Hello,

Let me add a “me too” to express my sadness seeing firefox not being
able to use alsa anymore. IMO, this is a clear regression.

Regards

-- 
Florent

Bug#848114: flightgear: Allows the route manager to overwrite arbitrary files

[Florent Rougon]

Markus Wanner  wrote:

> Hello Florent,
>
> thanks a lot for your notification and the patch(es). Uploads to stable
> (security) and unstable should follow, shortly.

Fine, thank you, Markus!

Regards

-- 
Florent

Bug#848114: flightgear: Allows the route manager to overwrite arbitrary files

[Florent Rougon]

Source: flightgear
Version: 3.0.0-5
Severity: grave
Tags: security upstream fixed-upstream patch
Justification: user security hole

Hello,

As already stated in several places:

  
https://sourceforge.net/p/flightgear/flightgear/ci/280cd523686fbdb175d50417266d2487a8ce67d2/
  https://sourceforge.net/p/flightgear/mailman/message/35548661/
  
http://lists.alioth.debian.org/pipermail/pkg-fgfs-crew/2016-December/001795.html

and reported to people in charge of FlightGear both upstream (of which I am a
recent addition) and in several Linux distributions, the flightgear package
has a security bug allowing malicious Nasal code[1] to overwrite arbitrary
files the user running FlightGear has write access to, by using the property
tree to cause the route manager to save a flightplan.

This problem is, AFAICT, present in all FlightGear versions released after
October 5, 2009, which largely includes those shipped in Debian stable,
testing and unstable. It is however fixed in the upstream Git repository:

  
https://sourceforge.net/p/flightgear/flightgear/ci/280cd523686fbdb175d50417266d2487a8ce67d2/

and I have backported this fix to FlightGear 3.0.0, i.e., the version shipped
in jessie: cf. two links given above
(<https://sourceforge.net/p/flightgear/mailman/message/35548661/> and
<http://lists.alioth.debian.org/pipermail/pkg-fgfs-crew/2016-December/001795.html>),
the second one being more ready-to-use for Debian since it contains a debdiff
including an additional fix for build failures I encountered while testing the
fix in the jessie package.

Since all parties have already been contacted, this bug report is mainly for
tracking purposes, as advised by
<https://www.debian.org/security/faq#discover>.

I'm attaching here the patch for FlightGear 3.0.0 as well as the mentioned
debdiff for completeness and “self-containedness” of this report. The upstream
fix
(<https://sourceforge.net/p/flightgear/flightgear/ci/280cd523686fbdb175d50417266d2487a8ce67d2/>)
can certainly be used as is for the version in unstable.

Regards

[1] Which can be embedded in aircraft, which can in their turn be installed by
users from various third-party sources.
Description: Security fix: don't allow the route manager to overwrite arbitrary files
 Since the Save function of the route manager can be triggered from Nasal with
 an arbitrary path, we must check the path before overwriting the file.
 .
 (also add a missing include that is directly needed for this commit)
Author: Florent Rougon <f.rou...@free.fr>
Origin: upstream, https://sourceforge.net/p/flightgear/flightgear/ci/280cd523686fbdb175d50417266d2487a8ce67d2/

--- a/src/Autopilot/route_mgr.cxx
+++ b/src/Autopilot/route_mgr.cxx
@@ -47,6 +47,7 @@
 #include 
 #include 
 
+#include 
 #include "Main/fg_props.hxx"
 #include "Navaids/positioned.hxx"
 #include 
@@ -55,6 +56,8 @@
 #include "Airports/runways.hxx"
 #include 
 #include 
+#include // fgValidatePath()
+#include 
 
 #define RM "/autopilot/route-manager/"
 
@@ -707,7 +710,23 @@ void FGRouteMgr::InputListener::valueChanged(SGPropertyNode *prop)
   mgr->loadRoute(path);
 } else if (!strcmp(s, "@SAVE")) {
   SGPath path(mgr->_pathNode->getStringValue());
-  mgr->saveRoute(path);
+  const std::string authorizedPath = fgValidatePath(path.str(),
+true /* write */);
+
+  if (!authorizedPath.empty()) {
+mgr->saveRoute(authorizedPath);
+  } else {
+const SGPath proposedPath = SGPath(globals->get_fg_home()) / "Export";
+std::string msg =
+  "The route manager was asked to write the flightplan to '" +
+  path.str() + "', but this path is not authorized for writing. " +
+  "Please choose another location, for instance in the $FG_HOME/Export "
+  "folder (" + proposedPath.str() + ").";
+
+SG_LOG(SG_AUTOPILOT, SG_ALERT, msg);
+modalMessageBox("FlightGear", "Unable to write to the specified file",
+msg);
+  }
 } else if (!strcmp(s, "@NEXT")) {
   mgr->jumpToIndex(mgr->currentIndex() + 1);
 } else if (!strcmp(s, "@PREVIOUS")) {
diff -Nru flightgear-3.0.0/debian/changelog flightgear-3.0.0/debian/changelog
--- flightgear-3.0.0/debian/changelog	2015-03-18 11:19:39.0 +0100
+++ flightgear-3.0.0/debian/changelog	2016-12-13 12:40:51.0 +0100
@@ -1,3 +1,13 @@
+flightgear (3.0.0-5+deb8u1) jessie; urgency=medium
+
+  * Add patch route-manager-secu-fix-280cd5.patch (security fix preventing
+the route manager from being able to overwrite arbitrary files
+writable by the user running FlightGear).
+  * Add patch fix-missing-lX11-in-link-commands.patch to fix an FTBFS
+failure due to -lX11 missing in two link commands.
+
+ -- Florent Ro

Bug#785606: linux-image-4.0.0-1-amd64: DragonRise joystick support broken in 4.0.2-1

[Florent Rougon]

It seems the bug was fixed by this upstream commit:

commit 18339f59c3a6698ee17d32970c9e1e450b16e7c3
Author: Maciej Zuk
Date:   Thu Sep 3 21:46:39 2015 +0200

HID: dragonrise: fix HID Descriptor for 0x0006 PID

Fixed HID descriptor for DragonRise Joystick.  Replaced default descriptor
which doubles Z axis and causes mixing values of X and Z axes.

This means the first release incorporating the fix is v4.4 (v4.4-rc1
already contains it).

-- 
Florent

Bug#785606: linux-image-4.0.0-1-amd64: DragonRise joystick support broken in 4.0.2-1

[Florent Rougon]

Update:
  - upstream kernel 4.3.3 (most probably Debian also) and many kernels
(probably all) between, at least and inclusive on both ends, versions
4.0.2 and 4.3.3 are affected by this bug;
  - upstream kernel 4.5.5 is *not affected*; Debian kernels 4.5.4-1 and
4.5.5-1 are *not affected* either (the axes numbers have changed
since 3.16.7, I believe, but this is a minor inconvenience);
  - Benjamin Tissoires replied to me;
  - why recent kernels are not affected is still unclear, because the
code from commit 79346d620e9de87912de73337f6df8b7f9a46888 is still
there---I imagine that some change between 4.3.3 and 4.5.4 maybe
causes the DragonRise joypad to use a code path that doesn't go
through the lines added by said commit;
  - I offered to build a patched kernel with debug statements to clarify
this point.

-- 
Florent

Bug#816227: ping: socket: Address family not supported by protocol (raw socket required by specified options).

[Florent Rougon]

Hello,

Noah Meyerhans  wrote:

> Confirmed that this breaks ping when run without an explicit address
> family. This is actually already fixed upstream, but not in a tagged
> snapshot. It'll be fixed in the next upload, by cherry-picking that
> commit or syncing a new snapshot.

Good news, thank you. :-)

-- 
Florent

Bug#815864: python3-venv: unable to create a virtual environment

[Florent Rougon]

Simple workaround for this bug:

  1) Create the venv with --without-pip. For instance:

   /usr/bin/python3.5 -m venv --without-pip 

  2) Download https://bootstrap.pypa.io/get-pip.py as ~/tmp/get-pip.py.

  3) Bootstrap pip "manually" in your venv:

   /bin/python ~/tmp/get-pip.py

HTH

-- 
Florent

Bug#816227: ping: socket: Address family not supported by protocol (raw socket required by specified options).

[Florent Rougon]

Hello,

On Sun, 28 Feb 2016 22:38:05 + Jamie Heilman  
wrote:

> Noah Meyerhans wrote:
> > I cannot reproduce this on a host with no ipv6 connectivity. Does 
> > 'ping -4 127.0.0.1' work any differently?
> 
> Yeah, that works.

Same here. 'ping -4 ' works fine but 'ping '
doesn't (I tried with 127.0.0.1, with the address of a local Ethernet
interface, with the address of a host I can ssh to on the local
network...).

> > By "no ipv6 support", do you mean you're running a custom kernel with a
> > different configuration than provided by Debian?

For me, the kernel is that from linux-image-4.4.0-1-amd64 version
4.4.2-3 (recently updated from unstable), rebuilt with one tiny patch
that is not network-related in any way, and which I have been using
since June 2015 without any problem: it is just reverting upstream Linux
kernel commit 79346d620e9de87912de73337f6df8b7f9a46888 ("HID: input:
force generic axis to be mapped to their user space axis"; I
unfortunately have to apply this patch to every kernel release since
then, because nobody bothered to even answer bug #785606 despite my
'git bisect'ing it).

Apart from that, I use:

  GRUB_CMDLINE_LINUX="init=/bin/systemd ipv6.disable=1"

in /etc/default/grub, which effectively disables IPv6, AFAICT.

My aptitude.log shows:

  [UPGRADE] iputils-ping:amd64 3:20121221-5+b2 -> 3:20150815-1

on Fri, Feb 26 2016 20:48:43 +0100, and I only noticed the problem
today.

Thanks for considering!

-- 
Florent

Bug#815864: python3-venv: unable to create a virtual environment

[Florent Rougon]

Some more info:

Inserting a 'print(cmd)' at line 259 showed that the direct cause of
the error message is the command:

  ['/home/flo/python-venv/testdir/bin/python3.5',
   '-Im', 'ensurepip', '--upgrade', '--default-pip']

exiting with a non-zero exit status. Running this command by hand after
the venv creation failed yields:

~/python-venv % /home/flo/python-venv/testdir/bin/python3.5 -Im ensurepip 
--upgrade --default-pip; echo $?
Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 184, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3.5/ensurepip/__main__.py", line 4, in 
ensurepip._main()
  File "/usr/lib/python3.5/ensurepip/__init__.py", line 218, in _main
version="pip {}".format(version()),
  File "/usr/lib/python3.5/ensurepip/__init__.py", line 74, in version
assert len(wheel_names) == 1, wheel_names
AssertionError: []
1
~/python-venv %

The assertion error comes from this in
/usr/lib/python3.5/ensurepip/__init__.py:

wheel_names = glob.glob('/usr/share/python-wheels/pip-*.whl')
assert len(wheel_names) == 1, wheel_names

and indeed:

~/python-venv % ls /usr/share/python-wheels/pip-*.whl
zsh: no matches found: /usr/share/python-wheels/pip-*.whl
~/python-venv % apt-file search /usr/share/python-wheels/pip-
virtualenv: /usr/share/python-wheels/pip-8.0.2-py2.py3-none-any.whl
~/python-venv %

I then installed the 'virtualenv' package, which does provide the
mentioned file, and tried to recreate the venv from scratch after adding
a 'print(os.getcwd())' right after the previously-added 'print(cmd)' in
/usr/lib/python3.5/venv/__init__.py (lines 259-260, before the 'try'
statement in EnvBuilder._setup_pip()):

~/python-venv % rm -rf testdir
~/python-venv % /usr/bin/python3.5 -m venv testdir
['/home/flo/python-venv/testdir/bin/python3.5', '-Im', 'ensurepip', 
'--upgrade', '--default-pip']
/home/flo/python-venv
The virtual environment was not created successfully because ensurepip is not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

apt-get install python3-venv

You may need to use sudo with that command.  After installing the python3-venv
package, recreate your virtual environment.

~/python-venv % /usr/bin/python3.5 -c "import subprocess; 
subprocess.check_output(['/home/flo/python-venv/testdir/bin/python3.5', '-Im', 
'ensurepip', '--upgrade', '--default-pip'])"
Traceback (most recent call last):
  File 
"/tmp/tmpicb907db/pip-8.0.2-py2.py3-none-any.whl/pip/_vendor/__init__.py", line 
33, in vendored
ImportError: No module named 'pip._vendor.cachecontrol'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 184, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3.5/ensurepip/__main__.py", line 4, in 
ensurepip._main()
  File "/usr/lib/python3.5/ensurepip/__init__.py", line 269, in _main
default_pip=args.default_pip,
  File "/usr/lib/python3.5/ensurepip/__init__.py", line 175, in bootstrap
_run_pip(args + _PROJECTS, additional_paths)
  File "/usr/lib/python3.5/ensurepip/__init__.py", line 65, in _run_pip
import pip
  File "/tmp/tmpicb907db/pip-8.0.2-py2.py3-none-any.whl/pip/__init__.py", line 
12, in 
  File "/tmp/tmpicb907db/pip-8.0.2-py2.py3-none-any.whl/pip/exceptions.py", 
line 6, in 
  File 
"/tmp/tmpicb907db/pip-8.0.2-py2.py3-none-any.whl/pip/_vendor/__init__.py", line 
52, in 
  File 
"/tmp/tmpicb907db/pip-8.0.2-py2.py3-none-any.whl/pip/_vendor/__init__.py", line 
35, in vendored
ImportError: No module named 'cachecontrol'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.5/subprocess.py", line 626, in check_output
**kwargs).stdout
  File "/usr/lib/python3.5/subprocess.py", line 708, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command 
'['/home/flo/python-venv/testdir/bin/python3.5', '-Im', 'ensurepip', 
'--upgrade', '--default-pip']' returned non-zero exit status 1
~/python-venv %

-- 
Florent

Bug#815864: python3-venv: unable to create a virtual environment

[Florent Rougon]

Package: python3-venv
Version: 3.5.1-2
Severity: serious
Justification: renders the package unusable

Hello,

It seems current Python 3 packages in Debian unstable don't allow
creating a virtual environment anymore with pyvenv and friends:

~/python-venv % /usr/bin/python3.5 -m venv testdir
The virtual environment was not created successfully because ensurepip is not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

apt-get install python3-venv

You may need to use sudo with that command.  After installing the python3-venv
package, recreate your virtual environment.

~/python-venv % dpkg -l python3-venv
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  python3-venv   3.5.1-2  amd64pyvenv-3 binary for python3 (defa
~/python-venv %

Thanks in advance for looking into this.

Regards

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

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

Versions of packages python3-venv depends on:
ii  python3 3.5.1-2
ii  python3.5-venv  3.5.1-7

python3-venv recommends no packages.

python3-venv suggests no packages.

-- no debconf information

Bug#811479: boot fails in "run-init -n ..."

[Florent Rougon]

Hello,

Same problem here after yesterday's upgrade. The 0.122~a.test
initramfs-tools and initramfs-tools-core packages mentioned by Ben at
 allowed my
system to boot, thank you!

(along with the Debian jessie installation DVD in rescue mode, its
option to automatically assemble RAID arrays, followed by mounting the
/, /usr and /var filesystems of my normal system at temporary mount
points, chrooting into the temporarily-mounted root before running dpkg
-i the_deb_files [maybe simply booting with the previous kernel to
install the test packages would have worked, too?..])

Regards

-- 
Florent

Bug#808762: 'remote: error: unable to update info/refs+' when pushing to a repo on alioth

[Florent Rougon]

Package: tracker.debian.org
Severity: normal

Hello,

I got the error cited in the subject when doing 'git push' for the fgo Git
repo hosted on alioth:

% git push
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 664 bytes | 0 bytes/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: Sending notification emails to: dispatch+fgo_...@tracker.debian.org
remote: error: unable to update info/refs+
To git+ssh://f...@scm.alioth.debian.org//git/collab-maint/fgo.git
   413b26a..73f1c15  master -> master
%

The commit seems to have worked, but I thought it would be good to know what
caused this error message. My apologies if this is not the right place for
such a report.

Thanks

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

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

Bug#805964: geographiclib: Please provide a package for Python 3

[Florent Rougon]

Hi Bas,

> I've just uploaded geographiclib (1.45-2) which adds
> python3-geographiclib using pybuild for all python versions.
>
> Because python3-geographiclib is a new package it will have to pass the
> NEW queue before it will be available in the archive.

That's great, thank you very much! :-)

-- 
Florent

Bug#805964: geographiclib: Please provide a package for Python 3

[Florent Rougon]

Source: geographiclib
Severity: wishlist

Hello,

I am using GeographicLib under Python 3 for FFGo[1], and it works fine
for what I ask it to do. It would be nice for users if you could ship a
package for Python 3 in addition to the Python 2 package. Not to mention
that Python 2 is progressively being phased out...

Thank you.

Regards

  [1] http://people.via.ecp.fr/~flo/projects/FFGo/

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

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

Bug#801150: openssh-client: PubkeyAuthentication not working when ~/.ssh/id_rsa.pub is present

[Florent Rougon]

retitle 801150 PubkeyAuthentication not working when ~/.ssh/id_rsa.pub is 
present
thanks

(I let you adjust the severity as you see fit)

Hi Colin, thanks for your prompt answer!

Colin Watson  wrote:

> Do you have a good reason to still be using the RSAAuthentication
> option?  It's protocol 1 only, which has been obsolete for a decade or
> so, and your -vv transcript shows that you're using protocol 2 so
> RSAAuthentication cannot possibly work.  Since you're communicating with
> a server version that is substantially less than a decade old, there
> should be no reason to try to use protocol 1 with it.  The protocol 2
> equivalent is PubkeyAuthentication.

Ah, right, then I meant PubkeyAuthentication, sorry for the confusion.

> You will of course need to make sure that you aren't using an RSA1 key
> (ssh-keygen -t rsa1 vs. -t rsa).

I generated a new key with '-t rsa' but it doesn't change anything.
After some trial and error, I determined that authentication works iff I
rename ~/.ssh/id_rsa.pub to something else (e.g., 'disabled.pub', or
moved to a different directory). This is on the client, of course.

I got this idea because ssh-add(1) now says:

  After loading a private key, ssh-add will try to load
  corresponding certificate information from the filename obtained by
  appending -cert.pub to the name of the private key file.

so I first tried id_rsa-cert.pub, then found out that anything other
than ~/.ssh/id_rsa.pub appears to work. BTW, I have no idea what this
new -cert.pub suffix is about.

If you think this would be useful, I can send you logs of the sshd
server in debug mode by private mail.

Thanks for your support.

-- 
Florent

Bug#801150: openssh-client: RSAAuthentication not working

[Florent Rougon]

Package: openssh-client
Version: 1:6.9p1-2
Severity: important

Hello,

I am having problems connecting to other hosts using RSAAuthentication. The
password prompt for the key does not even appear. Adding the key to the
ssh-agent doesn't help. Usually, it works fine between the same hosts. Tested
with two different servers. I didn't change my key recently.
PasswordAuthentication works fine.

Thanks for your help!

% ssh -vv user@host
OpenSSH_6.9p1 Debian-2, OpenSSL 1.0.2d 9 Jul 2015
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 14: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to host [192.168.0.4] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Debian-2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 
Debian-5
debug1: match: OpenSSH_6.7p1 Debian-5 pat OpenSSH* compat 0x0400
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to host:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 
curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: 
ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ed25519-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
debug2: kex_parse_kexinit: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
debug2: kex_parse_kexinit: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-...@openssh.com,hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com,hmac-md5-96-...@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-...@openssh.com,hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com,hmac-md5-96-...@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,z...@openssh.com,zlib
debug2: kex_parse_kexinit: none,z...@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: 
curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com
debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com
debug2: kex_parse_kexinit: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,z...@openssh.com
debug2: kex_parse_kexinit: none,z...@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug1: kex: server->client chacha20-poly1...@openssh.com  none
debug1: kex: client->server 

Bug#785606: linux-image-4.0.0-1-amd64: DragonRise joystick support broken in 4.0.2-1

[Florent Rougon]

forwarded 785606 Benjamin!Tissoires!t!redhat!com
thanks

Bug forwarded on Wed, 26 Aug 2015 10:37:23 +0200 to the author of commit
79346d620e9de87912de73337f6df8b7f9a46888, no response received so far
AFAICT.

This bug still applies to:

  4.2.0-1-amd64 #1 SMP Debian 4.2.1-1 (2015-09-25) x86_64 GNU/Linux

Bug#750601: GnuTLS: Error in the push function when using a client certificate

[Florent Rougon]

reopen 750601
retitle 750601 wget: Unable to connect with HTTPS using a client certificate
found 750601 1.16-1
tags 750601 - moreinfo
thanks

Hello,

I'm afraid the problem remains that wget cannot download anything with
HTTPS when a client certificate is required. Tested on current unstable
and jessie (I double checked that connecting to the same address with
the same client cert does work with Firefox).

I retitled the bug since the error message has changed... The exact same
command as before does fail (i.e., from the initial bug report). I
simplified it here a little bit by omitting '-rc', which is not
necessary to reproduce the bug.

On unstable:

  % wget --certificate= --private-key= -nH -np -vvv \
--ca-cert= https://server-name:port/path
  --2015-08-28 17:58:48--  https://server-name:port/path
  Loaded CA certificate ''
  Resolving server-name (server-name)... server-ip
  Connecting to server-name (server-name)|server-ip|:port... connected.
  GnuTLS: A TLS fatal alert has been received.
  GnuTLS: received alert [40]: Handshake failed
  Unable to establish SSL connection.
  %

On jessie, omitting the '--ca-cert=' option, which is probably not
necessary since the corresponding cert is system-installed on the client
box (in /etc/ssl/certs):

  % wget --certificate= --private-key= -nH -np -vvv \
https://server-name:port/path
  --2015-08-28 18:08:22--  https://server-name:port/path
  Resolving server-name (server-name)... server-ip
  Connecting to server-name (server-name)|server-ip|:port... connected.
  GnuTLS: A TLS fatal alert has been received.
  GnuTLS: received alert [40]: Handshake failed
  Unable to establish SSL connection.
  %

 I'm marking this as fixed for 1.16 because there were no other bug
 reports like this.

Do you know any user who could successfully use client certs with wget?

I am including below the usual reportbug package/etc. info for the
unstable box used to run the first test from this mail.

Regards

-- 
Florent

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

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

Versions of packages wget depends on:
ii  libc6  2.19-19
ii  libgnutls-deb0-28  3.3.17-1
ii  libidn11   1.32-1
ii  libnettle6 3.1.1-4
ii  libpcre3   2:8.35-7.1
ii  libpsl00.8.0-1
ii  libuuid1   2.26.2-9
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages wget recommends:
ii  ca-certificates  20150426

wget suggests no packages.

-- no debconf information

Bug#750601: GnuTLS: Error in the push function when using a client certificate

[Florent Rougon]

Hello Noël,

Noël Köthe n...@debian.org wrote:

 Is this still reproduce able with wget in jessie (1.16) or later?

Um, that was more than one year ago... and I don't have the Apache setup
to test this anymore, unfortunately. I'll keep you informed when I can
do this test again (on jessie and unstable, presumably).

Regards

-- 
Florent


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

Bug#788856: joystick: jscal-store and jscal-restore can't find the product name or vendor anymore

[Florent Rougon]

Well, this problem seems to be sorted out now. Since the joystick
package has received no update in the meantime, and I don't think I have
upgraded the kernel after the last time I reproduced the bug, I suppose
the fix may have been brought by a recent udev upgrade (221-1?).

From my POV, the bug may be closed.

-- 
Florent


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

Bug#789922: kio-dev: uninstallable on current unstable

[Florent Rougon]

Hi Lisandro,

Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote:

 Qt5 is currently going trough a transition, so this is just OK. You just
 need to wait until it's sorted out.

 Actually you will need to wait until the package gets pushed to unstable or 
 rebuilt in experimental. It should happen soon though.

OK, thank you for your quick answer. I will wait, then. :)

Regards

-- 
Florent


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

Bug#789922: kio-dev: uninstallable on current unstable

[Florent Rougon]

Package: kio-dev
Version: 5.9.0-1
Severity: serious
Justification: Policy 7.2

Hello,

Since yesterday's upgrade, kio-dev is not installable anymore on sid:

# aptitude install kio-dev
The following NEW packages will be installed:
  kio{a} (for kio-dev)  kio-dev  libdbusmenu-qt5-2{a} (for kio-dev)
  libkf5attica5{a} (for kio-dev)  libkf5auth-data{a} (for kio-dev)
  libkf5auth-dev{a} (for kio-dev)  libkf5auth5{a} (for kio-dev)
  libkf5bookmarks-data{a} (for kio-dev)
  libkf5bookmarks-dev{a} (for kio-dev)  libkf5bookmarks5{a} (for kio-dev)
  libkf5codecs-data{a} (for kio-dev)  libkf5codecs-dev{a} (for kio-dev)
  libkf5codecs5{a} (for kio-dev)  libkf5completion-data{a} (for kio-dev)
  libkf5completion-dev{a} (for kio-dev)
  libkf5completion5{ab} (for kio-dev)  libkf5config-bin{a} (for kio-dev)
  libkf5config-data{a} (for kio-dev)  libkf5config-dev{a} (for kio-dev)
  libkf5configcore5{a} (for kio-dev)  libkf5configgui5{a} (for kio-dev)
  libkf5configwidgets-data{a} (for kio-dev)
  libkf5configwidgets-dev{a} (for kio-dev)
  libkf5configwidgets5{a} (for kio-dev)
  libkf5coreaddons-data{a} (for kio-dev)
  libkf5coreaddons-dev{a} (for kio-dev)
  libkf5coreaddons5{a} (for kio-dev)  libkf5crash5{a} (for kio-dev)
  libkf5dbusaddons-bin{a} (for kio-dev)
  libkf5dbusaddons-data{a} (for kio-dev)
  libkf5dbusaddons-dev{a} (for kio-dev)
  libkf5dbusaddons5{a} (for kio-dev)
  libkf5globalaccel-bin{a} (for kio-dev)
  libkf5globalaccel-data{a} (for kio-dev)
  libkf5globalaccel-dev{a} (for kio-dev)
  libkf5globalaccel5{a} (for kio-dev)
  libkf5guiaddons-dev{a} (for kio-dev)  libkf5guiaddons5{a} (for kio-dev)
  libkf5i18n-data{a} (for kio-dev)  libkf5i18n-dev{a} (for kio-dev)
  libkf5i18n5{a} (for kio-dev)  libkf5iconthemes-bin{a} (for kio-dev)
  libkf5iconthemes-data{a} (for kio-dev)
  libkf5iconthemes-dev{a} (for kio-dev)
  libkf5iconthemes5{a} (for kio-dev)
  libkf5itemviews-data{a} (for kio-dev)
  libkf5itemviews-dev{a} (for kio-dev)  libkf5itemviews5{ab} (for kio-dev)
  libkf5jobwidgets-data{a} (for kio-dev)
  libkf5jobwidgets-dev{a} (for kio-dev)
  libkf5jobwidgets5{a} (for kio-dev)  libkf5kiocore5{a} (for kio-dev)
  libkf5kiofilewidgets5{ab} (for kio-dev)  libkf5kiontlm5{a} (for kio-dev)
  libkf5kiowidgets5{a} (for kio-dev)
  libkf5notifications-data{a} (for kio-dev)
  libkf5notifications5{a} (for kio-dev)
  libkf5service-bin{a} (for kio-dev)  libkf5service-data{a} (for kio-dev)
  libkf5service-dev{a} (for kio-dev)  libkf5service5{a} (for kio-dev)
  libkf5solid-dev{a} (for kio-dev)  libkf5solid5{a} (for kio-dev)
  libkf5solid5-data{a} (for kio-dev)  libkf5sonnet-dev{a} (for kio-dev)
  libkf5sonnet5-data{a} (for kio-dev)  libkf5sonnetcore5{a} (for kio-dev)
  libkf5sonnetui5{a} (for kio-dev)
  libkf5textwidgets-data{a} (for kio-dev)
  libkf5textwidgets-dev{a} (for kio-dev)
  libkf5textwidgets5{a} (for kio-dev)  libkf5wallet-bin{a} (for kio-dev)
  libkf5wallet-data{a} (for kio-dev)  libkf5wallet5{a} (for kio-dev)
  libkf5widgetsaddons-data{a} (for kio-dev)
  libkf5widgetsaddons-dev{a} (for kio-dev)
  libkf5widgetsaddons5{a} (for kio-dev)
  libkf5windowsystem-data{a} (for kio-dev)
  libkf5windowsystem-dev{a} (for kio-dev)
  libkf5windowsystem5{a} (for kio-dev)  libkf5xmlgui-bin{a} (for kio-dev)
  libkf5xmlgui-data{a} (for kio-dev)  libkf5xmlgui-dev{ab} (for kio-dev)
  libkf5xmlgui5{ab} (for kio-dev)  libkwalletbackend5-5{a} (for kio-dev)
  libphonon4qt5-4{a} (for kio-dev)  libpolkit-qt5-1-1{a} (for kio-dev)
  libqt5svg5{a} (for kio-dev)  sonnet-plugins{a} (for kio-dev)
0 packages upgraded, 89 newly installed, 0 to remove and 0 not upgraded.
Need to get 275 kB/11.8 MB of archives. After unpacking 72.1 MB will be used.
The following packages have unmet dependencies:
 libkf5completion5 : Depends: qtbase-abi-5-3-2 which is a virtual package.
 libkf5xmlgui-dev : Depends: libkf5attica-dev (= 5.9.0~) but it is not going 
to be installed.
 libkf5xmlgui5 : Depends: qtbase-abi-5-3-2 which is a virtual package.
 libkf5itemviews5 : Depends: qtbase-abi-5-3-2 which is a virtual package.
 libkf5kiofilewidgets5 : Depends: qtbase-abi-5-3-2 which is a virtual package.
The following actions will resolve these dependencies:

  Keep the following packages at their current version:
1)  kio [Not Installed]
2)  kio-dev [Not Installed]
3)  libkf5bookmarks-dev [Not Installed]
4)  libkf5bookmarks5 [Not Installed]
5)  libkf5completion-dev [Not Installed]
6)  libkf5completion5 [Not Installed]
7)  libkf5iconthemes-bin [Not Installed]
8)  libkf5iconthemes-dev [Not Installed]
9)  libkf5iconthemes5 [Not Installed]
10) libkf5itemviews-dev [Not Installed]
11) libkf5itemviews5 [Not Installed]
12) libkf5kiofilewidgets5 [Not Installed]
13) libkf5kiowidgets5 [Not Installed]
14) libkf5notifications5 [Not Installed]
15) libkf5textwidgets-dev [Not Installed]
16) libkf5textwidgets5 [Not Installed]
17) libkf5wallet-bin [Not Installed]
18) libkf5wallet5 [Not Installed]
19) 

Bug#785606: linux-image-4.0.0-1-amd64: DragonRise joystick support broken in 4.0.2-1

[Florent Rougon]

retitle 785606 HID support broken for some devices (incl. DragonRise USB 
joystick)
tags 785606 upstream
notfound 785606 3.16.7-ckt9-3
thanks

On Mon, 18 May 2015 11:29:32 +0200 Florent Rougon f.rou...@free.fr wrote:

 The DragonRise joystick used to work fine in linux-image-3.16.0-4-amd64
 version 3.16.7-ckt9-3 and earlier versions, however its support is broken in
 linux-image-4.0.0-1-amd64 version 4.0.2-1. The problem is with the right
 stick:
   - moving it horizontally is reflected on axis 2 (instead of 3 in previous
 versions), but the values are mostly unusable, for instance 0 both in
 the center and leftmost positions;
   - moving it vertically changes axes 2 and 3 at the same time!

 (in previous versions, axis 2 was already bogus, but axes 0, 1 and 3-6 were
 all usable and reflected all possible movements; there is one less axis now
 [0-5], and the movements of the right stick are not reflected properly)

To put this in a simpler way, axis 3 of this joystick is just missing in
recent kernels; and it corresponds to horizontal movement of the right
stick. But I have now found which commit introduced the bug (thanks to
'git bisect'), see below.

 What puzzles me is that 'git diff v3.16..v4.0 drivers/hid/hid-dr.c' (in a
 clone of the upstream linux repo) gives no output. The change must be
 elsewhere?..

Yup, the change causing the bug belongs to drivers/hid/hid-input.c, and
was introduced in commit 79346d620e9de87912de73337f6df8b7f9a46888 of
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git,
aka v3.17-rc1-94-g79346d6, dating from August 2014. Applying the reverse
patch (obtained with 'git show -R v3.17-rc1-94-g79346d6') to the current
linux-image-4.0.0-1-amd64 package in sid (version 4.0.2-1) fixes the
problem for me. Of course, it probably causes a regression for the
people who introduced this change.

So, how do we proceed from here? Should I contact the commit author
myself? TIA

-- 
Florent


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

Bug#788856: joystick: jscal-store and jscal-restore can't find the product name or vendor anymore

[Florent Rougon]

Package: joystick
Version: 1:1.4.8-1
Severity: important

Hello,

I used to be able to use jscal-store and jscal-restore normally a few months
ago (probably with kernel linux-image-3.16.0-4-amd64 version 3.16.7-ckt9-3),
but these programs don't work in a satisfactory way anymore:

# jscal-store /dev/input/js0
No product name or vendor available, calibration will be stored for the
given device name (js0) only!
# tail /var/lib/joystick/joystick.state

NAME=SAITEK CYBORG 3D USB
VENDOR=06a3
PRODUCT=0006
jscal -u 
6,0,1,5,6,16,17,14,288,289,290,291,292,293,294,295,296,297,298,299,300,301
jscal -s 
6,1,0,90,101,9256113,9760991,1,0,87,94,9256113,8947575,1,1,75,93,10956215,8388352,1,1,87,87,7354172,7254791,1,0,0,0,-2147483648,536854528,1,0,0,0,-2147483648,536854528

DEVICE=js0
jscal -u 
6,0,1,5,6,16,17,14,288,289,290,291,292,293,294,295,296,297,298,299,300,301
jscal -s 
6,1,0,112,142,5534751,5534751,1,0,112,142,5534751,5534751,1,0,112,142,5534751,5534751,1,0,112,142,5534751,5534751,1,0,0,0,536870912,536870912,1,0,0,0,536870912,536870912
#

The paragraph starting with NAME=SAITEK CYBORG 3D USB was already there; the
jscal-store call added the last paragraph, identified with DEVICE=js0, which
is not very reliable of course. The corresponding dmesg output is:

[2.262075] usb 8-1.3: new low-speed USB device number 5 using ehci-pci
[2.358626] usb 8-1.3: New USB device found, idVendor=06a3, idProduct=0006
[2.358686] usb 8-1.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[2.358756] usb 8-1.3: Product: CYBORG 3D USB
[2.358804] usb 8-1.3: Manufacturer: SAITEK
[2.364616] input: SAITEK CYBORG 3D USB as 
/devices/pci:00/:00:1a.7/usb8/8-1/8-1.3/8-1.3:1.0/0003:06A3:0006.0002/input/input2
[2.364938] hid-generic 0003:06A3:0006.0002: input,hidraw1: USB HID v1.00 
Joystick [SAITEK CYBORG 3D USB] on usb-:00:1a.7-1.3/input0

As expected, jscal-restore does not restore anything except when
/var/lib/joystick/joystick.state contains a paragraph identified with
DEVICE=js0 or similar, which by chance happens to correspond to the right
joystick (I checked this with 'jscal -p /dev/input/js0').

Thanks

-- Package-specific info:

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device 
'/devices/pci:00/:00:1a.7/usb8/8-1/8-1.3/8-1.3:1.0/0003:06A3:0006.0002/input/input2/js0':
KERNEL==js0
SUBSYSTEM==input
DRIVER==

  looking at parent device 
'/devices/pci:00/:00:1a.7/usb8/8-1/8-1.3/8-1.3:1.0/0003:06A3:0006.0002/input/input2':
KERNELS==input2
SUBSYSTEMS==input
DRIVERS==

  looking at parent device 
'/devices/pci:00/:00:1a.7/usb8/8-1/8-1.3/8-1.3:1.0/0003:06A3:0006.0002':
KERNELS==0003:06A3:0006.0002
SUBSYSTEMS==hid
DRIVERS==hid-generic

  looking at parent device 
'/devices/pci:00/:00:1a.7/usb8/8-1/8-1.3/8-1.3:1.0':
KERNELS==8-1.3:1.0
SUBSYSTEMS==usb
DRIVERS==usbhid

  looking at parent device '/devices/pci:00/:00:1a.7/usb8/8-1/8-1.3':
KERNELS==8-1.3
SUBSYSTEMS==usb
DRIVERS==usb

  looking at parent device '/devices/pci:00/:00:1a.7/usb8/8-1':
KERNELS==8-1
SUBSYSTEMS==usb
DRIVERS==usb

  looking at parent device '/devices/pci:00/:00:1a.7/usb8':
KERNELS==usb8
SUBSYSTEMS==usb
DRIVERS==usb

  looking at parent device '/devices/pci:00/:00:1a.7':
KERNELS==:00:1a.7
SUBSYSTEMS==pci
DRIVERS==ehci-pci

  looking at parent device '/devices/pci:00':
KERNELS==pci:00
SUBSYSTEMS==
DRIVERS==


Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device 
'/devices/pci:00/:00:1a.7/usb8/8-1/8-1.1/8-1.1.3/8-1.1.3:1.0/0003:0079:0006.0005/input/input9/js1':
KERNEL==js1
SUBSYSTEM==input
DRIVER==

  looking at parent device 
'/devices/pci:00/:00:1a.7/usb8/8-1/8-1.1/8-1.1.3/8-1.1.3:1.0/0003:0079:0006.0005/input/input9':
KERNELS==input9
SUBSYSTEMS==input
DRIVERS==

  looking at parent device 
'/devices/pci:00/:00:1a.7/usb8/8-1/8-1.1/8-1.1.3/8-1.1.3:1.0/0003:0079:0006.0005':
KERNELS==0003:0079:0006.0005
SUBSYSTEMS==hid
DRIVERS==dragonrise

  looking at parent device 
'/devices/pci:00/:00:1a.7/usb8/8-1/8-1.1/8-1.1.3/8-1.1.3:1.0':
KERNELS==8-1.1.3:1.0
SUBSYSTEMS==usb
DRIVERS==usbhid

  looking at parent device 
'/devices/pci:00/:00:1a.7/usb8/8-1/8-1.1/8-1.1.3':
KERNELS==8-1.1.3
SUBSYSTEMS==usb

Bug#787464: libplib1: jsJoystick::open() breaks system calibration on Linux

[Florent Rougon]

Package: libplib1
Version: 1.8.5-7
Severity: important
Tags: upstream

[ Duplicating a bug I reported upstream, in the hope it could be fixed in
  Debian at least, as the upstream project appears to be dead unfortunately ]

[ FlightGear maintainers in Cc, as proper joystick calibration is likely to be
  important for many users of this simulator; in particular since this problem
  causes FlightGear (as well as most, if not all programs using libplibjs) to
  *break* joystick calibration performed with jscal or jscal-restore ]

Opening a joystick with plib on Linux breaks the in-kernel user settings for
that joystick (as set by jscal(1)). More specifically, the lower and upper
bounds of the dead band managed by the Linux joystick driver are both
overwritten by jsJoystick::open() with their arithmetic mean (after integer
truncation), effectively killing the dead band carefully configured by the
user. This has bitten a few users, for instance
http://forum.flightgear.org/viewtopic.php?f=24t=26084.

To reproduce the problem, you can do:

  jscal -s joystick calibration settings with dead band(s) /dev/input/js0
  # (or 'jscal-restore /dev/input/js0')

  # Should print the same 'jscal -s ...' command line (current settings)
  jscal -p /dev/input/js0

  [run a program that opens /dev/input/js0 with plib, for instance
   js_demo from the plib examples, or FlightGear]

  # Print the new joystick settings, with the two parameters specifying
  # the lower and upper bounds of the kernel driver dead band overwritten
  # by the plib-using program
  jscal -p /dev/input/js0

The modification of kernel driver settings happens in lines 84-94 of
src/js/jsLinux.cxx and was introduced in revision 1982 of the Subversion repo
after https://sourceforge.net/p/plib/mailman/message/13379198/. IMHO, these
lines should be simply removed, as done in the proposed patch:

  - this is not useful (if the user wants no dead band managed by the kernel
joystick driver, jscal(1) is the right tool for the job);

  - this breaks the joystick configuration for *all applications* that respect
the system calibration instead of blindly overwriting it!

  - this is not in the spirit of the plib documentation
(http://plib.sourceforge.net/js/, JS is essentially just a wrapper to
make the various underlying OS mechanisms look the same to application
code);

  - this is not consistent with the implementation for other platforms (I
looked at the Windows and MacOS X code, none of which seems to alter the
system settings).

The person who introduced this change (yup, in 2004) argued that:

“At least my thrustmaster topgun joystick/thrust combo works much better
with this patch. Without, the kernel driver introduces an unrecoverable
deadband plateau in the area of 50% thrust, which is pretty senseless to
have on the thrust axis. Even on the other axis I prefer to have exactly
one deadband parameter. Since plib has it's own ones, only take those
ones.”

If that person is bothered by the in-kernel dead band management, the correct
solution is to use jscal(1) to remove that dead band, not to break all users
settings. This is done by giving the same value to the two constants setting
the lower and upper bounds of the dead band. For instance, the following
command:

  jscal -s 
6,1,0,90,100,9256113,9760991,1,0,87,94,9256113,8947575,1,1,75,93,10956215,8388352,1,1,87,87,7354172,7254791,1,0,0,0,-2147483648,536854528,1,0,0,0,-2147483648,536854528
 /dev/input/js0

defines the calibration settings for a joystick with 6 axes. The part
corresponding to the first axis is 1,0,90,100,9256113,9760991. In this part,
90 and 100 define a dead band of width 10 (in the units sent by the hardware).
Setting both to, for instance 95, will effectively remove this dead band while
keeping the same center. The last two coefficients must be adapted
accordingly; I can explain that, but I don't think this bug report is the
right place for such an explanation.

Correctly calibrating an analog joystick takes some time. For users' sanity,
applications must allow them to do that *once*, in a place that is used by all
applications. If each application requires its own calibration, that is very
annoying and time-consuming for users. And it is even worse if some
applications arbitrarily overwrite the system settings...

I will attach a patch suitable for a QA upload, IMHO, once I have the bug
number.

Regards

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

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

Versions of packages libplib1 depends on:
ii  freeglut3 2.8.1-2
ii  libc6 2.19-18
ii  libgcc1   1:5.1.1-8
ii  libgl1-mesa-glx 

Bug#787464: Acknowledgement (libplib1: jsJoystick::open() breaks system calibration on Linux)

[Florent Rougon]

forwarded 787464 https://sourceforge.net/p/plib/bugs/47/
tags 787464 + patch
thanks

Attaching a patch for a QA upload in case someone wants to sponsor it.
TIA

-- 
Florent
diff -u plib-1.8.5/debian/changelog plib-1.8.5/debian/changelog
--- plib-1.8.5/debian/changelog
+++ plib-1.8.5/debian/changelog
@@ -1,3 +1,15 @@
+plib (1.8.5-8) unstable; urgency=medium
+
+  * QA upload.
+  * Add patch 06_dont_break_joystick_system_calibration.diff
+(Closes: #787464):
+
+  Don't break system calibration settings when a joystick is opened
+  (plib may do additional dead-band management on top of the OS joystick
+  driver, it should not break system settings for that reason!)
+
+ -- Florent Rougon f.rou...@free.fr  Mon, 01 Jun 2015 21:34:52 +0200
+
 plib (1.8.5-7) unstable; urgency=medium
 
   * Enable hardened build flags
@@ -484,3 +496 @@
-Local variables:
-mode: debian-changelog
-End:
+
diff -u plib-1.8.5/debian/patches/series plib-1.8.5/debian/patches/series
--- plib-1.8.5/debian/patches/series
+++ plib-1.8.5/debian/patches/series
@@ -6,0 +7 @@
+06_dont_break_joystick_system_calibration.diff
only in patch2:
unchanged:
--- plib-1.8.5.orig/debian/patches/06_dont_break_joystick_system_calibration.diff
+++ plib-1.8.5/debian/patches/06_dont_break_joystick_system_calibration.diff
@@ -0,0 +1,31 @@
+Description: Don't break system calibration settings when a joystick is opened
+ plib may do additional dead-band management on top of the OS joystick driver,
+ it should not break system settings for that reason!
+Author: Florent Rougon f.rou...@free.fr
+Bug: https://sourceforge.net/p/plib/bugs/47/
+Bug-Debian: http://bugs.debian.org/787464
+Last-Update: 2015-06-01
+
+--- a/src/js/jsLinux.cxx
 b/src/js/jsLinux.cxx
+@@ -79,20 +79,6 @@
+   if ( num_axes  _JS_MAX_AXES )
+ num_axes = _JS_MAX_AXES ;
+ 
+-  // Remove any deadband value already done in the kernel.
+-  // Since we have our own deadband management this is save to do so.
+-  struct js_corr* corr = new js_corr[ all_axes ] ;
+-  ioctl ( os-fd, JSIOCGCORR, corr );
+-  for ( int i = 0; i  num_axes ; ++i ) {
+-if ( corr[ i ] . type == JS_CORR_BROKEN ) {
+-  int nodeadband = ( corr[ i ] . coef[ 0 ] + corr[ i ] . coef[ 1 ] ) / 2 ;
+-  corr[ i ] . coef[ 0 ] = nodeadband ;
+-  corr[ i ] . coef[ 1 ] = nodeadband ;
+-}
+-  }
+-  ioctl ( os-fd, JSIOCSCORR, corr );
+-  delete [] corr;
+-
+   for ( int i = 0 ; i  _JS_MAX_AXES ; i++ )
+   {
+ max   [ i ] = 32767.0f ;

Bug#785606: linux-image-4.0.0-1-amd64: DragonRise joystick support broken in 4.0.2-1

[Florent Rougon]

Package: src:linux
Version: 4.0.2-1
Severity: normal

Hello,

The DragonRise joystick used to work fine in linux-image-3.16.0-4-amd64
version 3.16.7-ckt9-3 and earlier versions, however its support is broken in
linux-image-4.0.0-1-amd64 version 4.0.2-1. The problem is with the right
stick:
  - moving it horizontally is reflected on axis 2 (instead of 3 in previous
versions), but the values are mostly unusable, for instance 0 both in
the center and leftmost positions;
  - moving it vertically changes axes 2 and 3 at the same time!

(in previous versions, axis 2 was already bogus, but axes 0, 1 and 3-6 were
all usable and reflected all possible movements; there is one less axis now
[0-5], and the movements of the right stick are not reflected properly)

I am attaching a few files obtained with 'jstest /dev/input/js0' while moving
the right stick only to illustrate the problem. I have tested with two joypads
of the same model and switched several times between kernels 3.16 and 4.0, so
I am pretty sure the problem is not due to faulty/damaged hardware.

What puzzles me is that 'git diff v3.16..v4.0 drivers/hid/hid-dr.c' (in a
clone of the upstream linux repo) gives no output. The change must be
elsewhere?..

Notes:
  - all tests with jstest have been performed with joystick calibration
deactivated (/var/lib/joystick/joystick.state moved away) and with the
joypad in analog mode (central button associated with a LED pressed once
after plugging the joypad in);
  - the file DragonRise.messages gives dmesg and lsusb outputs with both
kernels 3.16 and 4.0, and shows jscal-restore complaining on kernel 4.0
because of the joypad showing one less axis than in previous versions.
  - as for the other files, if you don't want to read them all,
DragonRise.bug_jstest-center-to-left-with-Linux-4.0 and
DragonRise.bug_jstest-center-to-down-then-up-then-center-with-Linux-4.0
should be enough to understand the bug.

Thanks for your attention.

-- Package-specific info:
** Version:
Linux version 4.0.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 
(Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.0.0-1-amd64 root=UUID=... ro init=/bin/systemd 
ipv6.disable=1

** Not tainted

** Kernel log:
[   10.405848] [drm] ib test on ring 0 succeeded in 0 usecs
[   10.405920] [drm] ib test on ring 3 succeeded in 0 usecs
[   10.411961] tda829x 1-004b: setting tuner address to 61
[   10.632179] tda829x 1-004b: type set to tda8290+75a
[   11.052489] [drm] ib test on ring 5 succeeded
[   11.053111] [drm] Radeon Display Connectors
[   11.053154] [drm] Connector 0:
[   11.053194] [drm]   VGA-1
[   11.053234] [drm]   DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 
0x7e2c
[   11.053292] [drm]   Encoders:
[   11.053331] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[   11.053372] [drm] Connector 1:
[   11.053411] [drm]   HDMI-A-1
[   11.053450] [drm]   HPD2
[   11.053489] [drm]   DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c 
0x7f1c
[   11.053545] [drm]   Encoders:
[   11.053584] [drm] DFP2: INTERNAL_UNIPHY1
[   11.053624] [drm] Connector 2:
[   11.053664] [drm]   DVI-I-1
[   11.053702] [drm]   HPD1
[   11.053740] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 
0x7e4c
[   11.053797] [drm]   Encoders:
[   11.053839] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[   11.053880] [drm] DFP1: INTERNAL_UNIPHY
[   11.100099] [drm] fb mappable at 0xE045F000
[   11.100151] [drm] vram apper at 0xE000
[   11.100200] [drm] size 8294400
[   11.100247] [drm] fb depth is 24
[   11.100293] [drm]pitch is 7680
[   11.100616] fbcon: radeondrmfb (fb0) is primary device
[   11.111454] Console: switching to colour frame buffer device 240x67
[   11.113774] EXT4-fs (md1): mounted filesystem with ordered data mode. Opts: 
(null)
[   11.115122] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[   11.115123] radeon :01:00.0: registered panic notifier
[   11.135659] [drm] Initialized radeon 2.41.0 20080528 for :01:00.0 on 
minor 0
[   11.278051] EXT4-fs (sdb9): mounted filesystem with ordered data mode. Opts: 
(null)
[   11.441636] EXT4-fs (md4): mounted filesystem with ordered data mode. Opts: 
(null)
[   11.524908] EXT4-fs (sdb11): mounted filesystem with ordered data mode. 
Opts: (null)
[   11.580812] floppy0: no floppy controllers found
[   11.588078] EXT4-fs (md3): mounted filesystem with ordered data mode. Opts: 
(null)
[   11.875554] EXT4-fs (sdb8): mounted filesystem with ordered data mode. Opts: 
(null)
[   11.949068] snd_hda_intel :00:1b.0: azx_get_response timeout, switching 
to polling mode: last cmd=0x300f
[   12.466379] systemd-journald[342]: Received request to flush runtime journal 
from PID 1
[   12.957871] snd_hda_intel :00:1b.0: No response from codec, disabling 
MSI: last cmd=0x300f
[   13.966647] snd_hda_intel :00:1b.0: Codec #3 probe error; disabling it...
[   13.996429] sound hdaudioC1D2: 

Bug#780716: [pkg-fgfs-crew] Bug#780716: flightgear-data: nasal scripts can ready any file

[Florent Rougon]

Hi again,

As far as I know, this bug is still present in 3.4.0+dfsg-0~exp1 (from
experimental). The fix you applied to unstable (commit
d8603af7f98a6394442818d823a79b680b1f9e8b) can be cherry-picked to
experimental with minor conflicts (d/changelog and d/patches/series). It
seems to work fine here. What do you think?

Regards

-- 
Florent


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

Bug#775903: systemd: 'service initscript start' starts initscript.dpkg-dist under systemd

[Florent Rougon]

Hi Martin, hi Michael,

Martin Pitt mp...@debian.org wrote:

 I'm 99% sure that this is another duplicate of https://bugs.debian.org/775404

 I take it you have a /run/systemd/generator.late/fetchmail.service
 symlink which points to fetchmail.dpkg-dist.service?

Well, I have this file but it is a regular file starting with:

# Automatically generated by systemd-sysv-generator

[Unit]
SourcePath=/etc/init.d/fetchmail
Description=LSB: init script for per-user fetchmail daemons
Before=runlevel2.target runlevel3.target runlevel4.target runlevel5.target 
shutdown.target
After=network-online.target mail-transport-agent.service local-fs.target 
remote-fs.target local-rotate-fetchmail-logfiles.service
Wants=network-online.target
Conflicts=shutdown.target

This shows that it was generated from my own fetchmail script, not from
fetchmail.dpkg-dist. But as explained in my previous message, I fixed my
system by running 'systemctl daemon-reload'. Maybe it had the symlink
you mentioned when the bug was triggered, I can't say for sure now.

 I'm going to upload 215-10 with the fix for this in a few hours; it
 would be nice if you could report back with either confirming that it
 fixes the issue, or is something else (then I'll unduplicate this bug
 report).

I can test things if you want, but I have no idea of systemd things such
as automatic unit creation from init scripts, therefore I am not sure I
can restore the conditions in which I encountered the bug (I suspect
just recreating the .dpkg-dist file won't be enough). However, if you
give me precise instructions, I can try to reproduce the bug and see if
your new package fixes it.

Thank you!

-- 
Florent


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

Bug#775903: systemd: 'service initscript start' starts initscript.dpkg-dist under systemd

[Florent Rougon]

Package: systemd
Version: 215-9
Severity: serious
Tags: security

Dear maintainer,

I tried systemd after a wheezy → sid upgrade and encountered an annoying
problem: after modifying a file related to my /etc/init.d/fetchmail script[1],
I decided to start the fetchmail service with 'service fetchmail start'[2]. To
my great surprise, this did not start my /etc/init.d/fetchmail script but
/etc/init.d/fetchmail.dpkg-dist, i.e., the script I had explicitely told dpkg
to disable when doing the wheezy to sid upgrade.

  [1] Apparently run with 'set -e' under systemd, but that is another issue.

  [2] Being new to systemd, I didn't know the systemd idiom for this, but my
  reading of /usr/sbin/service leads me to think that 'systemctl start
  fetchmail.service' would have done exactly the same, hence the report to
  systemd as opposed to sysvinit-utils.

Apparently, systemd somehow kept thinking that the fetchmail service
corresponded to that .dpkg-dist script until I ran 'systemctl daemon-reload'.
This behavior has the adverse effect of running a service the administrator
explicitely disabled, or of running it with completely different options from
those he configured, etc. This is why I set the security tag on this bug.
Maybe the severity should be raised too.

Here is a transcript of the commands I ran to trigger and work around the bug:

# service fetchmail start
# systemctl status -l fetchmail
● fetchmail.dpkg-dist.service - LSB: init-Script for system wide fetchmail 
daemon
   Loaded: loaded (/etc/init.d/fetchmail.dpkg-dist)
   Active: active (exited) since Mon 2015-01-19 10:26:35 CET; 51min ago

Jan 19 10:26:35 zita fetchmail.dpkg-dist[3090]: Not starting fetchmail daemon, 
disabled via /etc/default/fetchmail.
Jan 19 10:26:35 zita systemd[1]: Started LSB: init-Script for system wide 
fetchmail daemon.
# find /etc/rc*.d /etc/init.d |grep fetchmail
/etc/rc0.d/K01fetchmail
/etc/rc1.d/K01fetchmail
/etc/rc2.d/S01local-rotate-fetchmail-logfiles
/etc/rc2.d/S04fetchmail
/etc/rc3.d/S01local-rotate-fetchmail-logfiles
/etc/rc3.d/S04fetchmail
/etc/rc4.d/S01local-rotate-fetchmail-logfiles
/etc/rc4.d/S04fetchmail
/etc/rc5.d/S01local-rotate-fetchmail-logfiles
/etc/rc5.d/S04fetchmail
/etc/rc6.d/K01fetchmail
/etc/init.d/fetchmail.dpkg-dist
/etc/init.d/fetchmail
/etc/init.d/local-rotate-fetchmail-logfiles
# mv fetchmail.dpkg-dist /root/tmp
# service fetchmail start
Warning: Unit file of fetchmail.service changed on disk, 'systemctl 
daemon-reload' recommended.
Job for fetchmail.dpkg-dist.service failed. See 'systemctl status 
fetchmail.dpkg-dist.service' and 'journalctl -xn' for details.
# systemctl status -l fetchmail
● fetchmail.dpkg-dist.service - LSB: init-Script for system wide fetchmail 
daemon
   Loaded: loaded (/etc/init.d/fetchmail.dpkg-dist)
   Active: failed (Result: exit-code) since Mon 2015-01-19 11:25:15 CET; 36s ago
  Process: 13937 ExecStart=/etc/init.d/fetchmail.dpkg-dist start (code=exited, 
status=203/EXEC)

Jan 19 11:25:15 zita systemd[1]: fetchmail.dpkg-dist.service: control process 
exited, code=exited status=203
Jan 19 11:25:15 zita systemd[1]: Failed to start LSB: init-Script for system 
wide fetchmail daemon.
Jan 19 11:25:15 zita systemd[1]: Unit fetchmail.dpkg-dist.service entered 
failed state.

Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.
# systemctl daemon-reload
# service fetchmail start
# systemctl status -l fetchmail
● fetchmail.service - LSB: init script for per-user fetchmail daemons
   Loaded: loaded (/etc/init.d/fetchmail)
   Active: active (exited) since Mon 2015-01-19 11:26:28 CET; 6s ago
  Process: 13983 ExecStart=/etc/init.d/fetchmail start (code=exited, 
status=0/SUCCESS)

Jan 19 11:26:27 zita fetchmail[13983]: Starting mail retrieval agent: fetchmail.
Jan 19 11:26:28 zita fetchmail[13983]: Waiting for a Mail Transport Agent 
lising on the SMTP port...done.
Jan 19 11:26:28 zita su[13992]: Successful su for flo by root
Jan 19 11:26:28 zita su[13992]: + ??? root:flo
Jan 19 11:26:28 zita su[13992]: pam_unix(su:session): session opened for usero 
by (uid=0)
Jan 19 11:26:28 zita fetchmail[13983]: Starting fetchmail for user flo...done
Jan 19 11:26:28 zita systemd[1]: Started LSB: init script for per-user fetchm 
daemons.
#

Thanks for considering, have a nice day. :-)

(the 'Init: sysvinit (via /sbin/init)' bit below is misleading, I am running
systemd via the 'init' kernel command line parameter)


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-58
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-4.1

Bug#750601: GnuTLS: Error in the push function when using a client certificate

[Florent Rougon]

Package: wget
Version: 1.13.4-3+deb7u1
Severity: normal

Hello,

It seems unfortunately that bug #646983 is back in wheezy, or something that
looks similar:

% wget --certificate=*.pem --private-key=*** -rc -nH -np -vvv \
  --ca-cert=*** https://server-name:port/path
--2014-06-03 23:09:39--  https://server-name:port/path
Resolving server-name (server-name)... server-ip
Connecting to server-name (server-name)|server-ip|:port... connected.
GnuTLS: Error in the push function.
Unable to establish SSL connection.

The same thing works fine in Firefox as well as with curl (using options
--cert and --key).

Thanks

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

Kernel: Linux 3.13-0.bpo.1-amd64 (SMP w/8 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 wget depends on:
ii  dpkg   1.16.14
ii  install-info   4.13a.dfsg.1-10
ii  libc6  2.13-38+deb7u1
ii  libgcrypt111.5.0-5+deb7u1
ii  libgnutls262.12.20-8+deb7u2
ii  libgpg-error0  1.10-3.1
ii  libidn11   1.25-2
ii  zlib1g 1:1.2.7.dfsg-13

wget recommends no packages.

wget suggests no packages.

-- no debconf information


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

Bug#746475: flightgear: crash with Nasal bindings

[Florent Rougon]

Package: flightgear
Version: 3.0.0-1
Severity: normal
Tags: fixed-upstream

Origin: upstream, https://gitorious.org/fg/flightgear/commit/b3c7cb7c151858ef79f9371a29be49915e5d3803
Bug: https://code.google.com/p/flightgear-bugs/issues/detail?id=1397
Author: Nicholas Scheel
Date: Tue Apr 15 14:13:46 2014 +0100
Description: Fix crash with Nasal bindings.
 naBindFunction doesn't save the function code to the global
 hash, so pass an explicit context to various 'call' overloads so
 the function can't be GC-ed in between parsing and calling.

--- a/src/Scripting/NasalSys.cxx
+++ b/src/Scripting/NasalSys.cxx
@@ -235,6 +235,11 @@
   return callMethod(code, naNil(), argc, args, locals);
 }
 
+naRef FGNasalSys::callWithContext(naContext ctx, naRef code, int argc, naRef* args, naRef locals)
+{
+  return callMethodWithContext(ctx, code, naNil(), argc, args, locals);
+}
+
 // Does a naCall() in a new context.  Wrapped here to make lock
 // tracking easier.  Extension functions are called with the lock, but
 // we have to release it before making a new naCall().  So rather than
@@ -247,6 +252,11 @@
   return naCallMethod(code, self, argc, args, locals);
 }
 
+naRef FGNasalSys::callMethodWithContext(naContext ctx, naRef code, naRef self, int argc, naRef* args, naRef locals)
+{
+  return naCallMethodCtx(ctx, code, self, argc, args, locals);
+}
+
 FGNasalSys::~FGNasalSys()
 {
 nasalSys = 0;
@@ -254,11 +264,15 @@
 
 bool FGNasalSys::parseAndRun(const char* sourceCode)
 {
-naRef code = parse(FGNasalSys::parseAndRun(), sourceCode,
+naContext ctx = naNewContext();
+naRef code = parse(ctx, FGNasalSys::parseAndRun(), sourceCode,
strlen(sourceCode));
-if(naIsNil(code))
+if(naIsNil(code)) {
+naFreeContext(ctx);
 return false;
-call(code, 0, 0, naNil());
+}
+callWithContext(ctx, code, 0, 0, naNil());
+naFreeContext(ctx);
 return true;
 }
 
@@ -1067,11 +1081,13 @@
   const SGPropertyNode* cmdarg,
   int argc, naRef* args)
 {
-naRef code = parse(fileName, src, len);
-if(naIsNil(code))
+naContext ctx = naNewContext();
+naRef code = parse(ctx, fileName, src, len);
+if(naIsNil(code)) {
+naFreeContext(ctx);
 return false;
+}
 
-naContext ctx = naNewContext();
 
 // See if we already have a module hash to use.  This allows the
 // user to, for example, add functions to the built-in math
@@ -1084,7 +1100,7 @@
 
 _cmdArg = (SGPropertyNode*)cmdarg;
 
-call(code, argc, args, locals);
+callWithContext(ctx, code, argc, args, locals);
 hashset(_globals, moduleName, locals);
 
 naFreeContext(ctx);
@@ -1100,10 +1116,9 @@
 naFreeContext(ctx);
 }
 
-naRef FGNasalSys::parse(const char* filename, const char* buf, int len)
+naRef FGNasalSys::parse(naContext ctx, const char* filename, const char* buf, int len)
 {
 int errLine = -1;
-naContext ctx = naNewContext();
 naRef srcfile = naNewString(ctx);
 naStr_fromdata(srcfile, (char*)filename, strlen(filename));
 naRef code = naParseCode(ctx, srcfile, 1, (char*)buf, len, errLine);
@@ -,14 +1126,11 @@
 SG_LOG(SG_NASAL, SG_ALERT,
Nasal parse error:   naGetError(ctx) 
 in  filename , line   errLine);
-naFreeContext(ctx);
 return naNil();
 }
 
 // Bind to the global namespace before returning
-naRef bound = naBindFunction(ctx, code, _globals);
-naFreeContext(ctx);
-return bound;
+return naBindFunction(ctx, code, _globals);
 }
 
 bool FGNasalSys::handleCommand( const char* moduleName,
@@ -1126,22 +1138,24 @@
 const char* src,
 const SGPropertyNode* arg )
 {
-naRef code = parse(fileName, src, strlen(src));
-if(naIsNil(code)) return false;
+naContext ctx = naNewContext();
+naRef code = parse(ctx, fileName, src, strlen(src));
+if(naIsNil(code)) {
+naFreeContext(ctx);
+return false;
+}
 
 // Commands can be run in a module.  Make sure that module
 // exists, and set it up as the local variables hash for the
 // command.
 naRef locals = naNil();
 if(moduleName[0]) {
-naContext ctx = naNewContext();
 naRef modname = naNewString(ctx);
 naStr_fromdata(modname, (char*)moduleName, strlen(moduleName));
 if(!naHash_get(_globals, modname, locals)) {
 locals = naNewHash(ctx);
 naHash_set(_globals, modname, locals);
 }
-naFreeContext(ctx);
 }
 
 // Cache this command's argument for inspection via cmdarg().  For
@@ -1149,7 +1163,8 @@
 // code doesn't need it.
 _cmdArg = (SGPropertyNode*)arg;
 
-call(code, 0, 0, locals);
+callWithContext(ctx, code, 0, 0, locals);
+naFreeContext(ctx);
 return true;
 }
 
--- a/src/Scripting/NasalSys.hxx
+++ b/src/Scripting/NasalSys.hxx
@@ -102,8 +102,10 

Bug#746475: flightgear: crash with Nasal bindings

[Florent Rougon]

Hello,

Sorry, I hit the wrong key in the draft folder, before writing the body
of the e-mail!

So, I encountered a crash with FlightGear 3.0.0-1 and the backtrace led
me to upstream bug
https://code.google.com/p/flightgear-bugs/issues/detail?id=1397

That address indicates that the bug has been fixed in upstream Git. I
have extracted the corresponding patch
(https://gitorious.org/fg/flightgear/commit/b3c7cb7c151858ef79f9371a29be49915e5d3803)
and applied it to the Debian package with very slight modification
because one of the context lines has changed between 3.0.0 and the
commit mentioned here. I have tested the resulting package for some time
and it seems to fix the bug.

(I didn't tag the bug with patch because I can't pretend I understand
the patch)

Thanks for your work.

-- 
Florent


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

Bug#741411: fgo: invalid or outdated format for machine-readable debian/copyright

[Florent Rougon]

By the way, the copyright file has a Maintainer field set to:

  Debian FlightGear Crew pkg-fgfs-c...@lists.alioth.debian.org

which seems to be in contradiction with debian/control. The patch I
posted renamed the field to Debian-Maintainer to make lintian (IIRC)
happy, but given the contents of debian/control, I suppose it would be
better to just remove the line from debian/copyright.

-- 
Florent


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

Bug#741410: fgo: new upstream version available

[Florent Rougon]

Package: fgo
Version: 1.3.1-2
Severity: wishlist

Hello,

There have been a few fgo releases in the last years... At the time
of this writing, upstream is at 1.5.0. Will attach a patch once I get the bug
number.

Thanks.

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

Kernel: Linux 3.11-0.bpo.2-amd64 (SMP w/8 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 fgo depends on:
ii  python 2.7.3-4+deb7u1
ii  python-imaging 1.1.7-4
ii  python-imaging-tk  1.1.7-4
ii  python-tk  2.7.3-1
ii  tcl8.5 8.5.11-2
ii  tk8.5  8.5.11-2

Versions of packages fgo recommends:
ii  flightgear  3.0.0-1~frougon+deb7.0

fgo suggests no packages.

-- no debconf information


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

Bug#741411: fgo: invalid or outdated format for machine-readable debian/copyright

[Florent Rougon]

Package: fgo
Version: 1.3.1-2
Severity: normal

Hello,

When building fgo, lintian complains:

W: fgo source: syntax-error-in-dep5-copyright line 18: Continuation line
outside a paragraph.

The patch in #741410 addresses this problem.

-- 
Florent


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

Bug#741410: fgo: new upstream version available

[Florent Rougon]

tags 670966 + patch
tags 741410 + patch
tags 741411 + patch
thanks

Attaching a patch against the debian directory of version 1.3.1-2.

-- 
Florent
diff -ur fgo-1.3.1/debian/changelog fgo-1.5.0.for_debian/debian/changelog
--- fgo-1.3.1/debian/changelog	2011-08-06 15:03:31.0 +0200
+++ fgo-1.5.0.for_debian/debian/changelog	2014-03-12 11:57:33.597893568 +0100
@@ -1,3 +1,24 @@
+fgo (1.5.0-1) unstable; urgency=low
+
+  * New upstream release (closes: #741410).
+  * Update fgo-config.patch (most notably using the correct paths for
+--fg-root and --fg-scenery). Closes: #670966.
+  * Install the 'data' directory under /usr/share/games/fgo.
+  * debian/copyright: update to comply with
+http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+(closes: #741411).
+  * debian/fgo.desktop:
+  - update the Version field to indicate the version of the Desktop
+Entry Specification, not FGo!;
+  - make the icon reference more robust (no path and no extension);
+  - fix a typo.
+  * debian/links:
+  - use the correct icon path (under the 'data' subdirectory of
+/usr/share/games/fgo and choosing the icon with best quality);
+  - remove the leading slashes.
+
+ -- Florent Rougon f.rou...@free.fr  Wed, 12 Mar 2014 11:57:33 +0100
+
 fgo (1.3.1-2) unstable; urgency=low
 
   * Fixed lintian info warning about encoding in .desktop file
diff -ur fgo-1.3.1/debian/copyright fgo-1.5.0.for_debian/debian/copyright
--- fgo-1.3.1/debian/copyright	2011-08-05 17:09:15.0 +0200
+++ fgo-1.5.0.for_debian/debian/copyright	2014-03-12 00:36:58.007589920 +0100
@@ -1,28 +1,27 @@
-Format-Specification: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=174
-Name: FGo
-Maintainer: Debian FlightGear Crew pkg-fgfs-c...@lists.alioth.debian.org
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: FGo!
 Source: http://sites.google.com/site/erobosprojects/flightgear/add-ons/fgo
+Debian-Maintainer: Debian FlightGear Crew pkg-fgfs-c...@lists.alioth.debian.org
 
-Copyright: 2011, Robert Leda er...@wp.pl
-
-License: WTFPL
+Files: *
+Copyright: 2009-2014 Robert 'erobo' Leda er...@wp.pl
+License: WTFPL-2
 
 Files: debian/*
-Copyright: 2011, Christopher Baines cbain...@gmail.com
-License: WTFPL
-
-License: WTFPL
-   DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
-   Version 2, December 2004
-
-   Copyright (C) 2004 Sam Hocevar s...@hocevar.net
-
-Everyone is permitted to copy and distribute verbatim or modified
-copies of this license document, and changing it is allowed as long
-as the name is changed.
-   
-   DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
-  TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-   
- 0. You just DO WHAT THE FUCK YOU WANT TO.
+Copyright: 2011 Christopher Baines cbain...@gmail.com
+License: WTFPL-2
 
+License: WTFPL-2
+DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
+Version 2, December 2004
+ .
+ Copyright (C) 2004 Sam Hocevar s...@hocevar.net
+ .
+ Everyone is permitted to copy and distribute verbatim or modified
+ copies of this license document, and changing it is allowed as long
+ as the name is changed.
+ .
+DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+ .
+  0. You just DO WHAT THE FUCK YOU WANT TO.
diff -ur fgo-1.3.1/debian/fgo.desktop fgo-1.5.0.for_debian/debian/fgo.desktop
--- fgo-1.3.1/debian/fgo.desktop	2011-08-06 14:56:01.0 +0200
+++ fgo-1.5.0.for_debian/debian/fgo.desktop	2014-03-12 00:36:58.035589921 +0100
@@ -1,12 +1,10 @@
-
 [Desktop Entry]
+Version=1.0
 Type=Application
-Version=1.4
 Name=FGo!
 Name[en_GB]=FGo!
 Exec=fgo
 Terminal=false
 Categories=Game;Simulation;
-Comment=Graphical launcher for the FlightGear Filght Simulator
-Icon=/usr/share/pixmaps/fgo.png
-
+Comment=Graphical launcher for the FlightGear Flight Simulator
+Icon=fgo
diff -ur fgo-1.3.1/debian/install fgo-1.5.0.for_debian/debian/install
--- fgo-1.3.1/debian/install	2011-08-05 18:20:39.0 +0200
+++ fgo-1.5.0.for_debian/debian/install	2014-03-12 00:36:58.019589921 +0100
@@ -1,4 +1,5 @@
 src/ /usr/share/games/fgo/
+data/ /usr/share/games/fgo/
 fgo /usr/share/games/fgo/
 debian/fgo.desktop /usr/share/applications
 
diff -ur fgo-1.3.1/debian/links fgo-1.5.0.for_debian/debian/links
--- fgo-1.3.1/debian/links	2011-08-05 18:29:19.0 +0200
+++ fgo-1.5.0.for_debian/debian/links	2014-03-12 00:36:58.031589921 +0100
@@ -1,2 +1,2 @@
-/usr/share/games/fgo/fgo /usr/games/fgo
-/usr/share/games/fgo/src/pics/icon.png /usr/share/pixmaps/fgo.png
+usr/share/games/fgo/fgo usr/games/fgo
+usr/share/games/fgo/data/pics/icons/256x256/fgo.png usr/share/pixmaps/fgo.png
diff -ur fgo-1.3.1/debian/patches/fgo-config.patch fgo-1.5.0.for_debian/debian/patches/fgo-config.patch
--- fgo-1.3.1/debian/patches/fgo-config.patch	2010-09-01 18:20

Bug#670966: fgo: Default paths for FG_ROOT and FG_SCENERY are incorrect

[Florent Rougon]

Hello,

This is addressed in the proposed patch for bug #741410.

-- 
Florent


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

Bug#737870: fgo: menu icon entry missing

[Florent Rougon]

tags 737870 patch
thanks

Hello,

Here is a patch for this bug. Just pay attention to the patch of
debian/changelog (created from a private version of the package) and
maybe mention there that imagemagick was added to Build-Depends in order
to create the 32x32 XPM required according to
https://wiki.debian.org/Games/JessieReleaseGoal.

Regards

-- 
Florent
diff -ur a/changelog b/changelog
--- a/changelog	2014-03-11 01:04:57.0 +0100
+++ b/changelog	2014-03-12 16:22:28.0 +0100
@@ -1,3 +1,10 @@
+fgo (1.5.0-1~frougon2+deb7.0) stable; urgency=low
+
+  * Create a 32x32 version of the icon in XPM format, install it in
+/usr/share/pixmaps and declare it in debian/menu (closes: #737870).
+
+ -- Florent Rougon f.rou...@free.fr  Wed, 12 Mar 2014 16:22:28 +0100
+
 fgo (1.5.0-1~frougon1+deb7.0) stable; urgency=low
 
   * Improve debian/patches/increase-font-sizes.patch: all font
diff -ur a/control b/control
--- a/control	2011-08-05 18:21:03.0 +0200
+++ b/control	2014-03-12 10:56:29.0 +0100
@@ -2,7 +2,7 @@
 Section: games
 Priority: extra
 Maintainer: Christopher Baines cbain...@gmail.com
-Build-Depends: debhelper (= 8.9.3), python (= 2.6.6-3~)
+Build-Depends: debhelper (= 8.9.3), python (= 2.6.6-3~), imagemagick
 Standards-Version: 3.9.2
 Homepage: http://sites.google.com/site/erobosprojects/flightgear/add-ons/fgo
 
diff -ur a/install b/install
--- a/install	2014-03-07 14:01:45.0 +0100
+++ b/install	2014-03-12 15:57:24.0 +0100
@@ -2,4 +2,4 @@
 data/ /usr/share/games/fgo/
 fgo /usr/share/games/fgo/
 debian/fgo.desktop /usr/share/applications
-
+debian/fgo.xpm /usr/share/pixmaps/
diff -ur a/menu b/menu
--- a/menu	2010-08-31 16:53:55.0 +0200
+++ b/menu	2014-03-12 16:18:52.0 +0100
@@ -2,5 +2,6 @@
  needs=X11\
  section=Games/Simulation\
  title=FGo!\
+ icon=/usr/share/pixmaps/fgo.xpm\
  command=fgo\
  hints=Flightgear,Games
diff -ur a/rules b/rules
--- a/rules	2011-08-06 17:10:27.0 +0200
+++ b/rules	2014-03-12 16:09:50.0 +0100
@@ -6,11 +6,19 @@
 %:
 	dh $@ --with python2
 
+override_dh_auto_clean:
+	dh_auto_clean
+	rm -f debian/fgo.xpm
+
+override_dh_auto_build:
+# cf. https://wiki.debian.org/Games/JessieReleaseGoal
+	convert data/pics/icons/32x32/fgo.png debian/fgo.xpm
+
 override_dh_installdocs:
 	dh_installdocs
 	# Remove the licence, this infomation is stored in the debian/copyright file
 	rm debian/fgo/usr/share/doc/fgo/docs/COPYING
 	rm -f debian/fgo/usr/share/doc/fgo/docs/CHANGE_LOG
-	
+
 override_dh_installchangelogs:
 	dh_installchangelogs docs/CHANGE_LOG

Bug#655154: woof: No space left on device when /tmp is full

[Florent Rougon]

tags 655154 + upstream
forwarded 655154 si...@budig.de
thanks

Hello,

The attached patch fixes this problem. I have forwarded it to the
upstream maintainer. Here follows the patch description:

,
| Improve handling of files received with option -U
| 
| Instead of storing the downloaded contents into a temporary file
| that is copied by woof to the final destination (current directory),
| the uploaded file is directly written to the current directory, with
| precautions to avoid overwriting existing files.
| 
| This is done by subclassing cgi.FieldStorage to override make_file() so
| that it does not create a temporary file when encountering an atomic
| part whose name is upfile in the MIME data.
| 
| This improvement is particularly welcome when receiving large files,
| since it avoids:
|   - a possible failure due to the temporary directory being too small to
| hold the file;
|   - a useless copy of the whole file;
|   - a possible loss of the whole download in case a failure occurs when
| woof copies the (complete) temporary file to its final destination.
`

For people who don't want to apply the patch, setting TMPDIR allows a
partial workaround: you may indicate a directory with more space than
/tmp this way, but you will still have to hold two copies of the
downloaded file at the same time (one in TMPDIR and the other in the
directory from which 'woof -U' was started), until woof deletes the
temporary file through garbage collection. Depending on the file size
and the available space, this may or may not be possible.

-- 
Florent
diff --git a/woof b/woof
index 2abedf0..fde8de1 100755
--- a/woof
+++ b/woof
@@ -124,6 +124,64 @@ class ForkingHTTPServer (BaseHTTPServer.HTTPServer):
   self.close_request (request)
 
 
+class MyFieldStorage (cgi.FieldStorage):
+   Subclass of FieldStorage with efficient handling of uploaded files.
+
+   This class behaves the same as FieldStorage except that it handles uploaded
+   files more efficiently: instead of storing the data into a temporary file
+   that is copied by woof to the final destination (current directory),
+   the uploaded file is directly written to the current directory, with
+   precautions to avoid overwriting existing files.
+
+   
+   # The function signature changed between Python 2 and Python 3; this will
+   # work in all cases.
+   def make_file(self, *args, **kwargs):
+  # The self.list is None check is here to prevent misbehaving in case we
+  # receive a multipart whose name happens to be upfile.
+  if self.list is None and self.name == upfile:
+ # make_file() was called for an uploaded file. No need to create a
+ # potentially huge temporary file only to copy it to the final
+ # destination. Just create the file in a way that avoids overwriting
+ # existing files.
+ upfilename = self.filename
+
+ if \\ in upfilename:
+upfilename = upfilename.split (\\)[-1]
+
+ upfilename = os.path.basename (self.filename)
+
+ destfile = None
+ for suffix in [, .1, .2, .3, .4, .5, .6, .7, .8,
+.9]:
+destfilename = os.path.join (upfilename + suffix)
+try:
+   destfile = os.open (destfilename,
+   os.O_WRONLY | os.O_CREAT | os.O_EXCL, 0o644)
+   break
+except OSError, e:
+   if e.errno == errno.EEXIST:
+  continue
+   raise
+
+ # Fallback to tempfile.mkstemp() in case the above did not manage to
+ # create the file.
+ if destfile is None:
+destfile, destfilepath = tempfile.mkstemp (
+   prefix = upfilename + ., dir = .)
+# 'destfilepath' is a full path, be consistent with the normal case
+destfilename = os.path.basename (destfilepath)
+
+ msg = Accepting uploaded file: '%s' % upfilename
+ if upfilename != destfilename:
+msg += , stored as '%s' % destfilename
+ sys.stderr.write (msg + ...\n)
+
+ return os.fdopen (destfile, wb)
+  else:
+ return cgi.FieldStorage.make_file (self, *args, **kwargs)
+
+
 # Main class implementing an HTTP-Requesthandler, that serves just a single
 # file and redirects all other requests to this file (this passes the actual
 # filename to the client).
@@ -152,49 +210,26 @@ class FileServHTTPRequestHandler (BaseHTTPServer.BaseHTTPRequestHandler):
   # http://mail.python.org/pipermail/python-list/2006-September/402441.html
 
   ctype, pdict = cgi.parse_header (self.headers.getheader ('Content-Type'))
-  form = cgi.FieldStorage (fp = self.rfile,
-   headers = self.headers,
-   environ = {'REQUEST_METHOD' : 'POST'},
-   keep_blank_values = 1,
-   strict_parsing = 1)
+  form = MyFieldStorage (fp = self.rfile,
+   

Bug#732640: woof: could have better tagging

[Florent Rougon]

Package: woof
Version: 20091227-2
Severity: wishlist

Hello,

woof is a very nice program but not so easy to find among the myriad of Debian
packages. Neither did the pages for sendfile and so-called similar packages
on packages.debian.org, nor did a search for file transfer in packagesearch
give any hint about the existence of woof. I could only find it because of a
file where I keep interesting packages from the Debian Weekly News.

Looking at the tags listed on http://packages.debian.org/sid/woof, it seems
to me that adding the use::transmission and maybe also use::downloading tag(s)
would make woof easier to find. I hope this is the right place for such a
report.

Thanks.


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

Bug#573007: NIC r8169 doesn t start at restart on kernel linux-image-2.6.32-trunk-686 (workaround)

[Florent Rougon]

Hi,

I applied this patch
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573007#54) on March
29[1], but unfortunately, the bug is still there for me. More precisely,
my script which detects and works around the problem triggered at the
following times since then:

Thu, 01 Apr 2010 21:11:18 +0200  Attempt to reinitialize Ethernet interfaces
Thu, 08 Apr 2010 10:21:39 +0200  Attempt to reinitialize Ethernet interfaces
Wed, 14 Apr 2010 10:42:20 +0200  Attempt to reinitialize Ethernet interfaces
Thu, 15 Apr 2010 10:27:03 +0200  Attempt to reinitialize Ethernet interfaces

(sorry, I was too busy to report before)

I just modified it so that it also logs the HW address of the Ethernet
interface that was detected as failed, and will report next time I have
a failure, to make sure we are really talking about the same bug (I also
noticed #516187...).

Thanks.


  [1] As I wrote to Ben Hutchings in private, I applied the patch on the
  source tree obtained from linux-source-2.6.32_2.6.32-10_all.deb
  and compiled with the standard kernel configuration options from
  linux-image-2.6.32-4-amd64_2.6.32-10_amd64.deb (/boot/config-...)

  I also investigated the following boot messages:

  [1.449790] r8169 :02:00.0: firmware: requesting rtl8168d-2.fw
  [1.529423] eth0: unable to apply firmware patch
  [2.338209] r8169 :03:00.0: firmware: requesting rtl8168d-2.fw
  [2.339586] eth1: unable to apply firmware patch

  but found no place to download the firmware file from, despite
  several people complaining about that and not finding the
  aforementioned file either. Apparently, the firmware file is not
  needed, or only for some model(s) if used in this or that way, but
  the message is always printed, no matter what.

-- 
Florent



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

Bug#573007: NIC r8169 doesn t start at restart on kernel linux-image-2.6.32-trunk-686 (workaround)

[Florent Rougon]

Another possible workaround (didn't try Ben's one, I just discovered
this thread today):

Save the attached script in /root/bin/flo-check-network-connections
(using bash because of $RANDOM). Change the line:

  interfaces=eth0 eth1

to list the interfaces that have the problem (and that you want to be
up; if you have unused interfaces that are managed by the buggy driver,
you can omit them from the list)

In /etc/init.d/networking, replace the line:

if ifup -a; then

with

if ifup -a; /root/bin/flo-check-network-connections; then

The script, when called, does the following:

  - if all listed interfaces are up and have a proper inet addr
setting according to ifconfig, do nothing;

  - otherwise, try to fix the problem by doing several
modprobe -r r8169; modprobe r8169 in a row, followed by an
ifdown -a / ifup -a sequence (you may pass arguments to the script
here, that are passed along to ifup and ifdown).

Yes, this clunky procedure does work for me, contrary to the
cold boot / wait 30 s workaround I found in another bug report;
you might want to modify $max_attempts, which I have set to 15 by
default; it has always worked for me in about 1-3 attempts.

The script returns exit status 0 if success (i.e., the listed interfaces
are properly initialized [maybe were already so before the script was
called]), 1 otherwise.

Of course, this is just a workaround for an annoying problem. A proper
fix in the kernel would be most welcome. :-)

HTH.

-- 
Florent



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

Bug#573007: NIC r8169 doesn t start at restart on kernel linux-image-2.6.32-trunk-686 (workaround)

[Florent Rougon]

Would be even better with the script actually attached...

-- 
Florent
#! /bin/bash

interfaces=eth0 eth1
max_attempts=15
exit_status=1

for attempt in $(seq 1 $max_attempts); do
all_intf_ok=1
for intf in $interfaces; do
ifconfig $intf | grep /dev/null ^[[:space:]]*inet addr: \
  || { all_intf_ok=0; break; }
done

[ $all_intf_ok -eq 1 ]  { exit_status=0; break; }

echo Ethernet interfaces not properly initialized. \
Trying to fix that (attempt $attempt)...
n=$(echo ($RANDOM % 3) + 2 | bc)
for i in $(seq 1 $n); do
modprobe -r r8169; modprobe r8169
done

ifdown -a $@
ifup -a $@
done

exit $exit_status

Bug#573007: NIC r8169 doesn t start at restart on kernel linux-image-2.6.32-trunk-686 (workaround)

[Florent Rougon]

Ben Hutchings b...@decadent.org.uk wrote:

 This is now being handled upstream and there is a proposed fix.  We will
 apply that once it has been tested across a range of RTL8169-family
 chips.

Thank you. If it can be of some help, I may test something. I am
currently using upstream 2.6.32 compiled with make-kpkg on lenny. My
Ethernet chip is RTL8111D according to the motherboard manual, and the
MB itself is Gigabyte GA-P55-UD5.

'lspci -v' says:

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI 
Express Gigabit Ethernet controller (rev 03)
Subsystem: Giga-byte Technology Device e000
Flags: bus master, fast devsel, latency 0, IRQ 35
I/O ports at ae00 [size=256]
Memory at fb6ff000 (64-bit, prefetchable) [size=4K]
Memory at fb6f8000 (64-bit, prefetchable) [size=16K]
[virtual] Expansion ROM at fb60 [disabled] [size=128K]
Capabilities: [40] Power Management version 3
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 
Enable+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [ac] MSI-X: Enable- Mask- TabSize=4
Capabilities: [cc] Vital Product Data ?
Capabilities: [100] Advanced Error Reporting ?
Capabilities: [140] Virtual Channel ?
Capabilities: [160] Device Serial Number 00-e0-4c-68-00-00-00-03
Kernel driver in use: r8169
Kernel modules: r8169

[ About the script I posted, if anyone wants to use it in the meantime:
  I noticed one can be more specific by replacing the ifup/ifdown -a
  calls with ifup/ifdown $interfaces. ]

Regards,

-- 
Florent



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

Bug#444307: [Frank Küster] Re: Wrong documentation for CM-Super in texdoctk

[Florent Rougon]

Norbert Preining [EMAIL PROTECTED] wrote:

 Or we just ignore it and wait for something more useful ... that reminds
 me that I have to ask Florent whether there is any progress on the new
 texdoc viewer...

Sorry about that, but no. Unfortunately, I'm unable to work on it these
days, and I cannot give you any deadline. I can only hope.

-- 
Florent



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

Bug#441526: lmodern: updmap-sys failed.

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 I agree that we shouldn't change dh_installtex's default.  Florent, will
 you have time to fix this?

Sorry, I don't feel well these days. Please do what you think should be
done.

-- 
Florent

Bug#400494: lirc: Fix for the build failure caused by the inclusion of linux/config.h is incomplete

[Florent Rougon]

Hi,

Loïc's upload of lirc 0.8.0-10 commented out the inclusion of
linux/config.h in drivers/lirc_dev/lirc_dev.c, but that was not enough
for me.

lirc-modules-source still failed to build because
drivers/lirc_serial/lirc_serial.c also wants to include that file.
Commenting out the relevant line in lirc_serial.c solved the problem.
The build now succeeds and the resulting module package works fine.

This is on etch with Linux 2.6.21 from bpo and lirc 0.8.0-12 backported
from unstable.

HTH,

-- 
Florent

Bug#435132: texlive-metapost: Please include latest latexmp version

[Florent Rougon]

Dear TeX Live maintainers,

We have here a request in the Debian BTS to update the version of
latexmp as shipped in TL. Could anyone take care of this?

Dylan Thurston [EMAIL PROTECTED] wrote:

 The version of latexmp included with texlive-metapost, version 1.1.0,
 is very outdated.  The current version is 1.2.1, released on 7 Apr
 2005.

 One improvement (fixing what I would consider a minor bug) is that it
 handles the origin relative to the bounding box better: by default it
 now places the origin where btex..etex would, rather than at the
 center of the bounding box.  The 1.1.0 behaviour (center of the
 bounding box) loses information and makes it very difficult to line up
 different textext strings.

TIA,

-- 
Florent


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

Bug#436235: texlive-lang-ukenglish: postinst and uninstall fail: Package color Error: No driver specified.

[Florent Rougon]

Hi,

Johannes Rohr [EMAIL PROTECTED] wrote:

 I was apparantly hit by bug #425803

Can we (or you) close the bug, then?

Thanks.

-- 
Florent


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

Bug#434706: texlive-latex-base: color package uses black for figure captions and page numbers

[Florent Rougon]

retitle 434706 Color handling could have the concept of a default foreground 
color
severity 434706 wishlist
thanks

Hi,

Ryo Furue [EMAIL PROTECTED] wrote:

 Hmm . . . It seems to me that a possible solution is to add a
 default foreground color (DFC) to the protocol.  The LaTeX color
 package would insert a special saying put this text in the DFC
 instead of saying put this text in black.  Then, xdvi, dvips,
 or dvipdf would substitute DFC with its current foreground color
 before it asks GhostScript to render the text.  I think this scheme
 would count as a proper fix rather than a workaround.

This looks like a complex change, involving at least:
  - color.sty / xcolor.sty;
  - xdvi
  - dvips
  - dvipdfm  Co

I fear none of us has the time and inclination to push such a change
upstream, so if you want it to become reality, I suggest you to discuss
it in comp.text.tex and/or with the xcolor package maintainer.

Regards,

-- 
Florent


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

Bug#436690: gkrellm-reminder: cannot remind about events more than 120 minutes early

[Florent Rougon]

Package: gkrellm-reminder
Version: 2.0.0-2
Severity: minor

Hi,

In the Settings tab, there is a spinbox for Remind me about events x
minutes early. The value of x is limited to 120 in reminder.c, line 2371:

  adj_remind_early = gtk_adjustment_new( config.remind_early, 0, 120, 1, 10, 0 
);

For some events, I'd like to be reminded, e.g., one day early, i.e. 1440
minutes. Because of this limitation of 120 (which looks arbitrary), this is
impossible.

Please remove this limitation.

Thanks.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: LANG=en_US, [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages gkrellm-reminder depends on:
ii  gkrellm 2.2.9-1  The GNU Krell Monitors
ii  libatk1.0-0 1.12.4-3 The ATK accessibility toolkit
ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libcairo2   1.2.4-4  The Cairo 2D vector graphics libra
ii  libfontconfig1  2.4.2-1.2generic font configuration library
ii  libglib2.0-02.12.4-2 The GLib library of C routines
ii  libgtk2.0-0 2.8.20-7 The GTK+ graphical user interface 
ii  libpango1.0-0   1.14.8-5 Layout and rendering of internatio
ii  libx11-62:1.0.3-7X11 client-side library
ii  libxcursor1 1.1.7-4  X cursor management library
ii  libxext61:1.0.1-2X11 miscellaneous extension librar
ii  libxi6  1:1.0.1-4X11 Input extension library
ii  libxinerama11:1.0.1-4.1  X11 Xinerama extension library
ii  libxrandr2  2:1.1.0.2-5  X11 RandR extension library
ii  libxrender1 1:0.9.1-3X Rendering Extension client libra

gkrellm-reminder recommends no packages.

-- no debconf information


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

Bug#436687: tex-common: Package upgrade fails in the Configure stage

[Florent Rougon]

reassign 436687 aptitude
retitle 436687 Symbol lookup error
thanks

This looks like a problem with aptitude or one of its dependencies.
Thus, I am reassigning the bug.

-- 
Florent


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

Bug#434706: texlive-latex-base: color package uses black for figure captions and page numbers

[Florent Rougon]

Hi,

Ryo Furue [EMAIL PROTECTED] wrote:

 If the original LaTeX source uses the color package, xdvi -rv
 shows figure captions and page numbers in black, which is invisible in
 default colors.  I confirmed they are black by

Frankly, I doubt upstream would want to workaround that (I say
workaround, because a proper fix would be *very* difficulut, I think).

Reasons:
  - TeX knowns *nothing* about colors, and neither do DVI files; the
color you get in your DVI is not really part of the DVI format, it
is inserted by PostScript specials, which are extension strings for
things not handled by the DVI format, such as, yes, color handling.

  - xdvi renders these PostScript specials by calling GhostScript,
AFAIK, so I suppose that the result, including the precise colors
used, is a black box as far as xdvi is concerned;

  - a proper fix would be to retrieve the color information from
GhostScript's output and fiddle with it so that it is displayed
correctly in reverse video. So, when your document says
\color{brown} and gs renders a few pixels in brown, xdvi should just
stop to show and say: Hey, guys, I'm smarter than everyone of you;
I'll pick green!!!. Hmmm.

-- 
Florent


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

Bug#430976: texlive-metapost: symbols don't appear when using metapost

[Florent Rougon]

Rogério Brito wrote:

 I think that Florent might not have seen the problem as, from what I
 understand, he has lmodern fonts installed in his system.

Quite so.

-- 
Florent

Bug#433329: Please clarify whether Lucida Bright/Lucida Sans fonts are supported

[Florent Rougon]

[Dropping the TL upstream list]

Rogério Brito [EMAIL PROTECTED] wrote:

 Wouldn't it be the case for having the support files for non-free fonts
 to be in contrib here? If I learned it correctly, I think that is the
 purpose of the contrib section. Is that right?

Quite correct. But if the contrib data is too small, it doesn't make
sense to create a whole new package for it. It would make sense if the
package they are currently part of would *as a whole* *only* be usable
with non-free stuff, but I don't think this is the case here.

-- 
Florent

Bug#400742: Bug#431671: Bug#400742: Bug#431671: piuparts test: fails to install: line 43: update-updmap: command not found

[Florent Rougon]

Hi,

Nice to see you back!

Frank Küster [EMAIL PROTECTED] wrote:

 I suggest we remove the wontfix tag and add a block on the dpkg bug
 requesting the trigger, what do you think?

Fine, feel free to do so.

Regards,

-- 
Florent

Bug#400742: Bug#431671: Bug#400742: Bug#431671: piuparts test: fails to install: line 43: update-updmap: command not found

[Florent Rougon]

Norbert Preining [EMAIL PROTECTED] wrote:

 retitle 400742 dh_installtex should check the existence for tex file
 tags 400742 - wontfix
 thanks

[...]

 Ok, I retitled the bug and removed the wontfix stuff. If I find time I
 will implement it.

*WARNING*  *WARNING*  *WARNING*  *WARNING*  *WARNING*  *WARNING*  *WARNING*

  If you check for the existence of TeX files in the package being built
  and don't run mktexlsr in case there is no TeX file, this is in
  general short-sighted and incorrect.

*WARNING*  *WARNING*  *WARNING*  *WARNING*  *WARNING*  *WARNING*  *WARNING*

Reason: if there were TeX files in any previous version of the package
(up to the previous Debian release), then mktexlsr *has* to be run.

People always complain about cheap stuff being run unnecessarily, but
then they will also complain when hell breaks because the cheap stuff
was so wisely not run...

If there is nothing TeX-related in your package, don't run
dh_installtex...

-- 
Florent


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

Bug#400742: Bug#431671: Bug#400742: Bug#431671: piuparts test: fails to install: line 43: update-updmap: command not found

[Florent Rougon]

Rene Engelhard [EMAIL PROTECTED] wrote:

 Reason: if there were TeX files in any previous version of the package
 (up to the previous Debian release), then mktexlsr *has* to be run.

 Why weren't they in their own package then?

Huh? I don't know. I'm not the maintainer of texpower.

 Then if the package goes away you already have the postrm run mktexlsr
 because it's there in the old package and gets run when you remove it.

Hah! So you would want mktexlsr to be run on 'postrm upgrade' for every
package that ships .tex files and runs dh_installtex, right?

I'm not opposed to that, because this is clean. But do you realize that
if go that route, when a package containing .tex files is upgraded to a
version that also contains .tex files, then mktexlsr would be run *twice
in a row*? Once by old-postrm upgrade and once by
new-postinst configure.

I can very well imagine the gazillion bug reports we would get if we did
that.

Reminder:

  * Why does mktexlsr need to be run on upgrade?

Because the list of .tex file can change (new files, removals,
renamings).

  * Why does mktexlsr need to be run by postinst configure?

Because when you go from the removed state to the installed state,
the .tex files added by the installation have to be registered.

Since new-postinst configure is automatically run on upgrades anyway,
we thought it not useful to *additionally* run it on old-postrm upgrade,
but if that's what you want, we can enable that and let you deal with
the bug reports. :-P

If I follow your reasoning, you're embarrassed seeing mktexlsr being run
on postinst configure for a package that doesn't ship tex files.
Right. But at the same time, you would like that the previous version of
the package runs mktexlsr as old-postrm upgrade because you know, the
next version might not ship the exact same list of .tex files. Since
we don't have a time machine, there is no way to know when writing
old-postrm that the next version will have .tex files (in which case,
running mktexlsr in old-postrm upgrade is useless, since it will be
run by new-postinst configure anyway). Therefore, by your reasoning,
we would have to *always* run mktexlsr in old-postrm upgrade. Since,
with your proposal of looking whether the new version contains .tex
files, postinst configure would also cause a mktexlsr run whenever the
new version contains .tex files, you're proposing a system where
mktexlsr is run twice in a row in most cases. Doesn't look like an
improvement to the current system to me.

 I'd have split out the tex files (let alone because the dependencies on
 TeX stuff) and if you app really needs them make the app depend on
 *them*, not ship them in the normal packages.

Making a new binary package only in order to avoid a dependency on
tex-common in the main package is ridiculous. tex-common is quite
small.

 This is like comparable to programs/libs, where the (public) libs built from a
 programs' source package should also not be in package foo but in
 libfooX.

Gni? The reason we need libfooX is for other packages to depend on it,
and only on it. But programs that are the only users of their libraries
don't need to create libfooX binary packages.

 dh_installmenu does not add update-menus to everything because one
 package produced has a menu file and is therefore called. It just adds
 the needed stuff to the needed packages.

So?

 In contrast to that, dh_installtex when ran without -p adds its snippet
 to *every* binary package, may it have tex stuff in it or not.

And rightly so, because if the maintainer runs dh_installtex for a
package, he should have a reason to do so. For instance, because the
previous version had .tex files.

 Anyway, I just worked around it by using -p and will keep it mind.

It is not a workaround. It is simply using the tool where it is
needed.

 Do whatever you think, but you are behaving completely different than
 many normal dh_*'s.

dh_installtex is doing more complex stuff than many dh_*'s. It is normal
that it is not a clone of all of them.

-- 
Florent


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

Bug#430976: texlive-metapost: symbols don't appear when using metapost

[Florent Rougon]

Rogério Brito [EMAIL PROTECTED] wrote:

 Indeed, they lack the fonts. Did you notice that the generated output
 comes with the math fonts embedded many times, when used this way? And
 one thing that is quite noticeable is that the fonts embedded in the PDF
 file normally have names in all caps, like CMR10, while the fonts used
 by these figures have names like cmr10.

I don't see any of this. With one of my lmodern-using documents, with
MetaPost figures that also use lmodern for the labels, I have:

% pdffonts cours-eqs-a-trous.pdf
name type emb sub uni object ID
  --- --- --- -
EGMZJN+LMRoman17-Regular Type 1   yes yes no   4  0
YUOMZI+LMRoman12-BoldType 1   yes yes no   5  0
MXMXMS+LMRoman12-Regular Type 1   yes yes no   6  0
FTFDIH+LMRoman12-Italic  Type 1   yes yes no   7  0
MXMXMS+LMRoman12-Regular Type 1   yes yes no   8  0
JTVECY+LMMathItalic12-Italic Type 1   yes yes no   9  0
DOUOBX+LMMathSymbols10-ItalicType 1   yes yes no  10  0
DBPJWC+LMRoman8-Regular  Type 1   yes yes no  11  0
CJXGWO+LMRoman10-BoldItalic  Type 1   yes yes no  16  0
%

With essai.tex + rbrito.mp as given in my previous mail, I have:

% pdffonts essai.pdf   [EMAIL PROTECTED]
name type emb sub uni object ID
  --- --- --- -
MDJGZL+LMRoman12-Regular Type 1   yes yes no   5  0
KGVGIZ+CMR10 Type 1   yes yes no   8  0
SPUPOK+CMSY10Type 1   yes yes no   9  0
TMHVPV+MSAM10Type 1   yes yes no  10  0
%

LMRoman12-Regular comes from essai.tex, which has \usepackage{lmodern};
the rest comes from rbrito.mp, which starts with:

,
| verbatimtex
| \documentclass{article}
| 
| \usepackage{amsmath}
| \usepackage{amssymb}
| 
| \begin{document}
`

I don't see anything suspicious here.

 It indeed helped a lot, but I still have one problem, even with the
 automatic inclusion of MetaPost files in pdflatex: xpdf doesn't show the
 little square that it is supposed to show.

Weird. It does here on etch and also on sid (the sid chroot isn't very
up-to-date, I'm upgrading it right now and will tell you if this changes
something once the upgrade is finished). Screenshots with xpdf and gv
here:

  http://people.via.ecp.fr/~flo/tmp/MetaPost-rbrito/

 With gv on the PDF file, it actually draws a very, very light square (I
 have to pay attention very hard on my screen to actually see it). It
 doesn't seem as black as the triangle or the other numbers included in
 the picture.

Here, it works fine with gv expect I get errors when I zoom too much
(i.e., 4 times). But gv has never been great for PDF viewing in my
experience...

 Ah, one more thing: other instances of this very same square *is* quite
 visible on the text (as expected), but this square is not visible. It
 must have something to do with it being in a picture... :-(

Mmmm... no idea...

 Do the triangle and the square look as black as each other in your
 screen?

Yes, judge by yourself from the screenshots I posted.

 I have not tried printing my text (it is part of an ongoing text for
 my students), but I suspect that it will appear light, if printed
 from the PDF file.

Dunno, but you should try if possible.

 Anyway, thank you very much for your very helpful hints, Rogério Brito.

You're welcome.

-- 
Florent

Bug#430976: texlive-metapost: symbols don't appear when using metapost

[Florent Rougon]

Florent Rougon [EMAIL PROTECTED] wrote:

 Weird. It does here on etch and also on sid (the sid chroot isn't very
 up-to-date, I'm upgrading it right now and will tell you if this changes
 something once the upgrade is finished).

On an up-to-date sid chroot, I have the same results except that xpdf
gives this warning:

  % xpdf essai.pdf
  xpdf: Symbol `_XmStrings' has different size in shared object, consider 
re-linking
  XtUngrabButton(drawArea,3,0)

which is reported as bugs #425568 and #425643 (actually, I suppose the
XtUngrabButton(drawArea,3,0) part is tied to the usual
Warning: Attempt to remove nonexistent passive grab reported as
#364773).

Both the xpdf and gv output show the triangle and square the same way,
which looks fine.

-- 
Florent


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

Bug#430976: texlive-metapost: symbols don't appear when using metapost

[Florent Rougon]

Hi,

Rogério Brito [EMAIL PROTECTED] wrote:

 I am trying to create a diagram for a text of mine using metapost.
 Unfortunately, when I typeset the following file (having the environment
 variable TEX=latex), I can't see all the symbols: the square does not
 appear (its position is blank), while the triangle *does* appear!

 For compiling the figure below, I use the following sequence of commands:

 mpost metapost-fail
 a2ping metapost.1
 xpdf metapost.pdf

Are you sure this is a MetaPost problem? Here, with texlive-metapost
version 2007-12.np.etch.1, including the compiled figure in a LaTeX
document processed by pdfTeX works fine. So, I'd say the problem is in
the conversion by a2ping, not in MetaPost.

-- 
Florent

Bug#430976: texlive-metapost: symbols don't appear when using metapost

[Florent Rougon]

Rogério Brito [EMAIL PROTECTED] wrote:

 Sorry for the use of wrong names. They should all have been
 metapost-fail in the examples above.

I understood that.

 Here, with texlive-metapost version 2007-12.np.etch.1, including the
 compiled figure in a LaTeX document processed by pdfTeX works fine.

 Which steps did you actually use? I'm curious. I tried to grab
 metapost-fail.pdf and include it with \includegraphics (with the
 graphicx package loaded) and I got a blank place where the square should
 have appeared, unfortunately. :-(

pdfTeX is able (thanks to Hans Hagen) to include MetaPost output files.
You don't need (and shouldn't) convert them to PDF beforehand.

Just give them the extension .mps and graphicx will do the rest. For the
extension thing, I usually create symlinks from schema1.mps to schema.1,
schema2.mps to schema.2, etc. so that I can write
\includegraphics*{schema7} in my main LaTeX document.

So, the steps are:

  1. TEX=latex mpost rbrito.mp

 (where rbrito.mp is the file you provided)

  2. ln -s rbrito.1 rbrito.mps

  3. cat essai.tex EOF
\documentclass[a4paper,12pt,pdftex]{article}
\usepackage{lmodern}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage{textcomp}
\usepackage{graphicx}

\begin{document}
\begin{center}
  \includegraphics*{rbrito}
\end{center}
\end{document}
EOF

  4. pdflatex essai.tex

 What exactly did you use to convert the picture to PDF? If I remember
 correctly, epstopdf crashes with a problem of ghostscript.

Don't convert the picture. Unless you use the prologues variable, output
files from MetaPost are incomplete PostScript files (something about the
fonts is missing), so the conversion is not straightforward. BTW, I
suppose that the .mps extension means MetaPost PostScript precisely to
remind us that these are not really PostScript files.

 Oh, it just occurred me that the versions of ghostscript that we may be
 using may be the culprit.

I didn't use gs at all here.

 But I am not exactly shure, unfortunately. Any light shed on this issue
 would be *quite* welcome.

I'm pretty sure it's not a MetaPost problem. BTW, it is IMHO clumsy to
require the setting of TEX to latex for your MetaPost documents to
compile. Other documents may well require TEX=tex, so you would have to
fiddle with the env var depending on the document. Bleh. Personally, I
declare the use of LaTeX where it belongs, i.e. in the .mp file, like
this:

,[ schemas.mp ]
| verbatimtex
| %latex
| \documentclass[a4paper,12pt,frenchb,french]{article}
| \usepackage{lmodern}
| \usepackage[T1]{fontenc}
| \usepackage[latin1]{inputenc}
| \usepackage{xspace}
| \usepackage[thinspace]{SIunits}
| \usepackage{babel}
| 
| \NoAutoSpaceBeforeFDP
| \FrenchItemizeSpacingtrue
| \FrenchListSpacingtrue
| 
| % Pour écrire AB, (AB), [AB], etc.
| \newcommand{\pts}[1]{\ensuremath{\mathit{#1}}}
| 
| \begin{document}
| etex
| 
| beginfig(1);
|   numeric u;
|   pair a, b, m, i;
| 
|   [...]
| 
| endfig;
| 
| verbatimtex
| \end{document}
| etex
| end
`

I'm also attaching a typical Makefile I use whose purpose is to:
  - compile a simple TeX document containing all figures created from
schemas.mp (this is used for developping the figures);
  - automatically create the .mps symlinks needed for the inclusion of
the MetaPost output files.

To use this Makefile, you need:
  - a simple LaTeX file 'essai.tex' as attached;
  - a file named 'schemas.mp' containing your MetaPost figures;
  - to adjust NUMBER_OF_SCHEMAS in the Makefile to match the number of
figures in schemas.mp (yes, this could be extracted
automatically...).
  - same thing with \setcounter{NumberOfFigures}{15} in essai.tex.

all: pdf

MP_BASE_NAME  := schemas
MP_STEM   := schema
NUMBER_OF_SCHEMAS := 15

LATEX_ARGS:= --src-specials \\nonstopmode
PDFLATEX_ARGS := \\nonstopmode
TEX_RUNS  := 1

SRC_BASE_NAME := essai
SRC   := $(SRC_BASE_NAME).tex

SRC_PDF_BASE_NAME := $(SRC_BASE_NAME)_pdf
SRC_PDF   := $(SRC_PDF_BASE_NAME).tex
SRC_PS_BASE_NAME  := $(SRC_BASE_NAME)_ps
SRC_PS:= $(SRC_PS_BASE_NAME).tex

DVI   := $(SRC_PS_BASE_NAME).dvi


COMPILED_SCHEMAS := $(foreach num, $(shell seq 1 $(NUMBER_OF_SCHEMAS)), \
$(MP_BASE_NAME).$(num))
$(COMPILED_SCHEMAS): $(MP_BASE_NAME).mp
mpost $(MP_BASE_NAME).mp

$(MP_STEM)%.mps: $(MP_BASE_NAME).%
@if [ ! -e '$@' ]; then \
   ln -s '$' '$@'; \
fi

$(MP_STEM)%.eps: $(MP_BASE_NAME).%
@if [ ! -e '$@' ]; then \
   ln -s '$' '$@'; \
fi

pdf: $(SRC_PDF) $(foreach num, $(shell seq 1 $(NUMBER_OF_SCHEMAS)), \
$(MP_STEM)$(num).mps)
for i in `seq 1 $(TEX_RUNS)`; do \
   pdflatex $(PDFLATEX_ARGS)'\input{$}'; \
done
@if [ ! -e '$(SRC_BASE_NAME).pdf' ]; then \
   ln -s '$(SRC_PDF_BASE_NAME).pdf' '$(SRC_BASE_NAME).pdf'; \
fi

ps: $(DVI)
dvips -o '$(SRC_BASE_NAME).ps' '$'

dvi: $(DVI)

$(DVI): 

Bug#364426: xserver-xorg-video-ati: display completely garbled with DRI, can even hard lock

[Florent Rougon]

Hi,

Brice Goglin [EMAIL PROTECTED] wrote:

 About a year ago, you reported a bug to the Debian BTS regarding the
 display being garbled when DRI is enabled on an ATI board. Did you
 reproduce this problem recently? With Xorg/Etch? With latest
 xserver-xorg-core and drivers? If not, I will close this bug in the next
 weeks.

You can close the bug: I'm using Xorg from etch with the same graphic
adapter, DRI enabled and it works fine.

Thanks for taking care.

Regards,

-- 
Florent


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

Bug#429314: texlive-context: missing dependency on lmodern

[Florent Rougon]

Sanjoy Mahajan [EMAIL PROTECTED] wrote:

 So, why are you reporting a bug against texlive-context, since you know
 it is deprecated?

 To help Debian ConTeXt users, because etch will be used for perhaps
 two years (and longer by people who then run it as 'oldstable').

OK.

[...]

 Meanwhile I'll switch to aptitude as my command-line tool.

The first benefit you'll get is packages being marked as automatic (if
you install A which depends on libobscure0 and you don't particularly
care about libobscure0 itself, then aptitude will mark libobscure0 as
automatic, which has the nice consequence that when you remove A and any
other packages that depend on libobscure0, it will automatically remove
libobscure0 so that you don't waste space for a package you don't care
about).

This functionality is being merged into libapt, so it will probably
eventually be available in apt-get, dselect and synaptic, but at the
moment, it is only offered by aptitude.
-- 
Florent


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

Bug#429314: texlive-context: missing dependency on lmodern

[Florent Rougon]

Hi,

Sanjoy Mahajan wrote:

 Installing 'lmodern' fixes the errors, because it provides those
 missing tfm files.  So texlive-context should depend on lmodern, not
 merely recommend lmodern.  Without lmodern, I think the package is
 totally unusable.

texlive-context is an old package. In unstable, it has been replaced by
context, which depends on lmodern (= 1.01).

 This machine runs Ubuntu feisty (i686), but I ran the above tests in a
 pbuilder Debian 'etch' chroot.  I did 'sudo pbuilder login' (I think
 it already had the etch security updates), then 'apt-get install
 texlive-context'.  Then I ran that test file, found that it failed,
 did 'apt-get install lmodern', and reran it with success.

apt-get is not a tool for newbies. If you don't install Recommends, you
should either know what you are doing or expect breakage.

-- 
Florent


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

Bug#429314: texlive-context: missing dependency on lmodern

[Florent Rougon]

Sanjoy Mahajan [EMAIL PROTECTED] wrote:

 I know: I maintain Ubuntu edgy backports of the Debian unstable/Ubuntu
 gutsy packages for texlive 2007, including 'context'.

So, why are you reporting a bug against texlive-context, since you know
it is deprecated?

 apt-get is not a tool for newbies. If you don't install Recommends,
 you should either know what you are doing or expect breakage.

 I didn't know that.  By the way, what do newbies use?  I've used
 apt-get since starting to use Debian years ago and don't even know any
 other tools.

Today, the recommended tool is usually aptitude, though some people
recommend synaptic for really basic users such as Mom. Personally, I've
never tried synaptic and I've used dselect since my first day with
Debian. dselect is quite usable if you're able to read the available
tutorials and the keystrokes section in the online help.

apt-get is a relatively low-level tool that doesn't always do what is
good for newbies. aptitude has a similar command-line interface that can
replace apt-get for most uses.

 The Debian policy manual, section 7.2
 http://www.debian.org/doc/debian-policy/ch-relationships.html, says:

   The Depends field should be used if the depended-on package is
   required for the depending package to provide a significant amount
   of functionality.

 I think lmodern fits in that category because without it most of
 ConTeXt's functionality is missing.

1. If ConTeXt cannot be used with other fonts than lmodern, it's an
   upstream bug, IMHO. If this is not the case, then Recommends would be
   appropriate (see the definition of Recommends in the same Policy
   Manual).

2. Anyway, I fail to see what you want us to do, since the context
   package currently in unstable *does* depend on lmodern. Please
   clarify.

-- 
Florent


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

Bug#429314: texlive-context: missing dependency on lmodern

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 So, why are you reporting a bug against texlive-context, since you know
 it is deprecated?

 Because context doesn't have the bug, but texlive-context has it.  And I
 think it should be even serious.

Okay, but texlive-context is dead, so this bug is nothing more than a
reminder for users of etch...

 I agree, but you must admit that a couple of years ago, apt-get was
 generally recommended to people,

Not by me. ;-)

 and aptitude was something new.

At that time, I recommended dselect to new users.

 At least that's whay I learned. This had also the effect that people
 put stuff into Recommends that should rather be in Suggests, and then
 people started arguing against installing Recommends by default...

Which is pure evil. Recommends is very useful.

 If ConTeXt uses the Latin Modern fonts by default, the package should
 depend on them.  Just as a package which provides LaTeX needs to depend
 on a package which provides the Computer Modern fonts IMO, even if you
 can use others.

I disagree. Putting lmodern in Recommends for context means: unless you
know what you are doing, if you install context, then you also have to
install lmodern. Consequently, if people follow this policy, they will
always install lmodern alongside with context. Additionally, those who
*really* know they won't need lmodern will be able to install context
without lmodern. I think that would make everyone happy.

 I suggest that we keep the bug open as a warning and information for
 users. 

Okay.

-- 
Florent

Bug#426169: texlive-games: Compilation problems with psgo

[Florent Rougon]

Hi,

Frank Küster [EMAIL PROTECTED] wrote:

 minimum.sty and its sister, tableau.sty, is completely in french.  Could
 one of you guys try to find a name or contact address of the author in
 the file?  At a first glance, I didn't find one.

There is none.

 And while you're at it, could you please also look whether there's any
 license statement in the file?

There is no license statement neither in minimum.sty, nor in tableau.sty
as shipped in TL 2007.

Regards,

-- 
Florent

Bug#427562: forkbomb: Workaround and request for comment on documentation

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 Comments?

Nice explanation, thank you.

-- 
Florent

Bug#428158: Dependency on texlive is not fine-grained enough

[Florent Rougon]

Package: maxima-emacs
Version: 5.10.0-6
Severity: normal

Hi,

maxima-emacs depends on tetex-extra | texlive, and this is wrong.
texlive is a meta package that depends on a *lot* of packages (all -lang
packages), which are obviously not needed for maxima-emacs.

You should find the exact texlive non-meta packages actually needed by
maxima-emacs and list them in the Depends line instead of texlive. If
unsure, you can ask on [EMAIL PROTECTED]

Thanks.

-- 
Florent


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