Bug#999858: pbuilder: debconf template suggest obsolete plain-http URL

[ydirson]

Package: pbuilder
Version: 0.231

Nowadays only HTTPS entries are in sources.list (maybe that could
unblock a fix for #790565 ?), the debconf script seems to fail to
detect a mirror as described in that bugreport... and we are shown:

  Here is a valid mirror example: http://deb.debian.org/debian

... which does not work when copypasted, and the user has to guess
it's because it should be https:// instead.

Bug#992806: ftjam - ship with bookworm?

[ydirson]

> ftjam is the freetype.org improved "jam" (a build tool thats
> supposedly better than make). I remember jam being "the hype" a long
> time ago. freetype.org themselves have switched away from jam ... a
> long time ago, and even switched to meson in the mean time.
> 
> I guess some users of the improved jam could still exist, but given
> ftjam has not seen any updates since 2007, and jam before that even
> longer, I find this somewhat unlikely.
> 
> Please speak up if you want to keep ftjam around.
> 
> Otherwise I'll raise severity of this bug over time and eventually
> might ask for removal from Debian.

I've pondered this in the past, and concluded that the maintenance load
was low enough not to bother.

OTOH the popcon graph clearly shows the decline of this legacy package.
It would seem like a good moment to drop it.

Bug#989102: memtest86 - upstream abandonded, still useful?

[ydirson]

> Given memtest86 has not received any updates since 2014, one has to
> ask if it is still useful. memtest86+ exists, and while it does not
> see -regular- updates, it at least gets some.
> 
> Maybe we should remove memtest86 from bookworm?
> 
> Parties interested in keeping memtest86 should speak up.

Just my 2 cents on this: I had managed to keep the 2 packages quite
close to one another, so the maintainance load of memtest86 itself is
really not that high.  I had kept it as a fallback for users, as
memtest86+ getting more aggressive hw features was sometimes failing
on newer platforms.  No hard numbers about how useful that has been
in reality, though.

Bug#965025: Acknowledgement (gpsshogi-data: data does not seem to be provided in the preferred format for modification)

[ydirson]

close 965025
thanks

upstream clarification from Daigo:

> We (as the upstream) created an opening book file and
> evaluation files in a statistical / machine learning
> way from a large amount of data with lots of machine
> power and tuning parameters. It was not our priority
> to develop an out-of-box environment of tools and data
> for exactly mirroring what we produced. However, it
> would be capable of power programmers to customize the
> binary files by reading and using APIs defined in OSL.
> Say, they could put more weight on Bishop or ban some
> moves in an opening position.

Bug#977532: gscan2pdf: save option not available

[ydirson]

>The version of libtiff-tools in testing still outputs to stderr, so I am 
>inclined to say this is not (yet) a Debian bug, and certainly not important.
>
>Indeed, your patch will break the version of gscan2pdf in testing.

Arguably, this is for this type of problems that we have the ability to
specify versions on Depends and Breaks.

Bug#975545: virtinst: bombs out when virsh missing

[ydirson]

Package: virtinst
Version: 1:3.1.0-1

virtinst should maybe "Recommends: libvirt-clients" ?


$ virt-install --virt-type kvm --name buster-amd64 \
> --location http://deb.debian.org/debian/dists/buster/main/installer-amd64/ \
> --os-variant debian10 \
> --disk size=10 --memory 1000 \
> --graphics none \
> --console pty,target_type=serial \
> --extra-args "console=ttyS0"
WARNING  Requested memory 1000 MiB is less than the recommended 1024 MiB for OS 
debian10

Starting install...
Retrieving file linux...

| 5.0 MB  00:00:00
Retrieving file initrd.gz...

|  29 MB  00:00:02
Allocating 'buster-amd64.qcow2' 

|  10 GB  00:00:00
Running text console command: virsh --connect qemu:///session console 
buster-amd64
Error launching ['virsh', '--connect', 'qemu:///session', 'console', 
'buster-amd64']: [Errno 2] Aucun fichier ou dossier de ce type
WARNING  Console command returned failure.

Domain is still running. Installation may be in progress.
You can reconnect to the console to complete the installation process.

Bug#972941: [DRE-maint] Bug#972941: jekyll: complains about missing kramdown-parser-gfm

[ydirson]

> > The real problem is probably https://bugs.debian.org/972702. For
> > the
> > time being
> > please add
> > 
> > gem "kramdown-parser-gfm"
> > 
> > to your Gemfile and eventually remove Gemfile.lock. That should fix
> > it.
> 
> Yes that does help, thanks!

It is still probably worth mentionning that the ruby-bundler I have is 2.1.4-2,
not the 2.2.0~rc.1 mentionned in #972702.

Bug#972941: [DRE-maint] Bug#972941: jekyll: complains about missing kramdown-parser-gfm

[ydirson]

- Mail original -
> De: "Daniel Leidert" 
> À: 972...@bugs.debian.org
> Cc: 972941-submit...@bugs.debian.org
> Envoyé: Lundi 26 Octobre 2020 17:50:13
> Objet: Bug#972941: [DRE-maint] Bug#972941: jekyll: complains about missing 
> kramdown-parser-gfm
> 
> Am Montag, den 26.10.2020, 13:49 +0100 schrieb ydir...@free.fr:
> > Package: jekyll
> > Version: 3.9.0+dfsg-1
> > 
> > Starting to use a new machine and incrementally installing missing
> > packages,
> > I finally
> > get stuck with this:
> > 
> > $ jekyll serve
> > Configuration file: /home/yann/perso/blog/floss-cook/_config.yml
> > Source: /home/yann/perso/blog/floss-cook
> >Destination: /home/yann/perso/blog/floss-cook/_site
> >  Incremental build: disabled. Enable with --incremental
> >   Generating...
> >Jekyll Feed: Generating feed for posts
> >   Dependency Error: Yikes! It looks like you don't have
> >   kramdown-parser-gfm
> > or one of its dependencies installed. In order to use Jekyll as
> > currently
> > configured, you'll need to install this gem. The full error message
> > from Ruby
> > is: 'cannot load such file -- kramdown-parser-gfm' If you run into
> > trouble,
> > you can find helpful resources at https://jekyllrb.com/help/!
> >   Liquid Exception: kramdown-parser-gfm in /_layouts/default.html
> >  ERROR: YOUR SITE COULD NOT BE BUILT:
> > 
> > kramdown-parser-gfm
> > 
> > 
> > kramdown-parser-gfm has been pulled as a dependency of the jekyll
> > package,
> > and it seems to load properly enough:
> > 
> > floss-cook (master>)$ irb
> > irb(main):001:0> require 'kramdown-parser-gfm'
> > => true
> > irb(main):002:0>
> > 
> > 
> > That message seems wrong, right ?  How can we know what the real
> > problem is ?
> 
> The real problem is probably https://bugs.debian.org/972702. For the
> time being
> please add
> 
> gem "kramdown-parser-gfm"
> 
> to your Gemfile and eventually remove Gemfile.lock. That should fix
> it.

Yes that does help, thanks!

Bug#972941: Acknowledgement (jekyll: complains about missing kramdown-parser-gfm)

[ydirson]

Digging further with "strace -e file", I can see that:

* other modules are indeed searched for in the kramdown-parser-gfm directory, 
eg:

187928 
stat("/usr/share/rubygems-integration/all/gems/kramdown-parser-gfm-1.1.0/lib/idn",
 0x7ffd35c48590) = -1 ENOENT (Aucun fichier ou dossier de ce type)
187928 
stat("/usr/share/rubygems-integration/all/gems/kramdown-parser-gfm-1.1.0/lib/idn.rb",
 0x7ffd35c48590) = -1 ENOENT (Aucun fichier ou dossier de ce type)
187928 
stat("/usr/share/rubygems-integration/all/gems/kramdown-parser-gfm-1.1.0/lib/idn.so",
 0x7ffd35c48590) = -1 ENOENT (Aucun fichier ou dossier de ce type)

* kramdown-parser-gfm itself is looked for in others' directories... but not in 
its own:

187928 openat(AT_FDCWD, "/usr/lib/ruby/vendor_ruby/kramdown-parser-gfm.rb", 
O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/bundler-2.1.4/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/minima-2.5.1/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/jekyll-titles-from-headings-0.5.3/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/jekyll-sitemap-1.4.0/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/jekyll-seo-tag-2.7.1/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/jekyll-last-modified-at-1.3.0/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/2.7.0/gems/posix-spawn-0.3.13/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/2.7.0/extensions/x86_64-linux/2.7.0/posix-spawn-0.3.13/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/jekyll-feed-0.15.1/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/jekyll-asciidoc-3.0.0/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/jekyll-3.9.0/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/safe_yaml-1.0.5/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/rouge-3.21.0/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/pathutil-0.16.1/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/mercenary-0.3.6/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/liquid-4.0.3/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/kramdown-2.3.0/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
187928 openat(AT_FDCWD, 
"/usr/lib/ruby/gems/2.7.0/gems/rexml-3.2.3/lib/kramdown-parser-gfm.rb", 
O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce type)
187928 openat(AT_FDCWD, 
"/usr/share/rubygems-integration/all/gems/jekyll-watch-2.2.1/lib/kramdown-parser-gfm.rb",
 O_RDONLY|O_NONBLOCK|O_CLOEXEC) = -1 ENOENT (Aucun fichier ou dossier de ce 
type)
...

$ grep kramdown-parser-gfm.rb /tmp/log | wc -l
45
 grep kramdown-parser-gfm.so /tmp/log | wc -l
45
$ grep kramdown-parser-gfm.rb /tmp/log | grep kramdown-parser-gfm-1.1.0 | wc -l
0
$ grep kramdown-parser-gfm.so /tmp/log | grep kramdown-parser-gfm-1.1.0 | wc -l
0

Bug#972941: jekyll: complains about missing kramdown-parser-gfm

[ydirson]

Package: jekyll
Version: 3.9.0+dfsg-1

Starting to use a new machine and incrementally installing missing packages, I 
finally
get stuck with this:

$ jekyll serve
Configuration file: /home/yann/perso/blog/floss-cook/_config.yml
Source: /home/yann/perso/blog/floss-cook
   Destination: /home/yann/perso/blog/floss-cook/_site
 Incremental build: disabled. Enable with --incremental
  Generating... 
   Jekyll Feed: Generating feed for posts
  Dependency Error: Yikes! It looks like you don't have kramdown-parser-gfm or 
one of its dependencies installed. In order to use Jekyll as currently 
configured, you'll need to install this gem. The full error message from Ruby 
is: 'cannot load such file -- kramdown-parser-gfm' If you run into trouble, you 
can find helpful resources at https://jekyllrb.com/help/! 
  Liquid Exception: kramdown-parser-gfm in /_layouts/default.html
 ERROR: YOUR SITE COULD NOT BE BUILT:

kramdown-parser-gfm


kramdown-parser-gfm has been pulled as a dependency of the jekyll package,
and it seems to load properly enough:

floss-cook (master>)$ irb
irb(main):001:0> require 'kramdown-parser-gfm'
=> true
irb(main):002:0> 


That message seems wrong, right ?  How can we know what the real problem is ?

Bug#972030: python3-nose: issues warning "No module named 'setuptools.extern.six'"

[ydirson]

Package: python3-nose
Version: 1.3.7-7

This may be linked to the update from python 3.8.5 to 3.8.6 which just reached 
testing,
at least I did not get that yesterday and that looks like a good culprit:

$ cd /tmp/
$ nosetests3
/usr/lib/python3/dist-packages/nose/plugins/manager.py:394: RuntimeWarning: 
Unable to load plugin nosedep = nosedep:NoseDep: No module named 
'setuptools.extern.six'
  warn("Unable to load plugin %s: %s" % (ep, e),

--
Ran 0 tests in 0.014s

Bug#970588: accerciser: exception on plugin initialzation

[ydirson]

Package: accerciser
Version: 3.38.0-1

When starting accerciser (on a recently installed buster upgraded to testing) I 
get
a "plugin errors" tab with a "io.UnsupportedOperation: fileno" title and the 
following
contents.  Not sure whose problem it is given the presence of ipython in this 
stack trace.


Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/accerciser/plugin/plugin_manager.py", 
line 192, in _enablePlugin
plugin_instance.init()
  File "/usr/share/accerciser/plugins/console.py", line 42, in init
self.ipython_view = ipython_view.IPythonView()
  File "/usr/share/accerciser/plugins/ipython_view.py", line 587, in __init__
IterableIPShell.__init__(self, cout=self.cout, cerr=self.cout,
  File "/usr/share/accerciser/plugins/ipython_view.py", line 111, in __init__
self.IP = IPython.terminal.embed.InteractiveShellEmbed.instance(\
  File "/usr/lib/python3/dist-packages/traitlets/config/configurable.py", line 
510, in instance
inst = cls(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/IPython/terminal/embed.py", line 159, in 
__init__
super(InteractiveShellEmbed,self).__init__(**kw)
  File "/usr/lib/python3/dist-packages/IPython/terminal/interactiveshell.py", 
line 526, in __init__
self.init_prompt_toolkit_cli()
  File "/usr/lib/python3/dist-packages/IPython/terminal/interactiveshell.py", 
line 318, in init_prompt_toolkit_cli
self.pt_app = PromptSession(
  File "/usr/lib/python3/dist-packages/prompt_toolkit/shortcuts/prompt.py", 
line 466, in __init__
self.app = self._create_application(editing_mode, erase_when_done)
  File "/usr/lib/python3/dist-packages/prompt_toolkit/shortcuts/prompt.py", 
line 717, in _create_application
application: Application[_T] = Application(
  File 
"/usr/lib/python3/dist-packages/prompt_toolkit/application/application.py", 
line 271, in __init__
self.output = output or session.output
  File "/usr/lib/python3/dist-packages/prompt_toolkit/application/current.py", 
line 70, in output
self._output = create_output()
  File "/usr/lib/python3/dist-packages/prompt_toolkit/output/defaults.py", line 
74, in create_output
return Vt100_Output.from_pty(
  File "/usr/lib/python3/dist-packages/prompt_toolkit/output/vt100.py", line 
458, in from_pty
fd = stdout.fileno()
io.UnsupportedOperation: fileno

Bug#969363: aptitude: goes to 100%CPU and ram usage skyrocketting when handling dependencies

[ydirson]

Package: aptitude
Version: 0.8.13-2

Starting from a task-desktop-lxde setup, and trying to remove 
xserver-xorg-video-all and
reselecting packages I don't want to go away seems to cause issues to aptitude.

I'm keeping an aptitude bundle for initial state, available on request (not 
sure it makes
sense to attach 500MB here).

>From there:

- select xserver-xorg-video-all for removal, then xserver-xorg-video-amdgpu for 
install
- solve conflicts (marks task-desktop-lxde task-desktop for removal)
- in task-lxde-desktop deps select lxde

Now aptitude quickly reaches 100%CPU and we can watch its memory usage go up.

Bug#968012: sjaakii: variant "judkins" has incomplete FEN, does not load properly in XBoard

[ydirson]

Package: sjaakii
Version: 1.4.1-2
Tags: patch
X-Debbugs-CC: Evert Glebbeek 

This change is necessary to avoid undefined behaviour from XBoard (which in this
cases ignores the last rook, leading to wrong initial position)

--- /tmp/variants.txt   2020-08-06 19:07:29.331235206 +0200
+++ /usr/share/games/sjaakii/variants.txt   2020-08-06 19:08:05.711475456 
+0200
@@ -1052,7 +1052,7 @@
 ##
 Variant: Judkins' Shogi (6x6)
 Board: 6x6
-FEN: "rbnsgk/5p/6/6/P5/KGSNBR"
+FEN: "rbnsgk/5p/6/6/P5/KGSNBR w 0 1"
 XBoard pieces: "PNBR.S...G..+Kpnbr.s...g..+k"
 XBoard parent: "shogi"
 Zone: white_promotion = a5,b5,c5,d5,e5,f5,a6,b6,c6,d6,e6,f6

Bug#966378: gazebo: exits with code 255 attempting to create a joint in model

[ydirson]

Package: gazebo
Version: 11.0.0+dfsg1-4+b3

context: after reading the "beginner:model editor" tutorial while on the move,
I tried to reproduce it from memory: creation of links, but manual positionning
of wheels and then creation of joints.

Then getting back to the tuto I wanted to try the "align links" feature, so I
cancelled my joint creations and some wheel positionning with "undo", moved a
wheel some more manually.

Then I clicked the "create joint" button and the UI bombed out, with this in the
terminal:

$ gazebo
Node::Advertise(): Error advertising topic [/ground_plane/joint_cmd]. Did you 
forget to start the discovery service?
Node::Advertise(): Error advertising topic 
[/ModelPreview_0/link_3_clone/joint_cmd]. Did you forget to start the discovery 
service?
Node::Advertise(): Error advertising topic [/ModelPreview_0/link_3/joint_cmd]. 
Did you forget to start the discovery service?
Node::Advertise(): Error advertising topic 
[/ModelPreview_0/link_3_clone_0/joint_cmd]. Did you forget to start the 
discovery service?
Node::Advertise(): Error advertising topic 
[/ModelPreview_0/link_3_clone_1/joint_cmd]. Did you forget to start the 
discovery service?
Node::Advertise(): Error advertising topic 
[/ModelPreview_0/link_3_clone/joint_cmd]. Did you forget to start the discovery 
service?
Node::Advertise(): Error advertising topic 
[/ModelPreview_0/link_3_clone/joint_cmd]. Did you forget to start the discovery 
service?
Node::Advertise(): Error advertising topic 
[/ModelPreview_0/link_3_clone_0/joint_cmd]. Did you forget to start the 
discovery service?
Node::Advertise(): Error advertising topic 
[/ModelPreview_0/link_3_clone_0/joint_cmd]. Did you forget to start the 
discovery service?
Node::Advertise(): Error advertising topic 
[/ModelPreview_0/link_3_clone_0/joint_cmd]. Did you forget to start the 
discovery service?
Node::Advertise(): Error advertising topic 
[/ModelPreview_0/link_3_clone_1/joint_cmd]. Did you forget to start the 
discovery service?
Node::Advertise(): Error advertising topic 
[/ModelPreview_0/link_3_clone_1/joint_cmd]. Did you forget to start the 
discovery service?
Node::Advertise(): Error advertising topic 
[/ModelPreview_0/link_3_clone/joint_cmd]. Did you forget to start the discovery 
service?
Node::Advertise(): Error advertising topic [/ModelPreview_0/link_3/joint_cmd]. 
Did you forget to start the discovery service?
$ echo $?
255
$

The only non-trivial information Icould find in logs is:

$ cat .gazebo/client-11345/default.log
Gazebo multi-robot simulator, version 11.0.0
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org


(1595859321 302209616) [Msg] Waiting for master.
(1595859321 313861858) [Msg] Connected to gazebo master @ http://127.0.0.1:11345
(1595859321 313892719) [Msg] Publicized address: 10.100.0.1
(1595859321 315079664) [Wrn] [GuiIface.cc:297] Couldn't locate specified .ini. 
Creating file at "/home/yann/.gazebo/gui.ini"
(1595859321 315166142) Loaded .ini file from: "/home/yann/.gazebo/gui.ini"
(1595859322 504761214) [Wrn] [ModelDatabase.cc:212] Unable to connect to model 
database using [http://models.gazebosim.org//database.config]. Only locally 
installed models will be available.
(1595859323 371021704) No spacenav daemon found. Spacenav functionality is 
disabled
(1595859350 124401526) [Wrn] [Publisher.cc:136] Queue limit reached for topic 
/gazebo/default/user_camera/pose, deleting message. This warning is printed 
only once.
(1595859858 594394295) [Wrn] [ModelCreator.cc:2948] Couldn't find top level 
visual for [ModelPreview_0::link_0]. Not selecting in 3D scene.
(1595859862 562385788) [Wrn] [ModelCreator.cc:2948] Couldn't find top level 
visual for [ModelPreview_0::link_0]. Not selecting in 3D scene.
(1595860378 375175810) [Err] [JointControlWidget.cc:393] Error advertising 
topic [/ground_plane/joint_cmd]
(1595860423 124412332) [Err] [JointControlWidget.cc:393] Error advertising 
topic [/ModelPreview_0/link_3_clone/joint_cmd]
(1595860461 619782521) [Err] [JointControlWidget.cc:393] Error advertising 
topic [/ModelPreview_0/link_3/joint_cmd]
(1595860473 15299013) [Err] [JointControlWidget.cc:393] Error advertising topic 
[/ModelPreview_0/link_3_clone_0/joint_cmd]
(1595860482 492269163) [Err] [JointControlWidget.cc:393] Error advertising 
topic [/ModelPreview_0/link_3_clone_1/joint_cmd]
(1595860504 878776990) [Err] [JointControlWidget.cc:393] Error advertising 
topic [/ModelPreview_0/link_3_clone/joint_cmd]
(1595860507 364929069) [Err] [JointControlWidget.cc:393] Error advertising 
topic [/ModelPreview_0/link_3_clone/joint_cmd]
(1595860512 358209615) [Err] [JointControlWidget.cc:393] Error advertising 
topic [/ModelPreview_0/link_3_clone_0/joint_cmd]
(1595860532 480516675) [Err] [JointControlWidget.cc:393] Error advertising 
topic [/ModelPreview_0/link_3_clone_0/joint_cmd]
(1595860537 803114798) [Err] [JointControlWidget.cc:393] Error advertising 
topic [/ModelPreview_0/link_3_clone_0/joint_cmd]

Bug#965153: gscan2pdf: "fails to open device" for Epson NX100

[ydirson]

Package: gscan2pdf
Version: 2.8.0-1, 2.8.1-1
Severity: grave

Except for a couple of times I've been able to get it to work (without knowing
what it was that made it finally work after minutes of battle)...

* when I start gscan2pdf it claims it does not see my scanner and offers to 
rescan
  or continue without
* rescanning sometimes get me back to this window, sometimes to main screen
* from main screen when I click the scan button, I often get the same complaint
* sometimes I get to the scan dialog with "Epson NX100" properly selected, but 
then
  launching the scan it complains that it "first has to open the device" (good 
guess,
  but I'd thought it would do that for me). After which the UI is completely 
unresponsive
  and I have to kill the app

Upgrading to unstable just adds me a "restart gscan2pdf" in the initial failure 
dialog,
but that does not help either.

Downgrading to stable's 2.3.0-1 gets me back a fully working version.

Bug#965022: ITP: apery -- Strong AI for playing Shogi

[ydirson]

> Package: wnpp
> Severity: wishlist
> Owner: Yann Dirson 
> 
> * Package name: apery
>   Version : WCSC28+git20191114
>   Upstream Author : Hiraoka Takuya 
> * URL : https://github.com/HiraokaTakuya/apery
> * License : GPL
>   Programming Lang: C++
>   Description : Strong AI for playing Shogi
> 
> Apery is a strong Shogi AI by today's standards, and was ranked
> 3rd at the 28th World Computer Shogi Championship (2018).
> 
> Relies on MIT-licensed evaluation function.

The evaluation function itself is quite a large thing (850MB), it looks like
a bad idea to include it in the same source package.

Even then, I'd like to check first whether such a near-gigagyte data package
would be allowed into the archive.  It could be worth to package an installer
for that data instead, what do you think ?

Bug#964730: ITP: gpsshogi -- Shogi playing program based on OpenShogiLib

[ydirson]

Hi Paul,

> On Thu, Jul 9, 2020 at 4:18 PM Yann Dirson wrote:
> 
> > This is rather an Intent to Resurrect, as gpsshogi was in Debian
> > 2 releases ago.
> 
> Please note the extra steps needed when reintroducing packages,
> principally reopening the bugs that were closed by the removal of the
> package from Debian.
> 
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs

Thanks for the reminder!

best regards,
-- 
Yann

Bug#964730: ITP: gpsshogi -- Shogi playing program based on OpenShogiLib

[ydirson]

> Package: wnpp
> Severity: wishlist
> Owner: Yann Dirson 
> 
> This is rather an Intent to Resurrect, as gpsshogi was in Debian
> 2 releases ago.
> 
> * Package name: gpsshogi
>   Version : 0.7.0
>   Upstream Author : Team GPS, feat. Daigo Moriwaki 
> * URL : http://gps.tanaka.ecc.u-tokyo.ac.jp/
> * License : BSD

Correction: gpsshogi is GPLv2, only libosl is BSD.

>   Programming Lang: C++
>   Description : Shogi playing program based on OpenShogiLib
> 
>  GPSShogi is a Shogi playing program based on OpenShogiLib and won
>  the 19th
>  World Computer Shogi Championship. This package contains several
>  binaries to
>  play with computer Shogi.
>- gpsshogi: support the CSA protocol
>- gpsusi: support the USI protocol
>- gpsshogi-viewer: GUI application to investigate positions
>- gpsshell: shell-like client to investigate positions
> 

Bug#964414: gnuchess: stdin parsing issues

[ydirson]

Package: gnuchess
Version: 6.2.5-1

Trying to pinpoint a problem I have driving gnuchess from another program, I 
stumbled on this:

$ printf "xboard\n" | gnuchess -x
Chess
*** buffer overflow detected ***: gnuchess terminated
Aborted (core dumped)


$ gdb gnuchess ./core
GNU gdb (Debian 9.2-1) 9.2
...
Reading symbols from gnuchess...  
Reading symbols from 
/usr/lib/debug/.build-id/38/08b38668f2dc7a592f79338e964d9bc2438872.debug...
[New LWP 3348306]
[New LWP 3348307]
[New LWP 3348309]
[New LWP 3348308]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `gnuchess -x'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f7969611740 (LWP 3348306))]
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f796963b55b in __GI_abort () at abort.c:79
#2  0x7f7969694038 in __libc_message (action=, 
fmt=fmt@entry=0x7f79697a0d32 "*** %s ***: %s terminated\n") at 
../sysdeps/posix/libc_fatal.c:181
#3  0x7f7969722d7d in __GI___fortify_fail_abort 
(need_backtrace=need_backtrace@entry=true, msg=msg@entry=0x7f79697a0cbe "buffer 
overflow detected") at fortify_fail.c:28
#4  0x7f7969722db1 in __GI___fortify_fail (msg=msg@entry=0x7f79697a0cbe 
"buffer overflow detected") at fortify_fail.c:44
#5  0x7f7969721750 in __GI___chk_fail () at chk_fail.c:28
#6  0x7f7969720f85 in __stpcpy_chk (dest=0x55e45e4678a0  "", 
src=src@entry=0x7ffe62215000 
"xboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboa"...,
 destlen=destlen@entry=4096) at stpcpy_chk.c:31
#7  0x55e45e16aa25 in strcat (
__src=0x7ffe62215000 
"xboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboard\nxboa"...,
 __dest=0x55e45e4678a0  "") at 
/usr/include/x86_64-linux-gnu/bits/string3.h:148
#8  ReadFromUser () at engine.cc:189
#9  0x55e45e15d907 in main (argc=, argv=) at 
main.cc:513



Note that the binary we shipped in jessie, when run on current testing, 
perfectly reacts to
even:

$ printf "xboard\nprotover 2\n" | /srv/chroot/jessie/usr/games/gnuchess -x
Chess
TimeLimit[0] = 0
TimeLimit[1] = 0
TimeLimit[0] = 0
TimeLimit[1] = 0
feature done=0
feature analyze=1
feature colors=0
feature draw=1
feature ics=1
feature myname="GNU Chess"
feature name=1
feature pause=0
feature ping=1
feature playother=1
feature reuse=1
feature san=0
feature setboard=1
feature sigint=0
feature sigterm=0
feature time=1
feature usermove=1
feature variants="normal"
feature done=1
^C


Could it have any link with #936023 ?

Bug#936023: CVE-2019-15767: fixed in latest upstream ?

[ydirson]

Given the comment on the upstream ml, this bug is likely fixed in latest
release.

Bug#963983: closed by Gianfranco Costamagna (Re: python3-pyside2.qtsvg: segfault on import)

[ydirson]

reopen 963983
thanks

The other pyside2 packages (code, gui etc) were still at 5.15.0-1~exp1.

If I just update qtsvg to 5.15.0-2 the segfault still happens.

Update the rest of pyside2 triggers a huge cascading of upgrades to Qt 5.14
which had not been done when I had installed the exp packages, and when I
updated qtsvg initially.

Among them:

 Unpacking libqt5svg5:amd64 (5.14.2-2) over (5.12.5-2) ...

With all this upgraded, I confirm there is no segfault any more.

Thus, the problem is likely caused by an undeclared versioned dependency on an
underlying lib, and libqt5svg5 looks like a good candidate.  

Not dealing with it is likely to lead to other insufficient partial updates.

Bug#963983: python3-pyside2.qtsvg: segfault on import

[ydirson]

Package: python3-pyside2.qtsvg
Version: 5.15.0-1
Severity: grave

$ gdb python3
...
Reading symbols from python3...
Reading symbols from 
/usr/lib/debug/.build-id/97/0f19629d98e5c631b44f6803fa34a5a07c3806.debug...

(gdb) r
Starting program: /usr/bin/python3 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Python 3.8.3 (default, May 14 2020, 11:03:12) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> from PySide2 import QtSvg
Program received signal SIGSEGV, Segmentation fault.
0x772cf2eb in Shiboken::ObjectType::introduceWrapperType(_object*, char 
const*, char const*, PyType_Spec*, char const**, void (*)(void*), 
SbkObjectType*, _object*, unsigned int) ()
   from 
/usr/lib/x86_64-linux-gnu/libshiboken2.cpython-38-x86_64-linux-gnu.so.5.15

(gdb) bt
#0  0x772cf2eb in Shiboken::ObjectType::introduceWrapperType(_object*, 
char const*, char const*, PyType_Spec*, char const**, void (*)(void*), 
SbkObjectType*, _object*, unsigned int)
() from 
/usr/lib/x86_64-linux-gnu/libshiboken2.cpython-38-x86_64-linux-gnu.so.5.15
#1  0x7731ec41 in ?? () from 
/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so
#2  0x7732a6a3 in PyInit_QtSvg () from 
/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so
#3  0x0067d0aa in _PyImport_LoadDynamicModuleWithSpec (
spec=, 
origin='/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so',
 loader_state=None, submodule_search_locations=None, _set_fileattr=True, 
_cached=None) at remote 0x7760d1f0>, fp=) at 
../Python/importdl.c:164
#4  0x0067dafd in _imp_create_dynamic_impl (module=, 
file=, 
spec=, 
origin='/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so',
 loader_state=None, submodule_search_locations=None, _set_fileattr=True, 
_cached=None) at remote 0x7760d1f0>) at ../Python/import.c:2221
#5  _imp_create_dynamic (module=, args=, 
nargs=) at ../Python/clinic/import.c.h:330
#6  0x005c066c in cfunction_vectorcall_FASTCALL (func=, args=, nargsf=, 
kwnames=) at ../Objects/methodobject.c:422
#7  0x005f1da9 in PyVectorcall_Call (callable=, tuple=, kwargs={}) at ../Objects/call.c:199
#8  0x0056d160 in do_call_core (kwdict={}, 
callargs=(, 
origin='/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so',
 loader_state=None, submodule_search_locations=None, _set_fileattr=True, 
_cached=None) at remote 0x7760d1f0>,), func=, tstate=) at 
../Python/ceval.c:4983
#9  _PyEval_EvalFrameDefault (f=, throwflag=) at 
../Python/ceval.c:3559
#10 0x00565602 in PyEval_EvalFrameEx (throwflag=0, 
f=Frame 0x77677610, for file , line 219, 
in _call_with_frames_removed (f=, args=(, 
origin='/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so',
 loader_state=None, submodule_search_locations=None, _set_fileattr=True, 
_cached=None) at remote 0x7760d1f0>,), kwds={})) at ../Python/ceval.c:741
#11 _PyEval_EvalCodeWithName (_co=, globals=, 
locals=, args=, argcount=, 
kwnames=, 
kwargs=0x776de7e0, kwcount=, kwstep=1, defs=0x0, 
defcount=0, kwdefs=0x0, closure=0x0, name='_call_with_frames_removed', 
qualname='_call_with_frames_removed')
at ../Python/ceval.c:4298
#12 0x005f12a3 in _PyFunction_Vectorcall (func=, 
stack=0x776de7d0, nargsf=, kwnames=) at 
../Objects/call.c:435
#13 0x0056c1bf in _PyObject_Vectorcall (kwnames=0x0, nargsf=, args=0x776de7d0, callable=) at 
../Include/cpython/abstract.h:127
#14 call_function (kwnames=0x0, oparg=, pp_stack=, tstate=0x959e20) at ../Python/ceval.c:4963
#15 _PyEval_EvalFrameDefault (f=, throwflag=) at 
../Python/ceval.c:3469
#16 0x005f10c6 in PyEval_EvalFrameEx (throwflag=0, 
f=Frame 0x776de640, for file , 
line 1357, in create_module (self=, spec=, 
origin='/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so',
 loader_state=None, submodule_search_locations=None, _set_fileattr=True, 
_cached=None) at remote 0x7760d1f0>)) at ../Python/ceval.c:741
#17 function_code_fastcall (globals=, nargs=, 
args=, co=) at ../Objects/call.c:283
#18 _PyFunction_Vectorcall (func=, stack=, 
nargsf=, kwnames=) at ../Objects/call.c:410
#19 0x005674c7 in _PyObject_Vectorcall (kwnames=0x0, nargsf=, args=0x777b2a30, callable=) at 
../Include/cpython/abstract.h:127
#20 call_function (kwnames=0x0, oparg=, pp_stack=, tstate=0x959e20) at ../Python/ceval.c:4963
#21 _PyEval_EvalFrameDefault (f=, throwflag=) at 
../Python/ceval.c:3486
#22 0x005f10c6 in PyEval_EvalFrameEx (throwflag=0, 
f=Frame 0x777b28b0, for file , line 556, 
in module_from_spec (spec=, 
origin='/usr/lib/python3/dist-packages/PySide2/QtSvg.cpython-38-x86_64-linux-gnu.so',
 loader_state=None, submodule_search_locations=None, _set_fileattr=True, 
_cached=None) 

Bug#952645: webext-ublock-origin: any reason we still have a 6-month old version ?

[ydirson]

Hi Markus,

> There is also little value in filing pointless bug reports against
> Debian packages.

Sorry, I did not meant any offense in this followup to an old bugreport.
It used to be that firefox allowed user to
locally install a newer version of a system-wide-installed extension, but this
is apparently not the case, and I could only get install a newer version by
uninstalling the deb.  You'll understand I found the situation as quite
self-disserving for the package.

> As a Debian developer you should check tracker.debian.org or NEW.
> 
> https://ftp-master.debian.org/new/ublock-origin_1.25.0+dfsg-1.html

Wouldn't the "pending" tag be suitable for this bugreport ?
Apparently there is no auto-tagged when fixes enter the NEW queue,
I though it was the case.

Best regards,
-- 
Yann

Bug#952645: webext-ublock-origin: any reason we still have a 6-month old version ?

[ydirson]

IMHO there's little value on having such a plugin packaged, if
we cannot follow the releases.

Bug#963011: scalene: please re-upload as source-only

[ydirson]

Package: python3-scalene
Version: 0.7.5-1

The package has not migrated to testing and 
https://tracker.debian.org/pkg/scalene shows
why:

 Not built on buildd: arch all binaries uploaded by sergi...@sergiodj.net, a 
new source-only upload is needed to allow migration

Bug#961593: emacs: help menu entries that require non-free info file should tell what to do

[ydirson]

Package: emacs
Version: 1:26.3+1-2

Default installation of emacs package does not include the info manual, as
they are in emacs-common-non-dfsg.

A user selecting help menu entries "read the emacs manual", "how to report a 
bug"
and such are given the info index window, and may miss easily the "info file 
emacs does
not exist" message in minibuffer, especially as it disappears on first event.

Even if a user does see the message:
* it is not that easy to parse for a common user, adding quotes around missing
  filename-without-its-extension would help
* finding out what the missing package is not that trivial

It is not useful to show the info index at all in such cases, and replacing
it with a debian-specific error buffer telling which package to install.

Maybe even using this space to explain the reason for the split would be good.

Bug#942596: [DRE-maint] Bug#942596: jekyll and required bundles

[ydirson]

Hi Daniel,


> > I finally understood what confused me at first: even with
> > --skip-bundle,
> > "jekyll new" creates a Gemfile.  And until this Gemfile is removed,
> > "jekyll build" will try to go the bundle way all by itself.
> 
> That is not true. As I explained earlier I'm using jekyll myself and
> bundler
> doesn't run at all. And you need Gemfile to list and load the plugins
> you need.
>
> I don't really see a nice route with this for packaging: just
> documenting
> > the fact and add a user notice in "jekyll new" that the package
> > won't work
> > until the file is removed feels awkward.
> >
> > OTOH, doesn't it feel awkward as well that just having Gemfile
> > present
> > causes the system binary to do what looks like a "bundle exec" ?
> >   Again
> > I'm too noob with ruby to say for sure, but that sure confused me.
> 
> What you describe really doesn't sound right. I really think the
> issue is not
> jekyll nor bundler but somewhere in your setup.
> 
> What I suspect is that you have dependencies in Gemfile which you
> have not yet
> installed via Debian package management. If all dependencies of your
> site are
> installed, then bundler won't do anything.

Before posting this I had done the following test, this may clarify what
I'm talking about:

tmp$ jekyll new --skip-bundle foo
New jekyll site installed in /tmp/foo. 
Bundle install skipped. 

tmp$ cd foo

foo$ ls
404.html  about.md  _config.yml  Gemfile  index.md  _posts

foo$ jekyll build
Traceback (most recent call last):
13: from /usr/bin/jekyll:9:in `'
12: from /usr/lib/ruby/vendor_ruby/jekyll/plugin_manager.rb:50:in 
`require_from_bundler'
11: from /usr/lib/ruby/2.7.0/bundler.rb:149:in `setup'
10: from /usr/lib/ruby/2.7.0/bundler/runtime.rb:20:in `setup'
 9: from /usr/lib/ruby/2.7.0/bundler/runtime.rb:101:in `block in 
definition_method'
 8: from /usr/lib/ruby/2.7.0/bundler/definition.rb:226:in 
`requested_specs'
 7: from /usr/lib/ruby/2.7.0/bundler/definition.rb:237:in `specs_for'
 6: from /usr/lib/ruby/2.7.0/bundler/definition.rb:170:in `specs'
 5: from /usr/lib/ruby/2.7.0/bundler/definition.rb:258:in `resolve'
 4: from /usr/lib/ruby/2.7.0/bundler/resolver.rb:22:in `resolve'
 3: from /usr/lib/ruby/2.7.0/bundler/resolver.rb:49:in `start'
 2: from /usr/lib/ruby/2.7.0/bundler/resolver.rb:258:in 
`verify_gemfile_dependencies_are_found!'
 1: from /usr/lib/ruby/2.7.0/bundler/resolver.rb:258:in `each'
/usr/lib/ruby/2.7.0/bundler/resolver.rb:290:in `block in 
verify_gemfile_dependencies_are_found!': Could not find gem 'jekyll (~> 3.8.6)' 
in any of the gem sources listed in your Gemfile.(Bundler::GemNotFound)
foo$ 

Best regards,
-- 
Yann

Bug#942596: [DRE-maint] Bug#942596: jekyll and required bundles

[ydirson]

Hi Daniel,

- Mail original -
> 1) Use the Debian package management and don't use bunlder at all
> (jekyll new
> --skip-bundle). All the Jekyll plugins have been packaged and most of
> them can
> be found in stable-backports. If you are missing some please let me
> know. Just
> add the plugins you need to Gemfile and _config.yml, run jekyll, and
> that
> should be it. In case of a missing theme (I just packaged the minima
> theme) one
> can use the ruby-jekyll-remote-theme package (and the plugin inside)
> to avoid
> bundler.

That one works fine indeed, both with ruby 2.5 and 2.7 (2.7 issues
language warnings that were apparently handled in 4.0.0, but they're
just warnings).

I finally understood what confused me at first: even with --skip-bundle,
"jekyll new" creates a Gemfile.  And until this Gemfile is removed,
"jekyll build" will try to go the bundle way all by itself.

I don't really see a nice route with this for packaging: just documenting
the fact and add a user notice in "jekyll new" that the package won't work
until the file is removed feels awkward.

OTOH, doesn't it feel awkward as well that just having Gemfile present
causes the system binary to do what looks like a "bundle exec" ?   Again
I'm too noob with ruby to say for sure, but that sure confused me.

Best regards,
-- 
Yann

Bug#795421: version 5.01 freezes on test #7 in SMP mode

[ydirson]

There is a rumor of an incoming upstream version including most
of the patches that appeared since the last one.  I'd rather
wait for that one :)

- Mail original -
> De: "Christoph Anton Mitterer" 
> À: 795...@bugs.debian.org
> Cc: dir...@debian.org
> Envoyé: Mercredi 22 Avril 2020 22:52:28
> Objet: Bug#795421: version 5.01 freezes on test #7 in SMP mode
> 
> Hey.
> 
> Anything new on merging this patch?
> 
> 
> Cheers,
> Chris.
> 

Bug#942596: [DRE-maint] Bug#942596: jekyll and required bundles

[ydirson]

Hi Daniel,

- Mail original -
> De: "Daniel Leidert" 
> À: ydir...@free.fr, 942...@bugs.debian.org
> Envoyé: Lundi 20 Avril 2020 16:19:17
> Objet: Re: [DRE-maint] Bug#942596: jekyll and required bundles
> 
> Am Sonntag, den 19.04.2020, 18:28 +0200 schrieb ydir...@free.fr:
> > Trying Jekyll for the first time, I get hit by the same issue.
> > 
> > Indeed this flag is a good start, but afterwards:
> > 
> > 1. we have to gather we should change the Gemfile to use:
> > 
> >  source "file:///usr/lib/ruby/vendor_ruby"
> 
> Why? You have three choices:
> 
> 1) Use the Debian package management and don't use bunlder at all
> (jekyll new
> --skip-bundle). All the Jekyll plugins have been packaged and most of
> them can
> be found in stable-backports. If you are missing some please let me
> know. Just
> add the plugins you need to Gemfile and _config.yml, run jekyll, and
> that
> should be it. In case of a missing theme (I just packaged the minima
> theme) one
> can use the ruby-jekyll-remote-theme package (and the plugin inside)
> to avoid
> bundler.

This is definitely the best way to go - for now I've gone the bundle route,
but having to wait nearly 5 minutes to get a 2-pages sites to format on
gitlab-ci, mostly for "bundle install" is just insane.  A bullseye docker
image with the proper packages will be much better, I won't need any
buster backports myself.

The minima theme is OK for me, but as an asciidoc junky I feel the lack
of jekyll-asciidoc.

Oh, and https://ydirson.gitlab.io/the-floss-cook/ went live yesterday,
looking forward to switching from bundler to bullseye :)

Thanks for your work!
-- 
Yann

Bug#942596: jekyll and required bundles

[ydirson]

I could finally install the dependencies with the default Gemfile,
by downgrading ruby from 2.7 back to 2.5.  Looks like eventmachine
does not have support for 2.7 yet (hint given by the ruby-eventmachine
package in experimental, which still uses 2.5).

"bundle exec jekyll build" now works.  Good luck getting everything
to work out of the box, I hope you'll get around to it :)

Best regards,
-- 
Yann

> 
> Trying Jekyll for the first time, I get hit by the same issue.
> 
> Indeed this flag is a good start, but afterwards:
> 
> 1. we have to gather we should change the Gemfile to use:
> 
>  source "file:///usr/lib/ruby/vendor_ruby"
> 
> 2. we get hit by missing bundles, that should surely be added as
> Recommends:
> (and it is a bit painful, as I'm testing using "bundle outdated"
> which only
> complains one missing package at a time).  I could install the
> following:
> 
> * jekyll-theme-minima
> * ruby-tzinfo
> 
> But then the following gem is missing, and apparently not available
> in Debian:
> 
> * tzinfo-data
> 
> I tried to remove it from the Gemfile, and the next problem is:
> 
>  Could not find gem 'jekyll (~> 3.8.6)' in any of the gem sources
>  listed in your Gemfile.
> 
> ... which is quite unfortunate, as obviously the Debian package is
> installed.
> 
> 
> So it seems we cannot make use of full-local gems yet.  But back to
> the https source,
> the install also fails to complete:
> 
> $ bundle install --path vendor/bundle
> [DEPRECATED] The `--path` flag is deprecated because it relies on
> being remembered across bundler invocations, which bundler will no
> longer do in future versions. Instead please use `bundle config set
> path 'vendor/bundle'`, and stop using this flag
> Fetching gem metadata from https://rubygems.org/...
> Fetching gem metadata from https://rubygems.org/.
> Resolving dependencies...
> Fetching public_suffix 4.0.4
> Installing public_suffix 4.0.4
> Fetching addressable 2.7.0
> Installing addressable 2.7.0
> Using bundler 2.1.4
> Fetching colorator 1.1.0
> Installing colorator 1.1.0
> Fetching concurrent-ruby 1.1.6
> Installing concurrent-ruby 1.1.6
> Fetching eventmachine 1.2.7
> Installing eventmachine 1.2.7 with native extensions
> Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
> 
> current directory:
> 
> /home/yann/perso/blog/bar/vendor/bundle/ruby/2.7.0/gems/eventmachine-1.2.7/ext
> /usr/bin/ruby2.7 -I /usr/lib/ruby/2.7.0 -r
> ./siteconf20200419-2300959-b7mzat.rb extconf.rb
> mkmf.rb can't find header files for ruby at
> /usr/lib/ruby/include/ruby.h
> 
> You might have to install separate package for the ruby development
> environment, ruby-dev or ruby-devel for example.
> 
> extconf failed, exit code 1
> 
> Gem files will remain installed in
> /home/yann/perso/blog/bar/vendor/bundle/ruby/2.7.0/gems/eventmachine-1.2.7
> for inspection.
> Results logged to
> /home/yann/perso/blog/bar/vendor/bundle/ruby/2.7.0/extensions/x86_64-linux/2.7.0/eventmachine-1.2.7/gem_make.out
> 
> An error occurred while installing eventmachine (1.2.7), and Bundler
> cannot continue.
> Make sure that `gem install eventmachine -v '1.2.7' --source
> 'https://rubygems.org/'` succeeds before bundling.
> 
> In Gemfile:
>   minima was resolved to 2.5.1, which depends on
> jekyll-feed was resolved to 0.13.0, which depends on
>   jekyll was resolved to 3.8.6, which depends on
> em-websocket was resolved to 0.5.1, which depends on
>   eventmachine
> 
> 
> 
> Now it I want to take the hint and use `gem install eventmachine -v
> '1.2.7' --source 'https://rubygems.org/'`, after following
> the recommendation to do `bundle config set path 'vendor/bundle'`,
> that just seems to ignore the setting:
> 
> $ gem install eventmachine -v '1.2.7' --source
> 'https://rubygems.org/'
> ERROR:  While executing gem ... (Gem::FilePermissionError)
> You don't have write permissions for the /var/lib/gems/2.7.0
> directory.
> 
> ... and it looks like `--source` and `--path` are incompatible
> anyway, if I use both, whatever the order, the second option
> is reported as "Unknown switches"
> 
> 
> Being quite a stranger to ruby things (which is usually a good
> starting point for validating a user documentation ;),
> all this is extremely confusing :)
> 
> 
> For a start, you could include a step-by-step instruction sheet to
> make use of jekyll in Debian.
> 
> 
> Best regards,
> --
> Yann
> 

Bug#942596: jekyll and required bundles

[ydirson]

Trying Jekyll for the first time, I get hit by the same issue.

Indeed this flag is a good start, but afterwards:

1. we have to gather we should change the Gemfile to use:

 source "file:///usr/lib/ruby/vendor_ruby"

2. we get hit by missing bundles, that should surely be added as Recommends:
(and it is a bit painful, as I'm testing using "bundle outdated" which only
complains one missing package at a time).  I could install the following:

* jekyll-theme-minima
* ruby-tzinfo

But then the following gem is missing, and apparently not available in Debian:

* tzinfo-data

I tried to remove it from the Gemfile, and the next problem is:

 Could not find gem 'jekyll (~> 3.8.6)' in any of the gem sources listed in 
your Gemfile.

... which is quite unfortunate, as obviously the Debian package is installed.


So it seems we cannot make use of full-local gems yet.  But back to the https 
source,
the install also fails to complete:

$ bundle install --path vendor/bundle
[DEPRECATED] The `--path` flag is deprecated because it relies on being 
remembered across bundler invocations, which bundler will no longer do in 
future versions. Instead please use `bundle config set path 'vendor/bundle'`, 
and stop using this flag
Fetching gem metadata from https://rubygems.org/...
Fetching gem metadata from https://rubygems.org/.
Resolving dependencies...
Fetching public_suffix 4.0.4
Installing public_suffix 4.0.4
Fetching addressable 2.7.0
Installing addressable 2.7.0
Using bundler 2.1.4
Fetching colorator 1.1.0
Installing colorator 1.1.0
Fetching concurrent-ruby 1.1.6
Installing concurrent-ruby 1.1.6
Fetching eventmachine 1.2.7
Installing eventmachine 1.2.7 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

current directory: 
/home/yann/perso/blog/bar/vendor/bundle/ruby/2.7.0/gems/eventmachine-1.2.7/ext
/usr/bin/ruby2.7 -I /usr/lib/ruby/2.7.0 -r ./siteconf20200419-2300959-b7mzat.rb 
extconf.rb
mkmf.rb can't find header files for ruby at /usr/lib/ruby/include/ruby.h

You might have to install separate package for the ruby development
environment, ruby-dev or ruby-devel for example.

extconf failed, exit code 1

Gem files will remain installed in 
/home/yann/perso/blog/bar/vendor/bundle/ruby/2.7.0/gems/eventmachine-1.2.7 for 
inspection.
Results logged to 
/home/yann/perso/blog/bar/vendor/bundle/ruby/2.7.0/extensions/x86_64-linux/2.7.0/eventmachine-1.2.7/gem_make.out

An error occurred while installing eventmachine (1.2.7), and Bundler cannot 
continue.
Make sure that `gem install eventmachine -v '1.2.7' --source 
'https://rubygems.org/'` succeeds before bundling.

In Gemfile:
  minima was resolved to 2.5.1, which depends on
jekyll-feed was resolved to 0.13.0, which depends on
  jekyll was resolved to 3.8.6, which depends on
em-websocket was resolved to 0.5.1, which depends on
  eventmachine



Now it I want to take the hint and use `gem install eventmachine -v '1.2.7' 
--source 'https://rubygems.org/'`, after following
the recommendation to do `bundle config set path 'vendor/bundle'`, that just 
seems to ignore the setting:

$ gem install eventmachine -v '1.2.7' --source 'https://rubygems.org/'
ERROR:  While executing gem ... (Gem::FilePermissionError)
You don't have write permissions for the /var/lib/gems/2.7.0 directory.

... and it looks like `--source` and `--path` are incompatible anyway, if I use 
both, whatever the order, the second option
is reported as "Unknown switches"


Being quite a stranger to ruby things (which is usually a good starting point 
for validating a user documentation ;),
all this is extremely confusing :)


For a start, you could include a step-by-step instruction sheet to make use of 
jekyll in Debian.


Best regards,
-- 
Yann

Bug#955588: keepassx: description says "install keepassx instead"

[ydirson]

Package: keepassx
Version: 2.0.3+git20190121.1682ab9-2.1+b1

The description explain that keepassxc is better than keepassx, but still says
"install keepassx instead".  It is highly confusing :)

Bug#954660: libsdl2: upstream 2.0.12 released

[ydirson]

Package: libsdl2
Version: 2.0.10+dfsg1-2
Severity: wishlist

See https://discourse.libsdl.org/t/sdl-2-0-12-released/27318

Bug#953154: lxqt-panel: huge memory leak

[ydirson]

Package: lxqt-panel
Version: 0.14.1-1+b1

After ~2 month uptime of a single session, resident memory usage is growing 
unreasonably.
A couple of days ago it was 1.5GB already, and today:

# top
[...]
2548446 yann  20   0 3205080   2.6g  12808 S   0.7  17.0  57:09.15 
lxqt-panel  
   
2548457 yann  20   0 1346568 994.4m   3636 S   0.0   6.2   1:04.22 
lxqt-runner 
   

Bug#921220: xchat stops autoconnecting, complaining about "%U" and "host unknown", broken .desktop entry ?

[ydirson]

The control email got bounced before unarchiving, here are the details of new 
findings. 

- Mail original -

> unarchive 921220
> reopen 921220
> retitle 921220 xchat.desktop makes invalid use of %U, breaks at least
> lxqt and flwm
> affects 921220 + lxqt flwm
> severity 921220 grave
> thanks

> I've switched away from lxqt and forgot to follow up on this issue,
> but now I'm stumbling on a configure error of flwm,
> which qualifies as grave under the "breaks other package" rule.

> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Setting up flwm (1.02+git2015.10.03+7dbb30-6) ...
> Exec key for 'XChat IRC' contains '%F', '%U' or '%D' at the wrong
> place
> dpkg: error processing package flwm (--configure):
> installed flwm package post-installation script subprocess returned
> error exit status 255
> Errors were encountered while processing:
> flwm

> Note that the freedesktop standard [1] says "Field codes must not be
> used inside a quoted argument, the result of field code expansion
> inside a
> quoted argument is undefined", this could possibly be the reason for
> any complaint.

> If I replace the faulty line by just "Exec=xchat --existing --url %U"
> the flwm configure step does succeed, which seems to confirm this
> diagnostic.

> Probably the better solution would be to use a wrapper script, which
> could have saner behaviour (the current behaviour lauches "exec
> xchat"
> on any error of the first try, where it looks like what we really
> want is to launch it if %U is empty.

> https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html

> - Mail original -

> > De: "Gianfranco Costamagna" 
> 
> > À: ydir...@free.fr, 921220-d...@bugs.debian.org
> 
> > Envoyé: Mardi 5 Février 2019 11:13:35
> 
> > Objet: Re: Bug#921220: xchat stops autoconnecting, complaining
> > about
> > "%U" and "host unknown", broken .desktop entry ?
> 

> > Hello,
> 

> > >OTOH when launched from cmdline the problem does not appear.
> 

> > >
> 

> > >And indeed the provided .desktop file shows:
> 

> > >
> 

> > >Exec=sh -c "xchat --existing --url %U || exec xchat"
> 

> > >
> 

> > >Could it be that there was a fix in a recently-dropped patch ?
> 

> > I didn't drop any patch (you didn't even tell me which was your
> > previous version, so its difficult to say)
> 
> > but looks like a network error to me
> 
> I guess at that time I made assumptions on not-so-recent "Drop old
> and useless patch" changelog entry, my bad.

Bug#943752: Needs GCC-6

[ydirson]

> A further information I received via IRC is that memtest86+
> _has_ to be compiled with GCC-6 - newer versions have a bug
> that break memtest86+.
> 
> I have verified that GCC-6 gives a working result,
> while GCC-8 doesn't.

Now that is a major issue, as gcc-6 was not even released with buster, we only 
have
7, 8 and 9 on hand now.

Bug#943752: memtest86+: Please switch source tree

[ydirson]

> Upstream memtest86+ is broken - and there are a few patches that
> aren't
> even included.
> 
> I'd recommend to switch over to
> 
>  $ git clone https://review.coreboot.org/memtest86plus
> 
> as that seems maintained, and will even work on my machine
> (and not just hang, like upstream).
> 
> 
> Base page is at
> 
>  https://www.coreboot.org/Memtest86%2B

Thanks, I'll look into this!

Bug#939754: not found in stable

[ydirson]

notfound 939754 2.10.8-2
thanks

Downgrading to the build currently in buster works around the crash.

Bug#563000: closed by Debian FTP Masters (Bug#935854: Removed package(s) from unstable)

[ydirson]

reopen 563000
found 563000 2.2.2-2
thanks

Still happens today:

Omaha/Holders/.#HexBoard.py:1:0: F0010: error while code parsing: Unable to 
load file Omaha/Holders/.#HexBoard.py:
[Errno 2] No such file or directory: 'Omaha/Holders/.#HexBoard.py' (parse-error)


- Mail original -
> De: "Debian Bug Tracking System" 
> À: ydir...@free.fr
> Envoyé: Mardi 27 Août 2019 03:06:51
> Objet: Bug#563000 closed by Debian FTP Masters 
>  (Bug#935854: Removed package(s) from
> unstable)
> 
> This is an automatic notification regarding your Bug report
> which was filed against the pylint package:
> 
> #563000: pylint: wrongly tries to open emacs locks
> 
> It has been closed by Debian FTP Masters
> .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP
> Masters  by
> replying to this email.
> 
> 
> --
> 563000: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563000
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> 

Bug#695873: memtest86+: Serial console does not work

[ydirson]

Hi,

Feel free do NMU - thanks much for this :)

- Mail original -
> De: "Louis-Philippe Véronneau" 
> À: 695...@bugs.debian.org
> Envoyé: Mardi 13 Août 2019 21:44:38
> Objet: Bug#695873: memtest86+: Serial console does not work
> 
> Hello!
> 
> I'd be happy to make an NMU to fix this, since:
> 
> * there is a patch
> * the patch was tested by 4 people and it seems to work
> * the patch looks trivial
> * the patch has been merged in Fedora [1]
> 
> I've emailed the maintainer directly to ask him if it would be OK
> with
> him for me to NMU this.
> 
> If I don't get an answer I'll look into fixing this by an NMU :)
> 
> Cheers,
> 
> [1]
> https://src.fedoraproject.org/rpms/memtest86+/blob/master/f/memtest86+-5.01-serial-console-fix.patch
> 
> --
>   ⢀⣴⠾⠻⢶⣦⠀
>   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
>   ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
>   ⠈⠳⣄
> 
> 

Bug#934265: qtbase5-dev: different archs ship different version of Qt-logo.png

[ydirson]

Package: qtbase5-dev
Version: 5.11.3+dfsg1-2+b1
Severity: serious

Unpacking qtbase5-dev:i386 (5.11.3+dfsg1-2+b1) over (5.11.3+dfsg1-2) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-01jgzV/14-qtbase5-dev_5.11.3+dfsg1-2+b1_i386.deb 
(--unpack):
 trying to overwrite shared 
'/usr/share/qt5/doc/global/template/images/Qt-logo.png', which is different 
from other instances of package qtbase5-dev:i386
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

Bug#927010: python3-babeltrace: Event instances all refer to a constantly-overwritten data - unexpected behaviours and segfaults

[ydirson]

Package: python3-babeltrace
Version: 1.5.6-2
Severity: important

While investigating why I was getting a segfault while processing a CTF trace 
(in which I
do a first pass extracting some info, before a second pass plotting the data...
while keeping a ref to various events to avoid making copies of everything in
the first pass), I finally understand that even though we get individual python 
handles
for all events, they get clobbered by further event parsing.


This script:

->8--
#!/usr/bin/env python3
import babeltrace
import sys

trace_collection = babeltrace.TraceCollection()
trace_collection.add_traces_recursive(sys.argv[1], 'ctf')

mylist = []
for event in trace_collection.events:
print(event, event.timestamp)
mylist.append(event)

print("")

for event in mylist:
print(event, event.timestamp)
->8--

shows:

 1555157078087460409
 1555157078447798861
 1555157079242934356
...
 1555157103166619955
 1555157103183287540
 1555157103200021333

 1555157103200021333
 1555157103200021333
 1555157103200021333
...
 1555157103200021333
 1555157103200021333
 1555157103200021333



Something feels Just Wrong here, and I somehow feel it could be linked to my 
script seeing, while
attempting to access fields of Event objects after keeping a ref to them:

=
$ gdb --args python3 ../scripts/graph-lttstats.py .../ust/
(gdb) r
...

Program received signal SIGSEGV, Segmentation fault.
bt_ctf_get_top_level_scope (ctf_event=ctf_event@entry=0xa64188, 
scope=BT_EVENT_FIELDS) at events.c:89
89  events.c: No such file or directory.
(gdb) directory /home/yann/soft/babeltrace/babeltrace-1.5.6/formats/ctf
Source directories searched: 
/home/yann/soft/babeltrace/babeltrace-1.5.6/formats/ctf:$cdir:$cwd
(gdb) l
84  case BT_EVENT_CONTEXT:
85  if (event->event_context)
86  tmp = >event_context->p;
87  break;
88  case BT_EVENT_FIELDS:
89  if (event->event_fields)
90  tmp = >event_fields->p;
91  break;
92  }
93  return tmp;
(gdb) p event
$1 = (const struct ctf_event_definition *) 0x5f2f64616f6c6e79
(gdb) p* ctf_event
$2 = {parent = 0x5f2f64616f6c6e79}
(gdb) p* ctf_event->parent
Cannot access memory at address 0x5f2f64616f6c6e79
=

Bug#921220: xchat stops autoconnecting, complaining about "%U" and "host unknown", broken .desktop entry ?

[ydirson]

Package: xchat
Version: 2.8.8-17

xchat when launched from lxqt menu does not autoconnect any more, showing only 
the following.

 Python interface loaded
 Tcl plugin for XChat - Version 1.64 
 Copyright 2002-2005 Daniel P. Stasinski
 http://www.scriptkitties.com/tclplugin/
 Tcl interface loaded
 Perl interface loaded
* Recherche de %U
* Hôte inconnu. Peut-être avez vous fait une faute de frappe ?


OTOH when launched from cmdline the problem does not appear.

And indeed the provided .desktop file shows:

 Exec=sh -c "xchat --existing --url %U || exec xchat"

Could it be that there was a fix in a recently-dropped patch ?

Bug#916200: script: does not reap signaled children any more, deadlocks until SIGKILL

[ydirson]

Package: bsdutils
Version: 1:2.32.1-0.1
Severity: important

Since upgrade from stretch to buster, script does not terminate any more when 
the monitored process
gets killed.  The child is left as a zombie, and when sent SITERM or SIGQUIT 
script only prints
"Session terminated." and does not exit.  Only SIGKILL was able to get rid of 
it.

24263 pts/5S+ 0:00  |   |   |   \_ 
script -c vi /etc/passwd
24264 ?Zs 0:00  |   |   |   
\_ [vi] 

Downgrading to stretch's 1:2.29.2-1+deb9u1 gets back to proper behaviour.

Bug#915313: packages-arch-specific: please blacklist cssc on mips

[ydirson]

Package: buildd.debian.org

Presumably following gcc upgrade, package cssc does not build correctly any 
more on mips
(as well as a couple of non-release archs).

Until someone can take the time to dive into this, could you please blacklist 
it from mips,
so that it does not prevent it to be included in buster for other archs ?

Bug#915310: developer-reference: broken link to anonscm.debian.org

[ydirson]

Package: developer-reference
Version: 3.4.18

We have a broken link in current master branch.  It also impacts stretch (hence 
my selection of version).

developers-reference (master=)$ git grep anonscm.debian.org
common.ent:https://anonscm.debian.org/cgit/mirror/packages-arch-specific.git/tree/Packages-arch-specific;>

Bug#905674: proper severity

[ydirson]

Adam wrote:
> Note that parallel's functionality is also provided by moreutils and xargs
> -P, thus moving the package out of main would be just an inconvenience (four
> packages need to be adjusted: roary last-align freebayes symfony).

That may be true of the basic usage of the tool.

However, I just stumbled on this package through the "sem" tool (aka. "parallel 
--semaphore",
which seems by far the most compelling tool to prevent parallel execution of 
particular make
rules (eg. some launching git commands that require acquiring the same lock).

(that said, the fact the package cannot be installed alongside moreutils is 
another
blocker ;)

Bug#905674: Funding free software

[ydirson]

Hello Ole,

I do understand that funding Free Software is a problem of its own, but
I'm quite surprised to see a program with "GNU" in its name doing things
that way.  Is it a way of funding that is endorsed by the GNU project ?

Best regards,
-- 
Yann

Bug#900399: More good news

[ydirson]

severity 900399 normal
thanks

I suggest you get some advice from the forum[1], and as Dmitry mentionned, 
bring the issue to Lenovo.

[1] 
http://forum.canardpc.com/forums/73-Memtest86-Official-forum?s=1407c99a4da914ef85e60c32c658ba16

- Mail original -
> De: "Сергей Коган" 
> À: 900...@bugs.debian.org
> Envoyé: Jeudi 7 Juin 2018 15:26:43
> Objet: Bug#900399: More good news
> 
> Hi!
> 
> Let's lower the severity of this bug and flag it as unverified.
> 
> Given the datasheet for the TB62501 and actual board layout of the
> T500
> - the described scenario (short from the VCC3SW to GND caused by a
> stray
> write to the PMH register) is highly improbable:
> 
> - The LDO inside the RINKAN has an over-current protection set as low
> as
> 55mA and should prevent any damage even if the VCC3SW is shorted.
> After
> the single over-current/under-voltage event, RINKAN LDO is locked in
> the
> OFF state and requires a complete power-off to restart.
> 
> - Unused pins of the PMH are in fact floating
> 
> - Some RINKAN batches do show tendency to malfunction with no
> apparent
> reasons. The main board temperature could be a contributing factor.
> 
> So, we have to seriously consider the possibility that two laptops
> died
> at the same time just by a coincidence.
> 
> We do plan to run a memtest on the restored laptop using a current
> measuring/limiting circuit on the VCC3SW bus. If no excessive current
> consumption would be detected - the memtest has nothing to do with
> the
> issue. If an excessive current during the test would be observed, it
> would get us a direction to resume the investigation.
> 
> ---
> Sincerely yours,
> Sergey Kogan
> 

Bug#902472: sdl2: can deadlock after hiding a window

[ydirson]

Package: libsdl2
Version: 2.0.5+dfsg1-3
Tags: stretch patch

It can happen that SDL gets stuck waiting for X to accept a grab request, when 
the
window has already been hidden with SDL_HideWindow.

This behaviour has been fixed in 2.0.6 with commit 8f0a002 "x11: Don't loop 
forever
if the X server refuses a pointer grab", and does fix the problem for me when 
cherry-picking
that commit.

It would be great if that patch could find its way in a stretch update.  In any 
case since
it would take some time to get the fix to users, it would be good to get a 
backport to point
impacted users to.  Would you mind if I uploaded a 2.0.8 backport ?

Bug#891840: gaminggearfxinfo: fails with missing gaminggear_plugins

[ydirson]

Hello,

That does not fix the init issue, likely 2 different problems:

$ gaminggearfxinfo 

** (process:21432): WARNING **: Could not initialize fx system
$ echo $?
1


- Mail original -
> De: "Pierre-Elliott Bécue" 
> À: 891...@bugs.debian.org, ydir...@free.fr
> Envoyé: Lundi 5 Mars 2018 14:55:04
> Objet: gaminggearfxinfo: fails with missing gaminggear_plugins
> 
> Hi,
> 
> Sorry for the delay in my answer, but package "gaminggearfxinfo"
> doesn't
> exist so I never received your bug report.
> 
> Please, be cautious when you make a report to provide the appropriate
> package name. :)
> 
> Anyway, thanks for your bug report.
> 
> Can you try to create the missing directory as root and see if it
> fixes the
> problem? If so I'll upload a new release ASAP. :)
> 
> --
> Pierre-Elliott Bécue
> GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
> It's far easier to fight for one's principles than to live up to
> them.
> 

Bug#891840: gaminggearfxinfo: fails with missing gaminggear_plugins

[ydirson]

Package: gaminggearfxinfo
Version: 0.15.1-7

Can't tell if the missing plugin dir is *the* problem.
Seems also strange that "Could not initialize fx system" is only reported as a 
warning and not as a fatal error.

$ gaminggearfxinfo 

** (process:4089): WARNING **: Error opening directory 
'/usr/lib/x86_64-linux-gnu/gaminggear_plugins': Error opening directory 
'/usr/lib/x86_64-linux-gnu/gaminggear_plugins': No such file or directory

** (process:4089): WARNING **: Could not initialize fx system
$ echo $?
1

Bug#886464: libgaminggear0: uhid line causing errors (with old libkmod ?)

[ydirson]

Package: libgaminggear0
Version: 0.15.1-3

This package maybe lacks a versionned dependency, it causes errors when 
installed on a mostly-stretch install:

Preparing to unpack .../linux-image-4.14.0-3-amd64_4.14.12-1_amd64.deb ...
/etc/kernel/preinst.d/intel-microcode:
libkmod: ERROR ../libkmod/libkmod-config.c:635 kmod_config_parse: 
/lib/modprobe.d/uinput.conf line 1: ignoring bad line starting with 'uhid'
Unpacking linux-image-4.14.0-3-amd64 (4.14.12-1) ...
...
update-initramfs: Generating /boot/initrd.img-4.14.0-3-amd64
libkmod: ERROR ../libkmod/libkmod-config.c:635 kmod_config_parse: 
/lib/modprobe.d/uinput.conf line 1: ignoring bad line starting with 'uhid'
libkmod: ERROR ../libkmod/libkmod-config.c:635 kmod_config_parse: 
/lib/modprobe.d/uinput.conf line 1: ignoring bad line starting with 'uhid'
...
(many times the same error)

Bug#886128: mini-buildd: answering "never" to auto-setup is not honored

[ydirson]

Package: mini-buildd
Version: 1.0.32~bpo9+1


yann@buildd:~$ mini-buildd-tool admin@buildd:8066 status
[admin@buildd:8066] Password: 

Saving 'mini-buildd' passwords to 'keyrings.alt.file.EncryptedKeyring' with 
policy 'Ask':

Save password for 'admin@buildd:8066': (Y)es, (N)o, (A)lways, Ne(v)er? v
Please set a password for your new keyring: 


OTOH, answering "n" works properly.

Bug#886126: mini-buildd: using alt.files as keyring backend is highly impractical

[ydirson]

Package: mini-buildd
Version: 1.0.29

With no external keyring software installed, python-keyring defaults to 
alt.files, and the impact
on scripting (eg. launching auto-setup for a test) is quite high:

* have to enter keyring password for each keyring access
* a single error in one of those numerous prompts stops the whole process:

Please enter password for encrypted keyring:
E: admin@yantop:8066: Login failed: admin@redacted:8066: Incorrect Password
root #

Bug#886123: python3-keyring: cannot import name 'unicode_str'

[ydirson]

Package: python3-keyring
Version: 10.5.1-1

After updating just this package on stretch to get the keyring binary:

$ keyring get mini-buildd admin
Error initializing plugin kwallet = keyrings.alt.kwallet.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/keyring/backend.py", line 171, in 
_load_plugins
init_func = ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2291, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2297, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/keyrings/alt/kwallet.py", line 6, in 

from keyring.py27compat import unicode_str
ImportError: cannot import name 'unicode_str'
Error initializing plugin Gnome = keyrings.alt.Gnome.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/keyring/backend.py", line 171, in 
_load_plugins
init_func = ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2291, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2297, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/keyrings/alt/Gnome.py", line 11, in 

from keyring.py27compat import unicode_str
ImportError: cannot import name 'unicode_str'


https://github.com/oemof/oemof.db/issues/30 hints to a bug in keyrings.alt 
fixed in 2.2, and
indeed upgrading it to 2.2 fixes the problem.

This package should probably declare "Breaks: python3-keyrings.alt (<< 2.2)" ?

Bug#884539: fbxkb: does not explain how to add new keyboards

[ydirson]

Package: fbxkb
Version: 0.6-2+b1

fbxkb adds a flag matching current layout to my panel, but it is not obvious 
what one should do to get access to more choices.
Left click on flag has no effect, right click only has "about" (curiously 
labeled "information") and "quit".

Bug#878265: libyami-utils: please build with GLES support

[ydirson]

Package: libyami-utils
Version: 1.2.0-1

When trying "yamidecode -m 2" or "-m 3" or "-m 4", we get an error message 
saying
"do not support this render mode".

Source code shows those are conditionned by GLES support, and rebuilding locally
with GLES detected by configure allows me to use modes 2 and 4 successfully, and
I dare say they are a really nice demo of what this lib is capable of.

Bug#876122: spam accumulating in debian-embedded archive

[ydirson]

Package: lists.debian.org

The last 5 months of debian-embedded archive is essentially spam.
At least some of them are rejected by my ISP's MTA with a 500, and that
causes reports from the list server that mails to me are bouncing, which
is quite uncomfortable :)

Bug#875912: Remove gcompris?

[ydirson]

No problem, we can request its removal and go for transition.
I'd suggest we wait for new gcompris-qt maintainer to finalize his first upload,
and then request removal of old gcompris.

- Mail original -
> De: "Jeremy Bicha" 
> À: "submit" 
> Envoyé: Vendredi 15 Septembre 2017 22:49:19
> Objet: Bug#875912: Remove gcompris?
> 
> Package: gcompris
> Version: 15.10-1
> 
> gcompris is no longer being developed because it has been replaced by
> gcompris-qt.  The developers refuse to make any more gcompris
> releases
> since they don't want there to be confusion about what project is
> being developed.
> 
> Therefore, I suggest converting gcompris into a transitional package
> depending on gcompris-qt. (Because the version numbering was reset,
> that transitional package can't easily be shipped in the gcompris-qt
> source.)
> 
> Thanks,
> Jeremy Bicha
> 

Bug#873642: weboob-qt: misses dependency on python-pyqt5.qtmultimedia

[ydirson]

Package: weboob-qt
Version: 1.2-1
Severity: serious

without it, qvideoob fails with:

$ qvideoob
Traceback (most recent call last):
  File "/usr/bin/qvideoob", line 24, in 
from weboob.applications.qvideoob import QVideoob
  File 
"/usr/lib/python2.7/dist-packages/weboob/applications/qvideoob/__init__.py", 
line 1, in 
from .qvideoob import QVideoob
  File 
"/usr/lib/python2.7/dist-packages/weboob/applications/qvideoob/qvideoob.py", 
line 24, in 
from .main_window import MainWindow
  File 
"/usr/lib/python2.7/dist-packages/weboob/applications/qvideoob/main_window.py", 
line 30, in 
from .video import Video
  File 
"/usr/lib/python2.7/dist-packages/weboob/applications/qvideoob/video.py", line 
23, in 
from PyQt5.QtMultimedia import QMediaContent, QMediaPlayer
ImportError: No module named QtMultimedia

Bug#861974: libcurl4-openssl-dev multi-architecture incompatibility also affects gnutls version

[ydirson]

The same problem happens when trying to install amd64 and i386 versions of the 
libcurl4-gnutls-dev package.

Bug#872223: tex-common: fails to configure, fmtutils reports errors about missing files

[ydirson]

reassign 872223 dpkg
severity 872223 grave
thanks

Well, probably not a missing Conflicts, as downgrading tex-common to the stretch
version does not fix the problem.  Really a problem with missing files that 
should
not be missing.

In fact, despite having the package installed, there is no such .ini files on 
my system.  packages.d.o shows that texlive-htmlxml from stretch should have 
them, but for some reason they do not appear on my system:


root@home:~# apt-cache policy texlive-htmlxml
texlive-htmlxml:
  Installed: 2016.20170123-5
  Candidate: 2016.20170123-5
  Version table:
 2017.20170808-1 900
500 ftp://ftp.debian.org/debian unstable/main amd64 Packages
500 ftp://ftp.debian.org/debian unstable/main i386 Packages
900 ftp://ftp.debian.org/debian testing/main amd64 Packages
900 ftp://ftp.debian.org/debian testing/main i386 Packages
 *** 2016.20170123-5 990
990 ftp://ftp.debian.org/debian stretch/main amd64 Packages
990 ftp://ftp.debian.org/debian stretch/main i386 Packages
100 /var/lib/dpkg/status

root@home:~# grep jadetex /var/lib/dpkg/info/texlive-htmlxml.list 
/usr/share/doc/texlive-doc/otherformats/jadetex
/usr/share/doc/texlive-doc/otherformats/jadetex/base
/usr/share/texlive/texmf-dist/tex/jadetex
/usr/share/texlive/texmf-dist/tex/jadetex/base


root@home:~# cp /var/lib/dpkg/info/texlive-htmlxml.list /tmp
root@home:~# aptitude reinstall texlive-htmlxml

... and then the configuration fails with another missing file:

! LaTeX Error: File `ulem.sty' not found.

Type X to quit or  to proceed,
or enter new name. (Default extension: sty)

Enter file name:
! Emergency stop.


l.27 \RequirePackage
{fancyhdr}^^M
!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on pdfjadetex.log.
fmtutil [ERROR]: running `pdftex -ini   -jobname=jadetex -progname=jadetex 
*jadetex.ini 
2017-08-01 11:00:49 status half-configured tex-common:all 6.07
2017-08-01 11:00:50 status installed tex-common:all 6.07
...
2017-08-01 23:32:55 configure texlive-generic-recommended:all 2016.20170123-5 

2017-08-01 23:32:55 status unpacked texlive-generic-recommended:all 
2016.20170123-5
2017-08-01 23:32:55 status half-configured texlive-generic-recommended:all 
2016.20170123-5
2017-08-01 23:32:55 status installed texlive-generic-recommended:all 
2016.20170123-5
...
2017-08-01 23:32:58 configure texlive-htmlxml:all 2016.20170123-5 
2017-08-01 23:32:58 status unpacked texlive-htmlxml:all 2016.20170123-5
2017-08-01 23:32:58 status half-configured texlive-htmlxml:all 2016.20170123-5
2017-08-01 23:32:58 status installed texlive-htmlxml:all 2016.20170123-5
...
2017-08-01 23:35:15 trigproc tex-common:all 6.07 
2017-08-01 23:35:15 status half-configured tex-common:all 6.07
2017-08-01 23:35:49 startup packages configure
2017-08-01 23:35:49 configure tex-common:all 6.07 
2017-08-01 23:35:49 status half-configured tex-common:all 6.07

 -rw-r--r-- 1 root root 2020 Aug  1 10:42 
/var/lib/dpkg/info/texlive-generic-recommended.list

Older logs show:

2017-07-14 22:33:44 configure texlive-generic-recommended:all 2017.20170629-1 

2017-07-14 22:33:44 status unpacked texlive-generic-recommended:all 
2017.20170629-1
2017-07-14 22:33:44 status half-configured texlive-generic-recommended:all 
2017.20170629-1
2017-07-14 22:33:44 status installed texlive-generic-recommended:all 
2017.20170629-1
...
2017-07-14 23:26:00 configure texlive-htmlxml:all 2017.20170629-1 
2017-07-14 23:26:00 status unpacked texlive-htmlxml:all 2017.20170629-1
2017-07-14 23:26:00 status half-configured texlive-htmlxml:all 2017.20170629-1
2017-07-14 23:26:00 status installed texlive-htmlxml:all 2017.20170629-1
...
2017-07-14 23:26:41 trigproc tex-common:all 6.07 
2017-07-14 23:26:41 status half-configured tex-common:all 6.07
2017-07-14 23:27:04 status installed tex-common:all 6.07


I know that we do not really support package downgrading, but still, that stuff 
really looks like a bad dpkg bug, right ?

A shame we do not git-version all .list files to track down when something goes 
wrong like that...

Bug#872223: tex-common: fails to configure, fmtutils reports errors about missing files

[ydirson]

Package: tex-common
Version: 6.07

I'll spare you the full logs, the end seems to make things quite clear:

fmtutil [INFO]: /var/lib/texmf/web2c/luatex/dviluatex.fmt installed.
fmtutil [WARNING]: inifile xmltex.ini for xmltex/pdftex not found.
fmtutil [WARNING]: inifile jadetex.ini for jadetex/pdftex not found.
fmtutil [WARNING]: inifile pdfjadetex.ini for pdfjadetex/pdftex not found.
fmtutil [WARNING]: inifile pdfxmltex.ini for pdfxmltex/pdftex not found.
fmtutil [INFO]: Disabled formats: 3
fmtutil [INFO]: Successfully rebuilt formats: 15
fmtutil [INFO]: Failed to build: 4 (pdftex/xmltex pdftex/jadetex 
pdftex/pdfjadetex pdftex/pdfxmltex)
fmtutil [INFO]: Total formats: 22
fmtutil [INFO]: exiting with status 4


This box is mostly-stretch with a number of packages from buster, so it may 
just be some
dependency missing after the move of those packages into texlive-htmlxml.

I have texlive-htmlxml 2017.20170808-1 from stretch here. If it is what 
tex-common dislikes,
it probably needs a Conflicts declaration ?

Bug#864826: gammaray: 2.8.0 is out

[ydirson]

Package: gammaray
Version: 2.7.0-1
Severity: wishlist

https://github.com/KDAB/GammaRay/releases

Bug#864825: gammaray: crashes target program on attach

[ydirson]

Package: gammaray
Version: 2.7.0-1
severity: grave

When attaching to any Qt5 or Qt4 process, the target process crashes.
Here with a freshly-launched kwrite for demonstration:

#0  0x7f21b4fd96ad in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7f21af8429f6 in g_main_context_poll (priority=, 
n_fds=1, fds=0x7f2194003020, timeout=, context=0x7f2194000990) 
at ././glib/gmain.c:4228
#2  g_main_context_iterate (context=context@entry=0x7f2194000990, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
././glib/gmain.c:3924
#3  0x7f21af842b0c in g_main_context_iteration (context=0x7f2194000990, 
may_block=1) at ././glib/gmain.c:3990
#4  0x7f21b58ed06b in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f21b58969ca in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7f21b56c40f3 in QThread::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x7f21b88b26d5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#8  0x7f21b56c8da8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x7f21b151e494 in start_thread (arg=0x7f21a0dfc700) at 
pthread_create.c:333
#10 0x7f21b4fe2aff in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 1 (Thread 0x7f21a5b0a580 (LWP 31110)):
[KCrash Handler]
#4  0x7f219a2d65b1 in GammaRay::Server::listen() () from 
/usr/lib/libgammaray_core-qt5_7-x86_64.so.2.7.0
#5  0x7f219a294bd1 in GammaRay::Probe::delayedInit() () from 
/usr/lib/libgammaray_core-qt5_7-x86_64.so.2.7.0
#6  0x7f21b58c5499 in QObject::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x7f21b617bb8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x7f21b6183341 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9  0x7f21b58989e0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x7f21b589b16d in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7f21b58ecc43 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7f21af8427f7 in g_main_dispatch (context=0x7f219c0016f0) at 
././glib/gmain.c:3203
#13 g_main_context_dispatch (context=context@entry=0x7f219c0016f0) at 
././glib/gmain.c:3856
#14 0x7f21af842a60 in g_main_context_iterate 
(context=context@entry=0x7f219c0016f0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3929
#15 0x7f21af842b0c in g_main_context_iteration (context=0x7f219c0016f0, 
may_block=1) at ././glib/gmain.c:3990
#16 0x7f21b58ed04f in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x7f21b58969ca in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x7f21b589f13c in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x557eafc8198f in main ()

Bug#859147: [Pkg-utopia-maintainers] Bug#859147: network-manager: restart failure on upgrade

[ydirson]

Purged laptop-mode-tools, rebooted, no change.

network-manager is properly started at boot time, service can be stopped, but 
not started again
afterwards: systemd now has a "(kManager)" child at near-100% CPU.

Found the culprit: I have a broken schroot configuration (talk about pending 
work and switching to other tasks...), where the
chroot is under my home dir, which gets mounted in the chroot.  Schroot does 
not detect the loop and
recursively mounts all /home submounts, apparently until a 65535 mountpoint 
limit

Thus I assume that systemd is attempting to mount something, and not dealing 
properly with
the error ?

- Mail original -
> De: ydir...@free.fr
> À: "Michael Biebl" 
> Cc: 859...@bugs.debian.org
> Envoyé: Samedi 1 Avril 2017 10:49:08
> Objet: Re: [Pkg-utopia-maintainers] Bug#859147: network-manager: restart 
> failure on upgrade
> 
> Will test this soon.
> 
> Oh, just noticed that the fan was indeed noisy... and top reports
> this:
> 
>   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
>   COMMAND
>  6019 root  20   0  237608  96996   2368 R 100.0  1.2   0:30.49
>  (kManager)
> 
> I can't seem to find what a "kManager" process could be around here.
>  There
> is but a common suffix with NetworkManager, but I admit I don't see
> why it
> would be truncated.  Looking at /proc it just looks like a systemd
> thread, and
> it gets started and restarted again and again.
> 
> - Mail original -
> > De: "Michael Biebl" 
> > À: ydir...@free.fr
> > Cc: 859...@bugs.debian.org
> > Envoyé: Vendredi 31 Mars 2017 11:12:38
> > Objet: Re: [Pkg-utopia-maintainers] Bug#859147: network-manager:
> > restart failure on upgrade
> > 
> > Am 31.03.2017 um 11:08 schrieb ydir...@free.fr:
> > > Here is the relevant journalctl -alb excerpt, sending more
> > > details
> > > in private mail
> > > 
> > > Mar 30 20:22:06 yantop systemd[1]: Stopping Network Manager Wait
> > > Online...
> > > Mar 30 20:22:06 yantop systemd[1]: Stopping Network Manager...
> > > Mar 30 20:22:06 yantop NetworkManager[4948]: 
> > >  [1490898126.5839] caught SIGTERM, shutting down normally.
> > > Mar 30 20:22:06 yantop NetworkManager[4948]: 
> > >  [1490898126.6660] device (wlan0): state change: unavailable ->
> > > unmanaged (reason 'unmanaged') [20 10 3]
> > > Mar 30 20:22:06 yantop NetworkManager[4948]: 
> > >  [1490898126.6663] device (wlan0): set-hw-addr: reset MAC address
> > > to B4:6D:83:58:53:31 (unmanage)
> > > Mar 30 20:22:06 yantop NetworkManager[4948]: 
> > >  [1490898126.6676] device (E0:98:61:62:F4:53): state change:
> > > disconnected -> unmanaged (reason 'unmanaged') [30 10 3]
> > > Mar 30 20:22:06 yantop NetworkManager[4948]: 
> > >  [1490898126.6761] device (44:00:10:24:8F:70): state change:
> > > disconnected -> unmanaged (reason 'unmanaged') [30 10 3]
> > > Mar 30 20:22:06 yantop NetworkManager[4948]: 
> > >  [1490898126.8186] exiting (success)
> > > Mar 30 20:22:07 yantop systemd[1]: Stopped Network Manager.
> > > Mar 30 20:22:07 yantop systemd[1]: Starting Network Manager...
> > > Mar 30 20:23:06 yantop systemd[1]: Starting Laptop Mode Tools -
> > > Battery Polling Service...
> > > Mar 30 20:23:06 yantop systemd[1]: Reloading Laptop Mode Tools.
> > > Mar 30 20:23:06 yantop systemd[1]: Started Laptop Mode Tools -
> > > Battery Polling Service.
> > > Mar 30 20:23:06 yantop laptop_mode[5372]: Laptop mode
> > > Mar 30 20:23:06 yantop laptop_mode[5372]: enabled, not active
> > > [unchanged]
> > > Mar 30 20:23:06 yantop systemd[1]: Reloaded Laptop Mode Tools.
> > > Mar 30 20:23:37 yantop systemd-journald[398]: Suppressed 1050
> > > messages from /init.scope
> > > Mar 30 20:23:37 yantop systemd[1]: NetworkManager.service: Start
> > > operation timed out. Terminating.
> > 
> > Your systemd instance seems to be in a confused state. I wonder if
> > that's related to laptop-mode-tools.
> > Try purging that package and reboot to reset the state.
> > 
> > 
> > --
> > Why is it that all of the instruments seeking intelligent life in
> > the
> > universe are pointed away from Earth?
> > 
> > 
> 

Bug#859147: [Pkg-utopia-maintainers] Bug#859147: network-manager: restart failure on upgrade

[ydirson]

Will test this soon.

Oh, just noticed that the fan was indeed noisy... and top reports this:

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND 

  
 6019 root  20   0  237608  96996   2368 R 100.0  1.2   0:30.49 (kManager)  

  

I can't seem to find what a "kManager" process could be around here.  There
is but a common suffix with NetworkManager, but I admit I don't see why it
would be truncated.  Looking at /proc it just looks like a systemd thread, and
it gets started and restarted again and again.

- Mail original -
> De: "Michael Biebl" 
> À: ydir...@free.fr
> Cc: 859...@bugs.debian.org
> Envoyé: Vendredi 31 Mars 2017 11:12:38
> Objet: Re: [Pkg-utopia-maintainers] Bug#859147: network-manager: restart 
> failure on upgrade
> 
> Am 31.03.2017 um 11:08 schrieb ydir...@free.fr:
> > Here is the relevant journalctl -alb excerpt, sending more details
> > in private mail
> > 
> > Mar 30 20:22:06 yantop systemd[1]: Stopping Network Manager Wait
> > Online...
> > Mar 30 20:22:06 yantop systemd[1]: Stopping Network Manager...
> > Mar 30 20:22:06 yantop NetworkManager[4948]: 
> >  [1490898126.5839] caught SIGTERM, shutting down normally.
> > Mar 30 20:22:06 yantop NetworkManager[4948]: 
> >  [1490898126.6660] device (wlan0): state change: unavailable ->
> > unmanaged (reason 'unmanaged') [20 10 3]
> > Mar 30 20:22:06 yantop NetworkManager[4948]: 
> >  [1490898126.6663] device (wlan0): set-hw-addr: reset MAC address
> > to B4:6D:83:58:53:31 (unmanage)
> > Mar 30 20:22:06 yantop NetworkManager[4948]: 
> >  [1490898126.6676] device (E0:98:61:62:F4:53): state change:
> > disconnected -> unmanaged (reason 'unmanaged') [30 10 3]
> > Mar 30 20:22:06 yantop NetworkManager[4948]: 
> >  [1490898126.6761] device (44:00:10:24:8F:70): state change:
> > disconnected -> unmanaged (reason 'unmanaged') [30 10 3]
> > Mar 30 20:22:06 yantop NetworkManager[4948]: 
> >  [1490898126.8186] exiting (success)
> > Mar 30 20:22:07 yantop systemd[1]: Stopped Network Manager.
> > Mar 30 20:22:07 yantop systemd[1]: Starting Network Manager...
> > Mar 30 20:23:06 yantop systemd[1]: Starting Laptop Mode Tools -
> > Battery Polling Service...
> > Mar 30 20:23:06 yantop systemd[1]: Reloading Laptop Mode Tools.
> > Mar 30 20:23:06 yantop systemd[1]: Started Laptop Mode Tools -
> > Battery Polling Service.
> > Mar 30 20:23:06 yantop laptop_mode[5372]: Laptop mode
> > Mar 30 20:23:06 yantop laptop_mode[5372]: enabled, not active
> > [unchanged]
> > Mar 30 20:23:06 yantop systemd[1]: Reloaded Laptop Mode Tools.
> > Mar 30 20:23:37 yantop systemd-journald[398]: Suppressed 1050
> > messages from /init.scope
> > Mar 30 20:23:37 yantop systemd[1]: NetworkManager.service: Start
> > operation timed out. Terminating.
> 
> Your systemd instance seems to be in a confused state. I wonder if
> that's related to laptop-mode-tools.
> Try purging that package and reboot to reset the state.
> 
> 
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 
> 

Bug#859147: [Pkg-utopia-maintainers] Bug#859147: network-manager: restart failure on upgrade

[ydirson]

Here is the relevant journalctl -alb excerpt, sending more details in private 
mail

Mar 30 20:22:06 yantop systemd[1]: Stopping Network Manager Wait Online...
Mar 30 20:22:06 yantop systemd[1]: Stopping Network Manager...
Mar 30 20:22:06 yantop NetworkManager[4948]:   [1490898126.5839] caught 
SIGTERM, shutting down normally.
Mar 30 20:22:06 yantop NetworkManager[4948]:   [1490898126.6660] device 
(wlan0): state change: unavailable -> unmanaged (reason 'unmanaged') [20 10 3]
Mar 30 20:22:06 yantop NetworkManager[4948]:   [1490898126.6663] device 
(wlan0): set-hw-addr: reset MAC address to B4:6D:83:58:53:31 (unmanage)
Mar 30 20:22:06 yantop NetworkManager[4948]:   [1490898126.6676] device 
(E0:98:61:62:F4:53): state change: disconnected -> unmanaged (reason 
'unmanaged') [30 10 3]
Mar 30 20:22:06 yantop NetworkManager[4948]:   [1490898126.6761] device 
(44:00:10:24:8F:70): state change: disconnected -> unmanaged (reason 
'unmanaged') [30 10 3]
Mar 30 20:22:06 yantop NetworkManager[4948]:   [1490898126.8186] exiting 
(success)
Mar 30 20:22:07 yantop systemd[1]: Stopped Network Manager.
Mar 30 20:22:07 yantop systemd[1]: Starting Network Manager...
Mar 30 20:23:06 yantop systemd[1]: Starting Laptop Mode Tools - Battery Polling 
Service...
Mar 30 20:23:06 yantop systemd[1]: Reloading Laptop Mode Tools.
Mar 30 20:23:06 yantop systemd[1]: Started Laptop Mode Tools - Battery Polling 
Service.
Mar 30 20:23:06 yantop laptop_mode[5372]: Laptop mode
Mar 30 20:23:06 yantop laptop_mode[5372]: enabled, not active [unchanged]
Mar 30 20:23:06 yantop systemd[1]: Reloaded Laptop Mode Tools.
Mar 30 20:23:37 yantop systemd-journald[398]: Suppressed 1050 messages from 
/init.scope
Mar 30 20:23:37 yantop systemd[1]: NetworkManager.service: Start operation 
timed out. Terminating.
Mar 30 20:23:37 yantop systemd[1]: Failed to start Network Manager.
Mar 30 20:23:37 yantop systemd[1]: Dependency failed for Network Manager Wait 
Online.
Mar 30 20:23:37 yantop systemd[1]: NetworkManager-wait-online.service: Job 
NetworkManager-wait-online.service/start failed with result 'dependency'.
Mar 30 20:23:37 yantop systemd[1]: NetworkManager.service: Unit entered failed 
state.
Mar 30 20:23:37 yantop systemd[1]: NetworkManager.service: Failed with result 
'timeout'.
Mar 30 20:23:37 yantop systemd[1]: NetworkManager.service: Service hold-off 
time over, scheduling restart.
Mar 30 20:23:37 yantop systemd[1]: Stopped Network Manager.
Mar 30 20:23:37 yantop systemd[1]: Starting Network Manager...
Mar 30 20:23:38 yantop systemd[1]: Reloading.
Mar 30 20:23:39 yantop systemd[1]: Failed to set up mount unit: Invalid argument
Mar 30 20:23:39 yantop systemd[1]: Failed to set up mount unit: Invalid argument
Mar 30 20:23:39 yantop systemd[1]: Failed to set up mount unit: Invalid argument
Mar 30 20:23:39 yantop systemd[1]: Failed to set up mount unit: Invalid argument


- Mail original -
> De: "Michael Biebl" 
> À: ydir...@free.fr, 859...@bugs.debian.org
> Envoyé: Vendredi 31 Mars 2017 00:12:59
> Objet: Re: [Pkg-utopia-maintainers] Bug#859147: network-manager: restart 
> failure on upgrade
> 
> Am 30.03.2017 um 23:50 schrieb ydir...@free.fr:
> 
> > Any other information would be useful ?
> 
> Can you attach the following information
> journalctl -alb
> systemd-cgls
> 
> 
> 
> 
> 
> 
> 
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Bug#859147: network-manager: restart failure on upgrade

[ydirson]

Package: network-manager
Version: 1.6.2-3

When upgrading from 1.6.2-2:

Setting up network-manager (1.6.2-3) ...
Job for NetworkManager.service failed because a timeout was exceeded.
See "systemctl status NetworkManager.service" and "journalctl -xe" for details.
invoke-rc.d: initscript network-manager, action "restart" failed.
● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor 
preset: enabled)
   Active: activating (auto-restart) (Result: timeout) since Thu 2017-03-30 
23:43:52 CEST; 4ms ago
 Docs: man:NetworkManager(8)
  Process: 16706 ExecStart=/usr/sbin/NetworkManager --no-daemon (code=killed, 
signal=TERM)
 Main PID: 16706 (code=killed, signal=TERM)
  CPU: 1min 30.013s

Mar 30 23:43:52 yantop systemd[1]: NetworkManager.service: Unit entered failed 
state.
Mar 30 23:43:52 yantop systemd[1]: NetworkManager.service: Failed with result 
'timeout'.
dpkg: error processing package network-manager (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 network-manager


===
# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

===
# cat /etc/network/interfaces.d/LOCAL-lxc 
auto lxcbr0
iface lxcbr0 inet static
address 10.100.0.1
bridge_ports none
bridge_fd 0
bridge_maxwait 0
up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Any other information would be useful ?

Bug#857374: virtualenvwrapper: bash completion lacks testing for availability

[ydirson]

Package: virtualenvwrapper
Version: 4.3.1-2

When virtualenvwrapper is uninstalled but not purged, we get this each time 
bash completion is sourced:

bash: /usr/share/virtualenvwrapper/virtualenvwrapper_lazy.sh: No such file or 
directory

Bug#855788: 855788 severity

[ydirson]

FWIW, no such problem here. Is that high severity really warranted ?

Bug#776941: dh-kpatches: please help make builds reproducible

[ydirson]

Well, the package is orphaned (although I never did an upload removing my name 
from
the maintainer field, it has a proper WNPP bug).

For some reason some people seem to be still using it :)

- Mail original -
> De: "Chris Lamb" 
> À: 776...@bugs.debian.org
> Envoyé: Samedi 18 Février 2017 23:05:36
> Objet: Bug#776941: dh-kpatches: please help make builds reproducible
> 
> > Would you consider applying this patch and uploading?
> 
> Friendly ping on this :)
> 
> 
> Best wishes,
> 
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
> 

Bug#833741: Patch updated for 1.8.3

[ydirson]

Updated Bob's patch, which was against 1.8.1, to 1.8.3.
This fixes both RC bugs, uploading a NMU hoping it's not too late...

diff --git a/debian/changelog b/debian/changelog
index e94d50a..965efd3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+pepperflashplugin-nonfree (1.8.4) unstable; urgency=medium
+
+  [ Bob Proulx ]
+  * Patched to use Adobe upstream rather than Google.
+  * Inspired by the patch provided in Bug#833741#15 by Kristian Klausen
+but rewritten.  Closes: #833741.
+  * Adds in 32-bit support.
+  
+  [ Yann Dirson ]
+  * Non-maintainer upload.
+  * Updated patch for 1.8.3
+
+ -- Yann Dirson   Sat, 14 Jan 2017 18:57:25 +0100
+
 pepperflashplugin-nonfree (1.8.3) unstable; urgency=medium
 
   * update-pepperflashplugin-nonfree:
diff --git a/debian/control b/debian/control
index 3e35edf..0e4f28d 100644
--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,6 @@ Pre-Depends: ca-certificates
 Suggests: chromium, ttf-mscorefonts-installer, ttf-dejavu, ttf-xfree86-nonfree, hal
 Conflicts: libflash-mozplugin, chromium (<< 37.0.2062.120-4)
 Description: Pepper Flash Player - browser plugin
- This package will download Chrome from Google, and unpack it to make the
+ This package will download Chrome from Adobe, and unpack it to make the
  included Pepper Flash Player available for use with Chromium.  The end user
- license agreement is available at Google.
+ license agreement is available at Adobe.
diff --git a/debian/install b/debian/install
index c4a3e4d..2b54a10 100644
--- a/debian/install
+++ b/debian/install
@@ -1,3 +1,2 @@
 update-pepperflashplugin-nonfree usr/sbin/
-pubkey-google.txt usr/lib/pepperflashplugin-nonfree/
 debian/etc/chromium.d/pepperflashplugin-nonfree etc/chromium.d/
diff --git a/debian/postinst b/debian/postinst
index 531d6dd..f7c7051 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -5,6 +5,9 @@ set -e
 case "$1" in
 configure)
 	update-pepperflashplugin-nonfree --install --fast || true
+	# Clean up the old Google debs as we are now using Adobe tar.gz files.
+	rm -rf /var/cache/pepperflashplugin-nonfree/*.deb
+	rm -rf /var/cache/pepperflashplugin-nonfree/latest-stable-verified.txt
 ;;
 
 abort-upgrade|abort-remove|abort-deconfigure)
diff --git a/update-pepperflashplugin-nonfree b/update-pepperflashplugin-nonfree
index 62aceb8..39784c6 100755
--- a/update-pepperflashplugin-nonfree
+++ b/update-pepperflashplugin-nonfree
@@ -17,12 +17,6 @@
 
 set -e
 
-return_0() {
-	return 0
-}
-
-trap "return_0" 0
-
 die_hard() {
 	echo "ERROR: $1" >&2
 	echo "More information might be available at:" >&2
@@ -30,7 +24,7 @@ die_hard() {
 	exit 1
 }
 
-[ `id -u` = "0" ] || die_hard "must be root"
+[ "$(id -u)" = "0" ] || die_hard "must be root"
 
 show_usage() {
 	echo "Usage:"
@@ -43,18 +37,16 @@ show_usage() {
 	exit 1
 }
 
-getopt_temp=`getopt -o iusfvq --long install,uninstall,status,fast,verbose,quiet,beta,unstable,unverified \
-	-n 'update-pepperflashplugin-nonfree' -- "$@"` || show_usage
-eval set -- "$getopt_temp" || show_usage
+getopt_temp=$(getopt -o iusfvq --long install,uninstall,status,fast,verbose,quiet \
+	-n 'update-pepperflashplugin-nonfree' -- "$@") || show_usage
+eval set -- "$getopt_temp"
 
 ACTION=none
 fast=no
 verbose=no
 quiet=no
-variant=stable
-verified=yes
 
-while [ true ]
+while [ $# -gt 0 ]
 do
 	case "$1" in
 		-i|--install)
@@ -81,18 +73,6 @@ do
 			quiet=yes
 			shift
 			;;
-		--beta)
-			variant=beta
-			shift
-			;;
-		--unstable)
-			variant=unstable
-			shift
-			;;
-		--unverified)
-			verified=no
-			shift
-			;;
 		--)
 			shift
 			break
@@ -109,106 +89,34 @@ done
 
 [ "$verbose" != "yes" ] || echo "options : $getopt_temp"
 
-latestfile=latest-$variant-verified.txt
-[ "$verified" != "no" ] || latestfile=latest-$variant.txt
-
-UNPACKDIR=`mktemp -d /tmp/pepperflashplugin-nonfree.XX` || die_hard "mktemp failed"
-echo "$UNPACKDIR" | grep -q "^/tmp/pepperflashplugin-nonfree\." || die_hard "paranoia"
-cd "$UNPACKDIR" || die_hard "cd failed"
-
-[ "$verbose" != "yes" ] || echo "temporary directory: $UNPACKDIR"
-
-do_cleanup() {
-	[ "$verbose" != "yes" ] || echo "cleaning up temporary directory $UNPACKDIR ..."
-	cd /
-	echo "$UNPACKDIR" | grep -q "^/tmp/pepperflashplugin-nonfree\." || die_hard "paranoia"
-	rm -rf "$UNPACKDIR"
-}
-
-die_hard_with_a_cleanup() {
-	return_0
-	do_cleanup
-	die_hard "$1"
-}
-
-trap "die_hard_with_a_cleanup interrupted" INT
+wgetquiet='-q'
+wgetfast='-t 3 -T 15'
+wgetprogress='-v --progress=dot:default'
+[ "$quiet" != "no" ] || wgetquiet=""
+[ "$fast" != "no" ] || wgetfast=""
+wgetoptions="$wgetquiet $wgetfast $wgetprogress"
+
+arch=""
+case $(dpkg --print-architecture) in
+	amd64)	arch="x86_64" ;;
+	i?86)	arch="i386" ;;
+	*)
+		die_hard "unsupported architectures" ;;
+esac
 
 cachedir=/var/cache/pepperflashplugin-nonfree
 
-wgetquiet=' -q '
-wgetfast='-t 3 -T 15 '
-wgetalways=' -nd -P . '
-wgetprogress=' -v --progress=dot:default '
-
-if [ "$ACTION" = "--install" -o 

Bug#849856: input-utils: outdated upstream URL, new upstream release

[ydirson]

Package: input-utils
Version: 1.0-1.1

Contents behind upstream URL in copyright in watch files is apparently a set of
CVS snapshot not updated any more.

There is a 1.2 release at https://www.kraxel.org/releases/input/
Homepage at https://www.kraxel.org/blog/linux/input/

Bug#849072: lightdm: add-seat badly documented, apparently deprecated

[ydirson]

Package: lightdm
Version: 1.18.2-2

While "dm-tool add-nested-seat" does work, it is not suitable for all uses, and 
"dm-tool add-seat" looks like
the way to launch a real new X session.

However:
* manpage mentions the syntax is "dm-tool add-seat TYPE" without giving any 
clue as to what TYPE should be
* https://answers.launchpad.net/lightdm/+question/176458 and 
https://bbs.archlinux.org/viewtopic.php?id=185297
  hint about "xlocal/xremote" as possible types
* all TYPEs I tried resulted in this error:

# dm-tool add-seat xlocal
Unable to add seat: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: AddSeat 
is deprecated


Looks like the message comes from lightdm itself!

if (g_strcmp0 (method_name, "AddSeat") == 0)
g_dbus_method_invocation_return_error (invocation, G_DBUS_ERROR, 
G_DBUS_ERROR_INVALID_ARGS, "AddSeat is deprecated");
else if (g_strcmp0 (method_name, "AddLocalXSeat") == 0)

At least the manpage should tell it's not supposed to work anymore, and explain 
how to replace
the feature.

* switch-to-greater works, unless one wants to open a new session as a user 
already logged in
* with add-local-x-seat we can get things to work with:

I tried:

# X :1 &
# dm-tool add-local-x-seat 1

... which does work, but with several inconveniences:

* we have to find out by hand which tty was selected - I get tty2 or tty3 
(despite a getty running there), instead of expected tty8,
  ie. the tty constraints obeyed by lightdm do not apply
* dm-tool switch-to-user is of no use to discover this tty with several 
sessions for the same user

Bug#848668: emacs25: please include .desktop file for emacsclient

[ydirson]

Package: emacs25
Severity: wishlist
Tags: patch

Today eg. firefox proposes to open a text file in emacs, but since it only finds
apps through desktop files, it won't propose emacsclient.

Attached the one I'm using now, quickly modified from emacs25.desktop


emacsclient25.desktop
Description: application/desktop

Bug#847996: edid-decode: wrongly interprets 13-byte strings as non-conforming

[ydirson]

Package: edid-decode
Version: 0.1~git20140128.afcf2a2e-1

The spec states that only when the "Alphanumeric Data String Descriptor 
Definition" is less
than 13 bytes, should it be followed by 0x0A and further padded with 0x20.

Thus, a 13-byte string without a 0x0A is valid, but edid-decode rejects it.

Note that other fields have the same description, eg. "Display Product Serial 
Number Descriptor Definition"

Bug#844296: libstdc++6-7-dbg: undeclared common file with libstdc++6-6-dbg

[ydirson]

Package: libstdc++6-7-dbg
Version: 7-20161112-1

Unpacking libstdc++6-7-dbg:amd64 (7-20161112-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-K00oDb/18-libstdc++6-7-dbg_7-20161112-1_amd64.deb 
(--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/debug/libstdc++.a', which is 
also in package libstdc++6-6-dbg:amd64 6.2.0-10
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /tmp/apt-dpkg-install-K00oDb/18-libstdc++6-7-dbg_7-20161112-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#833741: patch/nmu ?

[ydirson]

tags 833741 + patch
thanks

Is there any reason not to apply that patch ?

Bug#834790: aptitude hangs at "Loading cache" when unable to download package list

[ydirson]

Just hit the same problem after adding a valid sources.list entry without 
having imported the repo signing key,
and I can confirm it'the behaviour is really awkward - and reading suggestions 
that letting the user lose time
until he figures out he has to restarti aptitude would be a valid way out 
instead of displaying a proper message
to the user - that just makes me very uncomfortable, it's just not the level of 
software quality I have been
expecting around here :)

Regards,
-- 
Yann

Bug#841765: enet: new version available

[ydirson]

Package: enet
Version: 1.3.12+ds-2

1.3.13 was apparently released some time ago.

http://enet.bespin.org/download/

Bug#836777: perceptualdiff: does not catch disk-full condition, creates 0-size diffs

[ydirson]

Package: perceptualdiff
Version: 1.2-2

-output will always create a file, but when the disk is full its size is 0 and
we don't get an error message.

Bug#836265: [Aptitude-devel] Bug#836265: aptitude: keeps reselecting sysvinit

[ydirson]

- Mail original -
> De: "David Kalnischkies" 
> À: ydir...@free.fr, 836...@bugs.debian.org
> Envoyé: Jeudi 1 Septembre 2016 16:20:55
> Objet: Re: [Aptitude-devel] Bug#836265: aptitude: keeps reselecting sysvinit
> 
> On Thu, Sep 01, 2016 at 02:10:14PM +0200, ydir...@free.fr wrote:
> > > >> I don't see sysvinit being Essential anymore in unstable:
> > > >>
> > > >> → apt-cache show sysvinit | fgrep -i Essential
> > > >>  This package depends on init, which is an essential package
> > > >>  that
> > > >> →
> > > >>
> > > >> Any chance that you have stable/jessie in your sources.list,
> > > >> too?
> > > >
> > > > Yes: wheezy, jessie, testing, unstable, experimental.
> > >
> > > Actually only the wheezy version of sysvinit is essential, and
> > > you
> > > might want to remove that suite from your sources.list (mixing
> > > oldstable and unstable is not supported).
> >
> > I only have a couple of non-essential packages from wheezy for some
> > tests, I will end up removing them completely at some point.  But
> 
> So you even have packages installed on your system which depend
> (implicitly) on the essential package set they were released with,
> which
> includes sysvinit. Your system is therefore broken at the moment and
> libapt tools are trying to fix that.
> 
> The packages happen not to use that old-essential package (maybe, who
> knows without checking), but they could at any point in time. Perhaps
> they malfunction already and you just haven't noticed yet… You have
> to
> thank your tools that they try to help you to the best of their
> abilities!

:)

Sure for the general case, but (to just take my situation as an example)
I doubt that a couple of video libs and tools have such a tight coupling
the essential packages.  I'm still feeling that I know what I'm doing :)

Bug#836265: aptitude: keeps reselecting sysvinit

[ydirson]

- Mail original -
> De: "Sven Joachim" 
> À: ydir...@free.fr
> Cc: "Axel Beckert" , 836...@bugs.debian.org
> Envoyé: Jeudi 1 Septembre 2016 12:24:59
> Objet: Re: Bug#836265: aptitude: keeps reselecting sysvinit
> 
> On 2016-09-01 11:58 +0200, ydir...@free.fr wrote:
> 
> > - Mail original -
> >> I don't see sysvinit being Essential anymore in unstable:
> >> 
> >> → apt-cache show sysvinit | fgrep -i Essential
> >>  This package depends on init, which is an essential package that
> >> →
> >> 
> >> Any chance that you have stable/jessie in your sources.list, too?
> >
> > Yes: wheezy, jessie, testing, unstable, experimental.
> 
> Actually only the wheezy version of sysvinit is essential, and you
> might
> want to remove that suite from your sources.list (mixing oldstable
> and
> unstable is not supported).

I only have a couple of non-essential packages from wheezy for some
tests, I will end up removing them completely at some point.  But
having the sources.list entry still allows for getting info really quickly
and I'll likely keep it around for some time.

> >> If so, the bug might be that aptitude considers any version
> >> essential
> >> even if only a non-candidate version is marked as essential.
> 
> Note that apt behaves the same way, see #216768.  See also the
> changelog
> entry for 0.8.1-1:
> 
> ,
> | aptitude (0.8.1-1) unstable; urgency=low
> | [...]
> | - Bug fixes:
> |   * Install new Essential or Required packages with the
> |   commands
> | "full-upgrade" (command line) and MarkUpgradable ('U' in
> | the curses
> | interface) (Closes: #555896, #757028)
> `

I see, but here it's not even the case of a new Essential package.
I agree that new aptitude does not have to support wheezy->jessie
upgrade, so it's not a very serious bug, just annoying :)

Bug#836265: [Aptitude-devel] Bug#836265: aptitude: keeps reselecting sysvinit

[ydirson]

- Mail original -
> I don't see sysvinit being Essential anymore in unstable:
> 
> → apt-cache show sysvinit | fgrep -i Essential
>  This package depends on init, which is an essential package that
> →
> 
> Any chance that you have stable/jessie in your sources.list, too?

Yes: wheezy, jessie, testing, unstable, experimental.

> If so, the bug might be that aptitude considers any version essential
> even if only a non-candidate version is marked as essential.

Looks like.  "apt-cache show" confirms that 2.88dsf-41+deb7u1 is Essential
but that 2.88dsf-59 and 2.88dsf-59.7 are not, whereas aptitude shows
"Essential: yes" for all of them.

Bug#836068: tightvnc: version 1.3.10

[ydirson]

Package: tightvnc
Version: 1.3.9-8
Severity: wishlist

Although develelopment seems to have stopped in this software, the latest 
version on
http://www.tightvnc.com/download-old.php is more recent than ours.

Bug#835046: apt-listchanges: complains about InfoFD after upgrade

[ydirson]

Package: apt-listchanges
Version: 3.3

After an upgrade in aptitude, which notified me of changes in the config file, 
and for which the
config file was properly replaced by the new version, I get the following when 
I request
installation of a new package from the same aptitude session:

apt-listchanges: APT_HOOK_INFO_FD environment variable is incorrectly defined
(Dpkg::Tools::Options::/usr/bin/apt-listchanges::InfoFD should be greater than 
2).
E: Sub-process /usr/bin/apt-listchanges --apt || test $? -ne 10 returned an 
error code (1)
E: Failure running script /usr/bin/apt-listchanges --apt || test $? -ne 10
Press Return to continue, 'q' followed by Return to quit.


I apparently have to exit/restart aptitude so that the apt.conf files get 
refreshed, and
then I'm able to install packages again.

Bug#831825: clarification request

[ydirson]

severity 831825 important
tags 831825 + unreproducible moreinfo
reassign 831825 gcompris-qt
thanks


Let's lower the severity as it seems not to impact all users.

Trying to reproduce, I'm puzzled by the description, as gcompris does not
have a bottom-left menu, although gompris-qt has one.  I'm thus assuming
it is a gcompris-qt bug and reassigning.

Best regards,
Yann

Bug#833630: scalpel: performance decreases with running time

[ydirson]

Another test, more closely monitored, with the same set of 100 1024-bytes 
patterns,
carving a 1TB SATA drive, with defines updated to avoid buffer overflows:

+--- scalpel-1.60.orig/scalpel.h
 scalpel-1.60/scalpel.h
+@@ -143,11 +143,10 @@ void setProgramName(char *s);
+ 
+ 
+ #define SCALPEL_BLOCK_SIZE   512
+-#define MAX_STRING_LENGTH4096
+-#define MAX_NEEDLES   254
++#define MAX_STRING_LENGTH5000
+ #define NUM_SEARCH_SPEC_ELEMENTS6
+ #define MAX_SUFFIX_LENGTH   8
+-#define MAX_FILE_TYPES100
++#define MAX_FILE_TYPES600
+ 
+ #define MAX_FILES_PER_SUBDIRECTORY1000
+ 


elapsed  %done  ETA
1h   10.5%   8:28
2h   16.4%  10:12
3h   27.4%   7:59
4h   37.7%   6:32
5h   55.1%   4:03  # inflexion point
6h   62.4%   3:36
7h20 63.6%   4:14
8h   64.2%   4:30
9h   65.0%   4:50
10h  65.8%   5:09

16h2571.6%   6:32

Bug#833649: scalpel: no check for overflow while reading patterns

[ydirson]

Package: scalpel
Version: 1.60-1
Severity: important

Although the buffer used to hold a line is larger than in the original
foremost code, it still does not check that the buffer really holds a
complete line, and strtok will happily corrupt data outside of the
buffer when a line is large enough.  Checking the output of fgets
ought to be sufficient to catch the problem and tell the user to
increase MAX_STRING_LENGTH.

See #833639 for the foremost bug.

Also note that 2.0 is no better in this respect.

Also note that processSearchSpecLine hardcodes a 6 in the tokenarray
malloc call, instead of using NUM_SEARCH_SPEC_ELEMENTS.

Bug#632689: scalpel: upstream changed

[ydirson]

Taking a look at the 2.0 source code from the sleuthkit repo, we can see
a small issue with that version:

It looks like it uses PASCAL-style prefix-length strings to store patterns, 
which
prevents to use patterns larger than 256 bytes.  Why on earth not using a
struct to keep the size in an explicit field !?


- Mail original -
> De: ydir...@free.fr
> À: 632...@bugs.debian.org
> Envoyé: Dimanche 7 Août 2016 11:36:17
> Objet: scalpel: upstream changed
> 
> Looking for 2.0 source, one rapidly notices that the upstream
> Homepage
> is not valid any more.
> 
> Digging a bit:
> * Fedora seems to have an upstream tarball at
>   
> http://pkgs.fedoraproject.org/lookaside/pkgs/scalpel/scalpel-2.0.tar.gz/b0da813bf34941e79209d7fafe86a6e6/
> * http://fossies.org/linux/misc/scalpel-2.0.tar.gz/ points to
>   https://github.com/sleuthkit/scalpel, which appears to be 2.0 +
>   some patches, but
>   was last changed in 2014
> 
> 

Bug#833642: foremost: hardcoded limit of 50 patterns is not enforced, segfault

[ydirson]

Package: foremost
Version: 1.5.7-5
Severity: important

main.h: s_spec search_spec[50];  /*ARRAY OF BUILTIN SEARCH TYPES*/

Feeding a config with a large number of entries causes a buffer overflow.
It segfaults for my large config, but someone with 51 entries could have
funny surprises...

Bug#833639: foremost: cryptic/suspicious error message about config parsing and corrupts memory when lines are longer than 1024 bytes

[ydirson]

Package: foremost
Version: 1.5.7-5
Severity: important

When forging a config file with 100 big (1024-bytes) patterns, I get the
message "ERROR: In line 2 of the configuration file."

That:
* does not tell what the problem is
* is suspect because there is no reason why line 1 would have worked and
  not line 2, they have the same structure.  Nevertheless a 1-line config
  file does not report the error.
* does not give a clue about whether line 3 and later are even looked at

Furthermore, the config-parsing code issuing this message is quite strangely
formulated.


What happens is that read buffer is sized by MAX_STRING_LENGTH, which is defined
to be 1024, but the code does not check that it indeed got a line, and strtok
(which sucks) will happily corrupt memory after the buffer.  Which luckily I
didn't have the time to suffer from, but well...

Furthermore, this MAX_STRING_LENGTH is at the
same time the max length for a line, and the max length for suffix, header,
and footer.  A bit of nonsense, I would say.

Bug#833638: foremost: does not completely honor build opts

[ydirson]

Package: foremost
Version: 1.5.7-5
Tags: patch

Only adding flags to the default -O2 will not allow build option "noopt" to 
work.

From faa2c13f600818fc2aac0c293ff55a2935265041 Mon Sep 17 00:00:00 2001
From: Yann Dirson 
Date: Sun, 7 Aug 2016 13:46:04 +0200
Subject: [PATCH] Fix build to honor flags set by dh

---
 debian/changelog|  7 +++
 debian/patches/fix-hurd-and-kfreebsd-build.patch|  8 +---
 debian/patches/fix-hurd-max-path.patch  |  8 +---
 debian/patches/fix-lintian-hardening-warnings.patch | 16 +---
 debian/patches/series   |  1 +
 5 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index c92258a..133fc97 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+foremost (1.5.7-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build to honor flags set by dh.
+
+ -- Yann Dirson   Sun, 07 Aug 2016 13:18:25 +0200
+
 foremost (1.5.7-5) unstable; urgency=medium
 
   * Update maintainer email address.
diff --git a/debian/patches/fix-hurd-and-kfreebsd-build.patch b/debian/patches/fix-hurd-and-kfreebsd-build.patch
index 10d11e6..93434bb 100644
--- a/debian/patches/fix-hurd-and-kfreebsd-build.patch
+++ b/debian/patches/fix-hurd-and-kfreebsd-build.patch
@@ -1,8 +1,10 @@
 Fixed hurd-i386, kfreebsd-i386 and kfreebsd-amd64 build by adding its
 respective rules to Makefile.
 a/Makefile
-+++ b/Makefile
-@@ -76,6 +76,8 @@
+Index: debian-pkg-foremost/Makefile
+===
+--- debian-pkg-foremost.orig/Makefile
 debian-pkg-foremost/Makefile
+@@ -74,6 +74,8 @@ mac: goals
  netbsd:  unix
  openbsd: unix
  freebsd: unix
diff --git a/debian/patches/fix-hurd-max-path.patch b/debian/patches/fix-hurd-max-path.patch
index 8016ea9..22ebec3 100644
--- a/debian/patches/fix-hurd-max-path.patch
+++ b/debian/patches/fix-hurd-max-path.patch
@@ -1,7 +1,9 @@
 Fix FTBFS of hurd-i386 by defining the missing PATH_MAX macro.
 a/Makefile
-+++ b/Makefile
-@@ -76,7 +76,10 @@
+Index: debian-pkg-foremost/Makefile
+===
+--- debian-pkg-foremost.orig/Makefile
 debian-pkg-foremost/Makefile
+@@ -74,7 +74,10 @@ mac: goals
  netbsd:  unix
  openbsd: unix
  freebsd: unix
diff --git a/debian/patches/fix-lintian-hardening-warnings.patch b/debian/patches/fix-lintian-hardening-warnings.patch
index 0d5af69..3c49163 100644
--- a/debian/patches/fix-lintian-hardening-warnings.patch
+++ b/debian/patches/fix-lintian-hardening-warnings.patch
@@ -1,18 +1,4 @@
-Add hardening flags to compilation. Fix a format string in order to do
-so.
 a/Makefile
-+++ b/Makefile
-@@ -37,7 +37,9 @@
- WINCC = $(RAW_CC) $(RAW_FLAGS) -D__WIN32
- 
- # Generic "how to compile C files"
--CC = $(RAW_CC) $(RAW_FLAGS) -D__UNIX
-+CC = $(RAW_CC) $(RAW_FLAGS) -D__UNIX $(shell dpkg-buildflags --get CFLAGS)\
-+	$(shell dpkg-buildflags --get CPPFLAGS) \
-+	$(shell dpkg-buildflags --get LDFLAGS)	
- .c.o:   
- 	$(CC) -c $<
- 
+Fix a format string in order to add hardening flags.
 --- a/extract.c
 +++ b/extract.c
 @@ -2145,7 +2145,7 @@
diff --git a/debian/patches/series b/debian/patches/series
index 7308fb4..a6b8af7 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ fix-config-file-path.patch
 fix-lintian-hardening-warnings.patch
 fix-hurd-and-kfreebsd-build.patch
 fix-hurd-max-path.patch
+fix-make-flags.patch
-- 
2.8.1

Bug#632689: scalpel: upstream changed

[ydirson]

Looking for 2.0 source, one rapidly notices that the upstream Homepage
is not valid any more.

Digging a bit:
* Fedora seems to have an upstream tarball at
  
http://pkgs.fedoraproject.org/lookaside/pkgs/scalpel/scalpel-2.0.tar.gz/b0da813bf34941e79209d7fafe86a6e6/
* http://fossies.org/linux/misc/scalpel-2.0.tar.gz/ points to
  https://github.com/sleuthkit/scalpel, which appears to be 2.0 + some patches, 
but
  was last changed in 2014

Bug#833630: scalpel: performance decreases with running time

[ydirson]

Package: scalpel
Version: 1.60-1
Severity: important

Running scalpel on a 1TB drive with 100 patterns of 1024 bytes each:
* ETA some time after starting stabilized around 11h (as I recall it, but this
  number is superfluous, the next ones talk loud enough)
* after 11h run it has done 63% and the ETA is still in 6h
* after 9h more it has done 68% and ETA is now up to 9h

That does not quite match everyone's idea of high performance, there has
to be a problem.

Bug#832797: sgt-puzzles: missing menu entries

[ydirson]

Package: sgt-puzzles
Version: 20160429.b31155b-1

At least sgt-undead is not in the /usr/share/menu/ declaration - and since for 
some
reason (too many entries?) lxqt does not list all games from desktop files, the 
only
way to launch it from lxqt seems to be from cmdline.