Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Samuel Thibault]

Vincent Bernat, on lun. 10 juil. 2017 20:55:29 +0200, wrote:
> but there is nothing difficult in identifying the right interface with
> the new naming scheme.

Errr, it may not look difficult to *you*, but to someone who is learning
how to tinker Linux, things like enp0s25f1 looks really difficult and
scary.

And while I don't find it difficult either, I'm annoyed by having to
find out the name of the network board of the systems I'm using, while
basically 95% of them will ever have only one interface anyway. It looks
really odd that the default is to get annoyed 95% of the time for no
reason there... (again, because it seems this doesn't get through: I'm
*not* saying this naming scheme doesn't fix anything. I'm just saying
that 95% of the time there's only one network device anyway, so the fix
is moot 95% of the time)

> Other major distributions are using this new scheme (notably Ubuntu
> which has no reason to have users smarter than ours)

The reasoning is the converse: non-techy users will just not be exposed
to interface names anyway. Debian users, however, tend to be more techy,
and do see these interface names. And basically *all* documentation
before this interface name change is now incomprehensible to techy
beginners.

I'm really worried here: this change, like a lot others done recently,
is making the Linux ecosystem yet more complex to understand, thus
raising the barrier for techy beginners yet higher.

At which point will we just stop seeing new random contributers, just
become the system has become too complex to grasp by oneself?

Samuel

Bug#867993: RFP: pyscada -- SCADA system with web interface

[W. Martin Borgert]

Package: wnpp
Severity: wishlist

* Package name: pyscada
  Version : 0.7.0b17
  Upstream Author : Martin Schröder 
* URL : https://github.com/trombastic/PyScada
* License : GPL3
  Programming Lang: Python
  Description : SCADA system with web interface

>From the README:

> A Open Source SCADA System with HTML5 HMI, build using the
> Django framework. If you like to setup your own SCADA system
> head over to the
> http://pyscada.readthedocs.io/en/dev-0.7.x/installation.html
> section.
>
> Features
>
> HTML5 based HMI
>
> Supports the following industrial Protocols
>  * Modbus TCP/IP
>  * Modbus RTU
>  * Modbus ASCII
>  * Modbus Binary
>  * Phant http://phant.io/
>  * VISA https://pypi.python.org/pypi/PyVISA
>  * 1-Wire (only experimental only RPi3)
>  * BACNet/IP (in development)
>  * Meter-Bus, MBus (in development)
>
> very low Hardware requirements for the Server

Re: Naming of network devices

[Vincent Bernat]

 ❦ 10 juillet 2017 15:53 -0400, Marvin Renich  :

>> > With the new scheme, if I want to rename the interface to something more
>> > meaningful, I have to go find an older machine that already has a
>> > persistent-net.rules file or read through a lot of documentation to
>> > figure out the correct syntax.  I then have to determine the correct
>> > ATTR elements to identify the interface in question, and type all of
>> > that information by hand, hoping I type everything correctly.
>> 
>> Have a look at systemd.link(5) which enables you to do that without
>> debugging udev.
>
> Okay, I had a look on a six-weeks-before-release stretch VM, and I don't
> see anything there that makes this easier than with the udev .rules
> file.  There is still no skeleton .link file that already has the
> appropriate attributes already filled in.  It looks like I still have to
> create a .link file and manually type the appropriate attributes.  Am I
> missing something?

Not really.

In /etc/systemd/network/whatever.link, put:

#v+
[Match]
MACAddress=00:11:22:33:44:55

[Link]
Name=em0
#v-

Note the manual page has a similar example. I don't see exactly how this
is more complex than the udev rules we had:

#v+
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:11:22:33:44:55", ATTR{type}=="1", KERNEL=="eth*",
NAME="em0"
#v-

>
> BTW, there seems to be a typo in the man page:  it refers to a
> /run/systemd/network directory; should that be /run/systemd/netif/links?
> I'll leave you to file a bug if appropriate.

No, it seems correct. All systemd-related stuff look at /lib/systemd/X
(shipped with a package), /run/systemd/X (added by a third-party
program) and /etc/systemd/X (added by the user).

>> > There is an easy fix to revert the default behavior while still allowing
>> > knowledgeable sysadmins to get the new behavior.  On the other hand,
>> > those who need to administer systems but are not sysadmins by trade (and
>> > thus will have to do significantly more research to even know that the
>> > older behavior is possible) are the ones who need the older behavior as
>> > the default.
>> 
>> Having a default behavior that's unreliable doesn't seem great
>> either. The change is surprising (and not expected on non-new systems),
>> but there is nothing difficult in identifying the right interface with
>> the new naming scheme. Other major distributions are using this new
>> scheme (notably Ubuntu which has no reason to have users smarter than
>> ours) and I don't see a lot of drama on their side. It seems that for
>> some reason, we are the only ones making a fuss about any change.
>
> I don't get this at all.  The previous behavior was neither unreliable
> nor unpredictable (unless you are talking about much older systems
> before persistent-net.rules).

It was unreliable. Google for "eth0_rename", you'll get ton of examples
of people with hosts that don't boot reliably because of the inherent
race conditions. Udev people didn't invent all this just to get people
pissed. They have fixed a real problem.

> What change is surprising?  The change between jessie and stretch?
> Absolutely.

Yes.

> You have completely sidestepped the question, which is about the
> relative importance of the two goals, simple names _all the time_ vs
> avoiding a state file.  The previous behavior sacrifices the second,
> much less important goal in favor of the first.  The new behavior
> sacrifices the first in favor of the second.  Until you address this
> issue, all your explanations look like attempts to ameliorate bad
> behavior.

Predictable names are more important to me. Simple name should also work
for most people (using the eno*) scheme. Maybe it's not available as
widely as it should be.
-- 
Make sure input cannot violate the limits of the program.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Naming of network devices

[Philipp Kern]

On 07/10/2017 07:31 PM, Martin Steigerwald wrote:
> Which fails to mention how the feature can be configured and some mechanisms 
> like relying on BIOS name, can be disabled, for example:
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/
> Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html
> 
> Funnily enough the Debian wiki page even mentions that some BIOS firmwares 
> return crap as the onboard device number:
> 
>> Sadly, the system used is still somewhat arbitrary in that it relies on the
>> BIOS enumeration which changes in with buggy BIOSs and under some
>> situations.
> 
> without offering a solution:
> 
>> For people using more than one Network Interface - we will just have to deal
>> with the new system.
> 
> https://wiki.debian.org/
> NetworkConfiguration#Predictable_Network_Interface_Names

I was under the impression that Debian does not even use biosdevname.
(I'm not sure anyone else still does.)

But I can be wrong, of course.

I think now that we released this the most straightforward way to go
about this is to cope and document for others. Personally I dislike the
idea of a state file that you need to know about to remove during
imaging, but to everyone their own.

If you use things like systemd-networkd[1], you'll also notice that the
configuration scheme does not even require you to specify the interface
to operate on. Instead you get a bunch of match expressions. Which
leaves things like daemons, which more often hardcode IP addresses than
interfaces, though.

Kind regards
Philipp Kern

[1] Which indeed has flaws, most notably with IPv6.



signature.asc
Description: OpenPGP digital signature

Naming of network devices (was: Re: Debian 9 in a VM with Proxmox 5 system)

[Marvin Renich]

* Vincent Bernat  [170710 14:56]:
>  ❦ 10 juillet 2017 14:36 -0400, Marvin Renich  :
> 
> > The only benefit I have seen between the new scheme and the previous
> > one is that there is no state file.  While getting rid of the state
> > file is a nice goal, it is extremely minor compared to having short,
> > simple names in common use cases like inserting a wifi usb dongle.
> 
> Knowing the device name of a wifi dongle seems a pretty niche case. Most
> users will just use network manager to select the appropriate SSID and
> forget about it.

I am specifically addressing the middle-tier users:  those who have some
knowledge, are manually configuring the machine for some reason, but are
not professional sysadmins.  Neither the naive user nor the professional
sysadmin will be bothered by either choice, but I believe that there is
a significant population of Debian users (and Linux users in general)
that fall into the tech-hobbyist category, for whom this is an important
issue.

> > With the new scheme, if I want to rename the interface to something more
> > meaningful, I have to go find an older machine that already has a
> > persistent-net.rules file or read through a lot of documentation to
> > figure out the correct syntax.  I then have to determine the correct
> > ATTR elements to identify the interface in question, and type all of
> > that information by hand, hoping I type everything correctly.
> 
> Have a look at systemd.link(5) which enables you to do that without
> debugging udev.

Okay, I had a look on a six-weeks-before-release stretch VM, and I don't
see anything there that makes this easier than with the udev .rules
file.  There is still no skeleton .link file that already has the
appropriate attributes already filled in.  It looks like I still have to
create a .link file and manually type the appropriate attributes.  Am I
missing something?

BTW, there seems to be a typo in the man page:  it refers to a
/run/systemd/network directory; should that be /run/systemd/netif/links?
I'll leave you to file a bug if appropriate.

> > There is an easy fix to revert the default behavior while still allowing
> > knowledgeable sysadmins to get the new behavior.  On the other hand,
> > those who need to administer systems but are not sysadmins by trade (and
> > thus will have to do significantly more research to even know that the
> > older behavior is possible) are the ones who need the older behavior as
> > the default.
> 
> Having a default behavior that's unreliable doesn't seem great
> either. The change is surprising (and not expected on non-new systems),
> but there is nothing difficult in identifying the right interface with
> the new naming scheme. Other major distributions are using this new
> scheme (notably Ubuntu which has no reason to have users smarter than
> ours) and I don't see a lot of drama on their side. It seems that for
> some reason, we are the only ones making a fuss about any change.

I don't get this at all.  The previous behavior was neither unreliable
nor unpredictable (unless you are talking about much older systems
before persistent-net.rules).  What change is surprising?  The change
between jessie and stretch?  Absolutely.

You have completely sidestepped the question, which is about the
relative importance of the two goals, simple names _all the time_ vs
avoiding a state file.  The previous behavior sacrifices the second,
much less important goal in favor of the first.  The new behavior
sacrifices the first in favor of the second.  Until you address this
issue, all your explanations look like attempts to ameliorate bad
behavior.

...Marvin

Bug#867969: ITP: sdformat5 -- Simulation Description Format (SDF) parser

[Jose Luis Rivero]

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 

* Package name: sdformat5
Version   : 5.1.0
Upstream Author   : Open Source Robotics Foundation
* URL : http://sdformat.org
* License : BSD
Programming Lang  : C++
Description   : Simulation Description Format (SDF) parser

SDF is an XML file format that describes environments, objects, and
robots in a manner suitable for robotic applications. SDF is capable of
representing and describing different physic engines, lighting
properties, terrain, static or dynamic objects, and articulated robots
with various sensors, and acutators.  The format of SDF is also
described by XML, which facilitates updates and allows conversion from
previous versions. A parser is also contained within this package that
reads SDF files and returns a C++ interface.

Version 4 is already in debian.

Bug#867968: ITP: ign-transport3 -- Ignition Transport library v3

[Jose Luis Rivero]

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 

* Package name: ign-transport3
  Version : 3.0.1
  Upstream Author : Open Source Robotics Foundation
* URL : http://ignitionrobotics.org/libraries/transport
* License : Apache
  Programming Lang: C++
  Description : Transport library which combines ZeroMQ and Protobuf

ignition transport library combines ZeroMQ with Protobufs to create a
fast and efficient message passing system. Asynchronous message
publication and subscription is provided along with service calls and
discovery.

The version 1 is already in Debian. Here is the version 3.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Vincent Bernat]

 ❦ 10 juillet 2017 14:36 -0400, Marvin Renich  :

> The only benefit I have seen between the new scheme and the previous
> one is that there is no state file.  While getting rid of the state
> file is a nice goal, it is extremely minor compared to having short,
> simple names in common use cases like inserting a wifi usb dongle.

Knowing the device name of a wifi dongle seems a pretty niche case. Most
users will just use network manager to select the appropriate SSID and
forget about it.

> With the new scheme, if I want to rename the interface to something more
> meaningful, I have to go find an older machine that already has a
> persistent-net.rules file or read through a lot of documentation to
> figure out the correct syntax.  I then have to determine the correct
> ATTR elements to identify the interface in question, and type all of
> that information by hand, hoping I type everything correctly.

Have a look at systemd.link(5) which enables you to do that without
debugging udev.

> There is an easy fix to revert the default behavior while still allowing
> knowledgeable sysadmins to get the new behavior.  On the other hand,
> those who need to administer systems but are not sysadmins by trade (and
> thus will have to do significantly more research to even know that the
> older behavior is possible) are the ones who need the older behavior as
> the default.

Having a default behavior that's unreliable doesn't seem great
either. The change is surprising (and not expected on non-new systems),
but there is nothing difficult in identifying the right interface with
the new naming scheme. Other major distributions are using this new
scheme (notably Ubuntu which has no reason to have users smarter than
ours) and I don't see a lot of drama on their side. It seems that for
some reason, we are the only ones making a fuss about any change.
-- 
The mind is its own place, and in itself
Can make a Heav'n of Hell, a Hell of Heav'n.
-- John Milton


signature.asc
Description: PGP signature

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Marvin Renich]

* Marco d'Itri  [170710 13:12]:
> On Jul 10, Adam Borowski  wrote:
> 
> > Predictability is important, thus let's actually have _predictable_
> > interface names.  The kernel default, eth0 and wlan0, is good enough for
> > most users, why not keep that?  Even just ignoring the issue completely
> Because you cannot know how many interfaces a system has until all of 
> them will have appeared.
> Please stop beating this long time dead horse.

This has been discussed on debian-devel in the past, but this is the
first time that many of our users have seen this.  This horse is very
much alive, just locked in the barn without food.

Neither you, nor any other proponent of the new scheme has addressed the
fact that short, easily remembered names in _all_ cases is significantly
more important than not having a state file.

The only benefit I have seen between the new scheme and the previous one
is that there is no state file.  While getting rid of the state file is
a nice goal, it is extremely minor compared to having short, simple
names in common use cases like inserting a wifi usb dongle.

And no, enp2s0f1 is neither short nor simple.  It requires remembering
three numbers and three letters that identify internal parts of the
hardware hierarchy that are irrelevant to the sysadmin.

With the previous scheme, an interface would be assigned a short, simple
name the first time it was seen.  The sysadmin could easily edit the
state file to give it a more meaningful name, if desired.  The state
file already had all the other information needed to identify the
interface; a simple one-word change in the file was sufficient.
Whatever name was in the state file was used for that piece of hardware
from then on.  The names were at least as predictable as they are with
the new scheme.

With the new scheme, if I want to rename the interface to something more
meaningful, I have to go find an older machine that already has a
persistent-net.rules file or read through a lot of documentation to
figure out the correct syntax.  I then have to determine the correct
ATTR elements to identify the interface in question, and type all of
that information by hand, hoping I type everything correctly.

There is an easy fix to revert the default behavior while still allowing
knowledgeable sysadmins to get the new behavior.  On the other hand,
those who need to administer systems but are not sysadmins by trade (and
thus will have to do significantly more research to even know that the
older behavior is possible) are the ones who need the older behavior as
the default.

...Marvin

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Bjørn Mork]

m...@linux.it (Marco d'Itri) writes:
> On Jul 10, Adam Borowski  wrote:
>
>> Predictability is important, thus let's actually have _predictable_
>> interface names.  The kernel default, eth0 and wlan0, is good enough for
>> most users, why not keep that?  Even just ignoring the issue completely
> Because you cannot know how many interfaces a system has until all of 
> them will have appeared.

Just like you cannot know how many PCI buses a system has until all of
them have appeared.  But depending on the faulty assumption that PCI bus
numbers are static is apparently good enough for most users?

Yes, it *is* definitely a dead horse your are beating here. There is no
such thing as predictable network names.  Continuing to pretend
otherwise will not move this discussion forward.


Bjørn

Naming of network devices (was: Re: Debian 9 in a VM with Proxmox 5 system)

[Martin Steigerwald]

Hola.

Adam Borowski - 10.07.17, 18:22:
> On Mon, Jul 10, 2017 at 03:47:14PM +0200, Guus Sliepen wrote:
> > On Mon, Jul 10, 2017 at 01:57:08PM +0200, Rene Engelhard wrote:
> > > eth0 will be kept on upgrades, but new installs get new interface names
> > > (that is good, that removed unpredictability if you add a new network
> > > card.)> 
> > Interface names are, unfortunately, as unpredictable in stretch as they
> > were in jessie, just unpredictable in a different way. Now network names
> > are decided based on bus topology or MAC address. Bus topology however
> > is not something that is as predictable as you might think, and some
> > network cards just don't have a fixed MAC address. Bus topology might
> > change if you just move a card from one slot to the next, or as I've
> > experienced myself, when nothing in the hardware changes, but a BIOS
> > update causes enumeration to happen differently.
> > 
> > At least the interface names in jessie were shorter, and you had a good
> > chance that eth0 was exactly what you wanted :)
> 
> I'd say the last part is the most important one: the vast majority of
> machines have exactly one Ethernet interface and at most one WiFi interface.
> Furthermore, the ones that got more either have an admin with some
> knowledge (bigger servers) or come preloaded (routers).
> 
> Predictability is important, thus let's actually have _predictable_
> interface names.  The kernel default, eth0 and wlan0, is good enough for
> most users, why not keep that?  Even just ignoring the issue completely
> is much, much better than current state.
> 
> FreeDesktop's interface naming promised stability, it did not deliver.  Even
> regular non-fancy x86 machines often switch names on jessie->stretch
> upgrades, not to mention arm SoCs with no MAC address at all (that EPROM
> would cost a few cents, you see...).

Actually I disabled the new naming scheme in CentOS VMs I use for training 
already, cause… for VMware VM´s it tends to create names followed by a number 
of about 16 million – sometimes. Yes, thats no joke. I don´t have a copy of 
that name any more, but here is an online reference to that marvellous 
eno1636 name:

https://serverfault.com/questions/636621/why-is-my-eth0-called-eno1636

Yes, and it appears to be a negative overflow of acpi_index, so the actual 
issue below it may appear to be elsewhere, in the BIOS/UEFI firmware, but why 
rely on something that can have crazy values like that in the first place 
without checking it for sanity first?

https://communities.vmware.com/message/2378360

I can imagine the likely response by upstream "wontfix – not a bug" – I have 
seen this pattern way too often regarding this particular upstream meanwhile.


Also, RHEL 7´s networking guide has a *complete* chapter with eleven sub 
chapters about naming network devices:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/
Networking_Guide/ch-Consistent_Network_Device_Naming.html

Just the subchapter of disabling the names is quite hilarious:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/
Networking_Guide/sec-Disabling_Consistent_Network_Device_Naming.html

A *chapter* on the naming of network devices… sanity and simplicity look 
different to me and I am not happy about that being the new default in Stretch 
installs. I didn´t open a bug, cause my faith of it being handled in a way 
that actually creates a relief is pretty low. Thankfully it does´t change the 
naming scheme on upgrades:

https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#new-interface-names

But at least… RHEL has this documentation. In Debian it appears to be 
underdocumented, there is a snippet in README.Debian of udev package, the 
short mentioning in Release notes and a short snippet in Debian wiki which all 
refer to a quite short page on Freedesktop.org webpage which at least 
describes by what rules udev now tries to name network devices:

https://www.freedesktop.org/wiki/Software/systemd/
PredictableNetworkInterfaceNames/

Which fails to mention how the feature can be configured and some mechanisms 
like relying on BIOS name, can be disabled, for example:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/
Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html

Funnily enough the Debian wiki page even mentions that some BIOS firmwares 
return crap as the onboard device number:

> Sadly, the system used is still somewhat arbitrary in that it relies on the
> BIOS enumeration which changes in with buggy BIOSs and under some
> situations.

without offering a solution:

> For people using more than one Network Interface - we will just have to deal
> with the new system.

https://wiki.debian.org/
NetworkConfiguration#Predictable_Network_Interface_Names


So in summary this change adds a *huge lot* of complexity with questionable 
gain.


In addition to the new default VIM 

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Adam Borowski]

On Mon, Jul 10, 2017 at 07:11:58PM +0200, Marco d'Itri wrote:
> On Jul 10, Adam Borowski  wrote:
> 
> > Predictability is important, thus let's actually have _predictable_
> > interface names.  The kernel default, eth0 and wlan0, is good enough for
> > most users, why not keep that?  Even just ignoring the issue completely
> Because you cannot know how many interfaces a system has until all of 
> them will have appeared.
> Please stop beating this long time dead horse.

The problem is, that horse's replacement has just received a yet another
black mark, this time stretch-sized.  At this time I'd say even no horse at
all is way better than "predictable" random names.  The "no horse" solution
has the benefit of working better in 95% cases, the remaining ones being
very well correlated with expected admin skills.

Another potential horse would be to take current "predictable" output and
feeding it to a state file: that would fix at a good part (but not all) of
problems we have.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: New network interface naming scheme [was Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system]

[Vincent Bernat]

 ❦ 10 juillet 2017 18:37 +0200, Adam Borowski  :

>> > The cost of a state file (/etc/udev/rules.d/70-persistent-net.rules) is
>> > extremely small, even in the very worst case where a user continually
>> > plugs in many, many different usb network dongles, which is a very
>> > unrealistic case to begin with.
>> 
>> The state file solution was not perfect either. If you have two brands
>> of NIC (Intel 10G additional NIC and Broadcom 1G integrated NIC for
>> example), it was not uncommon to be left with an interface eth0_rename
>> after boot because the target name was used by the other driver.
>
> Because of a race with the kernel creating eth1 while you're trying to
> rename eth0->eth0_rename->eth1, right?  That's trivially solvable by
> inventing a new scheme, such as e0 e1 (I'm sure someone can sound a scheme
> that sounds better than this).

Yes, that would work. There are still some issues, like random numbering
during the first boot. Note that udev is mostly following this scheme
with "eno1", "eno2", ...

> On the other hand, I use kernel-assigned names on all my machines that don't
> have multiple interfaces, thus I don't know how stable
> 70-persistent-net.rules is on the MAC-less machines.  I guess you guys know
> more.  But even if you take those new "persistent" names as a base for the
> state file, we wouldn't gain stability over kernel upgrades but the names
> would be actually predictable for the user (ie, the admin would know the
> only interface will be "e0").

For a physical machine, the only interface is usually eno1. For a
virtual machine, the numbering may be absent and this case, the
interface name is ensX with X which depends on your provider. Maybe an
exception could have been done for virtio, but there are edge cases they
may be difficult to catch (someone changing virtio to e1000 for example).

This can be checked with:

  udevadm info -p /sys/class/net/eno1 | grep ID_NET_NAME

The default order is onboard, slot, path. Debian has a local
modification to use the MAC address for USB devices.

See also:
 
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/#comeagainwhatgooddoesthisdo
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Marco d'Itri]

On Jul 10, Adam Borowski  wrote:

> Predictability is important, thus let's actually have _predictable_
> interface names.  The kernel default, eth0 and wlan0, is good enough for
> most users, why not keep that?  Even just ignoring the issue completely
Because you cannot know how many interfaces a system has until all of 
them will have appeared.
Please stop beating this long time dead horse.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: New network interface naming scheme [was Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system]

[Adam Borowski]

On Mon, Jul 10, 2017 at 06:05:06PM +0200, Vincent Bernat wrote:
>  ❦ 10 juillet 2017 09:38 -0400, Marvin Renich  :
> 
> > The cost of a state file (/etc/udev/rules.d/70-persistent-net.rules) is
> > extremely small, even in the very worst case where a user continually
> > plugs in many, many different usb network dongles, which is a very
> > unrealistic case to begin with.
> 
> The state file solution was not perfect either. If you have two brands
> of NIC (Intel 10G additional NIC and Broadcom 1G integrated NIC for
> example), it was not uncommon to be left with an interface eth0_rename
> after boot because the target name was used by the other driver.

Because of a race with the kernel creating eth1 while you're trying to
rename eth0->eth0_rename->eth1, right?  That's trivially solvable by
inventing a new scheme, such as e0 e1 (I'm sure someone can sound a scheme
that sounds better than this).

On the other hand, I use kernel-assigned names on all my machines that don't
have multiple interfaces, thus I don't know how stable
70-persistent-net.rules is on the MAC-less machines.  I guess you guys know
more.  But even if you take those new "persistent" names as a base for the
state file, we wouldn't gain stability over kernel upgrades but the names
would be actually predictable for the user (ie, the admin would know the
only interface will be "e0").


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Adam Borowski]

On Mon, Jul 10, 2017 at 03:47:14PM +0200, Guus Sliepen wrote:
> On Mon, Jul 10, 2017 at 01:57:08PM +0200, Rene Engelhard wrote:
> 
> > eth0 will be kept on upgrades, but new installs get new interface names
> > (that is good, that removed unpredictability if you add a new network card.)
> 
> Interface names are, unfortunately, as unpredictable in stretch as they
> were in jessie, just unpredictable in a different way. Now network names
> are decided based on bus topology or MAC address. Bus topology however
> is not something that is as predictable as you might think, and some
> network cards just don't have a fixed MAC address. Bus topology might
> change if you just move a card from one slot to the next, or as I've
> experienced myself, when nothing in the hardware changes, but a BIOS
> update causes enumeration to happen differently.
> 
> At least the interface names in jessie were shorter, and you had a good
> chance that eth0 was exactly what you wanted :)

I'd say the last part is the most important one: the vast majority of
machines have exactly one Ethernet interface and at most one WiFi interface. 
Furthermore, the ones that got more either have an admin with some knowledge
(bigger servers) or come preloaded (routers).

Predictability is important, thus let's actually have _predictable_
interface names.  The kernel default, eth0 and wlan0, is good enough for
most users, why not keep that?  Even just ignoring the issue completely
is much, much better than current state.

FreeDesktop's interface naming promised stability, it did not deliver.  Even
regular non-fancy x86 machines often switch names on jessie->stretch
upgrades, not to mention arm SoCs with no MAC address at all (that EPROM
would cost a few cents, you see...).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: New network interface naming scheme [was Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system]

[Vincent Bernat]

 ❦ 10 juillet 2017 09:38 -0400, Marvin Renich  :

> The cost of a state file (/etc/udev/rules.d/70-persistent-net.rules) is
> extremely small, even in the very worst case where a user continually
> plugs in many, many different usb network dongles, which is a very
> unrealistic case to begin with.

The state file solution was not perfect either. If you have two brands
of NIC (Intel 10G additional NIC and Broadcom 1G integrated NIC for
example), it was not uncommon to be left with an interface eth0_rename
after boot because the target name was used by the other driver.
-- 
Each module should do one thing well.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#867920: ITP: libjlargearrays-java -- Java library for one dimensional arrays up to 2^63 elements

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libjlargearrays-java
  Version : 1.6
  Upstream Author : Piotr Wendykier 
* URL : https://gitlab.com/ICM-VisLab/JLargeArrays
* License : BSD-2-Clause
  Programming Lang: Java
  Description : Java library for one dimensional arrays up to 2^63 elements

Current implementations of Java Virtual Machines allow the creation of
one-dimensional arrays of length smaller than 2^31 elements.
JLargeArrays addresses the problem of maximal size of one-dimensional
Java arrays providing classes that can store up to 2^63 primitive
elements.

JLargeArrays provides the abstract class for primitive types, as well
as the non abstract classes for Number classes, String, bit values,
complex numbers, and objects.  It also supports subarrays.

This package is a common dependency on scientific java software where
the 2^31 number of elements is a common issue.

Bug#867915: ITP: xsimd -- C++ wrappers for SIMD intrinsics

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: xsimd
  Version : 3.0.0
  Upstream Author : Johan Mabille and Sylvain Corlay
* URL : https://github.com/QuantStack/xsimd
* License : BSD
  Programming Lang: C++
  Description : C++ wrappers for SIMD intrinsics

Long-Description:
 SIMD (Single Instruction, Multiple Data) is a feature of microprocessors
 that has been available for many years. SIMD instructions perform a
 single operation on a batch of values at once, and thus provide a way to
 significantly accelerate code execution. However, these instructions
 differ between microprocessor vendors and compilers.
 .
 xsimd provides a unified means for using these features for library
 authors. Namely, it enables manipulation of batches of numbers with the
 same arithmetic operators as for single values. It also provides
 accelerated implementation of common mathematical functions operating
 on batches.

The xsimd library is part of the xtensor stack. It will be maintained by
the Debian Science Team alongside the rest of the xtensor libraries.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Guus Sliepen]

On Mon, Jul 10, 2017 at 01:57:08PM +0200, Rene Engelhard wrote:

> eth0 will be kept on upgrades, but new installs get new interface names
> (that is good, that removed unpredictability if you add a new network card.)

Interface names are, unfortunately, as unpredictable in stretch as they
were in jessie, just unpredictable in a different way. Now network names
are decided based on bus topology or MAC address. Bus topology however
is not something that is as predictable as you might think, and some
network cards just don't have a fixed MAC address. Bus topology might
change if you just move a card from one slot to the next, or as I've
experienced myself, when nothing in the hardware changes, but a BIOS
update causes enumeration to happen differently.

At least the interface names in jessie were shorter, and you had a good
chance that eth0 was exactly what you wanted :)

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


signature.asc
Description: PGP signature

New network interface naming scheme [was Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system]

[Marvin Renich]

First, the original thread belongs on debian-user, not debian-devel.
Please move the "how do I use the new (more than a decade old)
networking tools" user question there.

* Rene Engelhard  [170710 08:03]:
> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.de.html#new-interface-names
> 
> eth0 will be kept on upgrades, but new installs get new interface names
> (that is good, that removed unpredictability if you add a new network card.)

I do want to respond to this, though.  (I see Adam already has, as
well.)

The new interface naming scheme seemed to have two primary goals:  to
have reproducible interface names, and to avoid using a state file.
There also appeared to be a very minor goal of having short, simple
names when easily done.

I am very disappointed at the outcome, because I believe having short,
simple names in _all_ cases is more important than not using a state
file, by _at least_ an order of magnitude.

The cost of a state file (/etc/udev/rules.d/70-persistent-net.rules) is
extremely small, even in the very worst case where a user continually
plugs in many, many different usb network dongles, which is a very
unrealistic case to begin with.

On the other hand, the cost of having to deal with wlxf81a671bcfae just
because you are using a usb dongle is considerable, and this is a very
realistic and much more common case.

This is a case of misplaced design priorities that has turned out very
badly.  I would like to see /lib/udev/rules.d/80-net-setup-link.rules
moved somewhere that is not used by default (e.g.
/usr/share/udev/optional-rules/) and only used if the sysadmin
explicitly links to it in /etc/udev/rules.d/.

Thanks, Adam, for the clue about how to disable this!

...Marvin

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Maximilian Althaus]

Hi!

Thanks, but this do not help me. I have still the same error.

http://prntscr.com/ftv2uj

This is a screenshot when I start the networking service and it failed, 
because of there is no route command!


--

This is the config for (/etc/network/interfaces)

auto lo
iface lo inet loopback

auto ens18
allow-hotplug ens18
iface ens18 inet static
addressIP.V4.ADDR.ESS
netmask 255.255.255.255
broadcastIP.V4.ADDR.ESS
post-up route addROOTER.IPV4.ADDR.ESSdev ens18
post-up route add default gwROOTER.IPV4.ADDR.ESS
pre-down route delROOTER.IPV4.ADDR.ESSdev ens18
pre-down route del default gwROOTER.IPV4.ADDR.ESS

Cheers,
Maximilian

Rene Engelhard 
10. July 2017 at 1:57 PM
On Mon, Jul 10, 2017 at 01:44:00PM +0200, Maximilian Althaus wrote:

Okay, I understand! But I have the problem that the Debian 9 VM can not


No, you don't. You already got told about ip -r. "route" and "ifconfig" are not
installed per default anymore.


get an internet connection. This is because the network configuration
(/etc/network/interfaces) fail, because Debian 9.0 could not found a
device named eth0, but with Debian 8.8 with the same configuration I have


https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.de.html#new-interface-names

eth0 will be kept on upgrades, but new installs get new interface names
(that is good, that removed unpredictability if you add a new network card.)


no problem and I have an internet connection. On top of this on the Debian
9 VM it the networking service says that there is no route commend. What
can I do ? Do I need an other network configuration
(/etc/network/interfaces) 


as already said: if you want route, you need net-tools installed.
otherwise (afaicr) ip r(oute).

https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html#iproute2

(I asume you're .de, if not, sorry and then read the english
release notes.)

Regards,

Rene
Maximilian Althaus 
10. July 2017 at 1:44 PM
Hi!

Okay, I understand! But I have the problem that the Debian 9 VM can 
not get an internet connection. This is because the network 
configuration (/etc/network/interfaces) fail, because Debian 9.0 could 
not found a device named eth0, but with Debian 8.8 with the same 
configuration I have no problem and I have an internet connection. On 
top of this on the Debian 9 VM it the networking service says that 
there is no route commend. What can I do ? Do I need an other 
network configuration (/etc/network/interfaces) 


Cheers,
Maximilian


Nicholas D Steeves 
10. July 2017 at 1:49 AM
P.S. That cheat sheet isn't nearly as nice...as I'd like it to be I
wish it was a compact printable two or three column reference with
net-tools commands in bold and the short-form iw equivalent
underneath.

eg: 'ip -r r' is more or less equivalent to 'route'
Maximilian Althaus 
10. July 2017 at 1:07 AM
Hello,

today I installed a Proxmox 5 system on a dedicated server. Then I 
want to create a VM using the netinst Debian 9 stretch image. After a 
successful installation without network access I want to add a 
network, but when I type route in the commend line debian say that 
this command is not found, but when I used Debian 8.8 jessie with the 
netinst-img without network access this commend worked. 
WHY??


On top of this when I want to add my network to the Debian 9 VM this 
failed because of the route commend is not found and with the Debian 
8.8 VM this is working. WHY??


Best wishes,
Maximilian Althaus

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Adam Borowski]

On Mon, Jul 10, 2017 at 01:57:08PM +0200, Rene Engelhard wrote:
> On Mon, Jul 10, 2017 at 01:44:00PM +0200, Maximilian Althaus wrote:
> >Okay, I understand! But I have the problem that the Debian 9 VM can not
> 
> No, you don't. You already got told about ip -r. "route" and "ifconfig" are 
> not
> installed per default anymore.

