Bug#963921: O: inputlirc -- Zeroconf LIRC daemon using input event devices

[Guus Sliepen]

On Wed, Apr 17, 2024 at 01:10:14PM +0200, Petter Reinholdtsen wrote:

> [Guus Sliepen 2020-06-28]
> > I'm also the upstream maintainer of this package, if you are interested
> > in maintaining it you are welcome to take over upstream maintainership
> > as well.
> 
> Is there a upstream home page for this project?  The one listed in
> d/copyright did not work (http://svn.sliepen.eu.org/inputlirc/ >).

Ouch that copyright file is old... 😅 Use this one:

https://git.sliepen.org/inputlirc

Or these mirrors:

https://github.com/gsliepen/inputlirc
https://gitlab.com/gsliepen/inputlirc

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#1020712: wireless-tools: Upstream contact all do no longer work

[Guus Sliepen]

On Mon, Sep 26, 2022 at 06:23:01PM +0200, Helge Kreutzmann wrote:

> Thanks for the heads up. Do you have a working e-mail address?

I only know of j...@hpl.hp.com, sorry.

> And I just checked, for me the site
> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
> consistently times out. Strange.

Indeed. But it seems it hasn't been updated since 2008 anyway, and
doesn't have any other email address.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#1020712: wireless-tools: Upstream contact all do no longer work

[Guus Sliepen]

On Sun, Sep 25, 2022 at 07:57:28PM +0200, Helge Kreutzmann wrote:

> I tried to contact upstream, however, this is not possible. The e-mail
> address 
> j...@hpl.hp.com
> times out, as does the homepage you reference:
> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html

The website works for me. He has been a co-author on networking related
papers even this year, so he is still active in his field, but it's been
a long time since he has worked on Wireless Tools (which has been
deprecated for a long time now).

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#1020619: libstdc++-arm-none-eabi-newlib: Fails to install because of incorrect versioned depency on gcc-arm-none-eabi

[Guus Sliepen]

Package: libstdc++-arm-none-eabi-newlib
Version: 15:10.3-2021.07-4+20
Severity: serious
Justification: Policy 2.2.1

This package depends on gcc-arm-none-eabi (= 15:10.3-2021.07-4), however
the latter version does not exist in main because there has been a
binNMU, so the version present is 15:10.3-2021.07-4+b1.


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libstdc++-arm-none-eabi-newlib depends on:
ii  gcc-arm-none-eabi15:10.3-2021.07-4+b1
ii  libnewlib-arm-none-eabi  3.3.0-1.3
ii  libnewlib-dev3.3.0-1.3
pn  libstdc++-arm-none-eabi-dev  

Versions of packages libstdc++-arm-none-eabi-newlib recommends:
ii  binutils-arm-none-eabi  2.38.90.20220713-2+17
ii  gcc-arm-none-eabi   15:10.3-2021.07-4+b1

libstdc++-arm-none-eabi-newlib suggests no packages.

Bug#821926: Group upload of geolocation enable fgallery (Was: Please support geolocation)

[Guus Sliepen]

On Sat, Apr 02, 2022 at 07:00:15PM +0200, Andreas Tille wrote:

> I've seen that you updated the packaging of fgallery in Git.  I'd like
> to join you as Uploader of this package and would love to inject my
> patch for geolocation.  I'm using my patch since six years now
> successfully.  It seems upstream is dead and so I think if we want
> to provide this functionality to our users we are on our own.  I'm
> happily support this patch since I use it in all my galleries.

As a bystander, I would say: great idea! Maybe even better would be to
check with the original upstream to see if you can take over? That way
not just Debian will benefit from your geolocation patch.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#990955: unblock: mstch/1.0.2-3

[Guus Sliepen]

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

Please unblock package mstch

[ Reason ]
Fixes release-critical bug 951647.

[ Impact ]
No packages in Debian depend on this library, but it would cause libmstch-dev
to be removed from Buster, preventing people from installing it.

[ Tests ]
Manual test has been done to confirm that the bugs have been fixed.

[ Risks ]
The change is trivial, and consists of moving a CMake configuration file
into an arch-specific directory where it belongs.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock mstch/1.0.2-3
diff -Nru mstch-1.0.2/debian/changelog mstch-1.0.2/debian/changelog
--- mstch-1.0.2/debian/changelog2018-01-03 00:35:05.0 +0100
+++ mstch-1.0.2/debian/changelog2021-07-11 14:18:54.0 +0200
@@ -1,3 +1,12 @@
+mstch (1.0.2-3) unstable; urgency=medium
+
+  * Bump Standards-Version.
+  * Add Rules-Requires-Root: no.
+  * Fix installation directory for the CMake configuration file.
+Closes: #951647, #897342
+
+ -- Guus Sliepen   Sun, 11 Jul 2021 14:18:54 +0200
+
 mstch (1.0.2-2) unstable; urgency=medium
 
   * Fix grammar in debian/control.
diff -Nru mstch-1.0.2/debian/control mstch-1.0.2/debian/control
--- mstch-1.0.2/debian/control  2018-01-03 00:33:44.0 +0100
+++ mstch-1.0.2/debian/control  2018-01-09 19:32:09.0 +0100
@@ -2,9 +2,10 @@
 Priority: optional
 Maintainer: Guus Sliepen 
 Build-Depends: debhelper (>= 10), cmake (>= 3.0), libboost-dev (>= 1.54)
-Standards-Version: 4.1.2
+Standards-Version: 4.1.3
 Section: libs
 Homepage: https://github.com/no1msd/mstch
+Rules-Requires-Root: no
 
 Package: libmstch-dev
 Section: libdevel
diff -Nru mstch-1.0.2/debian/patches/fix-lib-dir 
mstch-1.0.2/debian/patches/fix-lib-dir
--- mstch-1.0.2/debian/patches/fix-lib-dir  2018-01-02 16:59:55.0 
+0100
+++ mstch-1.0.2/debian/patches/fix-lib-dir  2021-07-11 14:17:41.0 
+0200
@@ -11,7 +11,7 @@
  
  install(
  FILES "${PROJECT_SOURCE_DIR}/include/mstch/mstch.hpp"
-@@ -55,7 +55,7 @@
+@@ -55,10 +55,10 @@
  EXPORT mstchTargets
  FILE mstch-targets.cmake
  NAMESPACE mstch::
@@ -20,3 +20,7 @@
  
  install(FILES
  "${PROJECT_SOURCE_DIR}/cmake/mstch-config.cmake"
+ "${CMAKE_CURRENT_BINARY_DIR}/mstch/mstch-config-version.cmake"
+-DESTINATION lib/cmake/mstch
++DESTINATION lib/${CMAKE_LIBRARY_PATH}/cmake/mstch
+ COMPONENT Devel)

Bug#868220: Bug#979963: bridge-utils: bridge often collapses when removing USB WiFi dongle

[Guus Sliepen]

On Wed, Feb 24, 2021 at 03:04:18PM +0100, Santiago Garcia Mantinan wrote:

> > Looking at the debdiff, I notice that upstream considers this package
> > as deprecated and recommends using the 'bridge' command from iproute2.
> > Is there any plan to migrate bridge-utils-interfaces to use this?
> 
> Well, kind of, I mean, on some of the bugs, at least on #868220, we've
> have talked about this. And given that upstream has been inactive for
> years... we have talked about getting the bridge setup scripts on
> ifupdown and leave bridge-utils with just the brctl tool.
> 
> I'm crossposting and adding Guus to the mail to see if we can agree on
> something here, I don't think it is now the time to do it, it would be
> for post Bullseye, but I don't have any problem in rewriting the
> scripts to use just iproute2 and maintain those scripts under ifupdown
> so that Guus didn't have to take care of more stuff.

Moving to the bridge command from iproute2 soon would be best, however
whether the bridge-utils package does it or ifupdown doesn't really
matter. At this point, I think it can still be done in bridge-utils,
migrating functionality between packages during the soft-freeze is
probably a no-go.

I did something similar in the past for the ifenslave package: it used
to be a compiled C program from the kernel sources that was shipped, at
some point I replaced it with a shell script that just echoed the right
values into the /sys/class/net/ hierarchy. The brctl command is very
simple, and the same thing could be done there. The hardest part would
be to emulate the output of `brctl show`. For the if-*.d scripts this is
not an issue of course.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#963929: O: rsh-redone -- Reimplementation of rsh and rlogin

[Guus Sliepen]

On Tue, Jun 30, 2020 at 10:27:10AM +0200, Albert van der Horst wrote:

> > [...] However, since no-one should be using RSH
> > in this day and age anymore, if no one is interested I will request
> > removal of this package.
> 
> I connect to xxx pi with linux/android using rlogin/rsh all the time.
> Isn't it a basic simple functionality?
> Why "should" I not be using rsh?
> What could I use instead, hooking up a vt100 via an usb to RS232 interface
> is not very practical?

You should use SSH, as it is much more secure. It made sense to use RSH
more than twenty years ago, when encryption took a lot of CPU time and
networks were more friendly. But nowadays, even the smallest systems
running Linux will have no problem running SSH, and even networked
microcontrollers like the ESP8266 can run an SSH server. 

However if you feel strongly about this and want to keep using RSH, then
you are welcome to take over maintenance of this package yourself, or
try to find someone else that could take over. I won't file a removal
request if there are more people wanting to keep it, but it would be
better if it didn't just linger in the archive without a proper
maintainer.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#963930: O: starfighter -- 2D scrolling shooter game

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the starfighter package.

I no longer have time to maintain this package. This game is actively
maintained, and there are newer upstream versions of this game that
should be packaged:

https://github.com/pr-starfighter/starfighter/releases

The package description is:
 After decades of war one company, who had gained powerful supplying both
 sides with weaponry, steps forwards and crushes both warring factions
 in one swift movement. Using far superior weaponry and AI craft, the
 company was completely unstoppable and now no one can stand in their
 way. Thousands began to perish under the iron fist of the company. The
 people cried out for a saviour, for someone to light this dark hour...
 and someone did.
 .
 Features of the game:
 .
  o 26 missions over 4 star systems
  o Primary and Secondary Weapons (including a laser cannon and a charge weapon)
  o A weapon powerup system
  o Wingmates
  o Missions with Primary and Secondary Objectives
  o A Variety of Missions (Protect, Destroy, etc)
  o Boss battles

Bug#963929: O: rsh-redone -- Reimplementation of rsh and rlogin

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the rsh-redone package.

I no longer have time to maintain this. I am also the upstream author of
this; if you want to adopt the package, you are also welcome to take
over upstream maintainership. However, since no-one should be using RSH
in this day and age anymore, if no one is interested I will request
removal of this package.

The package description is:
 Rsh-redone is a reimplementation of the remote shell clients and servers.
 It is written from the ground up to avoid the bugs found in the standard
 clients and servers. It also fully supports IPv6.
 .
 This package provides rsh and rlogin.

Bug#963928: O: omega-rpg -- text-based roguelike game

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the omega-rpg package.

I no longer have time to maintain this package.

The package description is:
 Omega is a complex rogue-style game of dungeon exploration. Unlike other such
 games, there are a number of ways to "win", depending on various actions
 taken during play. The ways you can get your name on the high score board
 include becoming the highest ranked head of a guild, sect, college, etc., as
 well as gaining the most points figured from possessions and experience. The
 game (via the oracle) may impose some structure on your exploration, but you
 need not follow all of the oracle's advice. There *is* a "total winner"
 status, by the way.

Bug#963925: O: mod-mime-xattr -- Apache2 module to get MIME info from filesystem extended attributes

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the mod-mime-xattr package.

Upstream has stopped maintaining this a long time ago, and there are
only few users according to popcon. If there is no interest in it, I
will request a removal.

The package description is:
 This is a module for the Apache HTTPD 2.4 which may be used to set a range of
 MIME properties of files served from a document tree with extended attributes
 (EAs) as supported by the underlying file system. The following attributes may
 be used:
 .
  - user.mime_type: set the MIME type of a file explicitly. This attribute is
compatible with the shared MIME database specification as published by
freedesktop.org.
  - user.charset: set the charset used in a file.
  - user.mime_encoding: set the MIME encoding of a file (e.g. gzip).
  - user.apache_handler: set the apache handler of a file explicitly.
 This is a module for the Apache HTTPD 2.4 which may be used to set a range of
 MIME properties of files served from a document tree with extended attributes
 (EAs) as supported by the underlying file system. The following attributes may
 be used:
 .
  - user.mime_type: set the MIME type of a file explicitly. This attribute is
compatible with the shared MIME database specification as published by
freedesktop.org.
  - user.charset: set the charset used in a file.
  - user.mime_encoding: set the MIME encoding of a file (e.g. gzip).
  - user.apache_handler: set the apache handler of a file explicitly.

Bug#963926: O: mstch -- Mustache implementation in C++11

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the mstch package.

The package description is:
 Mstch is a complete implementation of {{mustache}} templates using
 modern C++. It's compliant with specifications v1.1.3, including the
 lambda module.
 .
 Mustache is a logic-less template language. As such, it is very well
 suited for programs that are written in a compiled language, such as C
 and C++, as they cannot easily evaluate code found in a template.
 Mustache does however supports a simple conditional and a loop statement.
 .
 This package contains the header files and a static library.

Bug#963924: O: libdc1394-22 -- high level programming interface for IEEE 1394 digital cameras

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the libdc1394-22 package.

Note that libdc1394 replaces libdc1394-22, but this transition has not
finished.

The package description is:
 libdc1394 is a library that is intended to provide a high level
 programming interface for application developers who wish to control
 IEEE 1394 based cameras that conform to the 1394-based Digital Camera
 Specification (found at http://www.1394ta.org/).
 .
 This version of libdc1394 supports both the old and new (juju) FireWire stack.
 It automatically detects which one to use at runtime.
 .
 This package contains shared libraries.
 libdc1394 is a library that is intended to provide a high level
 programming interface for application developers who wish to control
 IEEE 1394 based cameras that conform to the 1394-based Digital Camera
 Specification (found at http://www.1394ta.org/).
 .
 This version of libdc1394 supports both the old and new (juju) FireWire stack.
 It automatically detects which one to use at runtime.
 .
 This package contains shared libraries.

Bug#963923: O: libdc1394 -- high level programming interface for IEEE 1394 digital cameras

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the libdc1394 package.

There is occasional upstream activity for this package. At the moment
there are no reverse dependencies, but this package replaces
libdc1394-22, and the new maintainer should ensure the transition from
libdc1394-22 to libdc1394 is completed.

The package description is:
 libdc1394 is a library that is intended to provide a high level
 programming interface for application developers who wish to control
 IEEE 1394 based cameras that conform to the 1394-based Digital Camera
 Specification (found at http://www.1394ta.org/).
 .
 This version of libdc1394 supports both the old and new (juju) FireWire stack.
 It automatically detects which one to use at runtime.
 .
 This package contains shared libraries.

Bug#963920: O: fgallery -- static HTML+JavaScript photo album generator

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the fgallery package.

There has been no upstream activity in the last 4 years, but apart from
that the package is working as intended. This program generates very
nice, mobile-friendly and responsive galleries.

The package description is:
 “fgallery” is a static photo gallery generator with no frills that has a
 stylish, minimalist look. “fgallery” shows your photos, and nothing else.
 .
 There is no server-side processing, only static generation. The resulting
 gallery can be uploaded anywhere without additional requirements and works with
 any modern browser.
 .
  * Automatically orients pictures without quality loss.
  * Multi-camera friendly: automatically sorts pictures by time: just throw your
(and your friends) photos and movies in a directory. The resulting gallery
shows the pictures in seamless shooting order.
  * Adapts to the current screen size and proportions, switching from
horizontal/vertical layout and scaling thumbnails automatically.
  * Includes original (raw) pictures in a zip file for downloading.
  * Panoramas can be seen full-size by default.

Bug#963921: O: inputlirc -- Zeroconf LIRC daemon using input event devices

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the inputlirc package.

I'm also the upstream maintainer of this package, if you are interested
in maintaining it you are welcome to take over upstream maintainership
as well.

The package description is:
 This is a small LIRC-compatible daemon that reads from /dev/input/eventX
 devices and sends the received keycodes to connecting LIRC clients. Inputlircd
 needs no configuration, it uses the standardised names for the keycodes as
 used by the kernel. Many USB remote controls that present HID devices, as well
 as multimedia keyboards should work out of the box.
 This is a small LIRC-compatible daemon that reads from /dev/input/eventX
 devices and sends the received keycodes to connecting LIRC clients. Inputlircd
 needs no configuration, it uses the standardised names for the keycodes as
 used by the kernel. Many USB remote controls that present HID devices, as well
 as multimedia keyboards should work out of the box.

Bug#963917: O: dhis-tools-dns -- Dynamic Host Information System - DNS configuration tools

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the dhis-tools-dns package.

According to popcon, there is very little interest in this package. If
no one will adopt it, I will request removal.

The package description is:
 This package includes a set of tools that may be used to manually
 create DHIS records on a dynamic DNS server.

Bug#963912: O: dhis-client -- Dynamic Host Information System - client

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the dhis-client package.

According to popcon, there is very little interest in this package. If
no one will adopt it, I will request removal.

The package description is:
 dhid is the DHIS client daemon. After setting up with a DHIS provider,
 each machine may run a dhid daemon (in background) in order to
 update its dynamic IP address within the server.

Bug#963913: O: dhis-server -- Dynamic Host Information System - server

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the dhis-server package.

According to popcon, there is very little interest in this package. If
no one will adopt it, I will request removal.


The package description is:
 DHIS is a client-server architecture meant to update databases
 for systems which are assigned a dynamic IP[v4] address.
 .
 By the means of a DHIS client a host which is assigned a dynamic
 IP address (either from its ISP or from DHCP) is able to
 communicate with a DHIS server in order to advertise its newly
 acquired IP address.

Bug#963915: O: dhis-mx-sendmail-engine -- Dynamic Host Information System - sendmail MX engine

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the dhis-mx-sendmail-engine package.

According to popcon, there is very little interest in this package. If
no one will adopt it, I will request removal.

The package description is:
 This package contains a mail relaying service module to be used
 with dhisd release 5 or above and the dynamic DNS module.
 .
 While the DHIS server dhisd retrieves dynamic IP addresses
 from clients, this module allows the server to deliver messages
 that were previously queued for the newly online host.

Bug#963914: O: dhis-dns-engine -- Dynamic Host Information System - DNS engine

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the dhis-dns-engine package.

According to popcon, there is very little interest in this package. If
no one will adopt it, I will request removal.

The package description is:
 This package contains a dynamic DNS service module to be used
 with dhisd release 5 or above.
 .
 While the DHIS server dhisd retrieves dynamic IP addresses
 from clients, this module allows the server to update a
 dynamic DNS zone based on those retrieved IP addresses.

Bug#963911: O: coriander -- control IEEE1394 digital camera

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the coriander package.

This is a live camera viewer for Firewire and USB Vision cameras (mainly
industrial and scientific cameras, not webcams). It is not being
maintained upstream anymore, but it is otherwise functional.

The package description is:
 Coriander is a GUI that lets you view camera images and control all the
 features of an IEEE-1394 Digital Camera complying with the DC Specifications
 v1.04 or later (see http://www.1394ta.org).

Bug#963910: O: blobwars -- platform shooting game

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the blobwars package.

This game has no active upstream developers, but it is in a very good
state. There are some minor bugs that could be fixed.

The package description is:
 Blob Wars: Metal Blob Solid is a 2D platform game. It is the first in the Blob
 Wars series.
 .
 Since their world was invaded by an alien race, the Blobs have faced a
 lifetime of war. But now they have a chance to win the war once and for
 all.
 .
 In Blob Wars: Metal Blob Solid, you take on the role of a fearless Blob
 agent, Bob. Bob's mission is to infiltrate the various enemy bases around
 the Blobs' homeworld and rescue as many MIAs as possible. But standing in
 his way are many vicious aliens, other Blobs who have been assimilated and
 the evil alien leader, Galdov.
 Blob Wars: Metal Blob Solid is a 2D platform game. It is the first in the Blob
 Wars series.
 .
 Since their world was invaded by an alien race, the Blobs have faced a
 lifetime of war. But now they have a chance to win the war once and for
 all.
 .
 In Blob Wars: Metal Blob Solid, you take on the role of a fearless Blob
 agent, Bob. Bob's mission is to infiltrate the various enemy bases around
 the Blobs' homeworld and rescue as many MIAs as possible. But standing in
 his way are many vicious aliens, other Blobs who have been assimilated and
 the evil alien leader, Galdov.

Bug#963909: O: blobandconquer -- 3D platform shooting game

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the blobandconquer package.

Due to the original game having undistributable music, sound and
graphics assets, this game is not very interesting to play. The upstream
developers are also not maintaining this game anymore. If you wish to
take over this package, some effort should be put into replacing all the
assets with DFSG-compatible ones. If there is no interest, I will ask
for removal of this package.

The package description is:
 Blob Wars episode II: Blob and Conquer is the sequel to Blob Wars:
 Metal Blob Solid.
 .
 With the apparent defeat of Galdov and the reclaiming of the Fire,
 Time, Space and Reality Crystals the Blobs' battle was only just
 beginning. Bob had rescued many Blobs and fought many battles, but now
 he had an ever bigger task ahead of him. The Blobs' homeworld is still
 littered with the alien forces and Bob once again makes it his task to
 lead the counter attack. But even without Galdov the aliens are still
 extremely well organised...
 Blob Wars episode II: Blob and Conquer is the sequel to Blob Wars:
 Metal Blob Solid.
 .
 With the apparent defeat of Galdov and the reclaiming of the Fire,
 Time, Space and Reality Crystals the Blobs' battle was only just
 beginning. Bob had rescued many Blobs and fought many battles, but now
 he had an ever bigger task ahead of him. The Blobs' homeworld is still
 littered with the alien forces and Bob once again makes it his task to
 lead the counter attack. But even without Galdov the aliens are still
 extremely well organised...

Bug#963901: O: glm -- C++ library for OpenGL GLSL type-based mathematics

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the glm package.

I no longer have time to maintain this package. GLM is used by quite a
lot of applications that render 3D graphics using OpenGL and Vulkan, and
might be used outside that as well due to its excellent implementation
of vector and matrix operations of up to 4(x4) components. Since it is a
header-only library, there only are build-dependencies, which means its
use isn't reflected by the popcon statistics.

This package is in very good shape with no open bugs, in great part due
to upstream being very responsive to bug reports that are forwarded to
them.

The package description is:
 OpenGL Mathematics (GLM) is a header only C++ mathematics library for graphics
 software based on the OpenGL Shading Language (GLSL) specification.
 .
 GLM provides classes and functions designed and implemented with the same
 naming conventions and functionalities as GLSL, so that when a programmer
 knows GLSL, he knows GLM as well, which makes it really easy to use.
 .
 This project isn't limited to GLSL features. An extension system, based on the
 GLSL extension conventions, provides extended capabilities: matrix
 transformations, quaternions, half-based types, random numbers, et cetera.
 .
 This library works perfectly together with OpenGL but it also ensures
 interoperability with other third party libraries and SDKs. It is a good
 candidate for software rendering (such as raytracing, rasterisation), image
 processing, physic simulations and any context that requires a simple and
 convenient mathematics library.

Bug#963896: O: wireless-tools -- Tools for manipulating Linux Wireless Extensions

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the wireless-tools package.

I no longer have time to work on this package. This package implements a
library and binary to perform static configuration of wireless network
interfaces using the legacy Wireless Extensions of the Linux kernel.
Wireless interfaces should now be configured via Netlink, which is what
the iw package does, so ideally wireless-tools should be phased out.
However, there are still some packages that depend on libiw30, which
wireless-tools provides.

The package description is:
 This package contains the Wireless tools, used to manipulate
 the Linux Wireless Extensions. The Wireless Extension is an interface
 allowing you to set Wireless LAN specific parameters and get the
 specific stats.

Bug#963893: O: ifscheme -- scheme control for network interfaces

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the ifscheme package.

I no longer have time to work on this package.

The package description is:
 ifscheme allows you to change network configuration schemes or query the
 current scheme. It integrates with the ifup(8) command and interfaces(5). For
 example, you might use this program to configure a "home" scheme and a "work"
 scheme for a network device on a laptop. When you move between home and work,
 a simple command can reconfigure your networking.

Bug#963891: O: ifupdown -- high level tools to configure network interfaces

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the ifupdown package.

I no longer have time to work on this package. If you are interested in
taking over this package, please make it team-maintained.

ifupdown is Debian's own native network configuration tool, and is more
than 20 years old. A core principle of ifupdown is that it runs only
when an interface is brought up or down; there is no daemon running in
the background that can react to eventsr, although are udev hooks so
that ifupdown is run whenever an interface is being created by the
kernel. ifupdown also offloads a lot of work to its own hook scripts,
and to daemons it starts (such as DHCP client daemons and
wpa_supplicant). Despite all this, it can manage quite complex network
setups, with only a very minimal binary (88 kB on amd64), making it
interesting for low-resource environments.


The package description is:
 This package provides the tools ifup and ifdown which may be used to
 configure (or, respectively, deconfigure) network interfaces based on
 interface definitions in the file /etc/network/interfaces.

Bug#963889: O: ifenslave -- configure network interfaces for parallel routing (bonding)

[Guus Sliepen]

Package: wnpp
Severity: normal

I intend to orphan the ifenslave package.

I no longer have any time to work on it. The package has an important
bug that should be fixed. Linux bonding interfaces use a controversial
naming scheme (master/slave, and the package name itself reflects this).
If you adopt this, I suggest changing the package name to "bonding", and
replace the master/slave terminology with parent/child.

ifenslave used to be a standalone binary that sent ioctls to the kernel,
but nowadays bonding can be configured via the "ip" command from the
iproute2 package, and by writing to the /sys/ tree. The package no
longer contains the standalone binary, but just provides hooks scripts
for ifupdown.


The package description is:
 This is a tool to attach and detach slave network interfaces to a bonding
 device. A bonding device will act like a normal Ethernet network device to
 the kernel, but will send out the packets via the slave devices using a simple
 round-robin scheduler. This allows for simple load-balancing, identical to
 "channel bonding" or "trunking" techniques used in switches.
 .
 The kernel must have support for bonding devices for ifenslave to be useful.
 This package supports 2.6.x kernels and the recent 3.x.x kernels.
 This is a tool to attach and detach slave network interfaces to a bonding
 device. A bonding device will act like a normal Ethernet network device to
 the kernel, but will send out the packets via the slave devices using a simple
 round-robin scheduler. This allows for simple load-balancing, identical to
 "channel bonding" or "trunking" techniques used in switches.
 .
 The kernel must have support for bonding devices for ifenslave to be useful.
 This package supports 2.6.x kernels and the recent 3.x.x kernels.

Bug#959867: ifup kills dhclient on if-up.d script failure

[Guus Sliepen]

On Wed, May 06, 2020 at 12:25:57PM +0200, Sergio Gelato wrote:

> I've now run into this problem on several systems running buster. Whenever
> a script in /etc/network/if-up.d/ fails (see, e.g., #959864) the dhclient
> instance dies. This behaviour may actually predate buster, but is much more
> noticeable now that dhclient-script sets the interface's valid_lft to
> the actual, finite lifetime of the lease (cf. #834532). The result is that
> the system drops off the network when the initial DHCP lease expires.
> 
> I'm not sure how well specified the behaviour of ifup is on script failure;
> I couldn't find it documented. Maybe this needs to be clarified? That's also
> why I've filed a bug against postfix, whose if-up.d script really shouldn't
> be failing so casually.
> 
> Still, doing things halfway (killing dhclient but leaving the interface up)
> doesn't feel right. I'd rather deal with an immediate failure than with a
> delayed one.

I can certainly document the behaviour on script failure (as well as
documenting the order in which things are executed). Cleaning up after a
failure is currently not done. I can partially add that; the problem is
that there is no clearly defined order of what (post-)down commands/scripts 
should
be executed given a failure at a given stage of bringing the interface
up.

However, I can ensure that at least the interface's built-in methods
clean up properly after an error, so that a failing script after the
DHCP client is started will cause the client to be stopped orderly by
ifupdown itself, and the link brought down as well.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#959075: ifupdown: Bonding is not working with ifenslave 2.10 wich removes ifenslave command

[Guus Sliepen]

On Wed, Apr 29, 2020 at 09:21:19AM +0200, Gilles Mocellin wrote:

> Package: ifupdown
> Version: 0.8.35+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> The ifenslave package does not provides ifenslave command anymore
> (starting from 2.10), bonding interface needs to be done with iproute2 :
> # ip link set enp6s0 master bond0
> 
> I think ifupdown uses ifenslave command, because my system does not
> bring my bond anymore.

Hello Gilles,

The ifupdown package itself doesn't provide support for bonding at all,
it is the ifenslave package itself which provides that support. Nothing
should be calling the ifenslave binary anymore.

> # The primary network interface
> auto enp6s0
> iface enp6s0 inet manual
>   ethernet-wol g
> #  offload-lro off
> #  offload-gro off
> 
> auto enp7s0
> iface enp7s0 inet manual
>   ethernet-wol g
> #  offload-lro off
> #  offload-gro off
> 
> auto bond0
> iface bond0 inet manual
>   bond-slaves enp6s0 enp7s0
>   bond-mode balance-alb
>   bond-miimon 100
>   mtu 9000

Hm, that looks fine. Can you try to run:

sudo ifdown -v bond0
sudo ifup -v bond0

And send me a copy of the output? Hopefully that will help narrow down
the issue. Another thing to try is to remove "bond-slaves enp6s0 enp7s0"
from the bond0 stanza, and instead add "bond-master bond0" to the enp6s0
and enp7s0 stanzas.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#945492: ifup/ifdown --all causes hooks to be called not per interface, but once with IFACE==--all

[Guus Sliepen]

severity 945492 wishlist
thanks

On Tue, Nov 26, 2019 at 11:16:56AM +1300, martin f krafft wrote:

> root@lotus:/etc/network/if-pre-up.d# ifup -a
> IFACE==--all
> run-parts: /etc/network/if-pre-up.d/000debug exited with return code 1
> ifup: pre-up script failed
> 
> Arguably, the hooks should be called once for each interface that is 
> brought up/down, with $IFACE set accordingly, not just once for all 
> of them.

It is called for all of them with $IFACE set accordingly, but in
addition, for each invocation of ifup -a, the scripts are run with
IFACE=--all.

This is documented behaviour, and some users' setups might depend on it.
I'll have to check whether this is still used by scripts provided by
other Debian packages, and if not then perhaps we can phase this out.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#946974: systemd: hang waiting for VM ethernet card to come online

[Guus Sliepen]

On Sun, Apr 26, 2020 at 01:09:06PM -0700, Joshua Hudson wrote:

> I suspect it might be confusing since I filed two different eth0-related bugs.
> 
> In this particular instance, the DHCP server was live, and I could
> have omitted the & from the line in rc.local and it would have come up
> only a couple of seconds slower.

Just to be sure, did you have both the /etc/rc.local file trying to run
dhclient AND /etc/network/interfaces set to automatically bring up eth0?
If so, what happens if you just disable rc.local?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#946974: systemd: hang waiting for VM ethernet card to come online

[Guus Sliepen]

Am 18.12.19 um 17:58 schrieb Joshua:

> systemd gets stuck in boot waiting for eth0 to start.
> 
> /etc/network/interfaces looks like:
> 
> source /etc/network/interfaces.d/*
> auto lo
> iface lo inet loopback
> iface eth0 inet dhcp
> 
> /etc/rc.local looks like:
> #!/bin/sh
> dhclient eth0 &
> 
> If I add a line "auto eth0" to interfaces, systemd will hang on boot
> for six and a half minutes, and even so if I remove the dhclient eth0
> line from /etc/rc.local, eth0 will not be brought up.

If you don't have a working DHCP server, then indeed with "auto eth0" it
will wait for the dhclient binary to time out, which can be a long time.
If your setup doesn't require a network to be available before starting
other daemons, then I suggest using "allow-hotplug eth0" instead of
"auto eth0". With allow-hotplug, ifupdown runs in the background
whenever udev detects eth0, and will not block systemd from booting.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#949062: ifupdown: Bonding interface gets the wrong MAC address when configured for the first time

[Guus Sliepen]

reassign 949062 ifenslave
thanks

The bond options are processed by the ifenslave package, so reassigning
it there. The ifenslave package can then install an override for
systemd's MACAddressPolicy.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#943934: ifupdown-wait-online.service is useless with dhcp and dhclient

[Guus Sliepen]

On Fri, Nov 01, 2019 at 09:50:17AM +0500, Alexander E. Patrakov wrote:

> I was trying to configure a service that needs networking to be completely
> configured when it starts, with addresses and the default route. To achieve
> that, I made it depend on network-online.target, and enabled
> ifupdown-wait-online.service. However, after the reboot, the service was
> still started before dhclient assigned the IP address to the interface.
[...]
> Nov 01 09:14:06 dhclient[405]: DHCPDISCOVER on enp0s3 to 255.255.255.255 port 
> 67 interval 7
> Nov 01 09:14:07 wait-online.sh[234]: + up=true
> Nov 01 09:14:07 wait-online.sh[234]: + /sbin/ifquery --state enp0s3
> Nov 01 09:14:07 wait-online.sh[234]: + [ true = true ]
> Nov 01 09:14:07 wait-online.sh[234]: + break
> Nov 01 09:14:07 wait-online.sh[234]: + [ true = true ]
> Nov 01 09:14:07 wait-online.sh[234]: + /sbin/ifquery --state
> Nov 01 09:14:07 wait-online.sh[234]: enp0s3=enp0s3
> Nov 01 09:14:07 wait-online.sh[234]: lo=lo
> Nov 01 09:14:07 systemd[1]: Started Wait for network to be configured by 
> ifupdown.

Indeed, that sounds like a bug. It should have waited for ifup to finish
bringing the interface up.

As a workaround, you can tell wait-online.sh to wait for a route to a
given address to become available. Edit /etc/default/networking, set
WAIT_ONLINE_METHOD to route, and WAIT_ONLINE_ADDRESS to the address you
want to wait for to become reachable.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#942258: Logs from boot

[Guus Sliepen]

On Sun, Oct 13, 2019 at 11:05:23AM +0100, Alex DEKKER wrote:

> This is what happens without dad-attempts 0 on br0:
> 
[...]
> Oct 13 10:31:31 westogre ifup[1521]: run-parts: executing
> /etc/network/if-up.d/mountnfs
> Oct 13 10:31:31 westogre systemd[1]: networking.service: Main process
> exited, code=exited, status=1/FAILURE
> Oct 13 10:31:31 westogre pppd[2055]: Terminating on signal 15
[...]
> Oct 13 10:31:31 westogre pppd[2055]: Exit.
> Oct 13 10:31:31 westogre systemd[1]: networking.service: Failed with result
> 'exit-code'.

I think the issue is that systemd kills the pppd process when ifup
reports an error bringing up br0. And that's probably because ppp0 was
brought up during startup of the networking service, and thus systemd
keeps track of all processes spawned at that time.

A possible workaround is to make ppp0 bringup not part of the network
initialization, but rather during the "hotplug" event of eth3. So
instead of having:

auto ppp0
iface ppp0 inet ppp
...

Write this:

allow-hotplug eth3

iface eth3 inet manual
mtu 1508
up ifup ppp0
down ifdown ppp0

iface ppp0 inet ppp
provider provider
post-up sh /root/firewall/delayed-post-up.sh

Note that hotplug doesn't mean when the cable is plugged in, it means
when the system detects the network card hardware. And for a built-in
network card, it detects it at boot time. So effectively you still get
ppp0 brought up at boot time this way.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#940969: libdc1394-22: Please package new upstream release (2.2.6)

[Guus Sliepen]

tags 940969 + pending
thanks

> Source: libdc1394-22
> Version: 2.2.5-2.1
> Severity: normal
> X-Debbugs-CC: g...@debian.org p...@debian.org
> 
> Dear libdc1394-22 maintainers,
> 
> The upstream of libdc1394-22 has made a new release on 2019-04-28 (2.2.6, 
> https://sourceforge.net/projects/libdc1394/files/libdc1394-2/2.2.6/ ). Please
> consider packaging it in Debian.

Upstream changed the soname of the library, this means new package names
are necessary. Packages for 2.2.6 are currently waiting in the NEW
queue:

https://ftp-master.debian.org/new/libdc1394_2.2.6-1.html

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#928984: ifupdown: networking lost when installing ifupdown2

[Guus Sliepen]

On Tue, May 14, 2019 at 03:35:07PM +, George Diamantopoulos wrote:

> I'm not sure if this bug should be filed against ifupdown or ifupdown2.
> This issue only seems to affect current versions of these packages
> in buster, I haven't encountered this in stretch.
> 
> When installing ifupdown2, apt will remove ifupdown before proceeding with
> installation of ifupdown2 as the two cannot co-exist on the same system.

This is a bit tricky. Especially with systemd, there is no easy way to
say "please stop this service but don't execute its ExecStop command".
Also, properly shutting down the network will be nicer for ifupdown2,
because if ifupdown doesn't shut down cleanly, ifupdown2 might not start
in an orderly way.

> When issuing the command to install ifupdown2 over SSH the issue can be
> quite easily worked around by restarting the networking service immediately
> after ifupdown2 is installed:
>   apt-get install ifupdown2 && systemctl restart networking
> 
> However, there seems to be no simple solution when using configuration
> management (like ansible) to install ifupdown2. The relevant tasks will
> hang forever upon ifupdown2 installation.

For provisioning systems like ansible, puppet etc., I recommend that you
set it up to push a script to the node that basically executes the
equivalent of "apt-get install ifupdown2 && systemctl restart
networking" using nohup or something else to make it not fail if the
network itself is down.

On the other hand, if ifupdown2 would automatically start the network at
install time, you wouldn't need the systemctl command to restart the
network. Maybe that is enough to fix this issue? I'm Cc'ing the
maintainer of ifupdown2.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#939713: ifupdown: brctl dependency

[Guus Sliepen]

reassign 939713 bridge-utils
thanks

On Sun, Sep 08, 2019 at 02:56:13AM +0300, sergio wrote:

> Package: ifupdown
> 
> Dear Maintainer,
> 
> ifupdown depends on brctl, but should use ip instead

The ifupdown package itself doesn't provide any support for bridge
interfaces, nor does it depend on brctl. It's the bridge-utils package
that provides a plugin for ifupdown to support bridge interfaces,
therefore I'm reassigning this bug report to the bridge-utils package.

I'm aware ip has taken over the functionality of many other network
utilities. If it provides all the functionality of brctl, perhaps the
bridge-utils package could start using ip command in
/etc/network/if-*.d?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#935526: pulseaudio: Pulseaudio no longer recognizes USB devices

[Guus Sliepen]

On Mon, Sep 09, 2019 at 08:53:46PM -0300, Felipe Sateler wrote:

> Could you please attach a verbose log of pulseaudio, both versions?
> https://wiki.ubuntu.com/PulseAudio/Log

Attached are the logs from both versions. Let me know if I need to
provide any other information.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


pulseverbose-12.2-4.log.gz
Description: application/gzip


pulseverbose-12.99.2-1.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#935526: pulseaudio: Pulseaudio no longer recognizes USB devices

[Guus Sliepen]

Package: pulseaudio
Version: 12.99.2-1
Severity: normal

After upgrading to 12.99.2-1, pulseaudio no longer recognizes USB audio
devices, even though ALSA sees them correctly. It is possible to
manually add a USB audio device after pulseaudio has started, by running
"pactl load-module module-alsa-sink device=hw:X", but this is of course
sub-optimal. Downgrading pulseaudio to version 12.2-4 from Buster fixes
the issue.

Output of "aplay -l | grep card":

card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
card 0: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
card 0: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3]
card 1: Generic [HD-Audio Generic], device 0: ALC1220 Analog [ALC1220 Analog]
card 1: Generic [HD-Audio Generic], device 1: ALC1220 Digital [ALC1220 Digital]
card 2: S7 [SteelSeries Arctis 7], device 0: USB Audio [USB Audio]
card 2: S7 [SteelSeries Arctis 7], device 1: USB Audio [USB Audio #1]
card 3: Microphone [Yeti Stereo Microphone], device 0: USB Audio [USB Audio]

Output of "pactl list short sinks" with pulseaudio 12.99.2-1:

0alsa_output.pci-_09_00.1.hdmi-stereo-extra1 module-alsa-card.c
s16le 2ch 44100HzIDLE
1alsa_output.pci-_0b_00.4.analog-stereo module-alsa-card.c 
s16le 2ch 44100HzIDLE

Output of "pactl list short sinks" with pulseaudio 12.2-4:

0alsa_output.pci-_09_00.1.hdmi-stereo-extra1 module-alsa-card.c
s16le 2ch 44100HzIDLE
1alsa_output.pci-_0b_00.4.analog-stereo module-alsa-card.c 
s16le 2ch 44100HzIDLE
2alsa_output.usb-SteelSeries_SteelSeries_Arctis_7-00.analog-mono 
module-alsa-card.cs16le 1ch 44100HzIDLE
3alsa_output.usb-SteelSeries_SteelSeries_Arctis_7-00.analog-stereo 
module-alsa-card.c  s16le 2ch 44100HzIDLE


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/24 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.57
ii  libasound2   1.1.8-1
ii  libasound2-plugins   1.1.8-1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libdbus-1-3  1.12.16-1
ii  libgcc1  1:9.2.1-4
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-10
ii  liborc-0.4-0 1:0.4.28-3.1
ii  libpulse012.99.2-1
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.28-6
ii  libsoxr0 0.1.2-3
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libstdc++6   9.2.1-4
ii  libsystemd0  242-4
ii  libtdb1  1.3.16-2+b1
ii  libudev1 242-4
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 12.99.2-1

Versions of packages pulseaudio recommends:
ii  dbus-user-session  1.12.16-1
ii  libpam-systemd 242-4
ii  rtkit  0.12-4

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  3.0-4
pn  pavumeter
ii  udev 242-4

-- debconf-show failed
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting t

Bug#934210: light-locker: VT corruption with Nvidia cards

[Guus Sliepen]

Package: light-locker
Version: 1.8.0-3
Severity: important

On some machines with a Nvidia card and using the non-free driver, I
have the issue that about 25% of the time, when light-locker locks the
screen, I see a text console flickering on and off rapidly. When this
happens, there is no way to unlock the screen. Trying to switch VTs does
not work. Without remote access into the machine to stop light-locker,
the only option is to reset the machine by pressing the reset button or
by using Alt-Sysrq.

I have seen many other bug reports with light-locker issues, and on a
laptop with Intel HD620 graphics, I have the issue that after resuming
from suspend-to-RAM, the screen stays black, I have to switch to VT1 and
back to VT7, and then I get an annoying message that "your session is
locked, we will show the unlock screen in a few seconds". With all these
issues, I believe that the way light-locker works is fundamentally
flawed, and maybe should not have been the default when using lightdm +
XFCE.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages light-locker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.16-1
ii  libdbus-glib-1-2 0.110-4
ii  libglib2.0-0 2.60.6-1
ii  libgtk-3-0   3.24.10-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libsystemd0  241-7
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  libxss1  1:1.2.3-1
ii  lightdm  1.26.0-5

light-locker recommends no packages.

light-locker suggests no packages.

-- no debconf information

Bug#929587: rsh-redone FTCBFS: does not pass cross tools to make

[Guus Sliepen]

On Sun, May 26, 2019 at 07:33:41PM +0200, Helmut Grohne wrote:

> rsh-redone fails to cross build from source, because it does not pass
> cross tools to make. The easiest way of doing so - using dh_auto_build -
> makes rsh-redone cross buildable. Please consider applying the attached
> patch.

Thanks for the patch! But that makes me realize that I should go a step
further and convert it completely to dh.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#661591: whereami shouldn't need to be purged

[Guus Sliepen]

reassign 661591 whereami
thanks

On Fri, Apr 19, 2019 at 12:35:39PM -0700, Mark A. Hershberger wrote:

> Just found that systemd thought networking.service was having trouble on my 
> machine. 
> 
> When I checked "journalctl -xe" I found the following: 
> 
> ifup[18149]: run-parts: /etc/network/if-pre-up.d/whereami exited with return 
> code 1 
> ifup[18149]: ifup: pre-up script failed 
> systemd[1]: networking.service: Main process exited, code=exited, 
> status=1/FAILURE 

The issue is in the script whereami installs; it should check for the
presence of the whereami binary, or else exit without an error.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#926654: tinc: Fails to parse '::' in IPv6-address

[Guus Sliepen]

On Mon, Apr 08, 2019 at 04:02:20PM +0200, Casper Gielen (Unix Administrator 
University Tilburg) wrote:

> if the Subnet in /etc/tinc//hosts/ contains '::' then
> TINC does not parse it correctly.
> 
> bad:
> /etc/tinc/cluster/hosts/nyorobo
> Subnet = fd00:610:1410:ae2e:23f0:c936::50
> 
> # service restart tinc && pkill -USR2 tincd
> 
> /var/log/syslog:
> Apr  8 15:57:08 nyorobo tincd[1427]: Subnet list:
> Apr  8 15:57:08 nyorobo tincd[1427]:  0:10:10:2e:f0:36#10 owner nyorobo

Ah, it actually depends on the place of the '::'; if it's after the
sixth element it will incorrectly parse it as a MAC address. In tinc 1.1
it's already fixed, I'll backport the fix.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#743138: [Pkg-utopia-maintainers] Bug#743138: Bug#743138: Bug#743138: [Needs upstream 0.9.10 release] Please only enable ifupdown plugin when ifupdown installed

[Guus Sliepen]

On Wed, Feb 27, 2019 at 10:51:35AM +0100, Michael Biebl wrote:

> > Even better, the plugin could
> > just call system("/sbin/ifquery ") to check whether an
> > interface is managed by ifupdown or not.
> 
> If the idea is to load and run less code in NM, this would mean we have
> to add more. So at a first glance this doesn't look very compelling.
> 
> Also, if we wanted to find devices which should not be touched by NM
> because they are defined in /e/n/i, is ifquery really sufficient to do that?

Yes.

> Say I have a br0 and eth0 in bridge_ports.
> What will ifquery eth0 return in such a case?

If will return an error, because as far as ifupdown itself is concerned,
no interface named eth0 has been defined. Ifupdown doesn't parse
bridge_ports, this is instead handled by /etc/network/if-pre-up.d/bridge
that's in the bridge-utils package. This is unfortunate, it is possible
to make it more visible to ifupdown: for example, when bonding
interfaces (which is similar to briding in the sense that you have a
bond interface and some other interfaces connected to it), the ifenslave
package provides an if-pre-up.d script that allows you to define a bond
interface, and instead of using bond_slaves (the equivalent of
bridge_ports), you can instead give slave interfaces their own iface
definition in /e/n/i and add something like "bond_master bond0" to it.

> Personally, I've never been a fan of the ifupdown plugin in NM. Parsing
> the /e/n/i file is hairy and incomplete.

It basically comes down to the fact that part of the parsing is done by
the plugins, and that there's no way just by looking at /e/n/i to
perfectly know which interfaces are controlled by ifupdown and which are
not.

> Especially the managed=true mode is something I would like to get rid off.
> If we removed managed=true mode, all that would remain from the ifupdown
> plugin is to mark devices as unmanaged by NM if they are defined in
> /e/n/i. In such a case we might consider replacing the handwritten
> parser and just exec ifquery.
> Maybe this could even be replaced by a udev rule which runs ifquery and
> sets ENV{NM_UNMANAGED}='1'

Or maybe set ENV{MANAGER}='ifupdown', to support other ways of managing
networks as well (ifupdown2, wicd, and probably more)? I like this
approach of signalling through udev though, it completely decouples
ifupdown from NetworkManager.

I just did some testing, and just using ifquery as it is now will not be
enough. The reason is that ifquery expects the name of a logical
interface (ie, the name of an iface stanza), and not that of a physical
interface. You can write something like:

allow-hotplug /eth*=eth
iface eth inet dhcp

This will bring up any interface whose name starts with eth (so eth0,
eth1, etc), and use the configuration of the iface eth stanza to
configure them. In this case, "ifquery eth0" would always return an
error, only "ifquery eth" would return zero. OTOH, if eth0 is up, then
"ifquery --state eth0" would return 0, but "ifquery --state eth" would
return an error.

Not confusing enough? The above can still be solved by adding an option
to ifquery to make it query a physical interface. But: you can also
define VLAN interfaces but omit the VLAN trunk interface. Is the
physical (trunk) interface then managed by ifupdown or not?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#743138: [Pkg-utopia-maintainers] Bug#743138: Bug#743138: [Needs upstream 0.9.10 release] Please only enable ifupdown plugin when ifupdown installed

[Guus Sliepen]

On Tue, Feb 26, 2019 at 10:37:28PM +0100, Michael Biebl wrote:

> >> Andrej, I'm fine with dropping ifupdown from the default NM
> >> configuration if the ifupdown package is going to ship such a config
> >> snippet for NM.
> > 
> > Are we talking about /etc/NetworkManager/dispatcher.d/01-ifupdown here?
> > It seems like a hack to avoid having to update some packages to directly
> > support NetworkManager. For the long run, it's probably better if we
> > don't have this dependence on scripts written for ifupdown.
> 
> No, we are talking about the ifupdown plugin in NM, i.e.
> /usr/lib/*/NetworkManager/1.14.6/libnm-settings-plugin-ifupdown.so
> 
> which is responsible for parsing /etc/network/interfaces (and depending
> on whether managed=true or false, simply ignores interfaces configured
> in /e/n/i or tries to apply the configuration set there)

Ah, OK.

> ifupdown could ship the file as /etc/NetworkManager/conf.d/ifupdown.conf
> This would have the downside, that the ifupdown plugin would still be
> active if the ifupdown package is removed, but not purged.

But it could just check for /sbin/ifup being executable before
continuing, just like init scripts do. Even better, the plugin could
just call system("/sbin/ifquery ") to check whether an
interface is managed by ifupdown or not. If the return value is 0, it
means it's managed. If it's anything else, either ifupdown is not
installed or it is but that interface is not known to ifupdown.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#743138: [Pkg-utopia-maintainers] Bug#743138: [Needs upstream 0.9.10 release] Please only enable ifupdown plugin when ifupdown installed

[Guus Sliepen]

On Tue, Feb 26, 2019 at 07:24:27PM +0100, Michael Biebl wrote:

> On Sun, 10 Feb 2019 11:03:55 +0100 Andrej Shadura
>  wrote:
> 
> > > this is fixed a while ago.
> > > 
> > > Handling of hostname moved from the settings plugin to NMSettings.
> > > Also, hostnamed is supported as one of several options.
> > > 
> > > There were many changes there, so I am not going to hunt down for a 
> > > particular BZ which fixed this. However, the functionality is now all in 
> > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/nm-settings.c
> 
> Andrej, I'm fine with dropping ifupdown from the default NM
> configuration if the ifupdown package is going to ship such a config
> snippet for NM.

Are we talking about /etc/NetworkManager/dispatcher.d/01-ifupdown here?
It seems like a hack to avoid having to update some packages to directly
support NetworkManager. For the long run, it's probably better if we
don't have this dependence on scripts written for ifupdown.

> Once such an ifupdown package is available in the archive, I can drop
> the config from NetworkManager.conf and add a versioned Breaks against
> ifupdown.

I can see why you want to move it to ifupdown, but that would mean that
if you have the situation where the network is fully controlled by
NetworkManager (ie, no or an empty /etc/network/interfaces), and you
have a package that provides an /etc/network/if-*.d script, then your
network configuration will be different depending on whether you have
ifupdown installed or not.

> Bringing Guus into the loop here.
> Someone interested in this issue should probably file a proper bug
> report against the ifupdown package and mark this bug report by it.

Personally, I think the proper solution is to have the few packages that
do use ifupdown hooks that always run when an interface goes up/down,
create hooks for NetworkManager as well.

To ensure only one of the hooks is run, a package that provides hooks
for both NetworkManager and ifupdown can check in the ifupdown hooks if
$METHOD = "NetworkManager", and if so exit without doing anything.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#919272: Is multiple-layers of alternatives a good thing to users?

[Guus Sliepen]

On Mon, Feb 04, 2019 at 06:07:55AM +, Mo Zhou wrote:

> My updated version, all variants are co-installable now:
> 
>  Package: libblis2-openmp,  Provides: libblas.so.3, libblis.so.2
>  Package: libblis2-pthread, Provides: libblas.so.3, libblis.so.2
>  Package: libblis2-serial,  Provides: libblas.so.3, libblis.so.2
>  Package: libblis2 (meta),
>  Package: python3-numpy,Depends: libblas.so.3
> 
> The meta package is still necessary because of symbols/shlibdeps.
> Different threading variants have the same ABI/API, so the
> dependency template is written as
> 
>  libblis.so.2 libblis2 #MINVER#

If the ABI and API are the same for all variants, a much better
solutions seems to me to have a single libblis2 that can switch at
runtime between the different variants, perhaps using an environment
variable to decide. That would require some support from upstream
though.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#920791: New libglm-dev

[Guus Sliepen]

retitle 920791 FTBFS on all non-SIMD architectures
forwarded 920791 https://github.com/g-truc/glm/issues/865
thanks

On Tue, Jan 29, 2019 at 07:50:44AM +0100, Guus Sliepen wrote:

> I cannot reproduce it either, but according to the logs it looks like it
> might be some #defines not working properly on some architectures.

The issue is that the new version of GLM conditionally adds constexpr to
some member functions where that would cause a compiler error. It so
happens that constexpr is not used on any architecture with SIMD
instructions supported by GLM, which are amd64 and arm64 as far as I can
tell.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#920791: New libglm-dev

[Guus Sliepen]

Package: libglm-dev
Version: 0.9.9.3-1
Severity: grave
Justification: renders package unusable

On Tue, Jan 29, 2019 at 12:09:37AM +0100, Sylvain Beucler wrote:

> I receive lots of reports of GNU FreeDink not building with weird errors
> from GLM - and I can't reproduce locally!
> 
> I see you just made a new upload - any clue?
> 
>  * Build log: 
> https://buildd.debian.org/status/fetch.php?pkg=freedink&arch=s390x&ver=109.4-1&stamp=1548702166&file=log
>  * Build log: 
> https://buildd.debian.org/status/fetch.php?pkg=freedink&arch=ppc64el&ver=109.4-2&stamp=1548715950&file=log
>  * Build log: 
> https://buildd.debian.org/status/fetch.php?pkg=freedink&arch=armel&ver=109.4-2&stamp=1548716184&file=log

I cannot reproduce it either, but according to the logs it looks like it
might be some #defines not working properly on some architectures.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#914490: ifupdown: networking.service timeout due to /dev/crng initalization?

[Guus Sliepen]

reassign 914490 wpasupplicant
thanks

On Fri, Nov 23, 2018 at 02:06:07PM -0800, Grant Grundler wrote:

> I'm not sure why I didn't see this before, but it seems to be a "known
> problem". Searching for
> "wpa_supplicant crng" yields some helpful information. e.g.:
> https://forums.gentoo.org/viewtopic-t-1081710-start-0.html
[...]
> Anyway, My guess is this report should be assigned to wpa_supplicant,
> not ifupdown package.

Reassigning.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#899002: systemd: networking and rdma-load-modules@infiniband service run in parallel despite the declared dependency order

[Guus Sliepen]

severity 899002 important
clone 899002 -1 -2
retitle -2 Networking not waiting for USB Ethernet dongle to be detected
thanks

On Sun, Jan 27, 2019 at 02:40:06PM +0100, Benjamin Drung wrote:

> severity 899002 grave

The definition of grave is: “makes the package in question unusable or
mostly so, or causes data loss, or introduces a security hole allowing
access to the accounts of users who use the package.” While it might
make the package unusable on YOUR system, this is only an issue for some
particular, not so common setups.

Also, this issue has nothing to do with RDMA, and while there are
similarities, I'll treat this as a separate bug.

> This race condition bug hit me also with an Odroid HC1. This ARM boards
> has an Ethernet controller connected over USB. Without this bugfix, the
> networking service does not wait until the USB hub is initialised and
> the Ethernet controller is found:

Can you provide me with a copy of your /etc/network/interfaces file? In
particular, did you use "auto eth0" or "allow-hotplug eth0"? If the
interface's presence is delayed because of the USB hub being initialized
in parallel, then using allow-hotplug might work around the issue for you.

> Please get ifupdown >= 0.8.33 > into testing!

Good point, I have to fix #900269 to do that.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#858823: check: version 0.12.0 is available

[Guus Sliepen]

Package: check
Version: 0.10.0-3+b3
Followup-For: Bug #858823

Version 0.12.0 has been released upstream last year. Unless there are
objections, given the lack of package maintenance activity, I will
prepare a new package and upload it to DELAYED/7.

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

Kernel: Linux 4.18.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8), 
LANGUAGE=nl_NL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages check depends on:
ii  dpkg1.19.2
ii  install-info6.5.0.dfsg.1-4+b1
ii  libsubunit-dev  1.3.0-1
ii  mawk1.3.3-17+b3

check recommends no packages.

check suggests no packages.

-- debconf-show failed

Bug#912112: Please enable ifupdown-wait-online.service by default

[Guus Sliepen]

On Sun, Oct 28, 2018 at 11:41:17AM +0100, Laurent Bigonville wrote:

> Any reasons why ifupdown-wait-online.service is not enabled by default?
> 
> Having a functional network-online.target by default seems to be
> essential to me (ie. working NFS/network shares).
> 
> Am I overlooking something?

Only the fact that not everyone needs working NFS/network shares.
Consider people with laptops that might not have an Internet connection
when they boot their machine. Having to wait one and a half minute for
ifupdown-wait-online to time out would be very annoying to them.

Another issue is that a working network connection still doesn't imply
that you will get a working NFS mount. If you really depend on NFS, then
the service that does the NFS mount should wait for the NFS server to
become reachable and the mount to succeed.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#900269: ifupdown: last version breaks upgrade

[Guus Sliepen]

On Sun, Sep 02, 2018 at 03:34:46PM +0200, Michael Biebl wrote:

> On Mon, 28 May 2018 11:08:00 +0200 Eric Valette 
> wrote:
> 
> > When upgrading, you're stuck with the last message in console "setting up
> > ifupdown" and nothing else. The machine dropped its ip address but
> > seems to fails to acquire a new one. and stay like this for minutes.
> 
> I'm suprised ifupdown reconfigures interfaces during package upgrades.
> Guus, is that intentional?

That's not intentional. It seems I forgot to add --no-start to the calls
to dh_installsystemd.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#906993: rsh-redone-client: Please include rexec

[Guus Sliepen]

On Sat, Aug 25, 2018 at 08:53:44PM +0200, Patrik Schindler wrote:

> > Hello Patrik, rsh-redone was made in a different era where computers were 
> > slow and encryption was expensive.
> 
> I encounter this reasoning from time to time in different contexts. With all 
> due respect for the hard work of package maintainers and devs: I think, this 
> decision should be left to the user. My personal reason: I'd like to see a 
> regular packaged rexec(d) for talking to my old AS/400 which has no 
> cryptographic options.

With my package maintainer hat on: it is not our duty to add
functionality to the software we package. With my upstream developer hat
on: I have only so much time I can spend myself on software development,
and because the reasons I have given I'm not going to spend that time on
rsh-redone.

> But I accept your reply and will go forward to create my own rexec(d) 
> packages then.

That is great! Feel free to base your work on the source code of
rsh-redone. If you want to take over development of rsh-redone, that is
fine as well, and then I'd be happy to upload new versions of it to
Debian.

I've uploaded the full history to GitHub and GitLab, so you can fork
the repository from there if you wish:

https://github.com/gsliepen/rsh-redone
https://gitlab.com/gsliepen/rsh-redone

> > rsh-redone is in maintenance mode; I will not add any more functionality to 
> > it.
> 
> Is there any way to mark this package accordingly?

There's no standard way to do so.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#906993: rsh-redone-client: Please include rexec

[Guus Sliepen]

tags 906993 + wontfix
tags 906994 + wontfix
thanks

On Thu, Aug 23, 2018 at 12:21:28AM +0200, Patrik Schindler wrote:

> Package: rsh-redone-client
> Version: 85-2+b1
> Severity: wishlist
> 
> Please include rexec command.
[...]
> Please include in.rexecd into this package.

Hello Patrik, rsh-redone was made in a different era where computers
were slow and encryption was expensive. Today I would not recommend
using this package anymore at all, when SSH is a much better and safer
tool. rsh-redone is in maintenance mode; I will not add any more
functionality to it.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#904127: ifupdown: should wait for link carrier before starting dhcp

[Guus Sliepen]

reassign -1 wpasupplicant
thanks

On Fri, Jul 20, 2018 at 09:58:22AM +0200, Samuel Thibault wrote:

> My wlo1 configuration reads as:
> 
> iface wlo1 inet dhcp
> wpa-conf /etc/wpa_supplicant.conf
> 
> when I ifup wlo1, ifup starts the dhcp client immediately, without
> waiting for wpa_supplicant to actually negociate the link. This is
> deemed to fail, the first DHCPDISCOVER will for sure get lost since the
> link is not up yet. As a consequence, one systematically has to wait for
> the random delay before the dhcp client sends another DHCPDISCOVER.
> 
> ifupdown could wait for the link carrier to get up before starting the
> dhcp client, which would then most probably always succeed on first try,
> and not need random retry delays.

While it might be nice to shave off a few seconds from getting the
network up and running, this is unfortunately not something that is easy
for ifupdown to do because of its architecture. Wireless configuration
is not handled by ifupdown itself; it just calls the if-pre-up plugin
from the wpasupplicant package. Even if ifupdown itself would be able to
check if this is a wireless interface and whether it has associated or
not, this would involve ifupdown doing polling, and it's just not built
to do that: its design is to just run a bunch of scripts and quit.

The solution might be for the wpasupplicant package to have the
if-pre-up.d script wait (up to some timeout) for the link to associate
to the access point before exitting. This would delay ifupdown from
starting the DHCP client. I'm therefore reassigning the package.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#906008: ITP: lizzie -- GUI for analyzing games in real time using Leela Zero

[Guus Sliepen]

On Sun, Aug 12, 2018 at 10:06:43PM -0700, Ximin Luo wrote:

> * Package name: lizzie
>   Description : GUI for analyzing games in real time using Leela Zero
> 
> Features include:
> 
> - show win rates and confidence levels for selected moves on the board
> - show best move sequence continuation, for these selected moves
> - displays a graph of winrate against move number
> - show whole game history including forked moves
> - interactive play including undo/redo
> - load and save games in SGF format

You might want to mention in both the short and long description that
this is meant for Go games.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#902267: ITP: jiq -- jid on jq

[Guus Sliepen]

On Sun, Jun 24, 2018 at 07:46:06PM +, Zenon Mousmoulas wrote:

> I posted an updated ITP (should it be a new submission?) but let me try 
> again, also correcting the license (s/MIT/Expat/). As for digger, I am afraid 
> that is part of the acronym chosen by (the forked) upstream.
> 
> 
> Package: wnpp
> Severity: wishlist
> Owner: Zenon Mousmoulas 
> 
> * Package name: jiq
>   Version : 0.6.0+git20180621.a79e8b2-1
>   Upstream Author : Giovanni T. Parra
> * URL : https://github.com/fiatjaf/jiq
> * License : Expat
>   Programming Lang: Go
>   Description : json incremental digger (jid) with jq

Even though the name jid stands for json incremental digger, you don't
need to include that in the description. I'd certainly not use it in the
short description, but mention it in the long description so one can
still search for "incremental digger" and find this package. Also, the
acronym JSON should be spelled with all caps.

>  jiq is a fork of jid (https://github.com/simeji/jid) using
>  jq (https://stedolan.github.io/jq/) under the hood.

I would not mention these facts as the first thing in the description.

>  It is a command line tool that can be used to interactively drill
>  down on json input using jq filtering queries.

That's useful information. I'd still try to reword "drill down".

>  jiq calls jq and requires that it can be found in PATH.

This is useless information. Your package should have a Depends: jq, so
this will be taken care of automatically when you install your package.
Just like you won't see "foo uses the GNU standard C library and
requires that it be found in the standard system library paths or in
LD_LIBRARY_PATH".

Ok, it's easy to criticize, so let me try to make a description myself,
and then you can decide if you want to pick some things from it:

Description: interactive JSON query tool using jq expressions
 jiq is a command line tool that parses a JSON document and allows you
 to interactively query and filter it using jq expressions. jiq also
 provides suggestions and tab completion.
 .
 jiq is a fork of jid, but fully supports the jq language (see
 https://stedolan.github.io/jq/).

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#902267: ITP: jiq -- jid on jq

[Guus Sliepen]

On Sun, Jun 24, 2018 at 10:07:46AM +0300, Zenon Mousmoulas wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Zenon Mousmoulas 
> 
> * Package name: jiq
>   Description : jid on jq 
[...]
> jiq is a fork of jid

But what is jid? What is jq? This whole description is useless. Also, in
the updated description, it says "json incremental digger". The only
thing that tells me is that it has something to do with JSON. And it's
interactive, but is this a command line tool? A GUI? A web thing?

The description should be such that someone who doesn't already know the
tool will understand what this tool is about, what it can do, and what
environment it can be used in. Also please avoid terms like "digging"
and "drilling" in the description, those are not commonly used terms and
it will confuse people. Rather use "querying", "searching" et cetera.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#901412: ITP: ibmquantumexperience -- A Python library for the IBM Quantum Experience API (Python 3)

[Guus Sliepen]

> * Package name: ibmquantumexperience
>   Description : A Python library for the IBM Quantum Experience API  
> (Python 3)

If it's a Python 3 library, the package name should have the python3- prefix, 
and you
might want to consider naming it (python3-)qiskit instead of 
(python3-)ibmquantumexperience.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#900841: [git-buildpackage/master] changelog: try iso8859-1 when utf-8 fails

[Guus Sliepen]

tag 900841 pending
thanks

Date:   Tue Jun 5 21:43:10 2018 +0200
Author: Guus Sliepen 
Commit ID: 48ef0ecff04f52734a3e0424201df6f303d1c9cd
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=48ef0ecff04f52734a3e0424201df6f303d1c9cd
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=48ef0ecff04f52734a3e0424201df6f303d1c9cd

changelog: try iso8859-1 when utf-8 fails

Fall back to iso8859-1 when opening the changelog. Helps when importing
old versions.

Closes: #900841
Signed-off-by: Guido Günther 

  

Bug#900742: iwlist: argument list too long

[Guus Sliepen]

tags 900742 + wontfix
thanks

On Sun, Jun 03, 2018 at 09:27:18PM -0700, Ernesto Alfonso wrote:

> Package: wireless-tools
> Version: 30~pre9-12+b1
> Severity: important
> 
> Dear Maintainer,
> 
> iwlist fails with the error "Failed to read scan data : Argument list too 
> long" when there
> are too many reachable access points. I've encountered this issue 
> consistently at certain hotels,
> and I've had to resort to using iw instead, as this stackoverflow question 
> from March 2017 answer suggests:

The problem is unfortunately a limitation of the Wireless Extensions
kernel API that wireless-tools uses, so there is nothing that I can do
to fix it. If iw works for you, then by all means keep using it.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#900841: git-buildpackage: Fails to import packages when the changelog contains invalid UTF-8 sequences

[Guus Sliepen]

Package: git-buildpackage
Version: 0.9.9
Severity: normal
Tags: patch

I ran into the following issue when importing the history of a Debian
package:

> gbp import-dscs --debsnap wireless-tools
gbp:info: Downloading snapshots of 'wireless-tools' to '/tmp/tmpkzi1rlbg'...
gbp:info: No git repository found, creating one.
Traceback (most recent call last):
  File "/usr/bin/gbp", line 149, in 
sys.exit(supercommand())
  File "/usr/bin/gbp", line 145, in supercommand
return module.main(args)
  File "/usr/lib/python3/dist-packages/gbp/scripts/import_dscs.py", line 180, 
in main
if importer.importdsc(dscs[0]):
  File "/usr/lib/python3/dist-packages/gbp/scripts/import_dscs.py", line 72, in 
importdsc
return import_dsc.main(['import-dsc'] + self.args + [dsc.dscfile])
  File "/usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py", line 518, in 
main
apply_debian_patch(repo, source, dsc, commit, options)
  File "/usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py", line 174, in 
apply_debian_patch
author = get_author_from_changelog(source.unpacked)
  File "/usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py", line 114, in 
get_author_from_changelog
dch = ChangeLog(filename=os.path.join(dir, 'debian/changelog'))
  File "/usr/lib/python3/dist-packages/gbp/deb/changelog.py", line 89, in 
__init__
self._read()
  File "/usr/lib/python3/dist-packages/gbp/deb/changelog.py", line 132, in _read
self._contents = f.read()
  File "/usr/lib/python3.6/codecs.py", line 321, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 906: 
invalid start byte

This happened while it was importing version 23-2 (see
http://snapshot.debian.org/package/wireless-tools/23-2/). The changelog
back then was in ISO-8859-1. I've attached a patch that treats invalid
UTF-8 files as ISO-8859-1.


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

Kernel: Linux 4.15.2 (SMP w/12 CPU cores)
Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8), 
LANGUAGE=nl_NL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.18.2
ii  git1:2.17.0-1
ii  man-db 2.8.3-2
ii  python33.6.5-3
ii  python3-dateutil   2.6.1-1
ii  python3-pkg-resources  39.1.0-1

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.87+b1
ii  pbuilder  0.229.2
ii  pristine-tar  1.44
ii  python3-requests  2.18.4-2

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.8.23-1
ii  unzip6.0-21

-- no debconf information
>From 48bc76b8a5294098548ef8c6b10e0f25b718fddf Mon Sep 17 00:00:00 2001
From: Guus Sliepen 
Date: Tue, 5 Jun 2018 21:41:28 +0200
Subject: [PATCH] Treat changelogs with invalid UTF-8 sequences as ISO-8859-1.

This allows import-dscs to import old versions of a package that did not
yet use UTF-8 encoding.
---
 gbp/deb/changelog.py | 8 ++--
 gbp/git/vfs.py   | 5 -
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/gbp/deb/changelog.py b/gbp/deb/changelog.py
index 5cfaaf79..dda9b753 100644
--- a/gbp/deb/changelog.py
+++ b/gbp/deb/changelog.py
@@ -128,8 +128,12 @@ class ChangeLog(object):
 self._cp = cp
 
 def _read(self):
-with open(self.filename, encoding='utf-8') as f:
-self._contents = f.read()
+try:
+with open(self.filename, encoding='utf-8') as f:
+self._contents = f.read()
+except UnicodeDecodeError:
+with open(self.filename, encoding='iso-8859-1') as f:
+self._contents = f.read()
 
 def __getitem__(self, item):
 return self._cp[item]
diff --git a/gbp/git/vfs.py b/gbp/git/vfs.py
index 8363f77b..ec47201a 100644
--- a/gbp/git/vfs.py
+++ b/gbp/git/vfs.py
@@ -33,7 +33,10 @@ class GitVfs(object):
 if binary:
 self._data = io.BytesIO(content)
 else:
-self._data = io.StringIO(content.decode())
+try:
+self._data = io.StringIO(content.decode())
+except UnicodeDecodeError:
+self._data = io.StringIO(content.decode("iso-8859-1"))
 
 def readline(self):
 return self._data.readline()
-- 
2.17.0

Bug#899355: ifupdown: Hotplugging IPoIB devices does not work

[Guus Sliepen]

On Fri, May 25, 2018 at 10:17:58AM +0200, Benjamin Drung wrote:

> > I could perhaps make it so that if you have "allow-hotplug ib0.1234",
> > that it will bring this one up if you do "ifup --allow hotplug ib0".
> > Then you can still choose which VLANs you want up by default. I guess
> > that would be ideal for you?
> 
> Yes. That's what I like would to see.

That's now possible in ifupdown 0.8.34. Let me know if that works for
your setup.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#899355: ifupdown: Hotplugging IPoIB devices does not work

[Guus Sliepen]

On Thu, May 24, 2018 at 06:16:46PM +0200, Benjamin Drung wrote:

> Is there a reason not to bring up all the allow-hotplug VLANs related
> to the physical device, i.e. bring up ib0. if `ifup --allow=hotplug 
> ib0` is called?

Yes, it would change the behaviour of ifupdown, and I know for certain
that some users have multiple VLAN stanzas in /etc/network/interfaces,
but only want a subset up at any given time.

I could perhaps make it so that if you have "allow-hotplug ib0.1234",
that it will bring this one up if you do "ifup --allow hotplug ib0".
Then you can still choose which VLANs you want up by default. I guess
that would be ideal for you?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#899002: systemd: networking and rdma-load-modules@infiniband service run in parallel despite the declared dependency order

[Guus Sliepen]

On Thu, May 24, 2018 at 10:28:51AM +0200, Benjamin Drung wrote:

> Attached is an updated and tested patch that splits the udevadm settle
> command into a separate ifupdown-pre service without modifying the
> logic. So a no-op 'udevadm settle' will stay a no-op.

While I think this is still a hack to work around limitations in udevadm
settle and/or systemd, I'll just add your patch to ifupdown for now. Thanks!

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#899355: ifupdown: Hotplugging IPoIB devices does not work

[Guus Sliepen]

On Wed, May 23, 2018 at 10:43:40AM +0200, Benjamin Drung wrote:

> Using allow-hotplug for InfiniBand devices does not work. The devices are 
> never
> brought up.
> 
> Example /etc/network/interfaces:
> ```
> allow-hotplug ib0.
> iface ib0. inet6 static
> address fd44:1:5255::
> netmask 64
> pre-up echo connected > /sys/class/net/$IFACE/mode
> dad-attempts 600
> ```

I should've seen this earlier, but the problem is the fact that you have
configured a VLAN interface, but udev only sees the plain interface
name:

> ```
> $ udevadm monitor
> [...]
> KERNEL[78666.922735] add  
> /devices/pci:00/:00:02.0/:03:00.0/net/ib0 (net)
> UDEV  [78666.941473] add  
> /devices/pci:00/:00:02.0/:03:00.0/net/ib0 (net)
> ```

So this effectively calls `ifup --allow=hotplug ib0`, but there is no
ib0 stanza, only an ib0. stanza.

So, in principle you'd want to create an iface stanza for ib0 that does
nothing but bring up its VLAN interfaces. Unfortunately, the following
currently does not work:

iface ib0 inet manual
up ifup ib0.

Because it detects recursion. I could probably loosen that
restriction.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#899002: systemd: networking and rdma-load-modules@infiniband service run in parallel despite the declared dependency order

[Guus Sliepen]

On Tue, May 22, 2018 at 03:20:42PM +0200, Benjamin Drung wrote:

> >  Maybe allow-hotplug would be a better fit or
> > another networking configuration system which is more dynamic and
> > does listen to uevents?
> 
> I tried to use allow-hotplug, but it does not work at all (see initial
> bug report for example configuration).

I don't see any reference to allow-hotplug in the initial bug report.
What exactly goes wrong when you do the following?

```
allow-hotplug  ib0.
iface ib0. inet6 static
...
```

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#899191: ifupdown: cannot interrupt dhclient

[Guus Sliepen]

On Sun, May 20, 2018 at 04:30:24PM +0200, Thorsten Glaser wrote:

> In BSD, I can interrupt a running dhclient by pressing ^C or, at
> least, ^\. This is not possible in Debian which really makes it
> not fun if you have bad network, like WLAN.
> 
> I almost reported this as a bug against dhclient, but Nik pointed
> out that I *can* actually ^C dhclient when called manually, just
> not when it was started by ifup.

Hm, that is weird, because I can actually interrupt dhclient started by
ifup using ^C. Also, ifup does not block SIGINT or SIGTERM, and any
command it executes runs in the foreground.

How exactly are you starting ifup? From a Linux console, a terminal
emulator, via SSH, from inside screen or tmux? Any information might
help.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#896433: ifupdown: ifquery can't be called recursively from ifup/ifdown, but if-pre/up.d scripts call it

[Guus Sliepen]

On Mon, Apr 23, 2018 at 05:18:53PM -0400, Dan Streetman wrote:

> > The patch avoids locking at all when no_act == true. Consider this:
> >
> > iface foo inet ...
> > pre-up ifquery --state bar
> >
> > iface bar inet ...
> >
> > Now if I call ifup foo and ifup bar at the same time, then the ifquery
> > might theoretically read a half-written /run/network/ifstate.bar.
> 
> Eh?
> 
> ifquery --state doesn't use the ifstate.* files.  It reads state from
> the global ifstate file.

Oh, you're absolutely right. It seems I mixed things up; ifquery --list
and "plain" ifquery lock ifstate.* files, but ifquery --state indeed
doesn't.

And indeed, with --state we only look at the global ifstate file. And
the other uses of ifquery only need to parse the interfaces file, so we
shouldn't ever need to touch the ifstate.* files when running ifquery.
But it's different for ifup and ifdown; even with --no-act we want to
lock. So I've made a patch to only avoid locking for ifquery.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#896433: ifupdown: ifquery can't be called recursively from ifup/ifdown, but if-pre/up.d scripts call it

[Guus Sliepen]

On Fri, Apr 20, 2018 at 04:52:24PM -0400, Dan Streetman wrote:

> Scripts in the if-pre-up.d and if-up.d dirs call ifquery directly, or call it 
> indirectly
> through other scripts.  However ifquery tries to lock each interface and 
> exits with
> error if it's called from ifup or ifdown.  Since ifquery doesn't change 
> anything,
> there is no reason interface locks need to be taken; ifquery can be safely run
> recurseively from ifup/ifdown.

You're right, it should be possible to run ifquery recursively. But it
should still ensure the interface is locked before querying it, to
ensure consistency.

> In Ubuntu, the attached patch was applied to achieve the following:

The patch avoids locking at all when no_act == true. Consider this:

iface foo inet ...
pre-up ifquery --state bar

iface bar inet ...

Now if I call ifup foo and ifup bar at the same time, then the ifquery
might theoretically read a half-written /run/network/ifstate.bar.
Granted, the change of this is extremely small, and one could also
question whether it makes sense to run ifquery in this way at all, since
even if it did read a consistent /run/network/ifstate.bar, it could
either read the state as being up or down depending on whether ifup bar
finished before or after ifquery. But it's not hard to do it correctly,
so I'll make it so it only avoids locking if it detects recursion.

> Thanks for considering the patch.

Thanks for sending the patch :)

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#895712: ITP: misspell-fixer -- Tool for fixing common misspellings, typos in source code.

[Guus Sliepen]

On Sun, Apr 15, 2018 at 12:49:05AM +0100, Lajos Veres wrote:

> * Package name: misspell-fixer
>   Description : Tool for fixing common misspellings, typos in source code.
[...]
> Reason:
> I have not found any sourcecode typofixer tool in Debian.
> Some users also mentioned that their life would be a little easier with a
> packaged version.

This sounds awfully similar to the package named codespell.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#895146: blobwars FTCBFS: uses the build architecture pkg-config

[Guus Sliepen]

tags 895146 + pending
thanks

On Sat, Apr 07, 2018 at 07:37:47PM +0200, Helmut Grohne wrote:

> blobwars fails to cross build from source, because it fails finding sdl
> as it uses the build architecture pkg-config. After making pkg-config
> substitutable, it cross builds successfully as dh_auto_build substitutes
> the right pkg-config. Please consider applying the attached patch.

Thanks for the patch! I applied it upstream, and will try to make a new
release soon.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#894511: Please emphasize in the documentation a possible race condition in if-*.d hooks with systemd

[Guus Sliepen]

On Sat, Mar 31, 2018 at 06:01:18PM +0200, Raphaël Halimi wrote:

> With /etc/init.d/networking script, network interfaces configured with
> class "auto" are raised first, and only when that's done, interfaces
> configured with class "allow-hotplug" are then raised:
> 
> ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose
> 
> With systemd, the unit file only calls:
> 
> /sbin/ifup -a --read-environment
> 
> ...letting udev (I guess) take care of the interfaces configured with
> class "allow-hotplug", the major difference being that both steps are
> done concurrently.

Hm, but that is more of a coincidence than by design. Ifupdown still has
a udev rule, regardless of the init system, that will bring up hotplug
interfaces. Also, the /etc/init.d/networking script might call
ifup_hotplug, but this only covers interfaces that are present at boot
time, while future hotplugged interfaces might still result in
concurrent calls to ifup.

> This leads to situation where a given hook in /etc/network/if-*.d can
> end up running multiple times simultaneously.

Indeed. I can see how this is a problem, but I don't think serializing
ifupdown is the right solution.

> The NEWS.Debian file's entry for 0.8 states that:
> 
> "Ifupdown will now be more strict when errors occur, and will also
> properly return a non-zero exit code when (de)configuring an interface
> fails. Please ensure your /etc/network/interfaces is correct and that
> your interfaces can be brought up and down without errors, especially
> during system startup."
> 
> IMHO, this doesn't emphasize enough on the fact that a given hook in
> if-*.d must be able to run several times simultaneously,

Yes, that should indeed be emphasized more. And it should be able to run
simultaneously both for SysV and systemd, although the problem happens
more often with the latter.

> I suppose the aggressive parallelizing done by systemd is expected
> behavior,

Debian's SysV system also runs init scripts in parallel! It's just that
the ordering is different than with systemd. I'm not sure why we still
call ifup_hotplug from the SysV init script as we also have the udev
rule, but it's pure luck that the init script configures the hotplug
interfaces before udev runs (unless udev really behaves differently
under SysV for some reason).

> IMHO, there should be at least some kind of warning documented somewhere

You are right. I'll add a an entry to the manual and to NEWS.Debian, so
there will be a clear warning when people are upgrading ifupdown.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#894759: ifupdown: networking.service ExecStartPre exits with status=1/FAILURE when it's supposed to do nothing.

[Guus Sliepen]

tags 894759 + pending
thanks

On Tue, Apr 03, 2018 at 02:56:59PM -0700, Filipe Brandenburger wrote:

> When networking.service's ExecStartPre is not supposed to do anything
> (for instance, when CONFIGURE_INTERFACES=no is set, or when `ifquery
> --read-environment --list --exclude=lo` returns an empty list, then the
> ExecStartPre will show with a (code=exited, status=1/FAILURE) in the
> `systemctl status networking.service` output.
> 
> That doesn't really cause any failures, but is misleading, since there's
> nothing necessarily wrong with that condition.
> 
> I suggest using an "if" instead of "&&" on that line, so that it still
> exits 0 if there's nothing to do.

Thanks, I applied your patch, it will be part of the next release!

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#892861: libglm-dev: removal of default type initialization breaking packages

[Guus Sliepen]

tags 892861 - wontfix
thanks

On Wed, Mar 28, 2018 at 01:19:44PM +1300, Andrew Caudwell wrote:

> Upstream has implemented my suggestion to re-add default initialization as
> opt-in via a new define:
> 
> https://github.com/g-truc/glm/issues/735
> https://github.com/g-truc/glm/commit/8390a77b3a278b15259e5ca6e67f7e41badc457b
> 
> Could you apply the commit as a patch so maintainers can then define
> GLM_FORCE_CTOR_INIT and avoid having to modifying code?

Sure. However, I'm running into problems trying to apply the patch: it
doesn't apply cleanly on 0.9.9~a2, and if I just package the latest
revision from git, then I am getting internal compiler errors from GCC.
I can still compile 0.9.9~a2 without problems, so I will try to see if I
can just adapt the commit which adds GLM_FORCE_CTOR_INIT to 0.9.9~a2.

> Let me know as then I can then avoid having to embed the current release in
> my software.

Yeah, that would be less than optimal.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#893224: ifupdown: Failed to start Raise network interfaces.

[Guus Sliepen]

On Sat, Mar 17, 2018 at 01:26:19PM +0100, Heinrich Schuchardt wrote:

> My system is booting from iSCSI. This implies that the network interface
> has to be always up.
> 
> The ifupdown-wait-online.service blocks booting for 5 minutes:
> 
> iscsistart: version 2.0-874
> iscsistart: initiator reported error (15 - session exists)
> root: recovering journal
> root: clean, 228233/2064384 files, 2669304/8257536 blocks
> [FAILED] Failed to start Raise network interfaces.

This line indicates that it failed to bring up the network interfaces
marked auto using ifup.

> See 'systemctl status networking.service' for details.
> [  OK  ] Reached target Network.
>  Starting Network Time Service...
>  Starting OpenBSD Secure Shell server...
> [  OK  ] Started OpenBSD Secure Shell server.
> [  OK  ] Started Network Time Service.
> [FAILED] Failed to start Wait for network to be configured by ifupdown.

The ifupdown-wait-online service failed because ifupdown never
succesfully brought a network interface up itself. This is the default
behaviour of the ifupdown-wait-online script. You can also have it wait
until a default route is present by adding the following line to
/etc/default/networking:

WAIT_ONLINE_METHOD=route

But you should try to find out why ifupdown failed bringing up the
network in the first place. You could do that by removing the auto eth*
lines from /etc/network/interfaces, reboot, and then run ifup -v eth0;
ifup -v eth0:1 by hand, and check for any error messages.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#892861: libglm-dev: removal of default type initialization breaking packages

[Guus Sliepen]

tags 892861 + wontfix
thanks

On Wed, Mar 14, 2018 at 10:48:33AM +1300, Andrew Caudwell wrote:

> The packaged version of GLM, 0.9.9~a2 is an alpha (the current release is 
> still
> 0.9.8.5) and removes the default initialization of vector, matrix and
> quaternion types. Because of this code written against any earlier versions of
> GLM may now have uninitialized value bugs introduced by this change (e.g. 
> where
> GLM types are member variables of a class) or now behave differently (mat4()
> previously gave you an identity matrix, now this gives you a zero'd matrix).
> Several issues have been raised upstream (including by myself) to re-add
> initialization or at least make it optional.
> Additionally the requirement in this version to define GLM_ENABLE_EXPERIMENTAL
[...]
> to use simple functions like length2() has broken multiple packages. I have 
> put
> off fixing this since making it compile just exposes the user to the
> uninitialized value bugs. Unfortunately this has now meant my gource and
> logstalgia debian packages have been removed from debian since they don't
> complile with this GLM version.

I believe these are intentional changes by the author of GLM. I expect
that GLM 1.0.0 will be released before the next release of Debian, and
any packages that depend on GLM should instead be fixed to handle the
new behavior.

Unless I am mistaken, projects depending on GLM can just #define
GLM_ENABLE_EXPERIMENTAL and provide explicit default initializers, which
will be backwards compatible with older versions of GLM.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#892152: wireless-tools: iwlist scan using the essid option,returns essids that do not match the given essid

[Guus Sliepen]

severity 892152 wishlist
tags 892152 + wontfix
thanks

On Tue, Mar 06, 2018 at 03:22:09AM +, Schorschi Decker wrote:

> What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Testing was consistent, it appears the essid parameter is completely ignored
> 
> What was the outcome of this action?
> Command # iwlist wlan0 scanning essid sample
> multiple cells returned but ssid sample is only one cell matching
> 
> What outcome did you expect instead?
> A single cell, and only a single cell should be returned

As the manpage says, options to the iwlist scanning command are
card-dependent, and ignored by most drivers. It seems that your wireless
card or the driver for your wireless card does not support scanning for
a single ESSID.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#891139: ifupdown: New ifupdown-wait-online.service stops package upgrading

[Guus Sliepen]

On Thu, Feb 22, 2018 at 04:30:17PM +0100, Sven-Haegar Koch wrote:

> With ifupdown 0.8.30 my systems tries to install a new service:
> 
> Setting up ifupdown (0.8.30) ...
> Created symlink 
> /etc/systemd/system/network-online.target.wants/ifupdown-wait-online.service 
> → /lib/systemd/system/ifupdown-wait-online.service.

Actually, it always installed that service, but after upgrading to
debhelper compat level 11, I accidentily made it enable that service by
default. I will undo that.

> And yes, there are currently no interfaces active with ifupdown,
> but eth0 is activated by wicd - but this should not block upgrading
> or booting.

With the ifup method, it checks for interfaces marked auto and hotplug.

> auto lo:2
> iface lo:2 inet static
>   address 127.0.0.2
>   netmask 255.255.255.255

This one matches too. It only excludes lo. Note, it's probably better to
just have two iface lo statements than using the ancient interface
aliases. So:

auto lo
iface lo inet loopback
iface lo inet static
address 127.0.0.2/32

> # kabelnetz
> auto eth0
> mapping eth0
>   script /sbin/ifscheme-mapping

Looks like something ifupdown will manage to me... Also, I'm afraid
reportbug helpfully copied your /etc/network/interfaces file in its
entirety, including wireless passwords.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#879458: inputlirc: diff for NMU version 23-2.1

[Guus Sliepen]

For your information, I just updated the upstream repository to include
the fix, and some other minor fixes as well (use /run instead of
/var/run, check the result of daemon(), update the manual page). I
already uploaded version 30-1 to unstable.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#879458: inputlirc: diff for NMU version 23-2.1

[Guus Sliepen]

On Tue, Feb 13, 2018 at 10:31:16PM +0100, Christoph Biedl wrote:

> as I got confirmation from another side this patch fixes the issue, I've
> prepared an NMU for inputlirc (versioned as 23-2.1) and uploaded it to
> DELAYED/2. Please feel free to tell me if I should delay it longer.

That's fine.

> Additionally, I'd also like to see this fixed in an upcoming stretch
> point release and might start the procedure on my own as well. Any "go"
> or "no go" is appreciated.

Go!

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#888661: "configure: error: glm/glm.hpp not found. install glm" although libglm-dev is installed

[Guus Sliepen]

reassign 888661 src:glm
forcemerge 888550 888661
thanks

On Sun, Jan 28, 2018 at 03:31:08PM +0100, Rene Engelhard wrote:

> >configure: WARNING: glm/glm.hpp: present but cannot be compiled
[...]
> /usr/include/glm/detail/setup.hpp:456:100: note: #pragma message: GLM: GCC 
> older than 4.6 has a bug presenting the use of rgba and stpq components
>  # pragma message("GLM: GCC older than 4.6 has a bug presenting the use of 
> rgba and stpq components")
[...]
> Guus, any idea?

This seems to be a duplicate of 888550. So it's a bug in GLM.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#887664: openal-soft: FTBFS: nothing is built

[Guus Sliepen]

Source: openal-soft
Version: 1:1.18.2-1
Severity: serious
Justification: Policy 4.9

Building openal-soft from source in a pbuilder environment fails. It
seems like it thinks there is nothing to build:

> sudo pbuilder build openal-soft_1.18.2-1.dsc
[...]
I: Running cd /build/openal-soft-1.18.2/ && env 
PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us 
-uc -rfakeroot
dpkg-buildpackage: info: source package openal-soft
dpkg-buildpackage: info: source version 1:1.18.2-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Markus Koschany 
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build openal-soft-1.18.2
 fakeroot debian/rules clean
dh clean --builddirectory=/build/openal-soft-1.18.2/build-tree
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/build/openal-soft-1.18.2'
rm -rf /build/openal-soft-1.18.2/build-tree
make[1]: Leaving directory '/build/openal-soft-1.18.2'
   dh_clean -O--builddirectory=/build/openal-soft-1.18.2/build-tree
 dpkg-source -b openal-soft-1.18.2
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building openal-soft using existing 
./openal-soft_1.18.2.orig.tar.gz
dpkg-source: info: building openal-soft in openal-soft_1.18.2-1.debian.tar.xz
dpkg-source: info: building openal-soft in openal-soft_1.18.2-1.dsc
 debian/rules build
make: Nothing to be done for 'build'.
 fakeroot debian/rules binary
dh binary --builddirectory=/build/openal-soft-1.18.2/build-tree
   debian/rules build
make[1]: Entering directory '/build/openal-soft-1.18.2'
make[1]: Nothing to be done for 'build'.
make[1]: Leaving directory '/build/openal-soft-1.18.2'
   dh_testroot -O--builddirectory=/build/openal-soft-1.18.2/build-tree
   dh_prep -O--builddirectory=/build/openal-soft-1.18.2/build-tree
   debian/rules override_dh_auto_install
make[1]: Entering directory '/build/openal-soft-1.18.2'
dh_auto_install
install -d debian/tmp/etc/openal
[...lots of errors about missing files...]
dh_install: libopenal-data missing files: usr/share/openal/hrtf
dh_install: missing files, aborting
debian/rules:34: recipe for target 'binary' failed
make: *** [binary] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2
I: copying local configuration
E: Failed autobuilding of package


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8), 
LANGUAGE=nl_NL.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#887401: tinc: SEGFAULT when trying to connect to IPv6 peer in non-IPv6 environment

[Guus Sliepen]

> Using my tinc setup I observe spurious SEGFAULTs in the daemon process.
[...]
> Apparently, the issue is caused by a use after free due to failing to
> reset a pointer. The patch is attached, too.

Thanks, the patch is now applied in tinc's git repository, and the fix
will be part of the next release.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#779809: /usr/bin/pahole: does not support DWARF 4

[Guus Sliepen]

severity: grave
thanks

None of the tools in the dwarves package seem to work anymore, rendering
the package in question unusable.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#886158: RM: coriander -- ROM; Dead upstream, depends on old libgnome libraries.

[Guus Sliepen]

Package: ftp.debian.org
Severity: normal

Last release was in early 2013, and there has been no activity from
upstream since 2014. It depends on libgnomeui, and is not trivial to
port. Popcon numbers are very low.

Bug#886129: ITP: mstch -- Mustache implementation in C++11

[Guus Sliepen]

Package: wnpp
Severity: wishlist
Owner: Guus Sliepen 

* Package name: mstch
  Version : 1.0.2 
  Upstream Author : Daniel Sipka
* URL : https://github.com/no1msd/mstch
* License : MIT
  Programming Lang: C++
  Description : Mustache implementation in C++11

Mstch is a complete implementation of {{mustache}} templates using
modern C++. It's compliant with specifications v1.1.3, including the
lambda module.

Mustache is a logic-less template language. As such, it is very well
suited for programs that are written in a compiled language, such as C
and C++, as they cannot easily evaluate code found in a template.
However, no C or C++ implementation of Mustache is in Debian yet, so
this package fills that gap, at least for C++.

Currently, this only builds a static library. The binary package will
be called libmstch-dev.

Bug#883816: zstd: Encoding errors when using a dictionary using zstdmt

[Guus Sliepen]

Package: zstd
Version: 1.3.2+dfsg2-1
Severity: important

While testing zstd, I found that when using a pre-made dictionary,
zstdmt will generate corrupted files:

[guus@haplo]/dev/shm/corpus>zstd --rm -D ../dictionary *
[guus@haplo]/dev/shm/corpus>zstd --rm -D ../dictionary -d *
[guus@haplo]/dev/shm/corpus>zstdmt --rm -D ../dictionary *
[guus@haplo]/dev/shm/corpus>zstdmt --rm -D ../dictionary -d *
ar,S=18008914:2,.zst : Decoding error (36) : Corrupted block detected
ar,S=6386609:2,S.zst : Decoding error (36) : Corrupted block detected
ar,S=6382007:2,S.zst : Decoding error (36) : Corrupted block detected
[...]
[guus@haplo]/dev/shm/corpus>zstd --rm -D ../dictionary -d *.zst
ar,S=18008914:2,.zst : Decoding error (36) : Corrupted block detected
ar,S=6386609:2,S.zst : Decoding error (36) : Corrupted block detected
ar,S=6382007:2,S.zst : Decoding error (36) : Corrupted block detected
[...]

Not all files are corrupt, only 1% has problems.

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

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

Versions of packages zstd depends on:
ii  libc6   2.25-3
ii  libgcc1 1:8-20170923-1
ii  libstdc++6  8-20170923-1
ii  libzstd11.3.2+dfsg2-1

zstd recommends no packages.

zstd suggests no packages.

-- no debconf information

Bug#882777: ifupdown: ifup -a tries to bring up an interface that already is up

[Guus Sliepen]

On Sun, Nov 26, 2017 at 06:09:29PM +0100, Ralf Jung wrote:

> The following command:
> 
>   /sbin/ifup -a --read-environment
> 
> tries to bring up some GRE tunnels on my system that are already up.  
> Obviously,
> this fails.  One consequence of that is that the systemd "networking" unit is
> always marked as failed, so systemd never thinks the network is actually up.
> 
> The relevant bits of the /etc/network/interfaces.d/* looks as follows:
[...]
> pre-up ip tunnel add $IFACE mode gre local 51.X.X.X remote 185.X.X.X 
> ttl 255
[...]

The problem with jessie was that it ignored any errors from
pre/post-up/down commands. This was fixed in stretch. If you want
ifupdown to ignore any errors from your pre-up command, just append "||
true" to it, like:

 pre-up ip tunnel add $IFACE mode gre local 51.X.X.X remote 185.X.X.X 
ttl 255 || true

However, this begs the question: why does this fail at all? I tried the
exact same iface stanza on a stretch machine, and doing repeated ifup and
ifdowns just works as it should.

> add tunnel "gre0" failed: File exists

I don't know why it prints "gre0" here, I think that's a bug in ip. I do
see it when I manually try to do the ip tunnel add command multiple
times without ip tunnel del inbetween.

> With exactly the same setup (literally -- this is all automatically 
> deployed), I
> do not get any errors on our jessie systems.  Also the stretch system with a
> slightly older kernel (4.9.0-3) is not affected.  The broken machine has
> 4.9.0-4-amd64.

Hm, that is also weird. Maybe there is something that causes this tunnel
to be brought up before ifup tries to do the same?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#880982: ifup does not trigger scripts any more after booting

[Guus Sliepen]

On Tue, Nov 07, 2017 at 09:55:17PM +0100, Narcis Garcia wrote:

> Thanks Guus for the suggestion about netplug as alternative.
> Network interface's configurtaion (IP) is already done when hotplugging
> the cable.
> 
> What is not working on same event is the run-parts of scripts in
> /etc/network/if-up.d [...]

Aha. If you are using DHCP, then the DHCP client will probably detect
that the cable is plugged in again at some point, and will assign it an
address. However, ifupdown is never called when that happens, so
ifupdown will not cause any of the scripts to run. Also, ifupdown will
consider the interface to be up all the time, whether the cable is
plugged in or not.

Note that dhclient itself can also run scripts when it gets or loses a
lease, see man dhclient-script.

> (as non-Systemd Debian versions did)

This has nothing to do with systemd vs. sysvinit. Maybe it is caused by
changes in udev. But on my computers, I don't see udev generating any
events when I plug or unplug a network cable...

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#880982: ifup does not trigger scripts any more after booting

[Guus Sliepen]

Am 06.11.2017 um 17:53 schrieb Narcis Garcia:

> Interface is declared at /etc/network/interfaces :
> auto enp2s0
> allow-hotplug enp2s0
> iface enp2s0 inet dhcp
> 
> An executable script:
> /etc/network/if-up.d/test1
> only runs on boot (per each NIC). If network cable is plugged to enp2s0
> some minutes later, script is not run.
> Same behavior when booting with network, and unplugging + plugging later.

Hotplug in the context of udev is the hotplugging of a hardware PCI or USB 
device,
not of a network cable. If you want to have a network interface brought
up or down whenever a cable is (un)plugged, try installing the netplug
package, edit /etc/netplug/netplugd.conf and add enp2s0 to it, and
remove both "auto enp2s0" and "allow-hotplug enp2s0" from
/etc/network/interfaces.

Note that cable (un)plug events might not be properly supported by all
network cards.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#879518: ifupdown: fail to start with bridge_stp on and recursion detected in parent-lock with vlan after jessie upgrade

[Guus Sliepen]

severity 879518 normal
thanks

On Sun, Oct 22, 2017 at 04:35:58PM +0200, Daniel wrote:

> Severity: critical
> Justification: breaks the whole system

Downgrading to normal since this bug doesn't fit the definition of
critical:

“Makes unrelated software on the system (or the whole system) break, or
causes serious data loss, or introduces a security hole on systems where
you install the package.”

> This setup was perfectly running on Jessie. After upgrading to Stretch, all 
> the network stuff was down, doesn't matter if local, VMs or Internet.
> In the interfaces file below we changed the bridge-stp to off to get rid from 
> the "set forward delay failed: Numerical result out of range" error.
> After this, interface bone was going up as well as eth0 but then we had the 
> parent-lock error. We commented the pre-up bone[.1|.2] on each interface who 
> call them
> and the system started with all interfaces up.

I see. Locking interfaces indeed prevents a VLAN interface from calling ifup on
its parent interface. It's actually with good reason; while it may have
worked on your bridge interface, it's not guaranteed to work correctly,
and it will break in situations where interface are created on demand
(like with tun/tap interfaces).

That said, it's of course necessary for the parent interface to be up
before you can bring up a VLAN interface. So I'll probably change
ifupdown to do that for you. That way, you won't need pre-up ifup
statements anymore.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#870217: glm: diff for NMU version 0.9.8.4-1.1

[Guus Sliepen]

On Sun, Oct 22, 2017 at 03:34:53PM +0200, Tobias Frost wrote:

> I've prepared an NMU for glm (versioned as 0.9.8.4-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

I was actually waiting for 0.9.8.6 or 0.9.9 to be released, but I won't
mind this NMU :)

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#754513: RFP: libressl -- SSL library, forked from OpenSSL

[Guus Sliepen]

On Mon, Oct 16, 2017 at 10:21:10PM -0400, Michael Stone wrote:

> On Tue, Oct 17, 2017 at 12:05:30AM +0200, Guus Sliepen wrote:
> > despite fears of OpenBSD only caring about themselves, I have found that
> > it is easier to compile LibreSSL for various platforms (even non-POSIX
> > ones) than OpenSSL. And that APIs might be broken more easily by LibreSSL
> > is ridiculous, as it is OpenSSL iself that has changed its API in a
> > non-backwards compatible way that is now causing this discussion.
> 
> It is not ridiculous to point out that LibreSSL is released every six months
> and supported for one year after release, while OpenSSL is supported for at
> least 2 years, and 5 years for LTS releases.

That is certainly not ridiculous. But, I had a look at the release plan
for OpenSSL at https://www.openssl.org/policies/releasestrat.html, and
it seems there only is one LTS release, namely 1.0.2, which will be
supported until the very end of 2019. 1.1.0 is only supported until
September 2018. In that context it is strange that we switched to 1.1.0
in stretch already. Let's hope there is an LTS for 1.1.x in time for
buster.

> It's not unrealistic to think
> that a Debian stable could release with a LibreSSL that's already
> unsupported upstream. It is also not ridiculous to point out that a number
> of distributions have an interest in long term maintenance of released
> versions of OpenSSL, while there is no such community around LibreSSL.

Maybe not currently for Debian or Fedora derivatives, but some
distributions (Alpine, OpenELEC amongst others) have switched to
LibreSSL as the default, and some (Gentoo, unsurprisingly) have it as an
option.

I see two main forces determining which fork of a library will be used:
either distributions themselves will choose based on technical and other
merits, or important applications will favor one of the forks, forcing
the decision for distributions. OpenSSH is now applying some force, I
have no idea what programs are out there that can only work with
OpenSSL. I assume those that moved to OpenSSL 1.1 and ditched OpenSSL
1.0 compatibility, but I wonder how many there are.

It would be interesting to recompile all packages that Build-Depend:
libssl-dev with LibreSSL, and see what actually breaks...

> As I continue to think about it, it may actually end up being better to
> embed a constrained subset of LibreSSL in OpenSSH than worry about either
> maintaining the entire LibreSSL package over a period of years, or fork.

I don't see why it couldn't be in its own package even if OpenSSH was
the only user. It doesn't change the maintenance burden.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature