Dear Maintainer,

After the patch has been applied fixing bug #705456 breaks configuration
which worked and was perfectly correct before. Applying a patch to fix a
problem should never cause valid uses of the package before suddenly
stop working.

Prior to vlan version 1.9-3.1 the following config worked as intended:
# The vlan carrying interface
auto eth1
iface eth1 inet manual

auto vmbr20
iface vmbr20 inet static
    address 172.16.2.60
    netmask 255.255.255.0
    bridge_ports eth1.20
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 5

auto vmbr30
iface vmbr30 inet static
    address 172.16.3.60
    netmask 255.255.255.0
    bridge_ports eth1.30
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 5

But after applying diff to fix bug #705456 the vlan's are not
crated causing bridges to be created untagged which breaks
networking. To have it working again you are now forced to add
vlan-raw-device configuration which should not be needed according
to manual. See below.

# The vlan carrying interface
auto eth1
iface eth1 inet manual

auto vmbr20
iface vmbr20 inet static
    address 172.16.2.60
    netmask 255.255.255.0
    bridge_ports eth1.20
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 5
    vlan-raw-device eth1

auto vmbr30
iface vmbr30 inet static
    address 172.16.3.60
    netmask 255.255.255.0
    bridge_ports eth1.30
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 5
    vlan-raw-device eth1

Hi,
Yes, I am sorry,

I got new packages to be uploade since 5 years or so, but my sponsor got
scared.
This one has been NMU'd.

Hmmm, actually I am a little bit surprised that the mere
mentioning of eth1.20 in the bridge configuration automagically
creates eth1.20.

I would suspect that the first 2 lines should be:

auto eth1.20
iface eth1.20 inet manual

As that would create an eth1.20 in the up state. Actually, that's
how I do it ;-).

On the other hand, the bridges should either not get created at
all, or created without ports, or somewhere in between.
If it attaches eth1 instead of nothing at all, that would be a
grave bug.

Regards,

Ard

From vlan-interfaces(5):
vlan-raw-device devicename
Indicates the device to create the vlan on.  This is ignored when the
devicename is part of the vlan interface name.

From bridge-utils-interfaces(5):
bridge_ports interface specification
this option must exist for the scripts to setup the bridge, with it you
specify the ports  you  want  to  add  to your bridge, either using
"none" if you want a bridge without any interfaces or you want to add
them later using brctl, or a list of  the interfaces you want to add
separated by spaces, for example: bridge_ports eth0 eth4 You  should
not put any lines to configure the interfaces that will be used by the
bridge, as this will be setup automatically by the scripts when
bringing the bridge up.

If you need to specify the interfaces more flexibly, you can use the
following syn‐ tax (most useful on a Xen  dom0): bridge_ports regex
(eth|vif).* This means to evaluate (as in egrep(1)) the expressions
that follow  after  "regex" until  either the end or a "noregex"
statement is reached.  The regular expressions are evaluated against
all local interfaces and those that match are added.

Specifying "all" is short for "regex eth.* em.* p[0-9].* noregex" and
will get  all the ethX and biosdevname-format (emX and pX) interfaces
added to the bridge.

Hi,
    if [ "$MODE" = "start" ] && [ ! -d /sys/class/net/$IFACE/brif/$port ]; then
      if [ -x /etc/network/if-pre-up.d/vlan ]; then
        env IFACE=$port /etc/network/if-pre-up.d/vlan
      fi

the magic you describes seems to happen and removing this broke the bridge
utils package.
scripts.
Just using these two lines for every port you use in the bridge will fix your
current problem.

As for the regression: I am not sure what to do about it.
Even if it was not NMU'd I would have removed the vlan part...

Let me think

Random observer here, looking through the bugs for vlan.  Shouldn't bug
#742547 simply be reassigned to bridge-utils?  This very much reads like
their bug, not vlan's bug.

What is in bridge-utils's /lib/bridge-utils/ifupdown.sh script looks
rather dangerous and near certain to break in reasonably common
scenarios.  Of note, if a given interface is explicitly mentioned in
/etc/network/interfaces and has some set of interesting parameters,
bridge-utils's invocation of the vlan script will ignore those
parameters.  Instead, likely it should be invoking ifupdown to handle the
interface; only trick is this would mean ifupdown needs to learn how to
handle implicit interfaces, such as vlans on an interface that is only
implicitly mentioned.