All packages shipped by Debian[1] either don't require net-tools anymore, or
pull them in via dependency.  If you wrote a custom script, you might need
to either migrate to ip or a friend (like, netstat -> ss), or install
net-tools.  The latter has been deprecated since a long, long time, so the
time to finally pull the plug had to come sooner or later.

> >get an internet connection. This is because the network configuration
> >(/etc/network/interfaces) fail, because Debian 9.0 could not found a
> >device named eth0, but with Debian 8.8 with the same configuration I have

> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.de.html#new-interface-names
> 
> eth0 will be kept on upgrades, but new installs get new interface names
> (that is good, that removed unpredictability if you add a new network card.)

Not sure how is it possible to argue that "eth0" is _less_ predictable than
ensp3 or wlxf81a671bcfae.  If you replace a network card, all your network
settings go wrong.  Same if you reconnect a removable card.  Or upgrade your
kernel.  Or, dist-upgrade.  Or, in case of a VM, use a slightly different
command line.  Or, on some hardware, on every boot.  The random number after
that "ensp" or "wlxf" can be re-rolled unexpectedly -- hope you have an
out-of-band way to reach that machine (ilo and iDrac are not really
trustworthy).

To fix this problem, you can:
ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules
update-initramfs -u

Also it's worth noting that if you do rename interfaces on your own (kind of
a must if there's more than one of its type -- both eth0 vs eth1 or ensp42
vs ensp78 require documentation that's guaranteed to be misplaced while out0
vs lan0 are self-describing even to an outsider), in jessie this overruled
the above "predictable" rule, in stretch it apparently does not.


HTH, meow!

[1]. At least popular ones -- there's a possibility something obscure has
slipped through, in which case, please install net-tools and report a bug.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Rene Engelhard]

On Mon, Jul 10, 2017 at 01:44:00PM +0200, Maximilian Althaus wrote:
>Okay, I understand! But I have the problem that the Debian 9 VM can not

No, you don't. You already got told about ip -r. "route" and "ifconfig" are not
installed per default anymore.

>get an internet connection. This is because the network configuration
>(/etc/network/interfaces) fail, because Debian 9.0 could not found a
>device named eth0, but with Debian 8.8 with the same configuration I have

https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.de.html#new-interface-names

eth0 will be kept on upgrades, but new installs get new interface names
(that is good, that removed unpredictability if you add a new network card.)

>no problem and I have an internet connection. On top of this on the Debian
>9 VM it the networking service says that there is no route commend. What
>can I do ? Do I need an other network configuration
>(/etc/network/interfaces) 

as already said: if you want route, you need net-tools installed.
otherwise (afaicr) ip r(oute).

https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html#iproute2

(I asume you're .de, if not, sorry and then read the english
release notes.)

Regards,

Rene

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Maximilian Althaus]

Hi!

Okay, I understand! But I have the problem that the Debian 9 VM can not 
get an internet connection. This is because the network configuration 
(/etc/network/interfaces) fail, because Debian 9.0 could not found a 
device named eth0, but with Debian 8.8 with the same configuration I 
have no problem and I have an internet connection. On top of this on the 
Debian 9 VM it the networking service says that there is no route 
commend. What can I do ? Do I need an other network configuration 
(/etc/network/interfaces) 


Cheers,
Maximilian


Nicholas D Steeves 
10. July 2017 at 1:49 AM
P.S. That cheat sheet isn't nearly as nice...as I'd like it to be I
wish it was a compact printable two or three column reference with
net-tools commands in bold and the short-form iw equivalent
underneath.

eg: 'ip -r r' is more or less equivalent to 'route'
Maximilian Althaus 
10. July 2017 at 1:07 AM
Hello,

today I installed a Proxmox 5 system on a dedicated server. Then I 
want to create a VM using the netinst Debian 9 stretch image. After a 
successful installation without network access I want to add a 
network, but when I type route in the commend line debian say that 
this command is not found, but when I used Debian 8.8 jessie with the 
netinst-img without network access this commend worked. 
WHY??


On top of this when I want to add my network to the Debian 9 VM this 
failed because of the route commend is not found and with the Debian 
8.8 VM this is working. WHY??


Best wishes,
Maximilian Althaus

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Maximilian Althaus]

Hi Nicholas!

Thanks for this information, I will change my configuration to the new one.

Cheers,
Maximilian


Nicholas D Steeves 
10. July 2017 at 1:49 AM
P.S. That cheat sheet isn't nearly as nice...as I'd like it to be I
wish it was a compact printable two or three column reference with
net-tools commands in bold and the short-form iw equivalent
underneath.

eg: 'ip -r r' is more or less equivalent to 'route'
Maximilian Althaus 
10. July 2017 at 1:07 AM
Hello,

today I installed a Proxmox 5 system on a dedicated server. Then I 
want to create a VM using the netinst Debian 9 stretch image. After a 
successful installation without network access I want to add a 
network, but when I type route in the commend line debian say that 
this command is not found, but when I used Debian 8.8 jessie with the 
netinst-img without network access this commend worked. 
WHY??


On top of this when I want to add my network to the Debian 9 VM this 
failed because of the route commend is not found and with the Debian 
8.8 VM this is working. WHY??


Best wishes,
Maximilian Althaus

Re: Upcoming stable point release (9.1)

[Philipp Kern]

On 2017-07-10 10:32, Pirate Praveen wrote:

On 07/10/2017 01:38 PM, Philipp Kern wrote:

On 07/10/2017 07:00 AM, Pirate Praveen wrote:

[Moving to -devel]

Not sure why, as this seems to be a release matter.

Because I wanted to get inputs from other developers on how to proceed.


Without involving the developers in question. But okay.


Well, I first tried, the BTS, which they should be reading, then I
posted in their IRC channel, which did not receive any response, then I
try to join their alioth team, which was not accepted. I think I made
reasonable efforts to reach out to them directly.


Well, then 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu 
exists and can be followed to the letter. None of the maintainers 
actually downgraded the bug's severity. I'd shoot for DELAYED/2-days 
despite it approving DELAYED/0-days.


Kind regards
Philipp Kern

Re: Upcoming stable point release (9.1)

[Pirate Praveen]

On 07/10/2017 01:38 PM, Philipp Kern wrote:
> On 07/10/2017 07:00 AM, Pirate Praveen wrote:
>> [Moving to -devel]
> 
> Not sure why, as this seems to be a release matter.

Because I wanted to get inputs from other developers on how to proceed.

>> I'd like this fix
>> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865316) to be part of
>> 9.1, but one of the maintainers of the package seems to not agree with
>> the severity [1]. It is already fixed upstream and updated package is
>> prepared.
> 
> It needs to be fixed in unstable first, anyway. Similarly I only see
> inaction on the bug, not disagreement. (What you linked to as "[1]" is
> different.) The fix itself feels fairly straightforward, given that it's
> a consensual revert applied upstream.

"a single bug, with inflated severity", the maintainer did not agree
with the severity. Inaction means, its severity is not accepted, is what
I understood. If there is an RC bug, you either fix it soon or accept
patches when someone fixes it.

> I think this could be suitable for stable, but I'd suggest to you to
> hash out the potential disagreement[2] in private mail to the
> maintainers rather than on project-wide mailing lists (not even cc'ing
> them).

Well, I first tried, the BTS, which they should be reading, then I
posted in their IRC channel, which did not receive any response, then I
try to join their alioth team, which was not accepted. I think I made
reasonable efforts to reach out to them directly.

> Kind regards
> Philipp Kern
> 
> [2] I'm not even sure there is any.
> 




signature.asc
Description: OpenPGP digital signature

Re: Upcoming stable point release (9.1)

[Philipp Kern]

On 07/10/2017 07:00 AM, Pirate Praveen wrote:
> [Moving to -devel]

Not sure why, as this seems to be a release matter.

> I'd like this fix
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865316) to be part of
> 9.1, but one of the maintainers of the package seems to not agree with
> the severity [1]. It is already fixed upstream and updated package is
> prepared.

It needs to be fixed in unstable first, anyway. Similarly I only see
inaction on the bug, not disagreement. (What you linked to as "[1]" is
different.) The fix itself feels fairly straightforward, given that it's
a consensual revert applied upstream.

I think this could be suitable for stable, but I'd suggest to you to
hash out the potential disagreement[2] in private mail to the
maintainers rather than on project-wide mailing lists (not even cc'ing
them).

Kind regards
Philipp Kern

[2] I'm not even sure there is any.



signature.asc
Description: OpenPGP digital signature

Bug#867869: ITP: beautify-bash -- Beautifier for Bash shell scripts written in Python

[Mike Mestnik]

Package: wnpp
Severity: wishlist
Owner: Mike Mestnik 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: beautify-bash
  Version : 1.0
  Upstream Author : Paul Lutus , Shriram V 

* URL : https://arachnoid.com/python/beautify_bash_program.html 
https://github.com/shri314/beautify_bash
* License : GPL
  Programming Lang: Python
  Description : Beautifier for Bash shell scripts written in Python

Second Bash script beautifier by Paul Lutus — the first is pretty
well-known.  This rewrite cleans up some annoying inconsistencies.

Currently Debian does not have a commandline tool that
tidies/beautifies shell scripts.  This is useful in git hooks to
ensure that only properly formatted/spaced code makes it into the
repository.  For example the d-i has several instances where shell
scripts have trailing whitespace, indicating disarray.

It's an old program that's seen recent development by Shriram, while
Paul Lutus is the original author he does not seem to have an email
address.  Paul can be reached via this URL, I assume,
https://arachnoid.com/messages/index.php

This is a Python script about 200 lines long, it can also serve as a
Python module.

I'm looking to hammer out the details concerning what version/release
and to find a sponsor.

Thanks for your consideration.

-BEGIN PGP SIGNATURE-

iQJLBAEBCAA1FiEE50YYYn+e/FujuFBs49GprY7cq4oFAlljL8sXHGNoZWFrb0Bt
aWtlbWVzdG5pay5uZXQACgkQ49GprY7cq4qrkQ//fnWwjj7g1mjac7cUT4T9D1o9
qKJZdXL2gvQWU0PtjavKWaqeVPdFebsiyDRjdnCOxjnap5P5HDogJzh1dA8Xwilt
9OWFD3ZImA6VBOvIwN7LjcguWe0Z7NSy8XjU42bvAzrDZWXf1DHj+G/TMB+ES8SC
dNLl/UJ64yTidsYlCdsZ1wRuDaaZlZ5eo/YoN+7SsYbcVRLF6U/HP9dPFChTBxpS
aVPKIysQZdrlOBAb3RfLXxhQNxpASLh+TYtHh0hi2vY9A3C9d1W9WFjprJs8/RI0
nxPGdw0abBFmuQR1KmLUDLrqTr0kPEP18cVVQ+3rYvVP6xN73mfqn4Uv6TTFx3DE
kVytozrVnCtFt3tS2VymETPES6ZZSSBHChgaTPlZBhO319iZUpCZt2PAQ7/13FLM
zUTfEcTQrpxNlRQnPVhf3KaJT1zNhI0XQJmFmpg04/BNGti0+4clO6d5fL7q/WT0
AAmDRlF+nV+RYU7bANBYKWMmvGeSFP0ahITXgcOAlira7qj5UB9JxZqOn2cfFEsc
xnD6hTOWHaH3w1jmeWR7+YI0HRsXWsGVwIYfmQW1cCAA4ojBIw36ZSQpjjNRqqVi
njixeBBPp6wJmzSaY0ABebctKy1rM3C0dFiuE8UopgAjfTU/TOy1vXmgPiOIc/CH
StQcY1Enco1GZkXCflU=
=UN9F
-END PGP SIGNATURE-