Bug#825031: [pkg-wpa-devel] Bug#825031: Outdated package description
Hi
On 2016-05-22, Ben Hutchings wrote:
> Package: iw
> Version: 3.17-1
> Severity: normal
>
> The current package description includes the sentence.
>
> In the future iw will become the canonical command line tool for wireless
> configuration and iwconfig/wireless-tools will no longer be required.
>
> I think the future is here and you can delete this sentence.
That particular paragraph was probably wrong to begin with...
But the situation itself is a tad more difficult, while iw is used
non-interactively by crda to set the regulatory domain configuration,
it was originally thought (and that's where that particular phrasing
comes from) to provide configuration hooks for ifupdown (equivalent
to wireless-tools' wireless-*). This later part hasn't happened, nor
'ever' will. Basically because there are unfortunately still too many
non-cfg80211 drivers (legacy ones, like predominantly ipw2x00, all the
random staging stuff, etc.) and because wpa_supplicant is actually
mandatory for 802.11n anyways (which provides said hooks, in a generic
way itself (for both wext and mac80211), while also taking care of link
supervision (reconnect, roaming, ...). Not even taking network-manager
or systemd-networkd into account, which are more and more replacing
ifupdown.
A 'normal' user will probably only use iw indirectly (via crda) or for
debugging purposes (scanning, link features, etc.), while only rather
advanced users might think about using it to create additional
interfaces, use 4addr or configure txpower or other special driver
settings.
So yes, the long description needs an overhaul, just not because the
previously thought of future, but because it was bad to begin with.
While the alternative to describe it as an nl80211 based tool to
configure mac80211- or cfg80211 wireless drivers sounds a bit like
buzzword bingo, I'll probably still change it roughly in that
direction (if just to provide these hints to apt-cache).
Thanks for reminding me, package descriptions are something one
rarely thinks about after the initial upload.
Regards
Stefan Lippers-Hollmann
pgp0XkeM95PSE.pgp
Description: Digitale Signatur von OpenPGP
Bug#806889: [pkg-wpa-devel] Bug#806889: wpasupplicant: New upstream version (2.5)
Hi On 2016-05-01, Faidon Liambotis wrote: > severity 806889 important > thanks > > On Wed, Dec 02, 2015 at 03:34:42PM +0100, Julian Wollrath wrote: > > please package the new upstream version (2.5). A patch that updates the > > debian folder accordingly is attached. > > I'm raising the severity, considering: > - Debian is at v2.3, two major upstream releases behind. > - The last maintainer upload happened over a year ago. > - The package has since seen 3 NMUs. > - Upstream released 2.4 back in October 2014(!) and 2.5 in > September 2015. > - This wishlist bug report is 5 months old. > > Moreover, there are several open bug reports that may have been fixed by > a new version (e.g. #815121) or can be easily fixed or closed (e.g. > #729934). #729934 will indeed by fixed by the next upload/ binNMU, thanks to the new dbgsym packages introduced by dh. > Please work on this package soon, or RFH/O it. It's a far too important > package to be in such a sad state. > > Warmly, > Faidon > (ex-maintainer of hostapd and past sponsor of wpasupplicant) I'm still debugging the 4addr regression mentioned in my previous mail, given the rather unfortunate approach to reproduce it, testing takes about a week for each iteration (unless it fails early by chance, so far I've seen time to failure up to 3-4 days, even though it often within hours). Replacing one bug with another doesn't sound like a good tradeoff to me. Regards Stefan Lippers-Hollmann pgp1NK1frZleQ.pgp Description: Digitale Signatur von OpenPGP
Bug#766746: [pkg-wpa-devel] Bug#806889: wpasupplicant: New upstream version (2.5)
Hi Thanks for the feedback, I'm really interested in the circumstances wpa_supplicant's networkd integration is supposed to be used. On 2016-04-20, Raphael Hertzog wrote: > On Wed, 20 Apr 2016, Stefan Lippers-Hollmann wrote: > > - systemd-networkd upstream hasn't committed to a policy regarding > > wireless devices, its handling might change in the future > > Yes, but the fact that systemd might get some native support is > not guaranteed to break the setup we want to use here. While that is correct, we've been there in the past with a dedicated sysv initscript rather than providing native hooks for ifupdown (and removing this was painful, to say the least), that's why I'm careful committing to a potentially temporary (but highly user-visible) way of configuring wpa_supplicant (users will find and use it - and complain loudly, if (when!) it goes away). > > - systemd-networkd doesn't provide any tools like ifup/ ifdown so > > far, making dynamic configuration changes (e.g. switch from wired- > > to wireless networks) difficult. > > - hotpluggable wireless cards (USB) are problematic in the sense > > that systemd will wait (until timeout, 90s by default) if the > > a configured device is unplugged. > > - basically unsuitable for notebook scenarios, where one might > > occasionally want to switch to wired ethernet (so far routing > > metrics seem to be the only, quite hacky workaround). > > I think that people opting for systemd-networkd are fine with those > limitations. Consider that people want to use it on devices like > the raspberry pi which is not really like a smartphone or a laptop... At least RPi 1 and 2 are in the same camp, as USB wlan is the only choice there as well, only the RPi 3B has a non-USB/ fixed wlan card. The same goes for many other ARM based devboards, even if they have wlan onboard, USB cards (and thereby hotplugging) are common there (be it that the onboard wlan card doesn't have mainline support yet or because it's not reliable enough). Admitted, they're less likely to be used in an interactive fashion. > Myself I was interested to document this setup for Kali Linux users > (Debian derivative) where we use lots of ARM devices with built-in > wifi. > > I also don't know what's hacky with the routing metric usage. What else > would be its purpose if not to prioritize between different routes? Routing metrics themselves aren't hacky at all, but more or less abusing them is. I'm indeed looking at it from a notebook centric side (not exclusively, more like an interactive system where one might plug/ unplug wired ethernet from time to time). The problem I see in this usage scenario is this. Imagine a notebook connected to your local network (192.168.x.y/24), usually via wlan, but with the intention of using the wired ethernet (if available) for larger file transfers. In this scenario, the ideal approach would be that the wireless interface would be deactivated automatically whenever the ethernet plug is connected (and re-activated whenever the wired interface goes down). However current systemd-networkd doesn't have this concept (no way for providing default-off networkd configurations, nor selectively enabling or disabling a particular, pre-configured, network interface), nor an automated ifplud/ guessnet alike. The only workaround here would be using routing metrics, e.g.: $ cat /etc/systemd/network/60-wired.network [Match] Name=enp2s0 [Network] DHCP=yes IPv6PrivacyExtensions=true [DHCP] UseDomains=yes RouteMetric=30 $ cat /etc/systemd/network/60-wireless.network [Match] Name=wlp3s0 [Network] DHCP=yes IPv6PrivacyExtensions=true [DHCP] UseDomains=yes RouteMetric=20 In the simple (IPv4-only!) case, this works quite nicely, even though both interfaces remain to be active, routing doesn't get confused and large file transfers work quickly (over wired ethernet) and hotplugging (or hot-unplugging) ethernet works nicely (to the extent possible). When both interfaces are up, you end up with two IPv4 addresses from the same subnet, routing works as expected. The problems start, once you add IPv6 and DHCPv6 to the mix. In contrast to IPv4, DHCPv6 doesn't request IPv6 addresses based on interface's MAC address, but based on a system-wide DUID. So in this case, both interfaces are up (and connected to the same subnet), but only one interface can get the correct (matching the configured DNS name) IPv6 address (first come, first served - more or less randomly), the other interface only gets a random IPv6 address, thereby making the routing metrics pretty useless (at least for incoming connections). [ yes, systemd-networkd has much bigger problems when it comes to IPv6 support, but this is a more or less wlan specific one ] Now let's see the next scenario, also not too uncommon for systems used in an interactive fashion (notebook
Bug#766746: [pkg-wpa-devel] Bug#806889: wpasupplicant: New upstream version (2.5)
Hi On 2016-04-20, Raphael Hertzog wrote: > Hi Stefan, > > On Thu, 17 Mar 2016 03:01:21 +0100 Stefan Lippers-Hollmann <s@gmx.de> > wrote: > > Given that it's opt-in, explicitly documenting this as volatile > > and potentially unsupported (in the future) might be a way out, > > but I'd still hate to eventually break previously working network > > configurations in the future. > > Please do this if it's the only way to reassure you about this feature. > But this setup is largely documented and already in use in ArchLinux for > example and I was surprised to see that Debian did not support it yet. > > It seems to work rather well for most persons including Debian persons: > https://www.joachim-breitner.de/blog/664-Switching_to_systemd-networkd > > That article is dated Oct 2014 so we're really late in the game... please > fix this soon. Thank you. What is your opinion regarding the system inherent problems I've raised? [ pasting from <20160317030121.68b23ccf@mir>, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766746#22 ] - systemd-networkd upstream hasn't committed to a policy regarding wireless devices, its handling might change in the future - systemd-networkd doesn't provide any tools like ifup/ ifdown so far, making dynamic configuration changes (e.g. switch from wired- to wireless networks) difficult. - hotpluggable wireless cards (USB) are problematic in the sense that systemd will wait (until timeout, 90s by default) if the a configured device is unplugged. - basically unsuitable for notebook scenarios, where one might occasionally want to switch to wired ethernet (so far routing metrics seem to be the only, quite hacky workaround). I was really hoping to get some feedback, especially the later three issues, from those looking to get it supported. Regards Stefan Lippers-Hollmann pgpNCZD6az3ki.pgp Description: Digitale Signatur von OpenPGP
Bug#700870: [pkg-wpa-devel] Bug#700870: building eapol_test
Hi On 2016-03-24, Christopher Hoskin wrote: > Hello, I've been doing some work on the upstream FreeRADIUS 3 Debian > package, with a view to eventually getting it accepted into Debian (Bug > #797181). > > https://github.com/FreeRADIUS/freeradius-server/pulls?q=is%3Apr+author%3Amans0954 > > I'm currently looking at enabling build and autopkgtest tests. Upstream > have some tests which make use of eapol_test. > > If eapol_test isn't available on the system, the upstream script clones the > upstream hostap repository and builds it. This isn't appropriate for a > Debian package. Including enough of the hostap source within the FreeRADIUS > Debian package to build eapol_test would not be ideal. > > Therefore, I'd also like to request that Matthew Newton's patch is applied, > so that the proposed eapoltest package can be specified as a build > dependency of FreeRADIUS. The patch appears to apply and build against the > latest wpa source package trunk (on amd64 at least). > > Please, would this be possible? Just a very quick/ short preliminary response, in general I'm not exactly thrilled about adding this -considering my build issues with eapol_test in previous src:wpa versions- but I haven't actually revisited this particular question recently. *If* eapol_test builds with v2.3, v2.4, v2.5 and hostapd HEAD without having to fix bugs in the upstream code (I haven't tested this yet), I could be convinced to add this functionality (well, v2.5 and HEAD would be more important than the previous versions) to src:wpa, but if this would still be a 'constant' source for build issues (demonstrating that this isn't actually tested by upstream - last time I looked into it, the build issues were trivial, but quite numerous), I'd tend towards declining this (however, if there'd be an src:wpa co-maintainer who'd take care of this aspect...). Have you checked buildability recently? Regards Stefan Lippers-Hollmann pgpa50bOT3paK.pgp Description: Digitale Signatur von OpenPGP
Bug#715267: [pkg-wpa-devel] Bug#806889: wpasupplicant: New upstream version (2.5)
Hi
[ I'm cross-posting this reply for #806889 to the bugreport in #766746
and #715267, if you're interested in networkd integration, feel free
to skip to the second ff. paragraph. ]
On 2016-03-16, Daniel Baumann wrote:
> Hi,
>
> any news on this?
I am currently seeing problems with a wpa_supplicant/ hostapd combination
using 4addr setups (potential regression compared to v2.3, link staying
connected, not transmitting any data on the hostapd side, but not
reconnecting - forcing a reconnect by restarting hostapd tends to help).
As of yet, I haven't been able to confirm if this is an issue with
src:wpa v2.5 or induced by unrelated changes (e.g. kernel version),
given that this is difficult to reproduce reliably (it might take
several days to happen, but can also happen within minutes, making
reliable bisecting hard).
Another open question, not preventing the upgrade to v2.5, but one that
needs to either be deferred/ backed out or decided is #715267/ #766746,
shipping a systemd unit for networkd integration. While this is
technically simple (and no, the upstream provided systemd unit as it
stands is not suitable[1]) and strictly opt-in, shipping this in an
upload implies committing to this way of starting wpasupplicant more or
less for "all eternity" as fixed ABI...
+ it works, I'm testing it for close to a year now - with mixed results
+ there seem to be advantages when it comes to suspend/ resume
+ it's strictly opt-in and needs explicit enabling from the admin
- systemd-networkd upstream hasn't committed to a policy regarding
wireless devices, its handling might change in the future
- systemd-networkd doesn't provide any tools like ifup/ ifdown so
far, making dynamic configuration changes (e.g. switch from wired-
to wireless networks) difficult.
- hotpluggable wireless cards (USB) are problematic in the sense
that systemd will wait (until timeout, 90s by default) if the
a configured device is unplugged.
- basically unsuitable for notebook scenarios, where one might
occasionally want to switch to wired ethernet (so far routing
metrics seem to be the only, quite hacky workaround).
While it's easy to defer this decision once more, I was hoping to
come to an conclusion regarding #766746 for the next (as in this)
upload.
Given that it's opt-in, explicitly documenting this as volatile
and potentially unsupported (in the future) might be a way out,
but I'd still hate to eventually break previously working network
configurations in the future.
Regards
Stefan Lippers-Hollmann
[1] breaks with legacy/ staging (non-cfg80211 wlan cards)
and DBus activation, I have fixes for both in the
packaging VCs.
pgpRSi1OG7uLc.pgp
Description: Digitale Signatur von OpenPGP
Bug#816215: [pkg-wpa-devel] Bug#816215: wpagui: When run, wpa_gui just shows an empty grey window
Control: severity -1 normal Control: tags -1 moreinfo Hi On 2016-02-29, Riley Baird wrote: > Package: wpagui > Version: 2.3-2.3 > Severity: grave > Justification: renders package unusable > > Hi, > > When I run wpa_gui (as root), a window appears, which is just filled with > grey. > I have included the terminal output and a screenshot of the problem. I can't quite tell from the screenshot, but which desktop environment/ window manager are you using and which helper do you use for elevating privileges? Testing wpa_gui, both as root (using kdesu on a KDE5 desktop) and as normal/ authorized (member of the netdev group and configuring said group to allow access using the wpa_supplicant.conf) user, is both working for me on an up to date unstable system. Therefore I'm reducing this bug's severity from RC to normal. In general I strongly recommend not running wpa_gui as root, but to use netdev membership instead; see /usr/share/doc/wpasupplicant/examples/wpa-roam.conf for reference, but it should work both ways. In case you do choose to run wpagui as root (please don't), make sure to use the preferred way of your desktop environment to elevate privileges for running X11 applications and test some other/ simpler applications as well (e.g. xclock/ xeyes) using the same approach. > X Error: BadAccess (attempt to access private resource denied) 10 > Extension:130 (MIT-SHM) > Minor opcode: 1 (X_ShmAttach) [...] > X Error: BadShmSeg (invalid shared segment parameter) 128 > Extension:130 (MIT-SHM) > Minor opcode: 2 (X_ShmDetach) > Resource id: 0x320002b These error messages point slightly into this direction of 'just' being an issue with your X11 MIT magic cookie. So assuming you're be running wpa_gui on a KDE desktop, I'd probably suggest to use (all as normal user, not root!) $ /usr/lib/kde4/libexec/kdesu /usr/sbin/wpa_gui gtk based desktop environments usually use gksu instead $ gksu /usr/sbin/wpa_gui alternatively using sudo should also work $ sudo /usr/sbin/wpa_gui respectively something like xclock for testing. Regards Stefan Lippers-Hollmann pgppT4PsFrWAk.pgp Description: Digitale Signatur von OpenPGP
Bug#814566: networkd >= 229-1 starts assigning IPv6 addresses/ routes to lower bridge members
Hi
Git bisecting the upstream systemd github repository in a disposable VM
points at
Revert "networkd: ndisc - revert to letting the kernel handle NDisc"
https://github.com/systemd/systemd/commit/fe30727643a7c53faa29f1caa8dcabcb2b6f6fcb
$ git bisect log
git bisect start
# good: [dd050decb6ad131ebdeabb71c4f9ecb4733269c0] build: bump version numbers
git bisect good dd050decb6ad131ebdeabb71c4f9ecb4733269c0
# bad: [96b08d65a12c304c59febbc52bc871753f0c6f31] Merge pull request #2722 from
torstehu/fix-typo2
git bisect bad 96b08d65a12c304c59febbc52bc871753f0c6f31
# bad: [c64327b7648f988186a3de55dde264c7c21f7d5f] Merge pull request #2347 from
aroig/gh/fix-udev-user-wants
git bisect bad c64327b7648f988186a3de55dde264c7c21f7d5f
# bad: [a0361331758dbdb2375d6f871bc959116b699e31] Merge pull request #2143 from
poettering/dnssec4
git bisect bad a0361331758dbdb2375d6f871bc959116b699e31
# bad: [c7bb28732f0c5d6e964197753d1d8d8a6a591d2f] tests: don't run test on
incomplete setup
git bisect bad c7bb28732f0c5d6e964197753d1d8d8a6a591d2f
# bad: [58db254ade4fb2ef77de68f28c4f13814819f6a1] resolved: implement
client-side DNAME resolution
git bisect bad 58db254ade4fb2ef77de68f28c4f13814819f6a1
# bad: [61fea35e14d84144e6e2122f5cd247f9c7e6245e] tests: fix initrd searching
on Debian/Ubuntu
git bisect bad 61fea35e14d84144e6e2122f5cd247f9c7e6245e
# good: [39609489ca9925f94fdd4ef12a8b3d5ee2e14ddd] update TODO
git bisect good 39609489ca9925f94fdd4ef12a8b3d5ee2e14ddd
# bad: [265fb8052dc3ca334951a5693cdfd6fb968c94c7] Merge pull request #1958 from
teg/networkd-fixes
git bisect bad 265fb8052dc3ca334951a5693cdfd6fb968c94c7
# bad: [854c1123f5fb6704e900d34c0165360f77ce4ef8] Merge pull request #1944 from
poettering/randoms-ec
git bisect bad 854c1123f5fb6704e900d34c0165360f77ce4ef8
# good: [3ccd316353532ff60326e91153677c308c032ecb] sd-ndisc: drop RA packets
from non-link-local addresses
git bisect good 3ccd316353532ff60326e91153677c308c032ecb
# bad: [25422154e8ebda7a9bfd52d7e0cbd7254fed39b3] Merge pull request #1948 from
teg/networkd-fixes
git bisect bad 25422154e8ebda7a9bfd52d7e0cbd7254fed39b3
Reverting just fe30727643a7c53faa29f1caa8dcabcb2b6f6fcb on top
of systemd 229-1 (after resolving minor merge conflicts, see attached)
fixes this bug for me (networkd's IPv6 handling is still not quite
perfect, but at least it's back to a networkd <= 228-6 equivalent
state and results in functional IPv6 connectivity for me again, while
networkd 229-1, and current upstream git HEAD, are totally broken).
Regards
Stefan Lippers-Hollmann
From f1f54ef2f8509100483cb8dc8a9a2f9c3c823700 Mon Sep 17 00:00:00 2001
From: Stefan Lippers-Hollmann <s@gmx.de>
Date: Thu, 25 Feb 2016 00:29:28 +0100
Subject: [PATCH] Revert "Revert "networkd: ndisc - revert to letting the
kernel handle NDisc""
networkd v229 introduces many regressions in IPv6 related RA handling,
reverting this at least fixes:
* https://bugs.debian.org/814566
networkd >= 229-1 starts assigning IPv6 addresses/ routes to lower bridge
members
which may be https://github.com/systemd/systemd/issues/2572
[networkd] bridged intefaces still get RA ipv6 addresses #2572
and is quite likely to also fix:
* https://bugs.debian.org/814667
systemd-networkd overrides default kernel net.ipv6.conf.interface.accept_ra
* https://bugs.debian.org/815586
does its own RA handling and is doing it wrong
This reverts commit fe30727643a7c53faa29f1caa8dcabcb2b6f6fcb.
Signed-off-by: Stefan Lippers-Hollmann <s@gmx.de>
---
src/network/networkd-link.c | 20
src/network/networkd-ndisc.c | 13 -
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 692c0bf..16c9927 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -623,9 +623,6 @@ void link_check_ready(Link *link) {
!link->dhcp4_configured && !link->dhcp6_configured))
return;
-if (link_ipv6_accept_ra_enabled(link) && !link->ndisc_configured)
-return;
-
SET_FOREACH(a, link->addresses, i)
if (!address_is_ready(a))
return;
@@ -1923,6 +1920,7 @@ static int link_set_ipv6_privacy_extensions(Link *link) {
static int link_set_ipv6_accept_ra(Link *link) {
const char *p = NULL;
+const char *v;
int r;
/* Make this a NOP if IPv6 is not available */
@@ -1935,12 +1933,16 @@ static int link_set_ipv6_accept_ra(Link *link) {
if (!link->network)
return 0;
+if (link_ipv6_accept_ra_enabled(link))
+v = "1";
+else
+v = "0";
+
p = strjoina("/proc/sys/net/ipv6/conf/", link->ifname, "/accept_ra");
-/* We handle router advertisments ourselves, tell the kernel t
Bug#814566: networkd >= 229-1 starts assigning IPv6 addresses/ routes to lower bridge members
Hi On 2016-02-13, Stefan Lippers-Hollmann wrote: [...] > $ ip -6 r > 2001:470:1234:10::/64 dev br0 proto ra metric 1024 pref medium > 2001:470:1234:10::/64 dev enp2s0 proto ra metric 1024 pref medium > 2001:470:1234:10::/64 dev br1 proto ra metric 1024 pref medium > 2001:470:1234:10::/64 dev enp4s0 proto ra metric 1024 pref medium > fd01:470:1234:10::/64 dev br0 proto ra metric 1024 pref medium > fd01:470:1234:10::/64 dev enp2s0 proto ra metric 1024 pref medium > fd01:470:1234:10::/64 dev br1 proto ra metric 1024 pref medium > fd01:470:1234:10::/64 dev enp4s0 proto ra metric 1024 pref medium > fe80::/64 dev enp2s0 proto kernel metric 256 pref medium > fe80::/64 dev br0 proto kernel metric 256 pref medium > fe80::/64 dev enp4s0 proto kernel metric 256 pref medium > fe80::/64 dev br1 proto kernel metric 256 pref medium > default via fe80::92f6:52ff:fef6:c88 dev br0 proto ra metric 1024 pref > medium > default via fe80::92f6:52ff:fef6:c88 dev enp2s0 proto ra metric 1024 pref > medium > default via fe80::92f6:52ff:fef6:c88 dev br1 proto ra metric 1024 pref > medium > default via fe80::92f6:52ff:fef6:c88 dev enp4s0 proto ra metric 1024 pref > medium Apparently I can work around this problem by explicitly disabling IPv6AcceptRouterAdvertisements for enp2s0 and enp4s0: $ cat /etc/systemd/network/51-enp2s0.network [Match] Name=enp2s0 [Network] Bridge=br0 IPv6AcceptRouterAdvertisements=no $ cat /etc/systemd/network/51-enp4s0.network [Match] Name=enp4s0 [Network] Bridge=br1 IPv6AcceptRouterAdvertisements=no $ ip -6 r 2001:470:1234:10::/64 dev br0 proto ra metric 1024 pref medium fd01:470:1234:10::/64 dev br0 proto ra metric 1024 pref medium fe80::/64 dev br0 proto kernel metric 256 pref medium fe80::/64 dev br1 proto kernel metric 256 pref medium fe80::/64 dev enp2s0 proto kernel metric 256 pref medium fe80::/64 dev enp4s0 proto kernel metric 256 pref medium default via fe80::92f6:52ff:fef6:c88 dev br0 proto ra metric 1024 pref medium But it does feel weird having to do this explicitly for a lower bridge member (and yes, I'm also slightly surprised about the (fe80::/64 routes for enp2s0 and enp4s0, but this isn't new). Regards Stefan Lippers-Hollmann pgp3AvEFOvkFh.pgp Description: Digitale Signatur von OpenPGP
Bug#814566: networkd >= 229-1 starts assigning IPv6 addresses/ routes to lower bridge members
Hi On 2016-02-13, Stefan Lippers-Hollmann wrote: > On 2016-02-13, Stefan Lippers-Hollmann wrote: [...] > Apparently I can work around this problem by explicitly disabling > IPv6AcceptRouterAdvertisements for enp2s0 and enp4s0: [...] > $ ip -6 r > 2001:470:1234:10::/64 dev br0 proto ra metric 1024 pref medium > fd01:470:1234:10::/64 dev br0 proto ra metric 1024 pref medium > fe80::/64 dev br0 proto kernel metric 256 pref medium > fe80::/64 dev br1 proto kernel metric 256 pref medium > fe80::/64 dev enp2s0 proto kernel metric 256 pref medium > fe80::/64 dev enp4s0 proto kernel metric 256 pref medium > default via fe80::92f6:52ff:fef6:c88 dev br0 proto ra metric 1024 pref > medium No, this doesn't actually work - after a couple of minutes the IPv6 addresses and route 'bleed over' to the second bridge (no, there isn't any connection between br0 and br1, neither any forwarding configured). $ ip -6 r 2001:470:1234:10::/64 dev br0 proto ra metric 1024 pref medium 2001:470:1234:10::/64 dev br1 proto ra metric 1024 pref medium fd01:470:1234:10::/64 dev br0 proto ra metric 1024 pref medium fd01:470:1234:10::/64 dev br1 proto ra metric 1024 pref medium fe80::/64 dev br0 proto kernel metric 256 pref medium fe80::/64 dev br1 proto kernel metric 256 pref medium fe80::/64 dev enp2s0 proto kernel metric 256 pref medium fe80::/64 dev enp4s0 proto kernel metric 256 pref medium default via fe80::92f6:52ff:fef6:c88 dev br0 proto ra metric 1024 pref medium default via fe80::92f6:52ff:fef6:c88 dev br1 proto ra metric 1024 pref medium $ ip a 4: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:08:54:57:18:2c brd ff:ff:ff:ff:ff:ff inet 192.168.20.20/24 brd 192.168.20.255 scope global br1 valid_lft forever preferred_lft forever inet6 fd01:470:1234:10:208:54ff:fe57:182c/64 scope global mngtmpaddr noprefixroute valid_lft forever preferred_lft forever inet6 2001:470:1234:10:208:54ff:fe57:182c/64 scope global mngtmpaddr noprefixroute valid_lft forever preferred_lft forever inet6 fe80::208:54ff:fe57:182c/64 scope link valid_lft forever preferred_lft forever 5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 94:de:80:02:ca:42 brd ff:ff:ff:ff:ff:ff inet 10.10.20.0/8 brd 10.255.255.255 scope global dynamic br0 valid_lft 39154sec preferred_lft 39154sec inet6 fd01:470:1234:10::f14/128 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fd01:470:1234:10:b81a:c792:6be1:c1f8/64 scope global temporary dynamic valid_lft 600756sec preferred_lft 81756sec inet6 fd01:470:1234:10:96de:80ff:fe02:ca42/64 scope global mngtmpaddr noprefixroute valid_lft forever preferred_lft forever inet6 2001:470:1234:10:b81a:c792:6be1:c1f8/64 scope global temporary dynamic valid_lft 600756sec preferred_lft 81756sec inet6 2001:470:1234:10:96de:80ff:fe02:ca42/64 scope global mngtmpaddr noprefixroute valid_lft forever preferred_lft forever inet6 fe80::96de:80ff:fe02:ca42/64 scope link valid_lft forever preferred_lft forever There is no apparent reason why br1 should have any IPv6 assigned (other than fe80::/64). Reverting back to src:systemd 228-6 is so far the only option to fix my IPv6 connectivity (at least on systems with more than one bridge configured). Interesting enough, extending /etc/systemd/network/60-br1.network with IPv6AcceptRouterAdvertisements=no prevents br0 from getting an IPv6 address as well (unless I systemctl restart systemd-networkd.service, then it suddenly gets one). Regards Stefan Lippers-Hollmann pgptSLn9vcFEI.pgp Description: Digitale Signatur von OpenPGP
Bug#814566: networkd >= 229-1 starts assigning IPv6 addresses/ routes to lower bridge members
behaviour on multiple systems, all with very similar configurations (most with more than just two physical/ independent subnets (no interconnections) and typically with 15-20 tap interfaces used for virtual (kvm) machines). I can reproduce this with src:systemd 229-1, reverting all installed src:systemd packages to 228-6 fixes the issue again. Regards Stefan Lippers-Hollmann -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-1.slh.1-aptosid-amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.113+nmu3 ii libacl1 2.2.52-3 ii libapparmor12.10-3 ii libaudit1 1:2.4.5-1 ii libblkid1 2.27.1-3 ii libc6 2.21-7 ii libcap2 1:2.24-12 ii libcap2-bin 1:2.24-12 ii libcryptsetup4 2:1.7.0-2 ii libgcrypt20 1.6.4-5 ii libgpg-error0 1.21-1 ii libkmod222-1 ii liblzma55.1.1alpha+20120614-2.1 ii libmount1 2.27.1-3 ii libpam0g1.1.8-3.2 ii libseccomp2 2.2.3-2 ii libselinux1 2.4-3 ii libsystemd0 229-1 ii mount 2.27.1-3 ii util-linux 2.27.1-3 Versions of packages systemd recommends: ii dbus1.10.6-1 ii libpam-systemd 229-1 Versions of packages systemd suggests: pn systemd-container pn systemd-ui Versions of packages systemd is related to: ii udev 229-1 -- no debconf information network.tar.gz Description: application/gzip pgprBQvJX1UCh.pgp Description: Digitale Signatur von OpenPGP
Bug#810445: lirc: please switch to libusb 1.0
Hi On 2016-01-08, Aurelien Jarno wrote: > Package: lirc > Version: 0.9.0~pre1-1.2 > Severity: wishlist > > Dear Maintainer, > > lirc has a build-depends on libusb-dev. A few years ago upstream > has released a new major version libusb 1.0 with a different API which > aims to fix design deficiencies with USB 2.0 and 3.0 in mind. > > The old libusb 0.1 package is not supported upstream anymore and should > be considered deprecated. [...] [ this will be basically the same answer as for libftdi1, so feel free to skip reading one ] What is the rough time frame you have in mind for removing libusb-0.1-4 from unstable? I'm asking because there are two options: - pushing the current upstream version, with a transition, involving around 30 rdepends, needing sourceful uploads for most of them, and a rather complex device specific config migration, plus some pending packaging work or - backporting (looks to be pretty reasonable) the necessary changes for libusb 1.0 to lirc 0.9.0 (or 0.9.1, which 'only' needs the config migration, but not the library transition and the corresponding transition slot). Depending on your schedule, I can look into the targeted backports, but naturally I'd prefer to avoid that (as long as lirc won't be one of the final blockers). Regards Stefan Lippers-Hollmann pgpqcQgBtZwtO.pgp Description: Digitale Signatur von OpenPGP
Bug#810370: lirc: please switch to libftdi1
Hi
On 2016-01-08, Aurelien Jarno wrote:
> Package: lirc
> Version: 0.9.0~pre1-1.2
> Severity: wishlist
>
> Dear Maintainer,
>
> lirc has a build-depends on libftdi-dev. Upstream has released a new
> major version with a slightly different API and based on libusb 1.0. The
> old libusb and libftdi versions should be considered deprecated as they
> are not maintained upstream anymore.
[...]
[ this will be basically the same answer as for libusb, so feel free
to skip reading one ]
What is the rough time frame you have in mind for removing libftdi1
from unstable?
I'm asking because there are two options:
- pushing the current upstream version, with a transition, involving
around 30 rdepends, needing sourceful uploads for most of them, and
a rather complex device specific config migration, plus some pending
packaging work
or
- backporting (looks to be pretty reasonable) the necessary changes for
libftdi1-dev to lirc 0.9.0 (or 0.9.1, which 'only' needs the config
migration, but not the library transition and the corresponding
transition slot).
Depending on your schedule, I can look into the targeted backports,
but naturally I'd prefer to avoid that (as long as lirc won't be
one of the final blockers).
Regards
Stefan Lippers-Hollmann
pgpQ9qg5OCG3s.pgp
Description: Digitale Signatur von OpenPGP
Bug#799098: [gcc-5 transition] vdr-plugin-live crashes vdr (segfault) when searching the EPG (http://localhost:8008/searchepg.html)
Package: vdr-plugin-live
Version: 0.3.0+git20141029-1+b1
Severity: important
Hi
Since the later stages of the g++5.0 transition, searching the EPG with
vdr-plugin-live via http://localhost:8008/searchepg.html (enter any
search term, hit enter --> vdr segfaults) reliably crashes vdr, since
today even just opening http://localhost:8008/ may crash vdr (not 100%
reliably).
[27618.813086] vdr[32637]: segfault at 7f7103aed1e8 ip 7f7102e4373e sp
7f70deff78c8 error 4 in libc-2.19.so[7f7102db3000+19f000]
Rebuilding only vdr-plugin-live with gcc-5.0 doesn't help, but doing
local bin-NMUs for vdr and all installed vdr plugins solves the problem
for me:
- libxine2-xvdr
- vdr
- vdr-dev
- vdr-plugin-epgsearch
- vdr-plugin-femon
- vdr-plugin-live
- vdr-plugin-osdteletext
- vdr-plugin-streamdev-client
- vdr-plugin-streamdev-server
- vdr-plugin-xineliboutput
- xineliboutput-sxfe
Regards
Stefan Lippers-Hollmann
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.2.0-0.slh.2-aptosid-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages vdr-plugin-live depends on:
ii libc6 2.19-20
ii libcxxtools9v5 2.2.1-2
ii libgcc1 1:5.2.1-17
ii libpcre32:8.35-7.2
ii libpcrecpp0v5 2:8.35-7.2
ii libstdc++6 5.2.1-17
ii libtntnet12 2.2.1-1+b1
ii vdr [vdr-abi-2.0.6-debian] 2.0.6-2
vdr-plugin-live recommends no packages.
vdr-plugin-live suggests no packages.
-- no debconf information
pgpW5YDaKezgr.pgp
Description: Digitale Signatur von OpenPGP
Bug#798494: [pkg-wpa-devel] Bug#798494: iw: Can't connect to wireless router when running 4.1 kernel
reassign 798494 wicd thanks On 2015-09-09, John Harrington wrote: > Package: iw > Version: 3.17-1 > Severity: important > > Dear Maintainer, > > My network manager (wicd) lost the ability to connect to my unsecured wireless > router when I upgraded from the 3.16-0-4-686-pae kernel to the 4.1.0-1-686-pae > kernel. It still works normally when I boot into the 3.16 kernel. iw is a command line tool to query and modify the configuration of cfg80211 based wlan cards via nl80211. To the best of my knowledge wicd still has no concept of nl80211 and still depends on the obsolete wext compatibility layer in order to speak to the kernel. Accordingly this bug can't be in iw, as iw isn't even involved in the use case you describe. Therefore, from an initial 10'000 mile bird view, the packages involved in your problem could be: - src:linux - crda/ wireless-regdb - wpasupplicant - wicd but not iw. The prime suspect would usually be the kernel upgrade, but considering that you experience problems with vastly different kernel modules (ath5k and iwlagn) suggests a more generic issue (and wlan as a whole certainly isn't broken in linux 4.1 for everyone). crda and wireless-regdb are only responsible for setting and obeying the regulatory domain settings (allowed channels, ~transmit power, and ~features). Unless you're operating your device outside of its specifications, these two packages aren't really an active component in your problem. wpasupplicant would be the next contender, but here the version didn't really change between jessie (roughly corresponding to kernel 3.16) and unstable (the difference between wpasupplicant 2.3-1+deb8u1 and 2.3-2 is tiny and doesn't affect functionality). wicd hasn't seen an uploaded since 2013, so at least no /change/ in wicd could be made responsible for your issues either - except that no change at all and using an obsolete API to talk to the kernel (wext) can be a source of problems on its own. I'm still tentatively reassigning this bug to wicd, as you apparently have only tried wicd as configuration and connection management frontend and didn't reproduce the issue any other way so far. > This computer has a Qualcomm Atheros wireless adapter using the ath5k driver. > See further details in the command line output below. > > On another computer of mine, wicd lost the ability to connect when upgrading > from the 4.0.0-2-686-pae to the 4.1.0-1-686-pae kernel. (On this computer -- > the one I'm preparing this bug report on -- I upgraded directly from the 3.16 > kernel to the 4.1 kernel, so have not tested the wireless connection on this > computer when running the 4.0 kernel.) On that other computer -- the one on > which I lost wireless capability on the upgrade from the 4.0 to the 4.1 kernel > -- I have an Intel Ultimate N Wifi Link 5300 adapter using the iwlwifi driver. > Since I have the same problem with two different devices, I assume this > problem > is not specific to a particular adapter or driver. > > Sorry if I'm reporting this bug against the wrong package. From the command > line I can't connect using either the iw or the iwconfig utilities, and I > don't > know how to narrow the problem down any further. Below are a series of > commands that I ran under both the 3.16 and the 4.1 kernel with the > corresponding terminal output, showing that both the iw and iwconfig commands > successfully connect when running the 3.16 but fail when running the 4.1 > kernel: Neither iw, nor wireless-tools (iwconfig) are able to connect to wireless networks using modern (required) encryption (WPA2/ CCMP) on their own. Therefore you do need to use wpa_supplicant, which can be configured manually, but it's much better to use more well-known frontends in order to configure it and manage the connection. Beyond wicd, the most common ones would be network-manager or wpasupplicant's own ifupdown integration[1]. Once you have configured any of these, you can query further information from syslog or wpa_supplicant using wpa_cli (status). This will probably provide further insight into your problem. > ___ > > OUTPUT WHEN RUNNING THE 3.16 KERNEL: > > root@kitchencomp:/home# lspci -k lspci -knn is typically preferred, as it also provide numeric vendor- and product IDs. > > 00:0d.0 Ethernet controller: Qualcomm Atheros AR5212/5213/2414 Wireless > Network > Adapter (rev 01) > Subsystem: D-Link System Inc AirPlus DWL-G520 Wireless PCI Adapter > (rev. B) > Kernel driver in use: ath5k > O.k., this one should be working - at least it is/ was working for me with kernel 4.2 (and 4.1 before) using systemd-networkd. Regards Stefan Lippers-Hollmann [keeping the rest of your mail intact for the wicd maintainers] > root@kitchencomp:/home# i
Bug#797779: brcmfmac4330-sdio.txt from OpenElec fixes the issue
Hi On 2015-09-02, Rainer Dorsch wrote: > Hi, > > I copied brcmfmac4330-sdio.txt from OpenElec > > https://github.com/OpenELEC/wlan-firmware/blob/master/firmware/brcm/brcmfmac4330-sdio.txt > > to /lib/firmware/brcm > > which fixes the issue [...] brcmfmac4330-sdio.txt is OEM, respectively even device specific[1], nothing that would be generic enough (for all bcm4330 devices) to be shipped by Debian's firmware packages. On x86 systems this blob is typically provided in a UEFI variable (but not found automatically by the kernel, so you need to copy it from the UEFI variable to /lib/firmware). On embedded devices it needs to be provided by the manufacturer (not Broadcom, but the OEM vendor) of your wlan card (respectively the devboard). Regards Stefan Lippers-Hollmann [1] These blobs contain calibration data, regulatory domain settings and similar information, which is highly specific to your exact device. Using data from a different device would make it run out of its specifications (getting you in trouble with FCC, ETSI, etc.) and could even physically damage your device. pgpB3yQFdQkGm.pgp Description: Digitale Signatur von OpenPGP
Bug#797779: brcmfmac4330-sdio.txt from OpenElec fixes the issue
Hi
On 2015-09-02, Rainer Dorsch wrote:
> Hi Stefan,
>
> I copied the debian-arm list, because this should be an issue which is
> present
> on almost any ARM based SoC and there might exist solutions for other SoCs
> already.
It's not really arm specific, as this particular SDIO based wlan chipset
is used on multiple architectures (including many windows 8.x based Intel
Atom tablets).
> On Wednesday 02 September 2015 19:37:13 Stefan Lippers-Hollmann wrote:
> > On 2015-09-02, Rainer Dorsch wrote:
[...]
> Are you saying that I opened the bugreport against the wrong package or that
> this is not a bug at all?
As far as I see it, this is not a /software/ bug and not actionable
from within Debian, the data blob in question can only be provided
by the OEM/ systems integrator manufacturing the devboard or the
vendor producing the wlan card in question (e.g. AMPAK for the AP6120
wlan/ BT daughterboard using the Broadcom BCM4329 SDIO chipset found
on many armhf devboards). It is calibration data for your particular
wlan card and not a generic firmware image.
At best (and this is pretty questionable as well) you could create a
dedicated firmware image providing brcmfmac4329-sdio.txt for each
particular devboard, conflicting with all other providers of this
file.
If I were the Debian maintainer for firmware-brcm80211, I'd see no
other option than to close this bug - likewise I don't think that it
can be re-assigned to any other package in Debian.
On more traditional PCI/ PCIe or USB wlan cards, this type of
calibration data is typically stored in a small EEPROM chip, together
with the device's MAC address, but in the embedded space, vendors try
to save the last cent and reuse other kinds of (independent) storage.
- on x86 Atom Baytrail-T tablets (many of which use this exact,
bcm4329, wlan chipset), this calibration data is usually stored in
the mainboard firmware (vulgo BIOS) and exposed to the Windows driver
as UEFI (nvram-) variable; brcmfmac does not look there on its own.
- on Atheros based (mips) routers, the calibration data usually goes
into a dedicated mtd partition of the main flash ("ART", aka Atheros
Radio Test), here it is unique (based on the OEM calibration) to each
specific router (or at least small batches of the production).
- on most armhf devices originally shipping with Android, it is usually
presented as firmware file shipped in the original Android system
partition (e.g. /system/etc/wifi/nvram_net.txt) and then used by the
bcmhd driver on Android, respectively its mainline counterpart and
successor brcmfmac via /lib/firmware/brcm/brcmfmac4329-sdio.txt.
you need to extract /system/etc/wifi/nvram_net.txt from your original
Android image and copy it to /lib/firmware/brcm/brcmfmac4329-sdio.txt
or ask the manufacturer of your board for it.
> Doesn't on an ARM system the device tree file contain embedded device
> specific
> information, which is shipped with the kernel itself? And would this txt file
> not fit perfectly in this category of information?
I'm not a specialist on device tree syntax, but I'd guess that it's a
bit too much information to be injected via DT.
> How is this issue addressed for other ARM SoCs?
Many ARM devboards go a simpler route, by simply using a USB based
daughterboard (which includes all these implementation details in an
EEPROM of the USB daughterboard itself). Android smartphones, which
are more likely to use SDIO based wlan cards (and bcmhd as its driver),
store it as /system/etc/wifi/nvram_net.txt and alternative firmwares
either need to take care of not overwriting it, or to ship it
themselves.
The few devboards using SDIO based BCM4329 wlan cards either provide
nvram_net.txt/ brcmfmac4329-sdio.txt somewhere (which is specific to
their particular device, respectively production batch) or punt the
task of extracting it from the original Android based firmware to the
user.
See the situation for x86 tablets and mips routers above.
Regards
Stefan Lippers-Hollmann
pgpPI4PWVduKq.pgp
Description: Digitale Signatur von OpenPGP
Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails
Hi As indicated in direct conversation, the changes in 2.02.126-3 seem to avoid the problem for me, both on lvm2-only and mdadm+lvm2 systems using initramfs-tools. Regards Stefan Lippers-Hollmann pgpv691z2KwIW.pgp Description: Digitale Signatur von OpenPGP
Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails
Hi
On 2015-08-01, Stefan Lippers-Hollmann wrote:
On 2015-07-31, Michael Biebl wrote:
[...]
Bastian built the lvm2 on amd64 on a non-systemd system, it seems. This
results in /lib/udev/rules.d/69-lvm-metad.rules lookin like this:
...
ENV{SYSTEMD_READY}=1
RUN+=/sbin/lvm pvscan --background --cache --activate ay --major $major
--minor $minor, ENV{LVM_SCANNED}=1
...
If you build lvm2 on a systemd system, those rules look like
...
ENV{SYSTEMD_READY}=1
ACTION!=remove, ENV{LVM_PV_GONE}==1, RUN+=/bin/systemd-run
/sbin/lvm pvscan --cache $major:$minor, GOTO=lvm_end
ENV{SYSTEMD_ALIAS}=/dev/block/$major:$minor
ENV{ID_MODEL}=LVM PV $env{ID_FS_UUID_ENC} on /dev/$name
ENV{SYSTEMD_WANTS}=lvm2-pvscan@$major:$minor.service
If I replace /lib/udev/rules.d/69-lvm-metad.rules with the attached
file, my problems with LVM on top of RAID1 are gone. Can you copy the
attached file to /etc/udev/rules.d/ and test if that fixes your problem?
Just an update for the situation with lvm2 2.02.126-2:
- all affected systems are running the amd64 architecture
- all systems are up to date Debian unstable/main
using initramfs-tools 0.120:
- most systems are broken with lvm2 2.02.126-2, to varying degrees.
the problem is apparently timing sensitive, systems using a SSD
for the system paths (with their dedicated volume group) are less
likely to fail booting, but occassionally they still do break.
- doing a local bin-NMU of lvm2 2.02.126-2, in order to update
/lib/udev/rules.d/69-lvm-metad.rules with the changes pointed out
by Michael Biebl helps me on all non-mdadm == lvm2-only systems.
Not a single failed boot on these systems so far.
- lvm2 (2.02.126-2) on top of mdadm (RAID1) fails reliably for me,
regardless of the bin-NMU for 69-lvm-metad.rules or staying on
the plain lvm2 2.02.126-2; I'm aware of #793631 and just mention
it because the update to lvm2 2.02.126-2 doesn't appear to make
a difference.
using dracut 040+1-1:
- all lvm-only systems are booting fine, no local bin-NMU needed.
- the mdadm(RAID1)+lvm2 system is also booting reliably, no local
bin-NMU needed.
- no issues found with the current lvm2 and dracut (but I obviously
don't need any special initramfs hooks/ scripts)
Regards
Stefan Lippers-Hollmann
pgpuC1sS9sf6f.pgp
Description: Digitale Signatur von OpenPGP
Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails
Hi
On 2015-07-31, Michael Biebl wrote:
On Fri, 31 Jul 2015 08:08:38 +0200 Stefan Lippers-Hollmann
s@gmx.de wrote:
Hi
On 2015-07-31, Stefan Lippers-Hollmann wrote:
On 2015-07-31, Stefan Lippers-Hollmann wrote:
On 2015-07-25, Bastian Blank wrote:
[...]
The attached bootlog (serial console udev.log-priority=7) has
unfortunately not been recorded with an official Debian kernel, but
I've been able to reproduce it with 4.0.0-2-amd64 as well. Just that I
missed increasing the scrollback buffer in time and wasn't able to
fetch a full bootlog then - and, regardless of the kernel in use,
reproducing takes quite many reboots (too many for now) with full
logging enabled.
It took many reboots (50), but here is a reproduction with the
official Debian kernel - gzipped logs attached.
Stefan, you are running amd64, right?
Yes, all affected systems are running unstable/ amd64.
While I still use 3 non 64 bit capable i386 systems, I haven't powered
them up often enough to be 100% sure about their status in this regard.
Bastian built the lvm2 on amd64 on a non-systemd system, it seems. This
results in /lib/udev/rules.d/69-lvm-metad.rules lookin like this:
...
ENV{SYSTEMD_READY}=1
RUN+=/sbin/lvm pvscan --background --cache --activate ay --major $major
--minor $minor, ENV{LVM_SCANNED}=1
...
If you build lvm2 on a systemd system, those rules look like
...
ENV{SYSTEMD_READY}=1
ACTION!=remove, ENV{LVM_PV_GONE}==1, RUN+=/bin/systemd-run
/sbin/lvm pvscan --cache $major:$minor, GOTO=lvm_end
ENV{SYSTEMD_ALIAS}=/dev/block/$major:$minor
ENV{ID_MODEL}=LVM PV $env{ID_FS_UUID_ENC} on /dev/$name
ENV{SYSTEMD_WANTS}=lvm2-pvscan@$major:$minor.service
If I replace /lib/udev/rules.d/69-lvm-metad.rules with the attached
file, my problems with LVM on top of RAID1 are gone. Can you copy the
attached file to /etc/udev/rules.d/ and test if that fixes your problem?
[...]
I've done a local bin-NMU (on a systemd using chroot, so I ended up
with exactly the same lib/udev/rules.d/69-lvm-metad.rules you got),
as that was easier to deploy and test locally - and it indeed seems
to fix the problem. Both the nforce4 system and the ivy-bridge system
used for reporting this bug have gone through 20 successful reboots
each and all other affected systems I've tested seem to be fixed as
well (none of them having mdadm installed, I haven't been able to
test the single system using mdadm+lvm2 so far).
Thanks a lot
Stefan Lippers-Hollmann
pgp7B_WY2_eFR.pgp
Description: Digitale Signatur von OpenPGP
Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails
Hi On 2015-07-31, Stefan Lippers-Hollmann wrote: On 2015-07-31, Stefan Lippers-Hollmann wrote: On 2015-07-25, Bastian Blank wrote: [...] The attached bootlog (serial console udev.log-priority=7) has unfortunately not been recorded with an official Debian kernel, but I've been able to reproduce it with 4.0.0-2-amd64 as well. Just that I missed increasing the scrollback buffer in time and wasn't able to fetch a full bootlog then - and, regardless of the kernel in use, reproducing takes quite many reboots (too many for now) with full logging enabled. It took many reboots (50), but here is a reproduction with the official Debian kernel - gzipped logs attached. Regards Stefan Lippers-Hollmann boot-serialcon.log.gz Description: application/gzip dmesg.log.gz Description: application/gzip journalctl.log.gz Description: application/gzip udevadm-info-post-fix.log.gz Description: application/gzip udevadm-info-pre-fix.log.gz Description: application/gzip pgpvMuGRYx9Vu.pgp Description: Digitale Signatur von OpenPGP
Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails
Hi On 2015-07-25, Bastian Blank wrote: On Tue, Jul 21, 2015 at 09:11:57PM +0200, Bastian Blank wrote: So the next step could be debugging udev and see what it calls and when. Please provide the complete udev db (udevadm info -e) and udev debugging attached (in the broken state) as nforce4.log.gz (gzipped). output (udev.log-priority=8 at the kernel command line) from a failed boot. I've finally found a system where I can grab this information via serial console (using the serial console makes it less likely to trigger, but it still happens): ### this is different hardware than the one used for the previous reports ### Loading Linux 4.0.0-2-amd64 ... Loading initial ramdisk ... [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.0.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.3 (Debian 4.9.3-2) ) #1 SMP Debian 4.0.8-2 (2015-07-22) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.0.0-2-amd64 root=/dev/mapper/vg--challenger-debian64 ro console=tty0 console=ttyS0,115200n8 udev.log-priority=8 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009f3ff] usable [0.00] BIOS-e820: [mem 0x0009f400-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xd7fe] usable [0.00] BIOS-e820: [mem 0xd7ff-0xd7ff2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xd7ff3000-0xd7ff] ACPI data [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x000127ff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.3 present. [0.00] AGP: No AGP bridge found [0.00] e820: last_pfn = 0x128000 max_arch_pfn = 0x4 [0.00] PAT configuration [0-7]: WB WC UC- UC WB WC UC- UC [0.00] e820: last_pfn = 0xd7ff0 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000f52f0-0x000f52ff] mapped at [880f52f0] [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] init_memory_mapping: [mem 0x127e0-0x127ff] [0.00] init_memory_mapping: [mem 0x12000-0x127df] [0.00] init_memory_mapping: [mem 0x1-0x11fff] [0.00] init_memory_mapping: [mem 0x0010-0xd7fe] [0.00] RAMDISK: [mem 0x35d6-0x36ea7fff] [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000F91D0 14 (v00 Nvidia) [0.00] ACPI: RSDT 0xD7FF3040 34 (v01 Nvidia AWRDACPI 42302E31 AWRD ) [0.00] ACPI: FACP 0xD7FF30C0 74 (v01 Nvidia AWRDACPI 42302E31 AWRD ) [0.00] ACPI: DSDT 0xD7FF3180 0062AC (v01 NVIDIA AWRDACPI 1000 MSFT 010E) [0.00] ACPI: FACS 0xD7FF 40 [0.00] ACPI: SSDT 0xD7FF9540 0001CA (v01 PTLTD POWERNOW 0001 LTP 0001) [0.00] ACPI: MCFG 0xD7FF9780 3C (v01 Nvidia AWRDACPI 42302E31 AWRD ) [0.00] ACPI: APIC 0xD7FF9480 72 (v01 Nvidia AWRDACPI 42302E31 AWRD ) [0.00] Scanning NUMA topology in Northbridge 24 [0.00] No NUMA configuration found [0.00] Faking a node at [mem 0x-0x000127ff] [0.00] NODE_DATA(0) allocated [mem 0x127ff8000-0x127ffbfff] [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x0001-0x000127ff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x0009efff] [0.00] node 0: [mem 0x0010-0xd7fe] [0.00] node 0: [mem 0x0001-0x000127ff] [0.00] Initmem setup node 0 [mem 0x1000-0x000127ff] [0.00] Nvidia board detected. Ignoring ACPI timer override. [0.00] If you got timer trouble try acpi_use_timer_override [0.00] ACPI: PM-Timer IO Port: 0x4008 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR
Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails
Hi On 2015-07-31, Stefan Lippers-Hollmann wrote: [...] challenger:~# pvs PV VGFmt Attr PSize PFree /dev/sda2 vg-challenger lvm2 a-- 831,49g 251,49g challenger:~# vgs VG#PV #LV #SN Attr VSize VFree vg-challenger 1 4 0 wz--n- 831,49g 251,49g challenger:~# lvs LV VGAttr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert debian64 vg-challenger -wi-ao 10,00g home vg-challenger -wi--- 310,00g storage vg-challenger -wi--- 250,00g var vg-challenger -wi--- 10,00g challenger:~# lsblk NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT fd0 2:01 4K 0 disk sda 8:00 931,5G 0 disk ├─sda18:10 100G 0 part └─sda28:20 831,5G 0 part └─vg--challenger-debian64 254:0010G 0 lvm / sr0 11:01 1024M 0 rom sr1 11:11 1024M 0 rom [...] and now the same from the, previously failed, boot that has been 'encouraged' to find the missing logical volumes via: challenger:~# vgchange -ay 4 logical volume(s) in volume group vg-challenger now active [ 525.672908] EXT4-fs (dm-3): barriers disabled) [ 525.731022] EXT4-fs (dm-1): barriers disabled [ 525.733624] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: barrier=0 [ 525.779844] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: barrier=0 [ 525.783631] EXT4-fs (dm-2): barriers disabled [ 525.808851] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: barrier=0 challenger:~# mount -a challenger:~# exit [...] challenger:~# pvs PV VGFmt Attr PSize PFree /dev/sda2 vg-challenger lvm2 a-- 831,49g 251,49g challenger:~# vgs VG#PV #LV #SN Attr VSize VFree vg-challenger 1 4 0 wz--n- 831,49g 251,49g challenger:~# lvs LV VGAttr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert debian64 vg-challenger -wi-ao 10,00g home vg-challenger -wi-ao 310,00g storage vg-challenger -wi-ao 250,00g var vg-challenger -wi-ao 10,00g challenger:~# lsblk NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT fd0 2:01 4K 0 disk sda 8:00 931,5G 0 disk ├─sda18:10 100G 0 part └─sda28:20 831,5G 0 part ├─vg--challenger-debian64 254:0010G 0 lvm / ├─vg--challenger-var 254:1010G 0 lvm /var ├─vg--challenger-home 254:20 310G 0 lvm /home └─vg--challenger-storage 254:30 250G 0 lvm /srv/storage sr0 11:01 1024M 0 rom sr1 11:11 1024M 0 rom challenger:~# cat /proc/mounts sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 udev /dev devtmpfs rw,relatime,size=10240k,nr_inodes=495884,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,relatime,size=810532k,mode=755 0 0 /dev/dm-0 / ext4 rw,noatime,nobarrier,data=ordered 0 0 securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0 cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 mqueue /dev/mqueue mqueue rw,relatime 0 0 debugfs /sys/kernel/debug debugfs rw,relatime 0 0 systemd-1 /proc/sys/fs/binfmt_misc
Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails
Hi
On 2015-07-31, Stefan Lippers-Hollmann wrote:
On 2015-07-25, Bastian Blank wrote:
output (udev.log-priority=8 at the kernel command line) from a failed
boot.
[...]
Loading, please wait...
invalid udev.log[2.343952] random: systemd-udevd urandom read with 4 bits
of entropy available
-priority ignored: 8
[...]
Well, obviously (or rather not quite that obviously), the maximum log
level is 7.
systemd-223/src/libudev/libudev-util.c:
int util_log_priority(const char *priority)
{
[...]
if (prio = 0 prio = 7)
return prio;
else
return -ERANGE;
[...]
}
However it seems to be even harder to reproduce with udev.log-priority=7
set. While it triggers in roughly 85% of all reboots on this system
without serial console and special logging parameters, it takes quite a
few reboots to reproduce with serial console and udev.log-priority=7.
The attached bootlog (serial console udev.log-priority=7) has
unfortunately not been recorded with an official Debian kernel, but
I've been able to reproduce it with 4.0.0-2-amd64 as well. Just that I
missed increasing the scrollback buffer in time and wasn't able to
fetch a full bootlog then - and, regardless of the kernel in use,
reproducing takes quite many reboots (too many for now) with full
logging enabled.
Regards
Stefan Lippers-Hollmann
boot.log.gz
Description: application/gzip
pgpyWrp9SRaNc.pgp
Description: Digitale Signatur von OpenPGP
Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails
Hi Just confirming that there's no change with src:lvm2 2.02.126-1, the problem is still present. Regards Stefan Lippers-Hollmann pgpIHCM9hkNXU.pgp Description: Digitale Signatur von OpenPGP
Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails
Hi Just for testing, I've tried using dracut as provider for linux-initramfs-tool instead of initramfs-tools. The results were positive, around 30 successful reboots - going back to initramfs-tools exposed the original problem right away again. I don't use any special initramfs-tools configuration or strange hooks/ scripts: $ dpkg -S /etc/initramfs-tools/ initramfs-tools: /etc/initramfs-tools $ dpkg -S /usr/share/initramfs-tools/ kmod, udev, initramfs-tools, ntfs-3g, dmsetup, lvm2, intel-microcode, fuse, busybox: /usr/share/initramfs-tools $ debsums -as initramfs-tools kmod udev ntfs-3g dmsetup lvm2 intel-microcode fuse busybox $ Regards Stefan Lippers-Hollmann pgpwcJQMdyy7j.pgp Description: Digitale Signatur von OpenPGP
Bug#793647: systemd: missing build conflict vs autoconf2.13 - AM_COND_IF: no such condition ARCH_IA32
Hi On 2015-07-25, Ben Pfaff wrote: On Sun, Jul 26, 2015 at 01:25:03AM +0200, Michael Biebl wrote: Am 25.07.2015 um 23:45 schrieb Alban Browaeys: [...] The wrapper in the autoconf2.13 package is supposed to automatically determine which version of Autoconf is necessary. I see a bug, however, which makes it fail to do that correctly with gummiboot. I can fix that, but I can't reproduce the same problem with systemd. With gummiboot, I just had to type autoreconf -f -i to get the error reported in bug #754911. I don't see that error, though, when I do the same with systemd (or if I run dpkg-buildpackage). Alban or Michael, how do you see the problem? (I tested against a slightly older systemd version, 215-17+deb8u1, not version 222-2. If there's been some important change since then, let me know, and I'll retest.) I can't speak for the systemd maintainers, but gummiboot has been merged into the upstream systemd source since systemd 220, which would explain this behaviour. Regards Stefan Lippers-Hollmann pgpkYLyPR8BC5.pgp Description: Digitale Signatur von OpenPGP
Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails
Hi On 2015-07-20, Ben Caradoc-Davies wrote: On Mon, 20 Jul 2015 01:16:12 +0200 Stefan Lippers-Hollmann s@gmx.de wrote: Interesting enough, systems using a SSD for the system mountpoints usually succeed booting most of the time Thanks for this observation, Stefan. My successful boots are indeed on a system using an SSD. I have not yet had a failed boot with lvm2 2.02.122-2. Actually I have to partially withdraw that earlier conclusion, today I did encounter one failure on a system with all logical volumes making up the system paths on a SSD. The system in question had been booting fine with lvm2 2.02.122-2 roughly a dozen of times before and I haven't been able to reproduce the failure case again, but it does strengthen the hunch of a timing related issue. Regards Stefan Lippers-Hollmann pgpOuAUDT96VH.pgp Description: Digitale Signatur von OpenPGP
Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails
Hi On 2015-07-19, Bastian Blank wrote: On Thu, Jul 09, 2015 at 05:16:57AM +0200, Stefan Lippers-Hollmann wrote: Upgrading src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting due to a new systemd unit dependency failures regarding lvmetad when mounting non-rootfs logical volumes. Jumping to the emergency shell and invoking vgchange -ay and mount -a allows booting to finish. Please provide all information from the system regarding the storage. This includes: - /etc/fstab already provided in the original submission: # cat /etc/fstab # /etc/fstab: filesystem table. # # filesystemmountpoint typeoptions dump pass /dev/vg-redstone/debian64 / ext4 defaults,noatime,barrier=0 1 1 LABEL=UEFI /boot/efi vfat auto,user,exec,nodev,nosuid,noatime 1 2 /dev/vg-redstone/swap noneswapsw 0 0 /dev/vg-redstone/var/varext4 auto,user,exec,dev,noatime,barrier=01 2 /var/tmp/tmpnonebind 0 0 /dev/vg-redstone/home /home ext4 auto,user,exec,nodev,nosuid,noatime,barrier=0 1 2 /dev/vg-redstone/storage/srv/storageext4 auto,user,noexec,nodev,nosuid,noatime,barrier=0 1 2 LABEL=seagate /srv/seagateext4 auto,user,noexec,nodev,nosuid,noatime 1 2 - /etc/lvm/lvm.conf /etc/lvm/lvm.conf is unchanged from the package default of lvm2 2.02.122-2, but I've attached it (gzipped) nevertheless. $ md5sum -b /etc/lvm/lvm.conf de7411c6a935b065dd7dcde6208c364f */etc/lvm/lvm.conf - pvs, vgs, lvs # pvs PV VG Fmt Attr PSize PFree /dev/sdb2 vg-redstone lvm2 a-- 800,00g 446,00g # vgs VG #PV #LV #SN Attr VSize VFree vg-redstone 1 5 0 wz--n- 800,00g 446,00g # lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert debian64 vg-redstone -wi-ao 10,00g home vg-redstone -wi-ao 30,00g storage vg-redstone -wi-ao 300,00g swap vg-redstone -wi-ao 4,00g var vg-redstone -wi-ao 10,00g - lsblk # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 2,7T 0 disk ├─sda1 8:10 299M 0 part └─sda2 8:20 2,7T 0 part /srv/seagate sdb 8:16 0 931,5G 0 disk ├─sdb1 8:17 0 300M 0 part /boot/efi └─sdb2 8:18 0 800G 0 part ├─vg--redstone-debian64 254:0010G 0 lvm / ├─vg--redstone-var 254:1010G 0 lvm /var ├─vg--redstone-home 254:2030G 0 lvm /home ├─vg--redstone-swap 254:30 4G 0 lvm [SWAP] └─vg--redstone-storage 254:40 300G 0 lvm /srv/storage - systemctl status in broken state Taken, and stored in a temporary file, from within the emergency shell. $ zcat systemctl-status.log.gz ● redstone State: maintenance Jobs: 0 queued Failed: 1 units Since: Mo 2015-07-20 00:04:38 CEST; 2min 18s ago CGroup: / ├─1 /sbin/init └─system.slice ├─lvm2-lvmetad.service │ └─200 /sbin/lvmetad -f ├─emergency.service │ ├─573 /bin/sh -c /sbin/sulogin; /bin/systemctl --job-mode=fail --no-block default │ ├─576 bash │ └─588 systemctl status ├─systemd-journald.service │ └─199 /lib/systemd/systemd-journald ├─systemd-networkd.service │ └─369 /lib/systemd/systemd-networkd └─systemd-udevd.service └─203 /lib/systemd/systemd-udevd Kernel: Linux 4.1.0-1.slh.3-aptosid-amd64 (SMP w/2 CPU cores; PREEMPT) Ah, this is no Debian system at all. It is a Debian system, I'm just usually running the kernel[1] I'm developing and working on - but even though I picked the wrong one when submitting the bug, the problem can be reproduced easily using Debian's linux-image-4.0.0-2-amd64: All logs above have been gathered using: $ dpkg -l | grep -e linux-image-amd64 -e linux-image-4.0.0-2-amd64 -e 2.02.122-2 -e 2:1.02.99-2 ii dmeventd 2:1.02.99-2 amd64Linux Kernel Device Mapper event daemon ii dmsetup 2:1.02.99-2
Bug#791869: lvm2: updating src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting, mounting LVs other than / fails
Package: lvm2 Version: 2.02.122-1 Severity: serious Hi Upgrading src:lvm2 from 2.02.111-2.2 to 2.02.122-1 breaks booting due to a new systemd unit dependency failures regarding lvmetad when mounting non-rootfs logical volumes. Jumping to the emergency shell and invoking vgchange -ay and mount -a allows booting to finish. Reverting all src:lvm2 packages to 2.02.111-2.2 from testing avoids the problem, re-upgrading results in the same error condition again. I can reproduce the problem on several distinct systems, which share a similar fstab structure for the basic system paths; in all cases all fstab devices exist and can be auto-mounted with src:lvm2 2.02.111-2.2. I have attached the logs for journalctl -xb (gzipped) and the fstab. Regards Stefan Lippers-Hollmann -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1.slh.3-aptosid-amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lvm2 depends on: ii dmeventd 2:1.02.99-1 ii dmsetup 2:1.02.99-1 ii init-system-helpers 1.23 ii initscripts 2.88dsf-59.2 ii libc6 2.19-18 ii libdevmapper-event1.02.1 2:1.02.99-1 ii libdevmapper1.02.12:1.02.99-1 ii libreadline5 5.2+dfsg-3 ii libudev1 222-1 ii lsb-base 4.1+Debian13+nmu1 lvm2 recommends no packages. Versions of packages lvm2 suggests: pn thin-provisioning-tools none -- no debconf information fstab Description: Binary data journalctl-xb.log.gz Description: application/gzip pgp1dDv9kWLnr.pgp Description: Digitale Signatur von OpenPGP
Bug#790326: [pkg-wpa-devel] Bug#790326: [wpasupplicant] Driver Wext works but not nl80211
) Subsystem: Intel Corporation Centrino Advanced-N 6205 AGN This card uses iwlwifi (for more recent Intel wlan cards), rather than iwlegacy needed by iwl3945/ iwl4965, this module is still actively maintained by Intel and may not expose this problem. Yes, wheezy still defaulted to using wext in many cases, however even there nl80211 should have been preferred for drivers based on mac80211. On 2015-07-01, Samuel Smith wrote: Just some more info. I took the t61 laptop to work, and using wpa_supplicant I was able to connect to the wirless here using either wext or nl80211. This points to an issue with my home router which is a netgear WG102 with an atheros chip: http://support.netgear.com/product/WG102 While it's not impossible to be an issue between different Access Points, respectively their configuration and chosen cyphers (additionally interoperability issues aren't unheard of), I'd tend to blame the iwl3945 driver instead. I have a newer minipci wifi card coming the mail for the t61, I am going to try that and see if it can connect to the WG102 router with nl80211 next. I'd expect it to just work. On 2015-07-02, Samuel Smith wrote: I booted a Wheezy 7.8 live CD and everything is working fine on my t61 laptop connecting to my home router. Attached logs of: wpa_supplicant -i wlan0 -ddd -Dnl80211 -c wpa.conf nl80211aa.log wpa_supplicant -i wlan0 -ddd -Dwext -c wpa.conf wextaa.log As mentioned before, I'd suspect kernel 3.16 in jessie to interfere here, if that's the case, it would need closer debugging with the kernel team to get it fixed in jessie as well. Unfortunately I can't reproduces the problem with the wlan hardware I have available and none of the previous reporters appear to have taken it up. Regards Stefan Lippers-Hollmann pgpCvPEReFcNj.pgp Description: Digitale Signatur von OpenPGP
Bug#783148: [pkg-wpa-devel] Bug#783148: wpa: CVE-2015-1863: wpa_supplicant P2P SSID processing vulnerability
Hi On 2015-04-23, Salvatore Bonaccorso wrote: Hi, I'm currently preparing the debdiffs for jessie-security and sid uploads. Thank you for taking care of it, I was about to respond now (and am currently testing the patched packages, successfully so far). Be aware that src:wpa 1.0-3+deb7u1 in wheezy is not affected by this bug, as we did (intentionally) disable CONFIG_P2P for those packages. Regards Stefan Lippers-Hollmann pgpPGtMHsDiIU.pgp Description: Digitale Signatur von OpenPGP
Bug#780552: [pkg-wpa-devel] Bug#780552: wpa_supplicant.service needs Before=network.target to ensure proper ordering on shutdown
Hi On 2015-03-16, Michael Biebl wrote: Package: wpasupplicant Version: 2.3-1 Severity: important Hi, please add a Before=network.target dependency to the [Unit] section of wpa_supplicant.service. This ensures, that wpa_supplicant is stopped on shutdown *after* remote mount points have been unmounted. See also the discussion at [1]. Thanks a lot for reporting this, even more for hinting at the solution :) Looking at it more thoroughly, I think After=syslog.target might be needed as well, given that (by default) wpa_supplicant uses the syslog facilities for logging purposes. Therefore I'd suggest this patch instead: ### snip ### wpasupplicant: fix systemd unit dependencies wpasupplicant needs to be started before the network target (Closes: 780552). Debian bug: https://bugs.debian.org/780552 Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769186#41 systemd upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=86707#c3 Signed-off-by: Stefan Lippers-Hollmann s@gmx.de --- a/wpa_supplicant/systemd/wpa_supplicant.service.in +++ b/wpa_supplicant/systemd/wpa_supplicant.service.in @@ -1,5 +1,7 @@ [Unit] Description=WPA supplicant +Before=network.target +After=syslog.target [Service] Type=dbus ### snip ### Do you agree with this evaluation? Given the current stage of the freeze[1], would you like to get this uploaded for jessie? In that case I'll coordinate with release and d-i teams after the upload to unstable, pending release and udeb unblock, it should migrate without problems. Please forward this upstream accordingly. There are more changes to the systemd units pending for stretch (shipping the wpa_supplicant unit[2] needed for networkd, which needs more changes), I'll wrap these up after preparing the packaging svn for wpa 2.4/ the first post-jessie upload and will take care of submitting these to upstream. Regards Stefan Lippers-Hollmann [1] technically the window for fixing non-RC (==important) bugs has already been closed following the current release policy, but I'd be fine with asking for an unblock if you'd like to see this fixed for jessie with your systemd/ network-manager maintainer hat. https://release.debian.org/jessie/freeze_policy.html [2] http://w1.fi/cgit/hostap/tree/wpa_supplicant/systemd/wpa_supplicant.service.arg.in pgpZFsm93d4k5.pgp Description: Digitale Signatur von OpenPGP
Bug#780552: [pkg-wpa-devel] Bug#780552: wpa_supplicant.service needs Before=network.target to ensure proper ordering on shutdown
Hi On 2015-03-17, Stefan Lippers-Hollmann wrote: On 2015-03-17, Michael Biebl wrote: Am 17.03.2015 um 03:51 schrieb Stefan Lippers-Hollmann: [...] There are two pending changes beyond this, but imho neither meet the unblock criterias at this stage. [...] - fixing a segfault when using hostapd for a non-wireless (ethernet) interface (this is not exploitable, hostapd will just hard-fail to start using a config file configuring driver=wired). Technically I'd consider this to be RC, but given how rare using IEEE 8021X on wired ethernet networks is in practice - especially on Debian compatible hardware (rather than using commercial/ managed ethernet switches) - I don't think this would warrant a freeze exemption (this bug has not been reported to the Debian BTS). The bugfix[1] itself should be self-contained enough and probably acceptable to the release team (not affecting the feature set chosen for wpasupplicant-udeb). [...] [1] hostapd: Verify VHT 160/80+80 MHz driver support http://w1.fi/cgit/hostap/commit/?id=7f0303d5b0bb425f3e7318a7016b55ba9e67f9de [...] Small correction for a mistyped patch, the actual patch for the hostapd with driver=wired regression would be: [1] Fix hostapd operation without hw_mode driver data http://w1.fi/cgit/hostap/commit/?id=e9b783d58c23a7bb50b2f25bce7157f1f3b5d58b The afforementioned/ mispasted hostapd: Verify VHT 160/80+80 MHz driver support introduced the bug by trying to enforce channel bandwidth conditions for non-wireless interfaces as well (which can only fail on a wired interface). Regards Stefan Lippers-Hollmann pgpRG2wvIFY1u.pgp Description: Digitale Signatur von OpenPGP
Bug#780552: [pkg-wpa-devel] Bug#780552: wpa_supplicant.service needs Before=network.target to ensure proper ordering on shutdown
Hi On 2015-03-17, Michael Biebl wrote: [...] Am 17.03.2015 um 03:51 schrieb Stefan Lippers-Hollmann: [...] Looking at it more thoroughly, I think After=syslog.target might be needed as well, given that (by default) wpa_supplicant uses the syslog facilities for logging purposes. Therefore I'd suggest this patch instead: After=syslog.target is not necessary, it will actually generate a lintian warning, since using that is deprecated. sysloggers are socket activated nowadays, so don't need an explicit dependency. [...] Thanks for clearing this up, I'll therefore drop (well not commit in the first place) the After=syslog.target addition. Given the current stage of the freeze[1], would you like to get this uploaded for jessie? In that case I'll coordinate with release and d-i teams after the upload to unstable, pending release and udeb unblock, it should migrate without problems. Good question. I think the combination of wireless + remote FS (like NFS) is not that common that we must need to get this into jessie. Fixed (as in fstab/ auto) nfs shares (or similar remote filesystem mounts, which don't cope well with shorter or longer service disruptions) over wlan are not a good idea - and outright insane for system mountpoints like / or /usr/. Mounting remote filesystems temporarily at runtime might be more acceptable though (but I'd strongly suggest to use userspace mounting, like KDE's kio-slaves, probably gvfs or autofs mounts, perhaps even fuse based filesystems, for unreliable links instead, something that doesn't lock up hard whenever the network link stalls). If you plan another upload though, I would probably squeeze that one in since it has pretty low regression potential. There are two pending changes beyond this, but imho neither meet the unblock criterias at this stage. - dropping Kel from Uploaders (upon his request, certainly not warranting an unblock, but this should be acceptable to the release team in combination with a real bugfix meeting the criterias). - fixing a segfault when using hostapd for a non-wireless (ethernet) interface (this is not exploitable, hostapd will just hard-fail to start using a config file configuring driver=wired). Technically I'd consider this to be RC, but given how rare using IEEE 8021X on wired ethernet networks is in practice - especially on Debian compatible hardware (rather than using commercial/ managed ethernet switches) - I don't think this would warrant a freeze exemption (this bug has not been reported to the Debian BTS). The bugfix[1] itself should be self-contained enough and probably acceptable to the release team (not affecting the feature set chosen for wpasupplicant-udeb). A more important bugfix would be backporting a patch for using AP mode wlan interfaces bridged with ethernet ones[2], however this hasn't been reported to the Debian BTS either and would be far too invasive to touch at this point - especially as this would need further patches (and larger backporting) to make it compile on top of wpa 2.3. I don't feel comfortable with pushing this particular fix to jessie at the moment (and haven't completed the actual backporting yet either), especially as no other distribution is shipping this (or wpa 2.4, containing it) yet (except for OpenWrt, which doesn't technically ship this patch either, but fixes the kernel regression in a non-upstreamable way instead). All of these bugs are fixed upstream for wpa 2.4 (released just last sunday) and will be ready for stretch just after jessie has been released. Nevertheless I have prepared these packages (without [1]), containing only the Before=network.target change and dropping Kel from Uploaders, if you'd like to upload this for jessie dget -ud http://aptosid.com/slh/wpa/wpa_2.3-2.dsc http://aptosid.com/slh/wpa/wpa_2.3-2.debian.tar.xz http://aptosid.com/slh/wpa/wpa_2.3.orig.tar.xz ### snip ### diff -Nru wpa-2.3/debian/changelog wpa-2.3/debian/changelog --- wpa-2.3/debian/changelog2014-10-14 21:30:29.0 +0200 +++ wpa-2.3/debian/changelog2015-03-17 02:24:32.0 +0100 @@ -1,3 +1,13 @@ +wpa (2.3-2) unstable; urgency=medium + + * remove Kel Modderman from Uploaders as per his request, many thanks for +all past efforts Kel. + * fix systemd unit dependencies for wpasupplicant, it needs to be started +before the network target (Closes: 780552), many thanks to Michael Biebl +bi...@debian.org for reporting and suggesting the patch. + + -- Stefan Lippers-Hollmann s@gmx.de Tue, 17 Mar 2015 02:23:24 +0100 + wpa (2.3-1) unstable; urgency=medium * New upstream release: diff -Nru wpa-2.3/debian/control wpa-2.3/debian/control --- wpa-2.3/debian/control 2014-09-18 06:28:20.0 +0200 +++ wpa-2.3/debian/control 2015-03-17 00:59:27.0 +0100 @@ -1,7 +1,6 @@ Source: wpa Maintainer: Debian wpasupplicant Maintainers pkg-wpa-de
Bug#779169: systemd =219-1 doesn't clean up /tmp/ on reboot
Hi On 2015-02-25, Stefan Lippers-Hollmann wrote: [...] Overriding tmp.conf back to specify d /tmp 1777 root root - Sorry for the typo, this was of course meant to read: $ grep -v -e ^$ -e ^\# tmp.conf D /tmp 1777 root root - x /tmp/systemd-private-%b-* X /tmp/systemd-private-%b-*/tmp x /var/tmp/systemd-private-%b-* X /var/tmp/systemd-private-%b-*/tmp Regards Stefan Lippers-Hollmann pgpafrwrMTPXA.pgp Description: Digitale Signatur von OpenPGP
Bug#779169: systemd =219-1 doesn't clean up /tmp/ on reboot
Package: systemd Version: 219-1 Severity: minor Hi Starting with systemd =219-1 (including 219-3), I notice that /tmp/ isn't cleaned up while rebooting anymore (stale directories and files remain, at least back to 2016-02-18, when I upgraded from 218-10 to = 219-1), which was working as expected up to and including 218-10. Looking through the debdiff between 218-10 and 219-3, the following commit jumps out: commit 8b9c316708dcc3c92c00b5fcd3dc202cd20fc430 Author: Martin Pitt martin.p...@ubuntu.com Date: Tue Feb 17 07:50:22 2015 +0100 New upstream release 219 [...] diff --git a/debian/patches/Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-defaul.patch b/debian/p atches/Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-defaul.patch index e63a657..a840694 100644 --- a/debian/patches/Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-defaul.patch +++ b/debian/patches/Bring-tmpfiles.d-tmp.conf-in-line-with-Debian-defaul.patch [...] --- a/tmpfiles.d/tmp.conf +++ b/tmpfiles.d/tmp.conf @@ -8,8 +8,8 @@ # See tmpfiles.d(5) for details # Clear tmp directories separately, to make them easier to override --d /tmp 1777 root root 10d --d /var/tmp 1777 root root 30d -+D /tmp 1777 root root - -+#d /var/tmp 1777 root root 30d +-v /tmp 1777 root root 10d +-v /var/tmp 1777 root root 30d ++v /tmp 1777 root root - ++#v /var/tmp 1777 root root 30d # Exclude namespace mountpoints created with PrivateTmp=yes x /tmp/systemd-private-%b-* [...] Overriding tmp.conf back to specify d /tmp 1777 root root - does indeed restore the original behaviour of properly cleaning /tmp/ while booting. This is occuring on multiple systems for me, most including lvm2 and (all) an ext4 filesystem mounted or bind-mounted at /tmp/, but I can easily reduce this to a simple test case using a single ext4 partition for the whole system in a kvm virtual machine. $ cat /etc/fstab UUID=a6a62fc2-14bc-4927-a2b7-afe5a65b62cc /ext4 defaults,relatime,errors=remount-ro 01 As I don't see this mentioned as an intentional change in the (Debian's) changelog, I assume that this might have been an unintentional modification. Feel free to close this bug if it was indeed an intentional change of behaviour. Regards Stefan Lippers-Hollmann -- Package-specific info: -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (200, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.19.0-0.slh.1-aptosid-amd64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.113+nmu3 ii initscripts 2.88dsf-58 ii libacl1 2.2.52-2 ii libapparmor12.9.0-3+exp1 ii libaudit1 1:2.4-1+b1 ii libblkid1 2.25.2-5 ii libc6 2.19-15 ii libcap2 1:2.24-6 ii libcap2-bin 1:2.24-6 ii libcryptsetup4 2:1.6.6-5 ii libgcrypt20 1.6.2-4+b1 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b3 ii libmount1 2.25.2-5 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 219-3 ii mount 2.25.2-5 ii sysv-rc 2.88dsf-58 ii udev219-3 ii util-linux 2.25.2-5 Versions of packages systemd recommends: ii dbus1.8.16-1 ii libpam-systemd 219-3 Versions of packages systemd suggests: pn systemd-ui none -- no debconf information pgpJbs9DPTNJg.pgp Description: Digitale Signatur von OpenPGP
Bug#768130: [pkg-wpa-devel] Bug#768130: wpa_supplicant[1689]: nl80211: send_and_recv-nl_recvmsgs failed: -33 when trying to start apache
Hi On 2015-02-23, Willem van den Akker wrote: I have a laptop with an Intel Corporation Centrino Wireless-N 1030 wifi adapter. (Network controller: Intel Corporation Centrino Wireless-N 1030 [Rainbow Peak] (rev 34)) This adapter worked fine until there was an upgrade to wpa_suppliant 2.x. After that many 'nl80211: send_and_recv-nl_recvmsgs failed: -33' messages are found in the log and the wifi connection is down for about 15 seconds. This happens every 2 minutes. Feb 23 17:40:14 notebook wpa_supplicant[1117]: nl80211: send_and_recv-nl_recvmsgs failed: -33 This makes the jessie for this kind of laptops almost unusable. I have tried the suggestion 'modprobe iwlwifi 11n-disable=1' 2, 4 or 8. But then can cannot connect at all to my AP. So I think there is a major problem for the Jessie iwlwifi users. I hope for a fast solution ;) As mentioned before, I do not believe that this is a bug in wpasupplicant, but rather a kernel issue - as I've never seen this (or similar) bugs myself with non-iwlwifi drivers (as I unfortunately don't have access to modern intel wlan cards) and it's the kernel's job to provide a driver agnostic API between mac80211 based kernel drivers and userspace, namely wpa_supplicant. Therefore we -well you or the original submitter, as I don't have access to iwlwifi based devices- really need to establish if this really is a regression in the wpasupplicant package or in the kernel, which probably was updated several times within a similar time frame of the wpa_supplicant 2.2/ 2.3 uploads. The absence of bugreports for non-iwlwifi devices suggests otherwise. In order to debug this, you can try kernel 3.19 from experimental, check if you have the most current firmware (ucode) for your wlan card (firmware-iwlwifi might not carry the newer firmware blobs due to the freeze, dmesg might tell) and do comparative tests with the different wpasupplicant versions from http://snapshot.debian.org/package/wpa/ My hunch remains that this is probably a kernel regression, but this can only be confirmed with those tests and by someone who can reproduce the issue/ owns the affected hardware - and if this really is a bug in wpa_supplicant, ideally by a git bisection between the last known-good and the first known-broken version. Regards Stefan Lippers-Hollmann pgp61oTJilwf2.pgp Description: Digitale Signatur von OpenPGP
Bug#768130: [pkg-wpa-devel] Bug#768130: wpa_supplicant[1689]: nl80211: send_and_recv-nl_recvmsgs failed: -33 when trying to start apache
Hi On 2015-02-23, Willem van den Akker wrote: I have installed 3.19 from experimental and for now the errors are gone and the wifi connection looks stable. So after all this looks like a kernel bug. I will report more after a few days. Thanks for (likely) confirming this, iwlwifi covers a huge range of quite different wlan chipset generations, some older, some very fresh. Although Intel is working hard on providing kernel support even before shipping the actual devices, the quality of support varies between kernel versions. Regards Stefan Lippers-Hollmann pgpB0udcZnT7S.pgp Description: Digitale Signatur von OpenPGP
Bug#779007: [pkg-wpa-devel] Bug#779007: closed by Stefan Lippers-Hollmann s....@gmx.de (Re: Bug#779007: iw: Implement hook script for ifupdown, please?)
Hi On 2015-02-22, Elliott Mitchell wrote: It would be helpful if the iw package could implement an ifupdown hook script similar to the one the wireless-tools package has [...] Just to be constructive about this topic, your original question: iface wlan0 inet dhcp wpa-ssid MyNetWork wpa-psk plaintextsecret respectively iface wlan0 inet dhcp wpa-ssid homezone wpa-psk 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f exists today, provided by the wpasupplicant package. Further information is provided by /usr/share/doc/wpasupplicant/README.Debian.gz and the other documentation and examples in and below that directory. This does use nl80211 by default (if you're using a mac80211 based kernel module), but can fall back to wext transparently for legacy wext based drivers (unless you force a mode explicitly). Equivalent configuration can be used to configure wpa_supplicant for WEP or unencrypted networks - or even roaming, if you're looking for a slightly more sophisticated setup. Regards Stefan Lippers-Hollmann pgppW5d3Xnk2b.pgp Description: Digitale Signatur von OpenPGP
Bug#777170: [pkg-wpa-devel] Bug#777170: wpasupplicant: lots of CTRL-EVENT-SIGNAL-CHANGE messages in syslog and couldn't connect to wireless network
tags -1 moreinfo Hi On 2015-02-05, Julian Gilbey wrote: Package: wpasupplicant Version: 2.3-1 Severity: normal I was trying to connect to a wireless network from my MacBook Pro running testing today, and it connected only intermittently. I'm using network-manager, if that makes any difference. It may be the network involved, as I can connect to my home network with no difficulties. What wireless card are you using in your system/ which kernel driver is in use? Overcrowded and noisy environments can certainly make the situation worse, especially when you're almost out of reach of your AP and may even hop between different, equally bad APs. I guess this part of the issue is more of kernel issue though. The log file was filled with thousands of lines of the form: Feb 5 16:54:18 redfield wpa_supplicant[2925]: wlan0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=0 noise=0 txrate=48000 which were appearing at the rate of about 10 per second. CTRL-EVENT-SIGNAL-CHANGE is emitted at the MSG_INFO (default) logging level - you can tune wpa_supplicant's logging level to reduce (and subsequently hide) these messages. If you start wpa_supplicant by hand, the parameters are -d, -dd, ... (to increase the logging level) or -q, -qq, ... (to reduce the logging level. ifupdown's wpa_supplicant integration allows you to set a debugging level via wpa-debug-level %d (where %d stands for positive or negative numbers, e.g. -3, ..., 0, ..., 3). I do not know how (or if) networkmanager exposes access to these settings. As long as your kernel driver/ module is working fine, you're usually not supposed to get bothered by this event - it may be emitted occassionally, but rarely enough not to be noticed. I had a similar problem last week, and I wonder whether the same was happening then. A reboot did not help. Try to move around, closer to an access point, and check if the situation improves. Chances for wireless problems typically increase in noisy environments. It made no difference whether I was plugged in or working on battery power, and I have also uninstalled laptop-mode-tools thinking that this might have been a contributory factor. This should not affect your problem (but you never know). I can happily do further experiments next week if that would help. [...] Unless you're simply having problems with your signal level (too much noise, APs (almost) out of range), this is most likely a kernel problem (and probably needs to get re-assigned there, wpa_supplicant emitting these event notices is then merely a consequence of your network going away/ re-appearing. While it's not impossible that this might also be an interoperability problem between the AP and your client (where either kernel or wpa_supplicant might be to blame, but given that hostapd, the other component of src:wpa, is the effective reference implementation for APs, this is slightly less likely), I don't think this to be the issue here. Regards Stefan Lippers-Hollmann pgpHs1yTg10Rv.pgp Description: Digitale Signatur von OpenPGP
Bug#775591: [src:linux] AUFS missing from 3.18.0 kernel = Docker 10x slower
Hi On Saturday 17 January 2015, Török Edwin wrote: [...] DISCLAIMER: I can't speak for the Debian kernel maintainers. [ Keep in mind that kernel = 3.18 is not targetting jessie, but will only enter unstable/ testing (==stretch) after jessie has been released. ] Using linux-image-3.18.0-trunk-amd64 I noticed that AUFS is missing from /proc/filesystems. This causes Docker to slow down even 10x in some situations: https://github.com/docker/docker/issues/10161 Please consider enabling AUFS again. You cannot just 'enable' AUFS, aufs3 is a rather invasive out-of-tree patch set, which requires a significant maintenance overhead. Kernel 3.18 has just gained support for overlayfs (aka overlay/ ovl) upstream/ in mainline, which is mostly equivalent to AUFS in most aspects. At this point, overlayfs has slightly less features than aufs3, but they're sufficient for live CD usages and most likely for docker as well - and there are extensive improvements in the queue for kernel =3.20, it's likely to expect that the docker userland intended for = stretch will therefore provide support for overlayfs (in addition or even instead of AUFS), alleviating this temporary problem. The removal of aufs from kernel = 3.18 has been an intentional change by the Debian kernel maintainters and has been announced in [1] and more or less already been pre-announced in [2]. For a live-CD context, switching support from AUFS to overlayfs basically involved a 2-line change (loading overlay.ko instead of aufs.ko and mounting it with only slightly different mount options compared to aufs3), I assume the situation will be equally easy for docker as well. Therefore I'd suggest to close this bug as wontfix. Regards Stefan Lippers-Hollmann [1] https://lists.debian.org/1418154910.3599.44.ca...@decadent.org.uk 2014 [2] https://lists.debian.org/1310334299.8783.13.camel@localhost 2011 signature.asc Description: This is a digitally signed message part.
Bug#774867: [Pkg-lirc-maint] Bug#774867: lirc: diff for NMU version 0.9.0~pre1-1.2
Hi
[ Apologies if you receive this twice, my mail relay/ smarthost seems
to have problems and my previous/ identical response hasn't gotten
through yet. ]
On Saturday 17 January 2015, gregor herrmann wrote:
Control: tags 774867 + patch
Control: tags 774867 + pending
Dear maintainer,
I've prepared an NMU for lirc (versioned as 0.9.0~pre1-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
First of all, I acknowledge the NMU - thanks a lot, go ahead as you
wish, but...
[feel free to ignore the rest of this mail]
I don't object to the patch, but it doesn't really help with this bug.
The bug itself only happens when dist-upgrading from squeeze to wheezy,
neither wheezy, jessie or wheezy--jessie upgrades are affected at all,
so fixing this bug in jessie doesn't help any squeeze user who's just
now starting to look at dist-upgrading to wheezy at all. Actually it's
even worse, symlink_to_dir was only added to dpkg's maintscript
collection in dpkg 1.17.14, while squeeze is at 1.15.11 (admitted,
Pre-Depends: ${misc:Pre-Depends} should handle that aspect).
Therefore I'm curious, what is your plan with this bugfix?
Asking the release team for a jessie unblock doesn't really meet the
unblock criteria anymore, as the bug doesn't affect jessie nor wheezy
to jessie dist-upgrades (actually, had this bug been reported and fixed
in time before the wheezy release, I would have already removed this
kind of pre-wheezy upgrade support from the packages intended for
jessie).
Asking the stable-release managers to accept a wheezy-proposed-updates
upload for an equivalent fix targetting the next wheezy point release
would be justified - and I certainly would have done so up to 'a year
ago', but now that squeeze is EOL for over half a year already, it
feels a bit late (still correct, but as no actual user ever complained,
'why bother' (and get the stable-release managers busy for basically an
obsolete problem) at this point in time)?
So considerding that this change is neither needed for jessie+1
(stretch), nor fullfills the unblock criterias for jessie (and isn't
actually needed there either), the (correct) upload can only migrate
to testing (==stretch) after jessie has been released - when and where
it is even less needed than in jessie itself.
Accordingly, my plan was waiting until this weekend for a potential
response from the reporter, but pending that, to close the bug for
lirc 0.9.0~pre1-1.1 (the package version in jessie, technically not
100% correct, but it conveys the message correctly; asking the release
team for a jessie-ignore would basically do the same job) and tagging
it wheezy and wontfix. But as I mentioned, your change is the correct
solution, it's imho just way too late to fix at this point in time,
when the fix won't ever propagate to the only ones (current squeeze
users who are planning to dist-upgrade to wheezy) anymore. Making it
just academic busy-work for everyone involved.
To be clear, I very much appreciate your effort - thanks a lot - and
I'm fine with getting this uploaded to unstable, but I personally don't
see a need to bother the release team with an unblock request
(certainly not for jessie, nor -at this point in time- for wheezy
anymore) at this point in the freeze.
...and the next regular post-jessie lirc upload will just remove all
pre-jessie upgrade support (including this change[1]) from the package
anyways...
This piuparts mass bug filing imho would have better concentrated on
just wheezy to jessie issues, rather than murkying the waters by
including squeeze--wheezy issues as well, that ship has sailed long
time ago.
Regards
Stefan Lippers-Hollmann
[1] there would be reason to make an exception for this particular
change to go through one stable release, just to get it fixed
once and for all for everyone, but that's mostly academic here.
signature.asc
Description: This is a digitally signed message part.
Bug#774867: Fwd: Re: [Pkg-lirc-maint] Bug#774867: lirc-x: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
[ Just as reference, as this previous mail doesn't appear to have
reached bugs.d.o either ('thanks' to changes in my provider's
smarthost configuration) ]
-- Forwarded Message --
Subject: Re: [Pkg-lirc-maint] Bug#774867: lirc-x: unhandled symlink to
directory conversion: /usr/share/doc/PACKAGE
Date: Friday 09 January 2015
From: Stefan Lippers-Hollmann s@gmx.de
To: 774...@bugs.debian.org
Hi
On Thursday 08 January 2015, Andreas Beckmann wrote:
Package: lirc-x
Version: 0.9.0~pre1-1.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
[...]
This was observed on the following upgrade paths:
squeeze - wheezy - jessie
This affects only the =squeeze -- wheezy upgrade path. Considering
that upgrades skipping a stable release aren't formally supported and
generally don't work, it does not affect =jessie anymore, even though
both wheezy and jessie share the same version of lirc.
With squeeze being EOL for over half a year by now (disregarding the
more server centric, rather inofficial LTS efforts) and lirc being a
predominantly desktop/ multimedia centric package, with no actual user
report about this particular issue so far, I'd tend not to touch this
problem for wheezy anymore - and jessie isn't affected either way.
2m28.1s ERROR: FAIL: silently overwrites files via directory symlinks:
/usr/share/doc/lirc-x/NEWS.Debian.gz (lirc-x) !=
/usr/share/doc/lirc/NEWS.Debian.gz (lirc)
/usr/share/doc/lirc-x - lirc
/usr/share/doc/lirc-x/changelog.Debian.gz (lirc-x) !=
/usr/share/doc/lirc/changelog.Debian.gz (lirc)
/usr/share/doc/lirc-x - lirc
/usr/share/doc/lirc-x/copyright (lirc-x) != /usr/share/doc/lirc/copyright
(lirc)
/usr/share/doc/lirc-x - lirc
While the bug itself is definately serious/ RC for wheezy, I'd tend to
consider this problem wontfix for wheezy at this stage[1] and not-a-bug
for jessie - can you agree with this evaluation?
Regards
Stefan Lippers-Hollmann
[1] it does affect dist-upgrades from squeeze to wheezy
it does not affect fresh installations of wheezy
it does not affect dist-upgrades from wheezy to jessie
it does not affect fresh installations of jessie
it won't affect dist-upgrading from jessie upwards to stretch+
as such, I don't think a bugfix for this would meet the unblock
criteria for jessie at this point of the freeze, but with wheezy
and jessie sharing the same version of lirc, any change for wheezy
would also require an update for jessie.
---
signature.asc
Description: This is a digitally signed message part.
Bug#774867: [Pkg-lirc-maint] Bug#774867: lirc: diff for NMU version 0.9.0~pre1-1.2
Hi
On Saturday 17 January 2015, gregor herrmann wrote:
Control: tags 774867 + patch
Control: tags 774867 + pending
Dear maintainer,
I've prepared an NMU for lirc (versioned as 0.9.0~pre1-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
First of all, I acknowledge the NMU - thanks a lot, go ahead as you
wish, but...
[feel free to ignore the rest of this mail]
I don't object to the patch, but it doesn't really help with this bug.
The bug itself only happens when dist-upgrading from squeeze to wheezy,
neither wheezy, jessie or wheezy--jessie upgrades are affected at all,
so fixing this bug in jessie doesn't help any squeeze user who's just
now starting to look at dist-upgrading to wheezy at all. Actually it's
even worse, symlink_to_dir was only added to dpkg's maintscript
collection in dpkg 1.17.14, while squeeze is at 1.15.11 (admitted,
Pre-Depends: ${misc:Pre-Depends} should handle that aspect).
Therefore I'm curious, what is your plan with this bugfix?
Asking the release team for a jessie unblock doesn't really meet the
unblock criteria anymore, as the bug doesn't affect jessie nor wheezy
to jessie dist-upgrades (actually, had this bug been reported and fixed
in time before the wheezy release, I would have already removed this
kind of pre-wheezy upgrade support from the packages intended for
jessie).
Asking the stable-release managers to accept a wheezy-proposed-updates
upload for an equivalent fix targetting the next wheezy point release
would be justified - and I certainly would have done so up to 'a year
ago', but now that squeeze is EOL for over half a year already, it
feels a bit late (still correct, but as no actual user ever complained,
'why bother' (and get the stable-release managers busy for basically an
obsolete problem) at this point in time)?
So considerding that this change is neither needed for jessie+1
(stretch), nor fullfills the unblock criterias for jessie (and isn't
actually needed there either), the (correct) upload can only migrate
to testing (==stretch) after jessie has been released - when and where
it is even less needed than in jessie itself.
Accordingly, my plan was waiting until this weekend for a potential
response from the reporter, but pending that, to close the bug for
lirc 0.9.0~pre1-1.1 (the package version in jessie, technically not
100% correct, but it conveys the message correctly; asking the release
team for a jessie-ignore would basically do the same job) and tagging
it wheezy and wontfix. But as I mentioned, your change is the correct
solution, it's imho just way too late to fix at this point in time,
when the fix won't ever propagate to the only ones (current squeeze
users who are planning to dist-upgrade to wheezy) anymore. Making it
just academic busy-work for everyone involved.
To be clear, I very much appreciate your effort - thanks a lot - and
I'm fine with getting this uploaded to unstable, but I personally don't
see a need to bother the release team with an unblock request
(certainly not for jessie, nor -at this point in time- for wheezy
anymore) at this point in the freeze.
...and the next regular /post-jessie/ lirc upload will just remove all
pre-jessie upgrade support (including this change[1]) from the package
anyways...
This piuparts mass bug filing imho would have better concentrated on
just wheezy to jessie issues, rather than murkying the waters by
including squeeze--wheezy issues as well, that ship has sailed long
time ago.
Regards
Stefan Lippers-Hollmann
[1] there would be reason to make an exception for this particular
change to go through one stable release, just to get it fixed
once and for all for everyone, but that's mostly academic here.
signature.asc
Description: This is a digitally signed message part.
Bug#771852: package not installable due to postinst syntax error
Package: mdadm Version: 3.3.2-3 Severity: serious Tags: patch Hi Installing mdadm 3.3.2-3 fails with the following error Setting up mdadm (3.3.2-3) ... W: mdadm: failed to load MD subsystem. Generating mdadm.conf... done (failed to scan arrays; /proc probably not mounted). rm: unrecognized option '--ignore-fail-on-non-empty' Try 'rm --help' for more information. dpkg: error processing package mdadm (--configure): subprocess installed post-installation script returned error exit status 1 as rm(1) doesn't support --ignore-fail-on-non-empty as parameter. However simply switching this to rmdir --ignore-fail-on-non-empty is not successful either, as /var/lib/mdadm doesn't exist on systems where mdadm hasn't been installed before (and rmdir --ignore-fail-on-non-empty does exit with an error code, if the directoy which it is supposed to remove doesn't exist). There are two alternatives to fix this, either by ignoring all bugs from rmdir, e.g. rmdir --ignore-fail-on-non-empty /var/lib/mdadm || : or by checking if the directory in question exists beforehand. --- mdadm-3.3.2/debian/mdadm.postinst +++ mdadm-3.3.2/debian/mdadm.postinst @@ -100,7 +100,9 @@ if dpkg --compare-versions $2 le 3.3.2-1; then rm -f /var/lib/mdadm/CONF-UNCHECKED /var/lib/mdadm/mdadm.conf-generated - rm --ignore-fail-on-non-empty /var/lib/mdadm + if [ -d /var/lib/mdadm ]; then +rmdir --ignore-fail-on-non-empty /var/lib/mdadm + fi fi ;; esac Regards Stefan Lippers-Hollmann -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.18.0-rc7-aptosid-amd64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash signature.asc Description: This is a digitally signed message part.
Bug#768908: networkd: please support bridge mac cloning
Hi This, in my case using the device's real hardware MAC address, works fine with the following configuration (well, only 50-br0.netdev matters): $ cat /etc/systemd/network/50-br0.netdev [NetDev] Name=br0 Kind=bridge MACAddress=01:23:45:67:89:AB $ cat /etc/systemd/network/51-eth0.network [Match] Name=eth0 [Network] Bridge=br0 $ cat /etc/systemd/network/60-br0.network [Match] Name=br0 [Network] DHCP=yes Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#768862: [pkg-wpa-devel] Bug#768862: wpasupplicant: large beacon interval is badly tolerated
Control: severity -1 minor Control: tags -1 upstream Hi On Sunday 09 November 2014, Vitez Gabor wrote: [...] With a wifi AP with a 1 second beacon interval wpa_supplicant will take multiple seconds to find the network, when theoretically 1 second should be enough. Neither Android, nor Windows suffers from this problem, they both find the network with very small delay. Setting autoscan=periodic:-1 in wpa_supplicant.conf seems to resolv the problem, so I propose setting the defaults accordingly. (The problem seems to lie in using a too short scan duration, coupled with a too long delay between the scans, so the AP and wpa_supplicant have no chance to find eachother.) [...] I'd suggest to take this upstream, as I'm not very confident in diverging from upstream's defaults in this regard. My reason for this is that I consider APs with these large beacon intervalls to be misconfigured. So assuming the the only result of said 'broken' AP configuration is that it takes a few seconds, rather than just one second[1], to find the network, the tradeoff/ penalty is imho in the correct place; accordingly I've lowered the severity of this bug to minor. I know that significant tweaking has gone into finding a good strategy to deal with background scanning and related infrastructure, so blindly changing these defaults from Debian's side feels wrong to me. Given that I currently don't know about any networks 'misconfigured' in this way and therefore can't debug it locally, I'd appreciate if you could approach upstream under HostAP mailing list hos...@lists.shmoo.com http://lists.shmoo.com/mailman/listinfo/hostap and present your case. Regards Stefan Lippers-Hollmann [1] Like there are several scanning strategies selectable via the ap_scan configuration setting, which might be needed in different circumstances. signature.asc Description: This is a digitally signed message part.
Bug#768130: [pkg-wpa-devel] Bug#768130: wpa_supplicant[1689]: nl80211: send_and_recv-nl_recvmsgs failed: -33 when trying to start apache
Control: severity -1 normal Hi On Wednesday 05 November 2014, Pierre Crescenzo wrote: Package: wpasupplicant Version: 2.3-1 Severity: important Tags: lfs Hello, When I try to start apache2 web server, there is an wpasupplicant error: [...] nov. 05 09:20:25 tpol wpa_supplicant[1689]: wlan0: WPA: Group rekeying completed with 00:14:1c:ac:a7:83 [GTK=CCMP] Group rekeying is a normal status message, so this part is nothing to worry about. nov. 05 09:20:46 tpol wpa_supplicant[1689]: nl80211: send_and_recv-nl_recvmsgs failed: -33 [...] Regarding this, I don't think this is a problem with wpasupplicant. Rather it's reporting a problem with talking to the kernel module, which apparently seems to be most common with Intel wlan cards (iwlwifi). In case you do indeed have an Intel wlan card, you can try to experiment with the 11n_disable kernel parameter for the iwlwifi module (e.g. modprobe -r iwlwifi, modprobe iwlwifi 11n_disable=1 or 2, 4, 8). If your symptoms disappear with 11n support being disabled, this should be re-assigned to the linux kernel instead, but as this seems to be a recurring problem with iwlwifi for years, I don't hold many hopes that it will be fixed any time soon. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#767410: systemd-resolved: doesn't include local search domain from DHCP query into resolv.conf
Package: systemd Version: 215-5 Severity: minor Tags: upstream patch Hi Using systemd-resolved, the local searchdomain provided by the DHCP server is not added to resolv.conf, which disables FQDN completion without domain suffix. e.g.: $ ls -al /etc/resolv.conf lrwxrwxrwx 1 root root 32 Okt 17 20:00 /etc/resolv.conf - /run/systemd/resolve/resolv.conf $ cat /run/systemd/resolve/resolv.conf # This file is managed by systemd-resolved(8). Do not edit. # # Third party programs must not access this file directly, but # only through the symlink at /etc/resolv.conf. To manage # resolv.conf(5) in a different way, replace the symlink by a # static file or a different symlink. nameserver 10.0.0.1 nameserver 8.8.8.8 nameserver 8.8.4.4 # Too many DNS servers configured, the following entries may be ignored nameserver 2001:4860:4860:: nameserver 2001:4860:4860::8844 Domain name without domain suffix: $ nslookup redstone Server: 10.0.0.1 Address:10.0.0.1#53 Non-authoritative answer: *** Can't find redstone: No answer FQDN, with full (local-) domain suffix: $ nslookup redstone.lan Server: 10.0.0.1 Address:10.0.0.1#53 Name: redstone.lan Address: 10.10.7.0 This seems to have been reported upstream under https://bugs.freedesktop.org/show_bug.cgi?id=79671 and probably also https://bugs.freedesktop.org/show_bug.cgi?id=85397 The formal patch that was actually merged upstream http://cgit.freedesktop.org/systemd/systemd/commit/?id=6192b846ca0d15602e94ddb5da4420b7c60d64a5 doesn't apply easily to systemd 215, but the initially suggested patch https://bugs.freedesktop.org/attachment.cgi?id=103315 applies to current (Debian-) systemd HEAD (as of debian/215-5-14-g8178d8d) and is working for me --- old/resolv.conf +++ /etc/resolv.conf @@ -5,6 +5,7 @@ # resolv.conf(5) in a different way, replace the symlink by a # static file or a different symlink. +domain lan nameserver 10.0.0.1 nameserver 8.8.8.8 nameserver 8.8.4.4 $ nslookup redstone Server: 10.0.0.1 Address:10.0.0.1#53 Name: redstone.lan Address: 10.10.7.0 systemd-networkd configuration: $ cat /etc/systemd/network/50-br0.netdev [NetDev] Name=br0 Kind=bridge MACAddress=01:23:45:67:89:AB $ cat /etc/systemd/network/51-eth0.network [Match] Name=eth0 [Network] Bridge=br0 $ cat /etc/systemd/network/60-br0.network [Match] Name=br0 [Network] DHCP=yes Regards Stefan Lippers-Hollmann -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.18-rc2-aptosid-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-57 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1 ii libblkid1 2.25.2-2 ii libc6 2.19-12 ii libcap2 1:2.24-6 ii libcap2-bin 1:2.24-6 ii libcryptsetup4 2:1.6.6-3 ii libgcrypt20 1.6.2-4 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-5 ii mount 2.25.2-2 ii sysv-rc 2.88dsf-57 ii udev215-5 ii util-linux 2.25.2-2 Versions of packages systemd recommends: ii dbus1.8.8-2 ii libpam-systemd 215-5 Versions of packages systemd suggests: pn systemd-ui none -- no debconf information signature.asc Description: This is a digitally signed message part.
Bug#766746: [pkg-wpa-devel] Bug#766746: wpasupplicant: install interface-specific systemd service file
Control: severity -1 wishlist Hi On Saturday 25 October 2014, Alessandro Ghedini wrote: Package: wpasupplicant Version: 2.3-1 Severity: normal Tags: patch Hi, the upstream project provides an additional systemd service that can be used to provide interface specific configuration, which is necessary to use wpasupplicant with systemd-networkd as described in [0]. It'd be nice if the Debian package installed that service as well (see attached patch). [...] I'm aware of that and plan[1] to look into it for jessie+1, but at this point in the freeze it feels too risky to add these (as there is a certain overlap with the systemd units for network-manager). If you are sufficiently confident about it /and/ can check it with network-manager, I'd be fine with you NMUing[2] wpa for this change - but I can't/ won't take the responsibility for potential network-manager related regressions 10 days before the freeze[3]. Regards Stefan Lippers-Hollmann [1] I'm very interested in networkd, but haven't completely migrated my relatively advanced networking setup (including tun, rather than tap based, virtual interfaces for qemu) from ifupdown to networkd. [2] experimental would be totally fine with me, but please be very careful if you want to get it into unstable and subsequently jessie. [3] keep in mind that wpa produces an udeb and also needs explicit unblocking by debian-boot and the d-i team as well. signature.asc Description: This is a digitally signed message part.
Bug#765631: unblock/ age to 5 days: wpa/2.3-1 (CVE-2014-3686, DSA-3052-1)
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal X-Debbugs-CC: debian-b...@lists.debian.org Hi Please unblock the udeb producing package wpa and reduce its propagation time to 5 days. wpa 2.3-1 has been successfully built and uploaded on all release architectures. wpa = 2.3-1 is vulnerable against a remotely exploitable security bug, which might allow attackers to inject an unsanitized string received from a remote device (potentially any device in radio range) to a privileged (typically root or netdev) system() call via wpa_cli/ hostapd_cli action scripts. CVE-2014-3686 https://security-tracker.debian.org/tracker/CVE-2014-3686 DSA-3052-1 https://www.debian.org/security/2014/dsa-3052 #765352 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765352 For debian-boot/ the upcoming stable point release (wheezy 7.7): wpasupplicant-udeb, as used by d-i, does not contain the exploitable binary (wpa_cli), which is only part of the full wpasupplicant/ hostapd packages (these are already fixed via debian-security). Accordingly d-i's usage of wpa_supplicant is not suspectible to this security issue. This is a new upstream version of wpa containing further changes and features of wpa's stable integration branch[1], rather than a targetted fix. unblock wpa/2.3-1 Regards Stefan Lippers-Hollmann [1] wpa 2.x is a continuous integration branch for bugfixes and new features, rather than a dedicated bugfix branch in the sense of PostgreSQL or the linux kernel. signature.asc Description: This is a digitally signed message part.
Bug#762554: [Pkg-lirc-maint] Bug#762554: Updating the lirc Uploaders list
Hi On Tuesday 23 September 2014, Ricardo Mones wrote: Package: lirc Version: 0.9.0~pre1-1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Matthew Johnson mj...@debian.org has retired, so can't work on the lirc package anymore (at least with this address). We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks for the notice, I've changed this in the packaging VCS[1], an upload for lirc will follow soon (for other reasons). Regards Stefan Lippers-Hollmann [1] http://lists.alioth.debian.org/pipermail/pkg-lirc-changes/2014-September/000640.html signature.asc Description: This is a digitally signed message part.
Bug#761922: [pkg-wpa-devel] Bug#761922: wpa: please enable syslog option for the udeb
Thanks On Tuesday 16 September 2014, Cyril Brulebois wrote: Source: wpa Version: 1.1-1 Severity: normal Tags: d-i Hi, as discussed in [1] it would be nice to get CONFIG_DEBUG_SYSLOG=y added to the wpasupplicant-udeb configuration. I've successfully tested this on linux (amd64), patching netcfg to call wpa_supplicant with the proper flags (-s and -d/-dd). 1. https://lists.debian.org/debian-boot/2014/09/msg00517.html I see patches are already in svn but I'd like to make sure we can track this properly to avoid adding those flags to netcfg before wpa is uploaded and possibly has migrated to testing. [...] Thanks, I'll try to get it uploaded as soon as possible (hopefully within the next 1-2 days). Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#760712: WEP vs WPA2
On Monday 15 September 2014, Ben Hutchings wrote: On Mon, 2014-09-15 at 23:08 +0200, Stefan Lippers-Hollmann wrote: On Monday 15 September 2014, Cyril Brulebois wrote: Stefan Lippers-Hollmann s@gmx.de (2014-09-15): [...] [...] but the udeb should support: - no encryption - WEP64 - WEP128 - WPAPSK v1 TKIP/ CCMP - WPAPSK2 TKIP/ CCMP More advanced setups, like IEEE8021X (using certificates and per-user encryption, e.g. eduroam and other commercial setups), smartcards and are not supported by the udeb (nor would netcfg know how to configure these). WPS would also be nice to have. Actually plain WPS support[1] (not allowing for external registrar functionality or NFC config methods) should already be supported by wheezy's wpasupplicant packages (1.0-3). However I have not tested WPS support (it was only enabled due to dependency issues of the udeb build config) and I'm pretty sure that netcfg doesn't know how to configure this. WPS using pin numbers or push-button (QSS) support is horribly insecure and should be strongly discouraged, even though it is convenient for the user (unfortunately many commercial access point firmware don't allow to disable this option completely). [...] The built-in world regulatory domain allows *passive* use of channels 12-13 and other channels that are not permitted in all countries. That is, the kernel will allow passively scanning on those channels and connecting to an AP, on the assumption that the AP is following the local rules. [...] Of course you're right, passive scanning mitigates this problem to quite some extent. Active scanning (which is faster and would be required for connecting to hidden SSIDs (which are a bad idea, but still common; of course netcfg would have to learn to support this as well) and 802.11d aren't available this way. Regards Stefan Lippers-Hollmann [1] This should cover most consumer routers/ access points signature.asc Description: This is a digitally signed message part.
Bug#760712: WEP vs WPA2
packages, both look identical… linux-image-3.16-1-amd64_3.16.2-3_amd64.deb kernel-image-3.16-1-amd64-di_3.16.2-3_amd64.udeb so that might be something different anyway. This is less of a configuration (as in kernel .config) problem, but more likely to be caused by some (newly) required kernel modules providing the functionality for wpa modes missing from the udebs for d-i. Taking a simple mac80211 based wlan card (ar5523, USB) as example, forced into wext mode mode, I see these wireless modules as required for wpa2-psk/ ccmp - this is not using the Debian kernel, which might be slightly less modular: plugging in ar5523, unconfigured: + arc4 + ar5523 (well, this is the particular module only require for ar5523) + mac80211 + cfg80211 + rfkill after starting wpa_supplicant in (forced) wext mode: + ctr + ccm + af_packet For ath9k, the required module needed on top of the ones above seam to be (less reliably, as I can't hotplug PCIe): + ath9k + ath9k_common + ath9k_hw + ath Depending on your particular wlan card and how its driver is divided into sub-modules (or how well it is integrated into other kernel subsystems), you might need additional modules as well. [with my wpa maintainer hat on] Semi-related, I have a pending upload for wpa (wpasupplicant-udeb), can you give me a rough guide when it's safe to upload in order not to interfere with d-i beta2[6]? There are no behavioural changes, besides many bugfixes[7]. If you want to test it for d-i, the packaging is ready (besides the changelog entries) in the normal VCS location[8]. Regards Stefan Lippers-Hollmann [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/feature-removal-schedule.txt?id=v3.6#n422 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683281#10 [4] https://dev.openwrt.org/browser/trunk/package/network/utils/iwinfo it only needs trivial modifications to the buildsystem to work in Debian. A pure nl80211 example implementation would be found in iw. [6] https://lists.debian.org/debian-cd/2014/09/msg00027.html Subject: (Almost) Time for Jessie Beta 2? [7] probably particularly important to eduroam setups, although this particular configuration isn't supported by netcfg and can only be used in a full installation [8] Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-wpa/wpa/trunk/ Vcs-Svn: svn://anonscm.debian.org/pkg-wpa/wpa/trunk/ http://aptosid.com/slh/wpa/wpa_2.2-0~svnr1884.0.dsc http://aptosid.com/slh/wpa/wpa_2.2-0~svnr1884.0.debian.tar.xz http://aptosid.com/slh/wpa/wpa_2.2.orig.tar.xz signature.asc Description: This is a digitally signed message part.
Bug#760712: WEP vs WPA2
Hi On Monday 15 September 2014, Cyril Brulebois wrote: Stefan Lippers-Hollmann s@gmx.de (2014-09-15): [...] Seeing that the actual problem are missing kernel modules for CCMP (AES), and probably TKIP as well, I'll concentrate on your new questions only Based on your answer, I'm wondering whether there might be some CONFIG_* differences between wpasupplicant and its udeb, which might explain? There are significant CONFIG_* differences between the regular wpasupplicant and wpasupplicant-udeb, both to get it smaller and to avoid dependencies on packages not providing udebs, but the udeb should support: - no encryption - WEP64 - WEP128 - WPAPSK v1 TKIP/ CCMP - WPAPSK2 TKIP/ CCMP More advanced setups, like IEEE8021X (using certificates and per-user encryption, e.g. eduroam and other commercial setups), smartcards and are not supported by the udeb (nor would netcfg know how to configure these). [ o.k., the following three paragraphs have been obsoleted by your other mail ] |As a quick test I have bind-mounted the wpa_supplicant binary from |wpasupplicant-udeb over /sbin/wpa_supplicant of a full installation |and successfully tested: | |# wpa_supplicant -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf |Successfully initialized wpa_supplicant |wlan0: CTRL-EVENT-SCAN-STARTED |wlan0: SME: Trying to authenticate with 01:23:45:67:89:ab (SSID='test' freq=2472 MHz) |wlan0: Trying to associate with 01:23:45:67:89:ab (SSID='test' freq=2472 MHz) |wlan0: Associated with 01:23:45:67:89:ab |wlan0: WPA: Key negotiation completed with 01:23:45:67:89:ab [PTK=CCMP GTK=CCMP] |wlan0: CTRL-EVENT-CONNECTED - Connection to 01:23:45:67:89:ab completed [id=4 id_str=test_aes] |wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=DE |wlan0: WPA: Group rekeying completed with 01:23:45:67:89:ab [GTK=CCMP] | |# wpa_cli status |Selected interface 'wlan0' |bssid=01:23:45:67:89:ab |ssid=test |id=4 |id_str=test_aes |mode=station |pairwise_cipher=CCMP |group_cipher=CCMP |key_mgmt=WPA2-PSK |wpa_state=COMPLETED |ip_address=10.20.27.0 |address=ba:98:76:54:43:21 | |This is 802.11bgn, using WPA2PSK and CCMP (AES) encryption with an |Atheros AR9285 (ath9k) wlan card, so relatively comparable to the |original submitter (while I have rtl8192du, I currently don't have |access to any wlan card supported by rtl8192cu). Accordingly the udeb |config for wpasupplicant (at least on linux) should be fine. This reminds me, without regulatory domain support (iw(semi-optional), crda, wireless-regdb) only the channels allowed for world-roaming (slightly depending on what the individual wlan drivers and firmwares understand under world-roaming) would be available, which means channel 1-11 (no access to 12/13) and very little, if anything, in the 5 GHz band. [...] [with my wpa maintainer hat on] Semi-related, I have a pending upload for wpa (wpasupplicant-udeb), can you give me a rough guide when it's safe to upload in order not to interfere with d-i beta2[6]? There are no behavioural changes, besides many bugfixes[7]. If you want to test it for d-i, the packaging is ready (besides the changelog entries) in the normal VCS location[8]. Well currently, as far as I can see/test, WPA support in d-i isn't exactly working nicely, so I don't think a wpa upload is going to hurt much. Quite the contrary, hopefully. Thanks, I'll do some final testing (and add CONFIG_DEBUG_SYSLOG=y, as requested in your other mail) and will try to get the new version sponsored quickly. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
Hi On Sunday 14 September 2014, Joerg Jaspert wrote: On 13616 March 1977, Christoph Anton Mitterer wrote: [ Not doing a full quote, but keeping quite a bit of context for debian-devel readers ] As Jakub Wilk pointed out[1] these are the current validity periods for Release files: [...] I'd suggest to reduce the validity to at most 1 day in all cases. Actually I'd choose much smaller values if this causes no other problems. Technically we could go down to 1 second, validtime is expressed in seconds in our setup. Please consider that too short intervals (24h might still work, but it's hard on the limit) make non-primary (cron based) mirrors basically impossible. Including local mirrors used for systems that can't connect to the internet directly or potentially even setups used for (personal) archive-wide rebuilds or debian-cd related tasks. Intervals below an hour, besides probably even invalidating most primary mirrors, are likely to render apt-get update to expire before it has finished downloading the meta data for all repos on slower internet connections. Decreasing these validity cycles too much would force many of these uses to ignore expiry times alltogether - or having to re-sign a local archive mirror with longer periods (which is not exactly a reasonable task for most users or anything that involves debootstrapping). I guess most uses would opt to go with the first option instead, which won't help anyone... Personally I think 24 hours (better something like 26-28 hours to allow some overlap for secondary/ tertiary/ local mirrors only updated daily) would be the technical limit that might be possible, but anything shorter than a week (or at very least three days) would already significantly impact many valid use cases where local mirroring and/or a fixed archive state is required. While there might be an argument to decrease the expiry times for security.d.o, perhaps even down to a day or at least half a day[1], the negative net impact for all normal archives (especially testing and unstable) would imho far outweigh any potential security improvements. Just look at the common advice given for expired signatures on snapshots.d.o, most suggest to use a global apt-get -o Acquire::Check-Valid-Until=false update or Acquire::Check-Valid-Until 0; for apt. For these reasons I would suggest against changing the current intervals, especially least not into the hour- or single day regions. Regards Stefan Lippers-Hollmann [1] and even for security.d.o I don't believe that anything below at least 2-3 days would be a good idea. signature.asc Description: This is a digitally signed message part.
Bug#746505: [Pkg-lirc-maint] Bug#746505: fix FTBFS on new architectures
Control: forcemerge -1 757124 Hi On Wednesday 10 September 2014, Andreas Barth wrote: * Stefan Lippers-Hollmann (s@gmx.de) [140910 14:24]: On Wednesday 30 April 2014, Breno Leitao wrote: Lirc is curretnly failing to build on new architectures, as ppc64el. In order to enable this package to be built on new architectures, autoreconf needs to be called before the package build. In order to do it, I am providing a patch that follows the instructions at Thanks for the patch, I was planning to enable autoreconf (following the recent threads on d-devel) anyways, so this patch is very welcome and it will be part of the next lirc upload (which may take 1-2 months to finalize, as there is some renewed upstream activity). As ppc64el is now part of Debian, I'd be willing to help fixing this bug, including sponsoring an upload or uploading an NMU. Do you have a package at hand, or would an NMU be more appropriate? If there is no newer package, and no reason against an NMU, I'll upload a fix probably end of the week. [...] Thank you very much for the sponsoring offer, it would be very appreciated. There is a new upstream version (using dh-autoreconf) pending. At this stage it's basically ready, but needs a little more attention to migrating existing configurations (and a few documentation changes) before it can be uploaded. Ideally I can get the new version into shape until the end of the weekend, but feel free to push a porter-NMU as needed. The patch attached to this bug should work and there's no need to bother about the pending new version (it's fixed there already in an equivalent way) or a formal NMU-diff. I'll take care to acknowledge the NMU and not to conflict with the testing migration then. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#759545: Ceni - Curses user interface for configuring network interfaces with ifupdown
Hi On Thursday 28 August 2014, Carlos Alberto Lopez Perez wrote: Package: wnpp Severity: wishlist X-Debbugs-CC: k...@otaku42.de, bernard.g...@gmail.com, x-u...@berlios.de, s@gmx.de, andre...@debian.org * Package name: ceni Version : 2.28 Upstream Author : Kel Modderman k...@otaku42.de * URL : https://github.com/fullstory/ceni * License : GPL-2+ Programming Lang: Perl Description : Ceni - Curses interface to /etc/network/interfaces A Curses user interface for configuring network interfaces with ifupdown. Ceni can manage basic network interface ifupdown configuration stanzas for ethernet and wireless devices. Please note that Ceni doesn't have IPv6 support[1], which is the reason why neither of us has pushed it to Debian so far. Adding support for the various IPv6 flavours (static, SLAAC with and without privacy extensions, dhcpv6) would be reasonably possible, but isn't on the immediate to-do list, patches are of course welcome. Likewise for supporting the various IPv6 related tunneling protocols (6in4, 6t4, 6rd) or additional imginable functionality (PPPoE, VPN tunnels, etc.). If anyone were to step up to maintain this in Debian despite this known problem, we'd be happy to accommodate Ceni and help with its (existing) packaging as needed. Regards Stefan Lippers-Hollmann [1] Ceni doesn't deal with inet6 stanzas, which effectively means that ifupdown falls back to SLAAC (if available by the router) without privacy extensions enabled (privext 0). signature.asc Description: This is a digitally signed message part.
Bug#756847: [pkg-wpa-devel] Bug#756847: wpasupplicant: systemd wpa_supplicant.service wrong behavior on target isolate
Control: tags -1 moreinfo Control: tags -1 help Hi On Saturday 02 August 2014, debianizzato wrote: Package: wpasupplicant Version: 1.1-1 Severity: normal Dear Maintainer, I switched from sysvinit to systemd in Debian Jessie. I created a personalized systemd target similar to graphical.target, just adding some Conflicts directives in order to stop some daemons (mysql and apache2). When I switch from graphical.target to personalized.target and vice-versa (using systemctl isolate name.target), everything works fine, except that WiFi connection in Gnome3 Network Manager drops and then restart. Syslog reports that it is wpa_supplicant.service that stops and then restarts. I think that it is not a desiderable behaviour of wpa_supplicant.service, unless it is explicitly stopped by a target. I tried to edit wpa_supplicant.service configuration: 1) I created a wpa_supplicant.service.d directory in /etc/systemd/system 2) I edited a personalized.conf file in it, in which I added the following 2 lines: [Unit] IgnoreOnIsolate=true 3) Then I restarted daemons and reloaded wpa_supplicant.service 4) systemd-delta reports that wpa_supplicant.service has been EXTENDED 5) switching from graphical.target to my personalize.target works fine, Wifi connection is not stopped. 6) errors happens when I switch to rescue.target and then back to graphical or personalized targets: - rescue shell is not closed - gnome3 doesn't load properly (just shows desktop image, but no login window) - I need to force a reboot - I suspect that it is an issue related to DBus (I am not an expert.) Do you think it is possible to fix wpa_supplicant.service ? thanks [...] $ cat /lib/systemd/system/wpa_supplicant.service [Unit] Description=WPA supplicant [Service] Type=dbus BusName=fi.epitest.hostap.WPASupplicant ExecStart=/sbin/wpa_supplicant -u -s -O /run/wpa_supplicant [Install] WantedBy=multi-user.target Alias=dbus-fi.epitest.hostap.WPASupplicant.service These are the full contents of said systemd unit, which looks sensible to me. I guess what happens in your case is not really wpasupplicant restarting, but the frontend driving it triggering the connection reset via DBUS, which could be the case of network-manager interacting with the graphical.target. Are you using network-manager - and if you do, are your wlan connections configured as system connections or user connections, the later are (afaik) bound to your logind console session and may stop (or restart) if you log out. Configuring these as system connections might provide further data points. Alternatively you could test what happens with different frontends for wpasupplicant, in particular the native ifupdown integration - which should be excempt from these problems. As these advanced aspects of systemd customisations are still rather new to me, I would suggest to solicit assistance from the systemd maintainers. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#756582: new syntax error when invoking udevadm test breaks installing/ upgrading
Source: fuse Version: 2.9.3-14 Severity: grave Tags: patch Hi When upgrading (or installing) fuse 2.9.3-13 to 2.9.3-14, the new postinst fails with: Setting up fuse (2.9.3-14) ... dpkg: error processing package fuse (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: fuse E: Sub-process /usr/bin/dpkg returned an error code (1) This is caused by this, change between the afforementioned versions, which is also not mentioned in the package's changelog: --- fuse-2.9.3/debian/fuse.postinst 2014-06-20 08:23:50.0 +0200 +++ fuse-2.9.3/debian/fuse.postinst 2014-07-30 23:01:26.0 +0200 @@ -17,7 +17,7 @@ then if [ -e /dev/fuse ] then - udevadm test -a -p $(udevadm info -q path -n /dev/fuse) /dev/null 21 + udevadm test -e -p $(udevadm info -q path -n /dev/fuse) /dev/null 21 fi fi fi Reverting this to udevadm test -a -p fixes the problem again. Regards Stefan Lippers-Hollmann -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16-rc7-aptosid-amd64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -Nru fuse-2.9.3/debian/fuse.postinst fuse-2.9.3/debian/fuse.postinst --- fuse-2.9.3/debian/fuse.postinst +++ fuse-2.9.3/debian/fuse.postinst @@ -17,7 +17,7 @@ then if [ -e /dev/fuse ] then - udevadm test -e -p $(udevadm info -q path -n /dev/fuse) /dev/null 21 + udevadm test -a -p $(udevadm info -q path -n /dev/fuse) /dev/null 21 fi fi fi signature.asc Description: This is a digitally signed message part.
Bug#756207: postinst requires perl-modules but doesn't depend on it
Package: src:linux Version: 3.14.13-2 Severity: normal linux-image-$KVER's postinst requires perl-modules (use File::stat;), but only perl-base is essential, accordingly the postinst fails in a minimal environment: # cdebootstrap --arch=amd64 --flavour=minimal sid /mnt/ http://ftp.debian.org/debian/ # chroot /mnt/ /bin/bash # apt update # apt install linux-image-3.14-2-amd64 Setting up linux-image-3.14-2-amd64 (3.14.13-2) ... debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline debconf: unable to initialize frontend: Readline debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.) debconf: falling back to frontend: Teletype Can't locate File/stat.pm in @INC (you may need to install the File::stat module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at /var/lib/dpkg/info/linux-image-3.14-2-amd64.postinst line 8. BEGIN failed--compilation aborted at /var/lib/dpkg/info/linux-image-3.14-2-amd64.postinst line 8. dpkg: error processing package linux-image-3.14-2-amd64 (--configure): subprocess installed post-installation script returned error exit status 2 Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#756241: systemd-sysv conflicts with wpasupplicant and ifup ifdown
Control: -1 tags moreinfo Hi As Michael Biebl suggested, a direct involvement of systemd is pretty unlikely (but nothing can ever be called impossible). Likewise there are no specific dependencies or conflicts/ breaks that would force a specific init from wpasupplicant's point of view, it does support- and integrate with all three contenders (well, there is only a very shallow direct integration, at most initiation the DBus interface in case of systemd, the actual configuration or startup sequence of wpasupplicant is not handled by any init system directly, but by the networking dæmons supervising wpasupplicant). In order to debug this further, it would help tremenduously to get an idea about your system state (before the upgrade and now), just as well as your network configuration. The most important data for now would be: - versions of ifupdown before and after the upgrade - versions of wpasupplicant before and after the upgrade - when was your last full (dist-)upgrade, did you try to do partial upgrades to avoid systemd from getting installed (anything relevant held back)? - your /etc/network/interfaces and wpasupplicant configuration, make sure to obfuscate personal information and passwords(!), but retain its structure and syntax. - what exactly is failing, did it work before - any hints in dmesg or when running wpa_cli - systemd (not systemd-sysv) is co-installable to sysvinit-core, accordingly you can switch between systemd as pid1 and sysvinit as pid1 with a simple kernel parameter (init=/lib/systemd/systemd), this can help to determine if sysvinit or systemd really makes a difference in your situation without changing any of the installed packages or modifying any of your configuration files Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#755978: Please support multiple installation targets for gummiboot in RAID environments
Hi On Friday 25 July 2014, Julian Andres Klode wrote: On Fri, Jul 25, 2014 at 04:29:02AM +0200, Stefan Lippers-Hollmann wrote: [...] It would be nice if gummiboot would support installing its EFI loader to multiple EFI system partitions in order to gain failsafe support for RAID setups under UEFI. The attached patch allows (optionally) configuring multiple targets via GUMMIBOOT_EFI. I understand what you're trying to do, but my plan was to drop options, not add some more. To be precise: Upstream only supports a single ESP in both gummiboot and systemd. systemd provides a script called kernel-install for installing kernels. I want to switch to that script. (and that script is really primitive, and only supports configuring the kernel cmdline or reading it from /proc/cmdline). Upstream mounts /boot/efi at /boot, so there's not much chance to get support for multiple ESPs there. I'm not sure what I should do now. I'm not married to any particular implementation (nor even bootloader), my goal is merely to provide fallback bootoptions for UEFI systems in a RAID-like fashion. When booting in BIOS mode (CSM emulation), the situation is rather simple. grub-pc has the option to embed its stage1/ stage1.5 between (MSDOS-) partition table and the start of the first partition (or the BIOS Boot partition/ 0xef02 for GPT respectively) of all installed harddisks (via debconf selection of potential target disks). Accordingly redundancy is provided for both the bootsector (stage 1/ stage 1.5) on each individual disk and the rootfs, /boot/ respectively, on a RAID1 volume. When booting in native UEFI mode, the situation is unfortunately a lot more difficult. - real hardware RAID, this might actually work if the hardware RAID controller completely abstracts its RAID functionality from the UEFI firmware and provides transparent support for UEFI and grub, so that the EFI system partition (0xef00) is actually part of the RAID volume. Lacking a full-hardware RAID controller, I have not tested this. - fake RAID/ BIOS assisted software RAID (e.g. dmraid/ Intel ISW). While the UEFI firmware might, or might not - depending on the actual firmware implementation, recognize an EFI system partition (0xef00), at least wheezy's grub was not able to cope with a sandy-bridge era Intel ISW fake RAID, neither via the ordinary installation means, nor fully manually. - Linux software RAID (mdadm), putting the EFI system partition on top of a mdadm volume is not possible, as no mainboard with UEFI firmware implementation recognizes this as a valid ESP. The only alternative I've seen so far (ignoring the real hardware RAID controller, which both busts the budget and introduce a strong hardware dependency on the controller hardware), is putting a full EFI system partition on each harddisk and the rootfs on RAID1. Given that the UEFI specification allows specifying multiple boot entries and usually manages to fall back transparently, if the primary boot entry is missing, this appears to be a nice workaround. grub-efi unfortunately does not directly support this scenario (at least not the current maintainer scripts in unstable. While it should be possible to add support for this in a similar as in my suggested patch for gummiboot, its maintainer scripts are considerably more complex - although it should still be possible. Another added complexity in case of grub2 is the split between stage1 (or the EFI binary) and the on-disk modules (/boot/grub/), which don't offer any ABI stability, making it essential to keep /boot/grub/ and /boot/efi/EFI/debian/grubx64.efi in perfect sync - which is not possible via a simple hook provided by the local admin and requires full-blown integration into grub-efi-amd64's maintainer scripts instead. Looking at gummiboot, I see several advantages over grub-efi for this particular situation (although it's certainly interesting to make grub2 compatible to the mdadm RAID1 scenario as well): - the maintainer scripts and kernel hooks are simple enough to allow this feature addition easily. - gummiboot essentially only needs a single EFI binary, without the risk of multiple components on multiple disks get out of sync. - in addition to its own native EFI binary at \EFI\gummiboot\gummibootx64.efi, it -optionally- also covers \EFI\Boot\bootx64.efi, which increases robustness quite a bit (of six different mainboard, each from different vendors, only one manages to remember boot entries and -order after a firmware upgrade all others reverted to a blank boot list/ -order; offering a \EFI\Boot\bootx64.efi binary helps a lot in this case; grub-efi does not support this (at least not in its current form in Debian)). - Using vmlinuz and initrd.img as bootloader makes mounting the rootfs from non-standard block devices, like mdadm, a lot easier - actually this would even allow booting from RAID5, RAID6 or even RAID0 or other strangely
Bug#755965: cdebootstrap leaves procfs mounted in the created rootfs after successful operation
Package: cdebootstrap Version: 0.6.2 Severity: minor Hi cdebootstrap 0.6.2 starts to leave procfs mounted in the generated rootfs after successful operations: # cdebootstrap --flavour=minimal sid /mnt/ http://ftp.debian.org/debian/ P: Deconfiguring helper cdebootstrap-helper-apt P: Deconfiguring helper cdebootstrap-helper-makedev P: Writing apt sources.list P: Writing hosts P: Writing resolv.conf # echo $? 0 # grep mnt /proc/mounts proc /mnt/proc proc rw,relatime 0 0 While I'm not 100% sure if this is an intended change of behaviour, it does differ from the previous behaviour in cdebootstrap = 0.6.1. Feel free to close this bugreport if this change is intentional, as d8233dc32be1729aa72d05fddc0fccd1500c3314 almost suggests (please consider to add Vcs-git, Vcs-Browser headers to debian/control). Regards Stefan Lippers-Hollmann -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16-rc6-aptosid-amd64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cdebootstrap depends on: ii debian-archive-keyring 2012.4 ii gpgv1.4.18-2 ii libbz2-1.0 1.0.6-5 ii libc6 2.19-7 ii libdebian-installer-extra4 0.94 ii libdebian-installer40.94 ii liblzma55.1.1alpha+20120614-2 ii wget1.15-1+b1 ii zlib1g 1:1.2.8.dfsg-1 cdebootstrap recommends no packages. cdebootstrap suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part.
Bug#755975: syntax error in /usr/sbin/update-gummiboot
Package: gummiboot Version: 45-2 Severity: minor Hi The current version of update-gummiboot has a small syntax error: if [ -z $GUMMIBOOT_ROOT] ; then GUMMIBOOT_ROOT=$(determine_root) fi the attached patch fixes this by adding the required whitespace to the test condition. Regards Stefan Lippers-Hollmann From 134e456d12a3877839396c5dc9d2648240e6b66b Mon Sep 17 00:00:00 2001 From: Stefan Lippers-Hollmann s@gmx.de Date: Fri, 25 Jul 2014 02:59:13 +0200 Subject: [PATCH 1/2] fix POSIX sh syntax for test Signed-off-by: Stefan Lippers-Hollmann s@gmx.de --- debian/update-gummiboot | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/update-gummiboot b/debian/update-gummiboot index 895dc4b..055742c 100755 --- a/debian/update-gummiboot +++ b/debian/update-gummiboot @@ -59,7 +59,7 @@ if [ -e /etc/default/gummiboot ]; then . /etc/default/gummiboot fi -if [ -z $GUMMIBOOT_ROOT] ; then +if [ -z $GUMMIBOOT_ROOT ] ; then GUMMIBOOT_ROOT=$(determine_root) fi -- 2.0.1 signature.asc Description: This is a digitally signed message part.
Bug#755978: Please support multiple installation targets for gummiboot in RAID environments
Package: gummiboot
Version: 45-2
Severity: wishlist
Tags: patch
It would be nice if gummiboot would support installing its EFI loader
to multiple EFI system partitions in order to gain failsafe support for
RAID setups under UEFI. The attached patch allows (optionally)
configuring multiple targets via GUMMIBOOT_EFI.
# gdisk -l /dev/sda
…
Number Start (sector)End (sector) Size Code Name
12048 616447 300.0 MiB EF00 EFI System
2 61644831457246 14.7 GiBFD00 Linux RAID
# gdisk -l /dev/sdb
…
Number Start (sector)End (sector) Size Code Name
12048 616447 300.0 MiB EF00 EFI System
2 61644831457246 14.7 GiBFD00 Linux RAID
An lvm2 volume group is on /dev/md0 (RAID1 using mdadm).
/etc/fstab:
LABEL=UEFI0 /boot/efi vfatauto,user,rw,quiet,umask=000
1 1
LABEL=UEFI1 /boot/efi1 vfatauto,user,rw,quiet,umask=000
1 1
/dev/vg-efi/debian64/ ext4defaults,relatime,errors=remount-ro
1 1
Installing the patched gummiboot and configuring
/etc/default/gummiboot:
$ grep -v -e ^$ -e ^\# /etc/default/gummiboot
GUMMIBOOT_EFI=/boot/efi /boot/efi1
GUMMIBOOT_ROOT=/dev/mapper/vg--efi-debian64
GUMMIBOOT_OPTIONS=ro quiet systemd.show_status=1
Installing gummiboot to both EFI system partitions:
# gummiboot install --path=/boot/efi
# gummiboot install --path=/boot/efi1
# update-gummiboot
setting up efibootmgr:
# efibootmgr -c -d /dev/sda -p 1 -l /EFI/Boot/Bootx64.efi -L gummiboot-primary
# efibootmgr -c -d /dev/sdb -p 1 -l /EFI/Boot/Bootx64.efi -L
gummiboot-secondary
# efibootmgr -v
BootCurrent:
BootOrder: ,0001
Boot* gummiboot-primary
HD(1,800,96000,a5409805-1336-4a17-8972-4d459592080a)File(\EFI\Boot\Bootx64.efi)
Boot0001* gummiboot-secondary
HD(1,800,96000,ac4d7872-1e4c-4b4d-903d-0037299d15ae)File(\EFI\Boot\Bootx64.efi)
Checking the contents of both configured GUMMIBOOT_EFI locations:
$ find /boot/efi /boot/efi1/ -type f | sort
/boot/efi1/EFI/Boot/bootx64.efi
/boot/efi1/EFI/gummiboot/gummibootx64.efi
/boot/efi1/f2f45aa2a06b475da40dae5565017d7a/3.14-2-amd64/initrd
/boot/efi1/f2f45aa2a06b475da40dae5565017d7a/3.14-2-amd64/linux
/boot/efi1/f2f45aa2a06b475da40dae5565017d7a/3.16-rc6-amd64/initrd
/boot/efi1/f2f45aa2a06b475da40dae5565017d7a/3.16-rc6-amd64/linux
/boot/efi1/loader/entries/f2f45aa2a06b475da40dae5565017d7a-3.14-2-amd64.conf
/boot/efi1/loader/entries/f2f45aa2a06b475da40dae5565017d7a-3.16-rc6-amd64.conf
/boot/efi1/loader/loader.conf
/boot/efi/EFI/Boot/bootx64.efi
/boot/efi/EFI/gummiboot/gummibootx64.efi
/boot/efi/f2f45aa2a06b475da40dae5565017d7a/3.14-2-amd64/initrd
/boot/efi/f2f45aa2a06b475da40dae5565017d7a/3.14-2-amd64/linux
/boot/efi/f2f45aa2a06b475da40dae5565017d7a/3.16-rc6-amd64/initrd
/boot/efi/f2f45aa2a06b475da40dae5565017d7a/3.16-rc6-amd64/linux
/boot/efi/loader/entries/f2f45aa2a06b475da40dae5565017d7a-3.14-2-amd64.conf
/boot/efi/loader/entries/f2f45aa2a06b475da40dae5565017d7a-3.16-rc6-amd64.conf
/boot/efi/loader/loader.conf
Regards
Stefan Lippers-Hollmann
From 0239ea69e443402540613399abfddf8a3100d0f6 Mon Sep 17 00:00:00 2001
From: Stefan Lippers-Hollmann s@gmx.de
Date: Fri, 25 Jul 2014 03:08:11 +0200
Subject: [PATCH 2/2] allow using multiple target locations for $GUMMIBOOT_EFI
This is useful for keeping multiple EFI system partitions in sync,
e.g. for a RAID setup using multiple disks. The EFI system partitions
must not be on the RAID array itself.
With this patch, it's possible to configure this in
/etc/default/gummiboot using this syntax:
GUMMIBOOT_EFI=/boot/efi /boot/efi1
As before, gummiboot and efibootmgr need to be installed manually.
Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
---
debian/gummiboot.postinst | 4 +++-
debian/update-gummiboot | 22 ++
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/debian/gummiboot.postinst b/debian/gummiboot.postinst
index 02fb99e..441837e 100644
--- a/debian/gummiboot.postinst
+++ b/debian/gummiboot.postinst
@@ -12,7 +12,9 @@ if [ $1 = configure -a $2 = ]; then
fi
if [ $1 = configure ]; then
-gummiboot update --path=$GUMMIBOOT_EFI || :
+for GUMMIBOOT_EFI_TARGET in $GUMMIBOOT_EFI; do
+gummiboot update --path=$GUMMIBOOT_EFI_TARGET || :
+done
fi
#DEBHELPER#
diff --git a/debian/update-gummiboot b/debian/update-gummiboot
index 055742c..560c4bc 100755
--- a/debian/update-gummiboot
+++ b/debian/update-gummiboot
@@ -29,14 +29,17 @@ determine_root() {
}
install_kernel() {
-install -D /boot/vmlinuz-$KERNEL $GUMMIBOOT_EFI/$MACHINE_ID/$KERNEL/linux
-if [ -e /boot/initrd.img-$KERNEL ]; then
-install -D /boot/initrd.img-$KERNEL $GUMMIBOOT_EFI/$MACHINE_ID/$KERNEL/initrd
-fi
+for GUMMIBOOT_EFI_TARGET in $GUMMIBOOT_EFI; do
+install -D /boot/vmlinuz-$KERNEL $GUMMIBOOT_EFI_TARGET/$MACHINE_ID/$KERNEL/linux
+if [ -e /boot/initrd.img
Bug#755978: Please support multiple installation targets for gummiboot in RAID environments
Hi
The previously submitted patch missed properly indenting one of the
hunks (I'm more used to using tabs), this uses the proper indentation
levels but is otherwise identical to the previously submitted patch.
This builds upon the patch submitted in #755975 fixing a syntax error
in update-gummiboot, but doesn't depend on it semantically.
Regards
Stefan Lippers-Hollmann
From 0239ea69e443402540613399abfddf8a3100d0f6 Mon Sep 17 00:00:00 2001
From: Stefan Lippers-Hollmann s@gmx.de
Date: Fri, 25 Jul 2014 03:08:11 +0200
Subject: [PATCH 2/2] allow using multiple target locations for $GUMMIBOOT_EFI
This is useful for keeping multiple EFI system partitions in sync,
e.g. for a RAID setup using multiple disks. The EFI system partitions
must not be on the RAID array itself.
With this patch, it's possible to configure this in
/etc/default/gummiboot using this syntax:
GUMMIBOOT_EFI=/boot/efi /boot/efi1
As before, gummiboot and efibootmgr need to be installed manually.
Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
---
debian/gummiboot.postinst | 4 +++-
debian/update-gummiboot | 34 --
2 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/debian/gummiboot.postinst b/debian/gummiboot.postinst
index 02fb99e..441837e 100644
--- a/debian/gummiboot.postinst
+++ b/debian/gummiboot.postinst
@@ -12,7 +12,9 @@ if [ $1 = configure -a $2 = ]; then
fi
if [ $1 = configure ]; then
-gummiboot update --path=$GUMMIBOOT_EFI || :
+for GUMMIBOOT_EFI_TARGET in $GUMMIBOOT_EFI; do
+gummiboot update --path=$GUMMIBOOT_EFI_TARGET || :
+done
fi
#DEBHELPER#
diff --git a/debian/update-gummiboot b/debian/update-gummiboot
index 055742c..65973d0 100755
--- a/debian/update-gummiboot
+++ b/debian/update-gummiboot
@@ -29,29 +29,33 @@ determine_root() {
}
install_kernel() {
-install -D /boot/vmlinuz-$KERNEL $GUMMIBOOT_EFI/$MACHINE_ID/$KERNEL/linux
-if [ -e /boot/initrd.img-$KERNEL ]; then
-install -D /boot/initrd.img-$KERNEL $GUMMIBOOT_EFI/$MACHINE_ID/$KERNEL/initrd
-fi
+for GUMMIBOOT_EFI_TARGET in $GUMMIBOOT_EFI; do
+install -D /boot/vmlinuz-$KERNEL $GUMMIBOOT_EFI_TARGET/$MACHINE_ID/$KERNEL/linux
+if [ -e /boot/initrd.img-$KERNEL ]; then
+install -D /boot/initrd.img-$KERNEL $GUMMIBOOT_EFI_TARGET/$MACHINE_ID/$KERNEL/initrd
+fi
+done
}
install_entry() {
-dir=$GUMMIBOOT_EFI/loader/entries/
-entry=$dir/$MACHINE_ID-$KERNEL.conf
-options=root=$GUMMIBOOT_ROOT $GUMMIBOOT_OPTIONS
+for GUMMIBOOT_EFI_TARGET in $GUMMIBOOT_EFI; do
+dir=$GUMMIBOOT_EFI_TARGET/loader/entries/
+entry=$dir/$MACHINE_ID-$KERNEL.conf
+options=root=$GUMMIBOOT_ROOT $GUMMIBOOT_OPTIONS
-[ -e $dir ] || mkdir -p $dir
+[ -e $dir ] || mkdir -p $dir
-cat $entry EOF
+cat $entry EOF
title $PRETTY_NAME
version $KERNEL
machine-id $MACHINE_ID
options $options
linux /$MACHINE_ID/$KERNEL/linux
EOF
-if [ -e $GUMMIBOOT_EFI/$MACHINE_ID/$KERNEL/initrd ]; then
-echo initrd /$MACHINE_ID/$KERNEL/initrd $entry
-fi
+if [ -e $GUMMIBOOT_EFI_TARGET/$MACHINE_ID/$KERNEL/initrd ]; then
+echo initrd /$MACHINE_ID/$KERNEL/initrd $entry
+fi
+done
}
@@ -77,8 +81,10 @@ do_install() {
do_remove() {
echo Remove $KERNEL from ESP 2
-rm -r $GUMMIBOOT_EFI/$MACHINE_ID/$KERNEL/ || true
-rm $GUMMIBOOT_EFI/loader/entries/$MACHINE_ID-$KERNEL.conf || true
+for GUMMIBOOT_EFI_TARGET in $GUMMIBOOT_EFI; do
+rm -r $GUMMIBOOT_EFI_TARGET/$MACHINE_ID/$KERNEL/ || true
+rm $GUMMIBOOT_EFI_TARGET/loader/entries/$MACHINE_ID-$KERNEL.conf || true
+done
}
if [ -e /boot/vmlinuz-$KERNEL ]; then
--
2.0.1
signature.asc
Description: This is a digitally signed message part.
Bug#718651: wpasupplicant: new upstream release
Hi
On Saturday 19 July 2014, Mert Dirik wrote:
Hi,
First of all I would like to thank you all for the huge effort that went
into packaging the new upstream version,
but hostapd 2.0+ causes some nasty problems that prevent creating access
points. [1] [2]
I am aware that hostapd 2.0 ('hostap_2_0') was broken, however I'm not
aware of any issues with 2.1 or 2.2 (and we're talking about upgrading
to 2.2, not 2.0, here). Your references to [1], and [2] are pretty much
useless, while they specify 2.0 as version, there has no actual
debugging taken place. While [3] and [4] have a bit more meat to it,
both are also referring to 2.0, not anything newer - and both threads
seem to have died off about a year ago. Likewise almost no one mentions
the hardware they're using, which would be an important part of the
equation as well (there is basically no USB device that fully supports
AP mode, except for some EOLed Atheros designs; and even among the PCI/
PCIe chipsets, only Atheros and RaLink can be considered to support
it).
So if you have noticed any issues with hostapd = 2.2, please do speak
up and provide any information you can get (you can build wpa 2.2 from
our packaging svn, if you have problems with that I could also provide
packages of that for internal testing), just stale information for 2.0
is not very helpful as that particular version was known-broken.
Personally I would be very grateful for reports (and/ or help) with the
hostapd component, as I don't use it production myself (well, I do, but
only on embedded devices which are not Debian compatible and use
OpenWrt instead - but I'm also using hostapd v2.2 there, without any
issues) and can only test it in a temporary setup before uploading any
new version.
Sure it does not affect every hostapd user but it downright renders the
package unusable for the ones who are affected. I'm not in a position to
give an advice, I just wanted to inform you about a point which may be
useful while evaluating the pros and cons of shipping Jessie with the
new upstream version.
The wpa 1.x branch has been discontinued, there is upstream support for
it anymore (not that Intel, who had adopted it, actually did an active
job with it in the first place). Accordingly sticking to 1.1 is not an
option for jessie, which will need to be supported for the next ~3-4
years - even if that meant breaking (or removing) hostapd (from
jessie).
I have done some rigorous testing on wpa 2.2 for the last few weeks and
am shortly before pushing for it to be uploaded. While I would like to
get a few things settled before uploading, those equally affect 1.1 and
2.2, so don't necessarily block 2.2 from being uploaded. The wpa
package in jessie will be, needs to be, 2.2, eventually 2.3 (but I
don't believe 2.3 will be released in time before the freeze).
Regards
Stefan Lippers-Hollmann
signature.asc
Description: This is a digitally signed message part.
Bug#753345: wpasupplicant hook for pm-utils breaks pm-suspend when used with wicd
reassign 753345 wicd-daemon notfound 753345 1.1-1 notfound 753345 1.7.0+ds1-5+squeeze3 found 753345 1.7.2.4-4 found 753345 1.7.2.4-4.1 thanks Hi On Monday 30 June 2014, Stefan Lippers-Hollmann wrote: Hi [ CC'ing the wicd maintainers ] On Monday 30 June 2014, fzacaria...@gmail.com wrote: Package: wpasupplicant Version: 1.1-1 Severity: important Dear Maintainer, After installing wicd and wpasupplicant, suspending the computer with pm-suspend stops working. The problem lies in the wicd and wpasupplicant installed hooks for pm-utils colliding. wicd's hook runs first and disconnects my wireless device, causing wpa_supplicant process to stop. Then the wpasupplicant's hook runs and tries to execute the suspend command but the hook fails because wpa_cli can't find the control socket (because it was removed by the previous hook!). Extract from /var/log/pm-suspend.log: --- Running hook /usr/lib/pm-utils/sleep.d/60_wpa_supplicant suspend suspend: Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory /usr/lib/pm-utils/sleep.d/60_wpa_supplicant suspend suspend: Returned exit code 255. Mon Jun 30 20:03:15 CEST 2014: Inhibit found, will not perform suspend Mon Jun 30 20:03:15 CEST 2014: Running hooks for resume --- This can be reproduced every time. I temporarily fixed it by appending exit 0 to wpasupplicant's hook. Better solutions might be: * run this hook before wicd's * verify wpa_supplicant's control socket existance -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') [...] Unless there is a reason to run wicd's pm-utils hook at 55, rather than = 61[1], I'd tend to reassign this bug to wicd. The reason being that wicd is the leaf package here, while changing the order for wpasupplicant might introduce subtile ordering problems with the other frontends that are possible to use with wpasupplicant, like ifupdown, network-manager, networkd (systemd = 209), connman, et al. As indicated above, I consider this (potential) ordering issue to be a bug in wicd rather than wpasupplicant. Especially as changing it in the leaf package, wicd-daemon, can be done without risking regressions in the alternative frontends to wpasupplicant. Given that this has apparently gone unnoticed since the wheezy development cycle and upower probably being the dominant option for suspending, I'd suggest lowering the severity of this bug - but I leave that to the wicd maintainers. [1] according to pm-action(8), the 50-74 range seems to be recommended for these kinds of services. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#753345: [pkg-wpa-devel] Bug#753345: wpasupplicant hook for pm-utils breaks pm-suspend when used with wicd
Hi [ CC'ing the wicd maintainers ] On Monday 30 June 2014, fzacaria...@gmail.com wrote: Package: wpasupplicant Version: 1.1-1 Severity: important Dear Maintainer, After installing wicd and wpasupplicant, suspending the computer with pm-suspend stops working. The problem lies in the wicd and wpasupplicant installed hooks for pm-utils colliding. wicd's hook runs first and disconnects my wireless device, causing wpa_supplicant process to stop. Then the wpasupplicant's hook runs and tries to execute the suspend command but the hook fails because wpa_cli can't find the control socket (because it was removed by the previous hook!). Extract from /var/log/pm-suspend.log: --- Running hook /usr/lib/pm-utils/sleep.d/60_wpa_supplicant suspend suspend: Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory /usr/lib/pm-utils/sleep.d/60_wpa_supplicant suspend suspend: Returned exit code 255. Mon Jun 30 20:03:15 CEST 2014: Inhibit found, will not perform suspend Mon Jun 30 20:03:15 CEST 2014: Running hooks for resume --- This can be reproduced every time. I temporarily fixed it by appending exit 0 to wpasupplicant's hook. Better solutions might be: * run this hook before wicd's * verify wpa_supplicant's control socket existance -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') [...] Unless there is a reason to run wicd's pm-utils hook at 55, rather than = 61[1], I'd tend to reassign this bug to wicd. The reason being that wicd is the leaf package here, while changing the order for wpasupplicant might introduce subtile ordering problems with the other frontends that are possible to use with wpasupplicant, like ifupdown, network-manager, networkd (systemd = 209), connman, et al. Regards Stefan Lippers-Hollmann [1] according to pm-action(8), the 50-74 range seems to be recommended for these kinds of services. signature.asc Description: This is a digitally signed message part.
Bug#718651: Built hostapd/wpasupplicant 2.1 (patch)
Hi On Monday 02 June 2014, Gerald Turner wrote: Stefan Lippers-Hollmann s@gmx.de writes: On Saturday 31 May 2014, Stefan Lippers-Hollmann wrote: On Saturday 31 May 2014, Gerald Turner wrote: Stefan Lippers-Hollmann s@gmx.de writes: On Saturday 31 May 2014, Gerald Turner wrote: [...] Would you like me to spend some time reconstructing a DEP-5 copyright file for 2.1, or would that also be wasted effort? It doesn't make sense to start collecting the copyright information from the 2.1 release, as meanwhile 28 files changed their copyright (new years, typically 2014, added), 24 new files were added + the whole new subdirectory hs20/ (which is fortunately licensed rather uniformly) and with 6 files being completely removed. If we already had this DEP-5 listing for 2.1, it would be reasonable to update it, but when starting from scratch, it only makes sense to start from current upstream HEAD (and then to use git diff hash..hostap_2_2, to fill up the gaps until v2.1 gets tagged. I'm not asking you to spend time on this, as I know far too well how demotivating this is, but I certainly wouldn't say no to a patch either. Just as a hint, I have just[1] updated debian/get-orig-source to work with wpa 2.2~. Using a version number like e.g. 2.1+git20140531.1+147848e-1 then fetches the according upstream tarball. Well, I've done it, and it sure was tedious! Steps: git log --full-diff -p hostapd hs20 patches src wpa_supplicant | \ egrep '(^diff|Copyright)' | \ grep -B1 Copyright | \ ./git-log-full-diff-parse-copyright The Perl script (attached) took a few hours to write - there's a brick of about 60 lines to munge file moves. Then about another hour to inspect all that output, plus poking at each file to make sure that the license change actually occured. I've just finished cross-checking debian/copyright and ended up with the attached diff[1]. A few differences can be attributed to slightly different collation methods, some add copyright information which is hard to parse/ find automatically and some add information that your parser appears to have missed. By the way, I've disabled Hotspot 2.0 support for now, as it appears to require a PHP- and webserver for the server part (hostapd), which would require quite significant packaging changes that would need confirmation (and efforts) of someone who actually intends to use it. Likewise I've disabled SQLITE support for hostapd, while hostapd isn't as size sensitive (nor critical in regards to its FHS location) as wpa_supplicant would be, adding sqlite seems just to optimise managing of the eap_user database, which is also available in a (duplicate) text file format. IMHO this can be left disabled, until anyone actually needs it and presents a use case requiring this functionality. If you did enable those symbols for a specific reason other than them just being there in the new version, please give me a hint. Regards Stefan Lippers-Hollmann [1] http://anonscm.debian.org/viewvc/pkg-wpa/wpa/trunk/debian/copyright?revision=1881view=markup --- /tmp/pkg/copyright 2014-07-01 03:08:02.301296645 +0200 +++ debian/copyright 2014-07-01 03:12:39.995009298 +0200 @@ -7,108 +7,75 @@ Files: * Copyright: 2002-2014, Jouni Malinen j...@w1.fi License: BSD +Files: hostapd/logwatch/* +Copyright: 2005, Henrik Brix Andersen b...@gentoo.org +License: BSD or GPL-2 + Files: hostapd/Android.mk Copyright: 2008, The Android Open Source Project License: BSD -Files: hostapd/logwatch/* -Copyright: 2005, Henrik Brix Andersen b...@gentoo.org -License: BSD or GPL-2 +Files: hostapd/hostapd.8 + hostapd/hostapd_cli.1 +Copyright: 2005, Faidon Liambotis fai...@cube.gr +License: BSD Files: hs20/* Copyright: 2012-2014, Qualcomm Atheros, Inc. License: BSD +Files: patches/* +Copyright: 2005, Alexey Kobozev akobo...@cisco.com + 2005-2012, Jouni Malinen j...@w1.fi +License: BSD + Files: src/ap/acs.* Copyright: 2011, Atheros Communications 2013, Qualcomm Atheros, Inc. License: BSD -Files: src/ap/ap_config.* -Copyright: 2003-2014, Jouni Malinen j...@w1.fi - 2007-2008, Intel Corporation -License: BSD - Files: src/ap/ap_list.* + src/ap/ap_mlme.* + src/ap/beacon.* + src/ap/hw_features.* + src/ap/vlan_init.* + src/ap/wmm.* Copyright: 2002-2009, Jouni Malinen j...@w1.fi - 2003-2004, Instant802 Networks, Inc. - 2006, Devicescape Software, Inc. - 2007-2008, Intel Corporation -License: BSD - -Files: src/ap/ap_mlme.* -Copyright: 2003-2008, Jouni Malinen j...@w1.fi - 2003-2004, Instant802 Networks, Inc. + 2002-2004, Instant802 Networks, Inc. 2005-2006, Devicescape Software, Inc. License: BSD -Files: src/ap/beacon.* -Copyright: 2002-2004, Instant802 Networks, Inc. - 2005-2006, Devicescape Software, Inc. - 2007-2008, Intel Corporation
Bug#718651: Built hostapd/wpasupplicant 2.1 (patch)
Hi
On Thursday 05 June 2014, Raphael Hertzog wrote:
Hi,
On Wed, 04 Jun 2014, Stefan Lippers-Hollmann wrote:
The Perl script (attached) took a few hours to write - there's a brick
of about 60 lines to munge file moves. Then about another hour to
inspect all that output, plus poking at each file to make sure that the
license change actually occured.
Thank you a lot, this really helps. I'll integrate your changes over
the next few days after some further local testing.
I'm glad that this got sorted out but I wanted to point out that
you are actually too demanding of yourself in terms of what to put in
debian/copyright.
You don't have to document the copyright holders of each and every file.
What truly matters is to properly distinguish the different licenses and
the files concerned by each license.
Listing of copyright holders doesn't have to be exhaustive (it's
impossible for big projects) and it's perfectly acceptable to group them
for a set of files that share a common license. See how the linux
packages uses:
Files: *
Copyright: 1991-2012 Linus Torvalds and many others
License: GPL-2
I'm aware of debian/copyright implementations like this and linux is
certainly in a particularly bad situation when it comes to doing a
complete copyright audit (it's all available, but just too exhaustive
to even start documenting it). But not every package gets this carte
blanche.
The better question however would be, if a package like this would be
able to pass NEW[1] (as wpa had to for 1.0-1 - and it will have to pass
through binary-NEW in the not too distant future again). While wpa
certainly has a non-trivial copyright status, recent history has shown
that ftp-master requests complete documentation for debian/copyright
even from much larger/ more complex packages than wpa. Just look at
chromium(-browser) or kfreebsd{9,10,11} for comparison, which were
REJECTed within the last few years, until the missing attributions
were added.
So, does wpa need to have a machine readable debian/copyright,
certainly not, as DEP-5 is just non-binding advice. Would it be easier
to forget about DEP-5 and use a more free-form listing of copyright
attribution? Quite likely yes, but would it be so much easier to make
a significant difference? This answer is less easy to answer, probably
it would be a yes after larger changes/ code movement like this time,
but that's less obvious for more incremental changes like 0.7.x --
1.x where diff(1) or git diff can do most of the job.
The level of difficulty for doing a sufficient documentation for
debian/copyright is less depending on DEP-5's syntax (although a few
changes later in the DEP-5 process certainly led to quite some useless
busy-work - and it's certainly rather verbose), nor is it doing the
mechanical listing (although there is a significant margin of error
regarding false negatives, when contributors get inventive regarding
anti-spam methods). The difficulty is in cleaning up the listings and
collating information into useable chunks, like you mentioned
historical mail addresses for the same copyright holder, collating
files into groups and dealing with unclear attributions or IP takeovers
(like Qualcomm buying Atheros). These issues are independent of the
preferred syntax for debian/copyright - and while it would be easier
to ignore these and just continue with a mechanical listing for version
'n', it's poses more of a problem for version 'n+1' (assuming
incremental, rather than monumental, changes).
Regards
Stefan Lippers-Hollmann
[1] Yes, src:linux has to go through binary-NEW every ~3 months.
signature.asc
Description: This is a digitally signed message part.
Bug#718651: [pkg-wpa-devel] Bug#718651: Bug#718651: Bug#718651: Built hostapd/wpasupplicant 2.1 (patch)
Hi On Thursday 05 June 2014, Gerald Turner wrote: Raphael Hertzog hert...@debian.org writes: On Wed, 04 Jun 2014, Stefan Lippers-Hollmann wrote: [...] Files: * Copyright: 1991-2012 Linus Torvalds and many others License: GPL-2 Thanks Raphael, I was wondering about this. Looks like Jouni Malinen began changing from dual license BSD/GPL-2 to BSD-only in February 2012 and the transition is well documented in the CONTRIBUTIONS file. Very few files remain containing the dual license file header comments: Files: hostapd/logwatch/* Copyright: 2005, Henrik Brix Andersen b...@gentoo.org License: BSD or GPL-2 Files: src/utils/radiotap.c src/utils/radiotap_iter.h Copyright: 2007, Andy Green a...@warmcat.com 2009, Johannes Berg johan...@sipsolutions.net License: BSD or GPL-2 There's also a couple other files: copy of nl80211.h from Linux kernel, some artwork, a spurious Android Makefile. Other than those exceptions, perhaps the following is sufficient as Raphael suggests: Files: * Copyright: 2002-2014, Jouni Malinen j...@w1.fi License: BSD If you look at the existing debian/copyright for wpa 0.7.x-1.x, you'll notice that I've tried to follow this collation order - but it only applies to files where Jouni Malinen is the sole (listed) copyright holder. There rest of the (existing listing) are just the exceptions of the norm, but there are quite a few of those. e.g. (I'm using debian/copyright of wpa 1.1-1 as reference): Files: src/ap/ap_list.* src/ap/ap_mlme.* src/ap/beacon.* src/ap/hw_features.* src/ap/vlan_init.* src/ap/wmm.* Copyright: 2002-2009, Jouni Malinen j...@w1.fi 2002-2004, Instant802 Networks, Inc. 2005-2006, Devicescape Software, Inc. License: BSD or GPL-2 Just listing Instant802 Networks, Inc. and Devicescape Software, Inc. wouldn't be sufficient here, as the exception doesn't inherit the catch-all stanza for Jouni Malinen; it's open to discussion if it could be simplified to: Copyright: 2002-2009, Jouni Malinen j...@w1.fi 2002-2006, Devicescape Software, Inc. though, as Instant802 Networks renamed itself to Devicescape Software in 2005. An oddity I've noticed while scrutinizing over the git history is that one attribution statement in particular, 2007-2008, Intel Corporation, has been deleted from many files. Should debian/copyright care? This is a result of larger code refactoring, the copyright stanzas were'nt just forgotten (I'm only looking at hostap_0_7_0..HEAD, if it happened before, I might have missed it), the code bearing them (hostapd/ap_list.*, hostapd/beacon.*, hostapd/config.*, hostapd/driver_i.*, hostapd/hostapd.h, hostapd/ieee802_11.* and hostapd/sta_info.c) actually went away (in the non git-rename meaning of the word). Also there are a lot of attributions to Atheros Communications and Qualcomm Atheros, Inc., looks like these companies merged and Jouni Malinen works at Qualcomm, further supporting a simplification of debian/copyright. Here you do have to distinguish between the person and the company as copyright holder, which are not equivalent at all. Much of the code attributed to QCA Atheros has not been written/ submitted by Jouni Malinen, but rather different (former-) Atheros employees. Especially in the kernel context, several subsystem maintainers and regular contributors carefully distinguish this difference by either signing off their code submission either with their personal mail address or the corporate one of their current employer. Copies of nl80211.h are a more difficult question though, as its copyright status in the kernel tree is scarcely documented, but also a can of worms if you actually go to the roots of it[1]. Regards Stefan Lippers-Hollmann [1] http://anonscm.debian.org/viewvc/pkg-wpa/iw/trunk/debian/copyright?view=markup#l13 signature.asc Description: This is a digitally signed message part.
Bug#718651: [pkg-wpa-devel] Bug#718651: Bug#718651: Bug#718651: Built hostapd/wpasupplicant 2.1 (patch)
Hi On Monday 02 June 2014, Gerald Turner wrote: Stefan Lippers-Hollmann s@gmx.de writes: On Saturday 31 May 2014, Stefan Lippers-Hollmann wrote: On Saturday 31 May 2014, Gerald Turner wrote: Stefan Lippers-Hollmann s@gmx.de writes: On Saturday 31 May 2014, Gerald Turner wrote: [...] Just as a hint, I have just[1] updated debian/get-orig-source to work with wpa 2.2~. Using a version number like e.g. 2.1+git20140531.1+147848e-1 then fetches the according upstream tarball. Well, I've done it, and it sure was tedious! Steps: git log --full-diff -p hostapd hs20 patches src wpa_supplicant | \ egrep '(^diff|Copyright)' | \ grep -B1 Copyright | \ ./git-log-full-diff-parse-copyright The Perl script (attached) took a few hours to write - there's a brick of about 60 lines to munge file moves. Then about another hour to inspect all that output, plus poking at each file to make sure that the license change actually occured. Thank you a lot, this really helps. I'll integrate your changes over the next few days after some further local testing. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#718651: [pkg-wpa-devel] Bug#718651: Built hostapd/wpasupplicant 2.1 (patch)
Control: tags -1 - patch Hi On Saturday 31 May 2014, Gerald Turner wrote: [...] I paid particular attention to merging upstream's defconfgs and debian/config/* files, activating several options: [...] Thank you for your efforts, but these changes are the straight-forward and easy part. What you've missed in your patch, is the actual difficulty (well, not 'difficult', but extremely time-consuming and tiresome) involved, updating debian/copyright... Upstream relicensed from dual-licensed GPL2 || BSD to 3-clause BSD exclusively[1], due to significant files movements (wpa_supplicant learning more tricks that were usually reserved to hostapd) and quite a few new features from new authors (like WiFi Direct/ p2p) it is not done with a mere s/BSD\ or\ GPL-2/BSD/. Hope to see 2.1 in jessie! No, but the upcoming 2.2, which is currently in its final stages before getting released upstream. Regards Stefan Lippers-Hollmann [1] I have already confirmed that there aren't any hidden licensing problems, but reflecting that in a DEP-5 compliant debian/copyright is everything but funny for any piece of non-trivial amount of code with various authors. signature.asc Description: This is a digitally signed message part.
Bug#718651: [pkg-wpa-devel] Bug#718651: Bug#718651: Built hostapd/wpasupplicant 2.1 (patch)
Hi On Saturday 31 May 2014, Gerald Turner wrote: Stefan Lippers-Hollmann s@gmx.de writes: On Saturday 31 May 2014, Gerald Turner wrote: [...] I paid particular attention to merging upstream's defconfgs and debian/config/* files, activating several options: [...] Thank you for your efforts, but these changes are the straight-forward and easy part. What you've missed in your patch, is the actual difficulty (well, not 'difficult', but extremely time-consuming and tiresome) involved, updating debian/copyright... Upstream relicensed from dual-licensed GPL2 || BSD to 3-clause BSD exclusively[1], due to significant files movements (wpa_supplicant learning more tricks that were usually reserved to hostapd) and quite a few new features from new authors (like WiFi Direct/ p2p) it is not done with a mere s/BSD\ or\ GPL-2/BSD/. Yikes! Last week I had opened that file (first step: where's upstream?) and was horrified by all the attributions in individual files. I suppose this is made worse by upstream having two git repositories (manual work to track file movements). Yes, the project being split into the, now abandoned, git://w1.fi/srv/git/hostap-1.git and git://w1.fi/srv/git/hostap.git repos (with no tags from the 1.x branch in hostap.git) makes the 'natural' way of using git --follow unfortunately impossible - and the large code movements from hostapd/ to common code defeats plain diff (or rather makes it just as difficult as starting from scratch). Likewise the natural approach of splitting the task into small chunks (like 5 files a day) is not really possible, as one needs a fresh memory to collate matching/ overlapping copyright stanzas for several files. In the end it does boil down to pretty much forgetting about the existing debian/copyright (which is (hopefully) 100% correct for wpa 1.1) and starting from scratch again for 2.x. Last time I did that (for 0.7.3, the intermediate steps up to 1.1 were reasonable to update in place), it took most of a full day and left me pretty wasted/ demotivated for a couple of days. Would you like me to spend some time reconstructing a DEP-5 copyright file for 2.1, or would that also be wasted effort? It doesn't make sense to start collecting the copyright information from the 2.1 release, as meanwhile 28 files changed their copyright (new years, typically 2014, added), 24 new files were added + the whole new subdirectory hs20/ (which is fortunately licensed rather uniformly) and with 6 files being completely removed. If we already had this DEP-5 listing for 2.1, it would be reasonable to update it, but when starting from scratch, it only makes sense to start from current upstream HEAD (and then to use git diff hash..hostap_2_2, to fill up the gaps until v2.1 gets tagged. I'm not asking you to spend time on this, as I know far too well how demotivating this is, but I certainly wouldn't say no to a patch either. Right now I'm a little sidetracked with preparing lirc 0.9.1 (which is currently at pre3) for unstable, as it needs quite a few of code changes and upstream fixes before it can be uploaded, but I hope to dive into debian/copyright for wpa just afterwards, hopefully soon. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#718651: [pkg-wpa-devel] Bug#718651: Bug#718651: Built hostapd/wpasupplicant 2.1 (patch)
Hi On Saturday 31 May 2014, Stefan Lippers-Hollmann wrote: On Saturday 31 May 2014, Gerald Turner wrote: Stefan Lippers-Hollmann s@gmx.de writes: On Saturday 31 May 2014, Gerald Turner wrote: [...] Would you like me to spend some time reconstructing a DEP-5 copyright file for 2.1, or would that also be wasted effort? It doesn't make sense to start collecting the copyright information from the 2.1 release, as meanwhile 28 files changed their copyright (new years, typically 2014, added), 24 new files were added + the whole new subdirectory hs20/ (which is fortunately licensed rather uniformly) and with 6 files being completely removed. If we already had this DEP-5 listing for 2.1, it would be reasonable to update it, but when starting from scratch, it only makes sense to start from current upstream HEAD (and then to use git diff hash..hostap_2_2, to fill up the gaps until v2.1 gets tagged. I'm not asking you to spend time on this, as I know far too well how demotivating this is, but I certainly wouldn't say no to a patch either. Just as a hint, I have just[1] updated debian/get-orig-source to work with wpa 2.2~. Using a version number like e.g. 2.1+git20140531.1+147848e-1 then fetches the according upstream tarball. Index: debian/changelog === --- debian/changelog(revision 1866) +++ debian/changelog(working copy) @@ -1,4 +1,4 @@ -wpa (1.1-2) UNRELEASED; urgency=medium +wpa (2.1+git20140531.1+147848e-1) UNRELEASED; urgency=medium * NOT RELEASED YET * drop pre-wheezy /lib/init/rw/sendsigs.omit.d/ migration support, invert the wpa/trunk$ mkdir ../tarballs wpa/trunk$ debian/rules get-orig-source [...] SUCCESS: New upstream tarball has been saved at ../tarballs/wpa_2.1+git20140531.1+147848e.orig.tar.xz wpa/trunk$ See debian/README.source[2] for the finer details. Regards Stefan Lippers-Hollmann [1] svn r1866 of Vcs-Svn: svn://anonscm.debian.org/pkg-wpa/wpa/trunk/ Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-wpa/wpa/trunk/ http://anonscm.debian.org/viewvc/pkg-wpa/wpa/trunk/?view=revisionrevision=1866 [2] http://anonscm.debian.org/viewvc/pkg-wpa/wpa/trunk/debian/README.source?view=markup signature.asc Description: This is a digitally signed message part.
Bug#737939: postinst requires /etc/{passwd, group}, but doesn't depend on base-passwd, breaking cdebootstrap
Hi On Friday 07 February 2014, Santiago Vila wrote: reassign 737939 cdebootstrap thanks On Fri, 7 Feb 2014, Stefan Lippers-Hollmann wrote: [...] Trying to cdebootstrap Debian unstable fails starting with the 2014-01-10 22:01:06[2] dinstall (2014-01-10 16:12:15[1]) is still o.k.) by throwing the following error condition: # cdebootstrap --arch=amd64 --flavour=minimal --debug --verbose sid /mnt/ http://ftp.de.debian.org/debian/ […] O: Setting up libdebconfclient0:amd64 (0.187) ... P: Configuring package libdebconfclient0:amd64 O: Setting up base-files (7.2) ... P: Configuring package base-files D: Updating base-files to status 3 O: chown: invalid user: 'root:root' O: dpkg: error processing package base-files (--configure): O: subprocess installed post-installation script returned error exit status 1 […] O: Processing triggers for libc-bin (2.17-97) ... O: Errors were encountered while processing: O: base-files O: bash D: Status: 256 E: Internal error: install [...] debootstrap explicitly explicitly installs base-passwd and base-files before unpacking the rest of the base system: http://anonscm.debian.org/gitweb/?p=d-i/debootstrap.git;a=blob;f=scripts/sid;h=bf3404f9b869b998a73c82834399ea932f8e8edd;hb=HEAD#l102 [...] x_core_install base-passwd x_core_install base-files [...] Would a similar approach be possible for cdebootstrap as well? Due to the multi-arch enabled base-passwd package, cdebootstrapping Debian unstable is impossible since 2014-01-10 22:01:06, respectively 2014-01-16 for cdebootstrapping testing; not to mention that cdeboostrapping testing/ jessie is impossible since wheezy was released: # cdebootstrap --arch=amd64 --flavour=minimal testing /mnt/ http://ftp.de.debian.org/debian/ P: Retrieving Release P: Retrieving Release.gpg P: Validating Release I: Good signature from Debian Archive Automatic Signing Key (7.0/wheezy) ftpmas...@debian.org P: Parsing Release E: Unknown suite jessie # cdebootstrap --arch=amd64 --flavour=minimal jessie /mnt/ http://ftp.de.debian.org/debian/ E: Unknown suite jessie The later should be fixed by --- a/config/suites +++ b/config/suites @@ -18,6 +18,10 @@ Suite: wheezy Config: generic Keyring: debian-archive-keyring.gpg +Suite: jessie +Config: generic +Keyring: debian-archive-keyring.gpg + Suite: sid Config: generic Keyring: debian-archive-keyring.gpg Untested, due to the afforementioned problem. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#748370: [pkg-wpa-devel] Bug#748370: wpasupplicant: Is wpasupplication supporting auth key type EAP-FAST
Control: tags -1 moreinfo Hi On Friday 16 May 2014, Ritesh Raj Sarraf wrote: Package: wpasupplicant Version: 1.1-1 Severity: normal Dear Maintainers, I get the following error when trying to connect to a wifi network that support EAP FAST. EAP-FAST is enabled in wpa_supplicant's configuration and should work, but off hand I have no way to actually test it against a network using it. wlan0: Trying to associate with b4:14:89:83:57:80 (SSID='corp' freq=2412 MHz) FT: Stored MDIE and FTIE from (Re)Association Response - hexdump(len=0): wlan0: Cancelling scan request wlan0: WPA: clearing own WPA/RSN IE wlan0: Automatic auth_alg selection: 0x1 wlan0: RSN: using IEEE 802.11i/D9.0 wlan0: WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 1 proto 2 wlan0: WPA: clearing AP WPA IE WPA: set AP RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 01 28 00 wlan0: WPA: using GTK CCMP wlan0: WPA: using PTK CCMP wlan0: WPA: using KEY_MGMT 802.1X wlan0: WPA: not using MGMT group cipher WPA: Set own WPA IE default - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 01 00 00 wlan0: No keys have been configured - skip key clearing wlan0: State: SCANNING - ASSOCIATING wpa_driver_wext_set_operstate: operstate 0-0 (DORMANT) netlink: Operstate: linkmode=-1, operstate=5 Limit connection to BSSID b4:14:89:83:57:80 freq=2412 MHz based on scan results (bssid_set=0) wpa_driver_wext_associate wpa_driver_wext_set_drop_unencrypted wpa_driver_wext_set_psk Is there a particular reason why you're using wext as wpa-driver? Modern linux wlan drivers, basically all except staging ones, are mac80211 based and according use cfg80211 and the nl80211 wpa-driver. While the kernel's cfg80211 subsystem has a basic wext compatibility layer, it is considered to be strongly discouraged and has known problems and bugs. If your wlan card is using a mainline (non-staging) driver, you should always prefer nl80211 (which is default, unless specifically overriden in your wpa_supplicant configuration). ioctl[SIOCSIWFREQ]: Device or resource busy wlan0: Association request to the driver failed wlan0: Setting authentication timeout: 5 sec 0 usec EAPOL: External notification - EAP success=0 EAPOL: Supplicant port status: Unauthorized EAPOL: External notification - EAP fail=0 EAPOL: Supplicant port status: Unauthorized EAPOL: External notification - portControl=Auto EAPOL: Supplicant port status: Unauthorized RSN: Ignored PMKID candidate without preauth flag RSN: Ignored PMKID candidate without preauth flag RSN: Ignored PMKID candidate without preauth flag RSN: Ignored PMKID candidate without preauth flag RSN: Ignored PMKID candidate without preauth flag RSN: Ignored PMKID candidate without preauth flag RSN: Ignored PMKID candidate without preauth flag RSN: Ignored PMKID candidate without preauth flag wlan0: Checking for other virtual interfaces sharing same radio (phy0) in event_scan_results RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added WEXT: if_removed already cleared - ignore event Wireless event: cmd=0x8b1a len=16 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added WEXT: if_removed already cleared - ignore event Wireless event: cmd=0x8b06 len=12 RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added WEXT: if_removed already cleared - ignore event Wireless event: cmd=0x8b1a len=20 EAPOL: Supplicant port status: Unauthorized [...] Which wlan card/ driver and kernel version are you using? Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#747921: Please use an explicit section for libavcodec-extra
Package: libavcodec-extra Version: 6:10.1-1 Severity: minor Tags: patch Hi Without an explicit section declaration, libavcodec-extra inherits Section: libs from the source stanza of debian/control and gets flagged as obsolete by tools like deborphan. An alternative is setting another section like metapackages or video explicitly, the attached patch uses metapackages as introduced in Debian Policy 3.9.3. Regards Stefan Lippers-Hollmann -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-3.slh.2-aptosid-amd64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libavcodec-extra depends on: ii libavcodec-extra-55 6:10.1-1 libavcodec-extra recommends no packages. libavcodec-extra suggests no packages. -- no debconf information From 946d34f4af500d8287f485887dd21ddc24292b47 Mon Sep 17 00:00:00 2001 From: Stefan Lippers-Hollmann s@gmx.de Date: Tue, 13 May 2014 00:49:55 +0200 Subject: [PATCH] libavcodec-extra: declare as Section: metapackages Without an explicit section declaration, libavcodec-extra inherits Section: libs from the source stanza of debian/control and gets flagged as obsolete by tools like deborphan. Pick metapackages as introduced in Debian Policy 3.9.3, which is handled specially by apt frontends; an alternative would be video like libav-tools. Signed-off-by: Stefan Lippers-Hollmann s@gmx.de --- debian/control | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/control b/debian/control index 80c9e5a..01363bf 100644 --- a/debian/control +++ b/debian/control @@ -396,6 +396,7 @@ Description: Libav codec library (additional codecs) GPL version 3 or later. Package: libavcodec-extra +Section: metapackages Priority: extra Architecture: all Depends: -- 2.0.0.rc2 signature.asc Description: This is a digitally signed message part.
Bug#746505: [Pkg-lirc-maint] Bug#746505: fix FTBFS on new architectures
Hi On Wednesday 30 April 2014, Breno Leitao wrote: Package: lirc Version: 0.9.0~pre1 Severity: normal Tags: patch User: debian-powe...@lists.debian.org Usertags: ppc64el User: debian-de...@lists.debian.org Usertags: autoreconf Hi, Lirc is curretnly failing to build on new architectures, as ppc64el. In order to enable this package to be built on new architectures, autoreconf needs to be called before the package build. In order to do it, I am providing a patch that follows the instructions at https://wiki.debian.org/qa.debian.org/FTBFS#A2014-01-21_using_dh-autoreconf_during_the_build Thanks for the patch, I was planning to enable autoreconf (following the recent threads on d-devel) anyways, so this patch is very welcome and it will be part of the next lirc upload (which may take 1-2 months to finalize, as there is some renewed upstream activity). Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#745736: RM: isdnutils/1:3.25+dfsg1-3.3 from testing
Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745698: please demote ovmf to Suggests, it's no longer in main
Package: qemu-system-x86 Version: 2.0.0~rc1+dfsg-1exp Severity: serious Hi Since version 0~20121205.edae8d2d-2, ovmf is no longer available in Debian/main, due to a license addendum that makes the embedded FAT driver non-free. qemu-system-x86 however started to recommend this package starting with 2.0.0~rc1+dfsg-1exp, including the current version 2.0.0+dfsg-3. While offering UEFI support for qemu-system-x86 is a nice feature, a package in main must not require or recommend a package outside of main for compilation or execution (Debian Policy §2.2.1[1]). I have chosen serious as bug severity, as this breaks a must-directive of the policy and in order to prevent qemu 2.0~ from migration to testing. This also creates practical problems, as recommends are installed by default and the ovmf dependency is not satisfiable without non-free being available. Suggesting a non-free package however avoids this problem. Regards Stefan Lippers-Hollmann [1] https://www.debian.org/doc/debian-policy/ch-archive.html#s-main signature.asc Description: This is a digitally signed message part.
Bug#744158: [pkg-wpa-devel] Bug#744158: wpasupplicant: Interface cannot associate to SSID
Control: severity -1 minor
Control: tags -1 moreinfo
On Thursday 10 April 2014, Daniele Giglio wrote:
Package: wpasupplicant
Version: 1.1-1
Severity: grave
Justification: renders package unusable
After an updare in the last days my wifi interface cannot associate to my
access point any longer. I have tried to use wpa_cli and I've got the
following
result:
The wpasupplicant package was last updated on february 21st, so unless
you haven't upgraded your system for one and a half month [1], it's
certainly not the wpasupplicant package which broke your ability to
connect to your wireless network. Besides that, grave is a heavily
inflated severity for this problem, unless you have a strong reason to
believe that wpasupplicant is indeed broken for everyone and any
imaginable purpose, not 'just' your own system (I realise that your
problem can be annoying enough, but it's far from grave). As a matter
of fact, wpasupplicant 1.1-1 is working fine on 33, mostly
different[2], wlan cards on up to date unstable systems for me.
3CTRL-EVENT-SCAN-RESULTS
3Trying to associate with 00:0c:f6:a1:ba:98 (SSID='SitecomA1BA98' freq=2462
MHz)
3Association request to the driver failed
This looks like a kernel issue, probably specific to the iwlegacy
driver for iwl3945. But the information you've presented so far isn't
comprehensive enough to make and educated guess.
3Associated with 00:0c:f6:a1:ba:98
3WPA: Key negotiation completed with 00:0c:f6:a1:ba:98 [PTK=CCMP GTK=CCMP]
3CTRL-EVENT-CONNECTED - Connection to 00:0c:f6:a1:ba:98 completed (auth)
[id=0 id_str=wifidhcp]
...and at this point it looks as if it had associated correctly, but
you're omitting eventual dmesg messages and the output of
wpa_cli status here, so we don't know where it fails, at assoc, auth
or further up the stack when requesting an IP address.
my lsmod returns:
iwl394558397 0
iwlegacy 55017 1 iwl3945
mac80211 450945 2 iwl3945,iwlegacy
cfg80211 394809 3 iwl3945,iwlegacy,mac80211
the wifi and firmware installed packages are:
ii firmware-iwlwifi 0.41 all
The firmware is up to date (although there haven't been any updates
for iwl3945 in years), so this is a good sign.
[...]
Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores)
[...]
So kernel 3.13, I'm not aware of any known issues here either.
My gut feeling suggests that this is more likely a problem with your
kernel (although iwlegacy is in deep maintenance mode, so there haven't
been many changes to its code recently) or a problem with your local
infrastructure (access point or wireless interference), but I have way
too little information to venture into reassigning to src:linux for
now.
Please provide further information about your wlan configuration (you
should use nl80211, not wext as driver type for wpa_supplicant; your
report doesn't suggest your setting), the required encryption type
(unencrypted, the various WEP or WPA flavours), your complete dmesg
(at least the debugging information for your wlan card and its
regulatory domain settings) and the output of wpa_cli status and
what debugging information appears when you let wpa_cli running in
interactive mode for a few minutes (e.g. if it goes into an auth/
deauth loop). It would also be tremenduously helpful if you could try
to find out what might have broken your previously working setup, by
checking which packages were installed/ upgraded in comparison to your
last known-working state (/var/log/{apt/,dpkg.log} should help here).
For testing, it probably won't hurt to restart your access point as
well, as these can also freeze or hang.
Regards
Stefan Lippers-Hollmann
[1] and it's in testing for just a few days less
[2] unfortunately none of them using the iwlegacy drivers
signature.asc
Description: This is a digitally signed message part.
Bug#537790: [pkg-wpa-devel] Bug#537790: wpa_supplicant references dynamic libs in /usr/lib; will not run at boot
Hi On Saturday 29 March 2014, Cameron Norman wrote: This bug can be seen in Upstart (#694963), and hangs boot in a NFS mounted /usr, as well as errors the network setup when one uses auto in /etc/network/interfaces. Here is the output of ldd, with the libs in /usr bolded (HTML): [ please avoid HTML Mails, they're very likely to be eaten by antispam measures along their way ] As you see in the bugreport, this is a long standing issue, which is only partially under our control. Actually the situation has been improved significantly during the last release cycle with many of the required libraries moving from /usr/lib/ to /lib/ already. What remains is libssl1.0.0, as libpcsclite can be avoided, but actually working on that (which is a bit problematic on kfreebsd-any) doesn't make sense before the hard-dependency is out of the way (libssl). So yes, wpa_supplicant being in /sbin/ is a bug, done ages ago by previous maintainers of the package. However moving it to /usr/ isn't a solution either, as wpa_supplicant is heavily used in local configuration scripts, which may break hard if wpa_supplicant were to disappear from /sbin/ (and introducing a compatibility symlink from /sbin/wpa_supplicant to /usr/sbin/ wouldn't actually gain you anything in practice, other than papering over the problem). And technically speaking you do want the stuff needed to bring up the network outside of /usr/. That said, trying to mount any remote filesystem over wlan at the kernel level, even more so for vital filesystems just as /usr/, /var/ or /tmp/ would be plainly insane, as you do have to expect interruption with wlan for any real world deployment (which would make your system hang, if vital parts are mounted over wlan). Likewise 'auto' is usually not a good configuration for wireless interfaces either, as -like you mentioned- this does block booting until a connection has been established, which is something you can't guarantee for wlan - not even for a static system. So what are the options to fix this? - the ideal fix for this would be to move libssl into /lib/, which is outside of our domain and depends on the openssl maintainer. Combined with using weak symbols for the libpcsclite dependency[1] (this has been tried already, but failed on kfreebsd-any - although this is fixable given enough attention), this would close the bug once and for all. However anyone mounting /usr/ over a wireless link would still be insane, even if this were possible from the policy side of it. - another approach would be mounting /usr/, along the rootfs, from within the initramfs environment, to the best of my knowledge this has been planned for quite a while already (and should even be possible in experimental, iirc rleigh's efforts correctly). - moving wpa_supplicant from the rootfs into /usr/ would fullfill the letter of the FHS and Debian policy, but wouldn't actually solve this problem at all (combined with a lot of pain in breaking lots of local configuration). Still, doing this would be the easiest option for us to close this bug (so consider me happy to oblige) - but that's not really helping anyone in practice. Whatever we end up with, you won't *ever* be able to depend on wireless links for reliable operations or mounting vital parts of your filesystem tree remotely. It just is, by definition, an unreliable network connection in practice (just about anywhere outside of lab environments). While you may not notice short interruptions for browsing the web (other than some log spam talking about reconnecting), the kernel (and nfsd in particular) doesn't like stalled network connections for mounted remote filesystems at all. Any assumptions relying on stable (and early boot) availability of wireless links are simply flawed, even if the the FHS issues were fixed. Regards Stefan Lippers-Hollmann [1] using weak symbols for libpcsclite would reduce the breakage to wpa_supplicant configurations reading wpa credentials from smartcards, which is a corner-case I'd be willing to risk. signature.asc Description: This is a digitally signed message part.
Bug#537790: [pkg-wpa-devel] Bug#537790: wpa_supplicant references dynamic libs in /usr/lib; will not run at boot
Hi On Saturday 29 March 2014, Cameron Norman wrote: On Sat, Mar 29, 2014 at 2:54 PM, Stefan Lippers-Hollmann s@gmx.de wrote: On Saturday 29 March 2014, Cameron Norman wrote: […] I think another problem with starting wpa_supplicant before the filesystem is up is that it uses /var/run where it should use /run. Do you think you (or somebody else) will be interested in doing that? If so, should I file a new bug? Moving from /var/run/ to /run/ directly has been done in the packaging Vcs already[1] and will be part of the next upload (for wpa 2.1). That said, trying to mount any remote filesystem over wlan at the kernel level, even more so for vital filesystems just as /usr/, /var/ or /tmp/ would be plainly insane, as you do have to expect interruption with wlan for any real world deployment (which would make your system hang, if vital parts are mounted over wlan). Likewise 'auto' is usually not a good configuration for wireless interfaces either, as -like you mentioned- this does block booting until a connection has been established, which is something you can't guarantee for wlan - not even for a static system. I do not think it blocks boot on async systems (at least when NFS is not used) like Upstart or systemd. It does block[2] until the connection is established, which -for wlan- includes associating with the AP and receiving a dhcp lease (if dhcp is in use); I've just confirmed that using wired ethernet with bridges and IPv6 involved a few weeks ago. Not using allow-hotplug for wireless devices is pretty much always a bad idea, especially considering that STA mode doesn't allow bridging (which would be one of the few potential reasons for auto) in the first place. Regards Stefan Lippers-Hollmann [1] http://anonscm.debian.org/viewvc/pkg-wpa?view=revisionrevision=1862 [2] many daemons, enough to considerably affect boot times and boot order signature.asc Description: This is a digitally signed message part.
Bug#742822: file conflict with sysvinit-utils breaks debootstrapping unstable
Package: startpar Version: 0.58-1 Severity: serious Tags: d-i Hi The undeclared file conflict between the new startpar package and sysvinit-utils (2.88dsf-51) breaks debootstrapping: # debootstrap --arch=amd64 --variant=minbase sid /mnt/ http://debianrepo.lan/debian/ [...] W: Failure while unpacking required packages. This will be attempted up to five times. W: See /mnt/debootstrap/debootstrap.log for details (possibly the package archive is at fault) which leads to dpkg: warning: ignoring pre-dependency problem! Preparing to unpack .../sysvinit_2.88dsf-51_amd64.deb ... Unpacking sysvinit (2.88dsf-51) ... Selecting previously unselected package sysvinit-core. Preparing to unpack .../sysvinit-core_2.88dsf-51_amd64.deb ... Unpacking sysvinit-core (2.88dsf-51) ... Selecting previously unselected package sysvinit-utils. Preparing to unpack .../sysvinit-utils_2.88dsf-51_amd64.deb ... Unpacking sysvinit-utils (2.88dsf-51) ... dpkg: error processing archive /var/cache/apt/archives/sysvinit-utils_2.88dsf-51_amd64.deb (--unpack): trying to overwrite '/etc/init/startpar-bridge.conf', which is also in package startpar 0.58-1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) The new startpar package is pulled into the debootstrap run due to being Priority: required, but neither startpart nor the package it aims to replace (sysvinit-utils) know about the file conflict via proper Conflicts/ Replaces. This most likely affects cdebootstrap just as well, although I can't confirm that because of #737939. Regards Stefan Lippers-Hollmann -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-rc8-aptosid-amd64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash signature.asc Description: This is a digitally signed message part.
Bug#655969: lirc: prompting due to modified conffiles which where not modified by the user
Hi On Sunday 23 March 2014, Ben Hutchings wrote: Some time ago you committed: r497 | slh-guest | 2012-02-23 12:20:25 + (Thu, 23 Feb 2012) | 1 line detection stages (Closes: #660956). Index: debian/changelog === --- debian/changelog(revision 496) +++ debian/changelog(revision 497) @@ -88,7 +88,7 @@ lirc 0.7.1pre2-8, previous versions unconditionally started an interactive non-debconf hardware detection/ selection menu, which always left hardware.conf modified; md5sums for prior versions apply to aborted h/w -detection stages. +detection stages (Closes: #660956). -- Stefan Lippers-Hollmann s@gmx.de Sat, 28 Jan 2012 20:03:16 +0100 I think you actually meant to close #655969. Thanks for noticing this, I didn't match up to the bug closure with the correct changelog entry when the bug was filed after the actual change had already been done long before. Given that both bugs will be fixed in the same version, the actual effects would have been limited, but I've fixed it (and removed a duplicate bug closure) in [1]. Anyway, as the postinst in wheezy does not appear to modify the config file, it appears that further upgrades should not have this problem. Given that the bug was tagged squeeze-ignore and wheezy-ignore, perhaps it can now be closed? I certainly won't object against closing this bug, especially as neither squeeze nor wheezy will be changed in this regard anymore (most users actually using lirc, would have needed to adapt their configuration for kernel = 2.6.37 anyways[2], when lirc was merged into the kernel and several modules moved from lirc to RC_CORE). However technically speaking, squeeze is still supported until roughly 2014-05-06 (depending on the actual EOL date to be announced by the stable release team) - and squeeze to wheezy upgrades also remain affected. While technically not correct either, it might make sense to drop its severity below the RC threshold though, to avoid bug squashers from wasting time on this though. On the other hand there will be an upload, with the afforementioned bug closures soon (for some value of 'soon', probably before the middle of the year), which requires some adaptions to these pending changes (in order to provide native systemd units, the sysv initscripts will have to be split into individual initscripts for lirc, lircmd and irexec, so the (to be added) systemd units can mask the corresponding initscripts properly[3]) - and it's best to avoid needless/ forseeable conffile churn until this is settled. Regards Stefan Lippers-Hollmann [1] http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/changelog?r1=517r2=518 [2] https://lists.debian.org/debian-backports/2012/04/msg00076.html [3] lirc's sysv initscripts are working fine under systemd's sysv compatibility mode, but native support needs further changes. signature.asc Description: This is a digitally signed message part.
Bug#741342: /usr/sbin/update-grub: update-grub writes root=UUID= to grub.cfg for LVM2, renders machine unbootable
Control: tags -1 patch
Hi
The bug has been introduced with this upstream commit
commit 588744d0dc655177d5883bdcb8f72ff5160109ed
Author: Vladimir 'phcoder' Serbinenko phco...@gmail.com
Date: Mon Oct 14 18:27:29 2013 +0200
* util/grub-probe.c (probe): Separate different drives in hint-str
by spaces and not newlines.
* util/grub-mkconfig_lib.in: Handle multidevice filesystem.
http://anonscm.debian.org/gitweb/?p=pkg-grub/grub.git;a=commitdiff;h=588744d0dc655177d5883bdcb8f72ff5160109ed
Which makes uses_abstraction() fail to recognize lvm2.
Reverting this commit, as in the rebased attachment, fixes the problem
for me on 10+ systems; this patch could be reduced further to the IFS
changes in uses_abstraction().
Regards
Stefan Lippers-Hollmann
From 8e4f8abcf253a36b6e4e2094fed8d776f787edca Mon Sep 17 00:00:00 2001
From: Stefan Lippers-Hollmann s@gmx.de
Date: Thu, 13 Mar 2014 17:28:17 +0100
Subject: [PATCH] Revert * util/grub-probe.c (probe): Separate
different drives in hint-str
This reverts commit 588744d0dc655177d5883bdcb8f72ff5160109ed, as this
commit breaks the lvm2 detection in uses_abstraction().
---
util/grub-mkconfig_lib.in | 33 ++---
util/grub-probe.c | 5 +
2 files changed, 11 insertions(+), 27 deletions(-)
--- a/util/grub-mkconfig_lib.in
+++ b/util/grub-mkconfig_lib.in
@@ -120,10 +120,7 @@ EOF
prepare_grub_to_access_device ()
{
- old_ifs=$IFS
- IFS='
-'
- partmap=`${grub_probe} --device $@ --target=partmap`
+ partmap=`${grub_probe} --device $@ --target=partmap`
for module in ${partmap} ; do
case ${module} in
netbsd | openbsd)
@@ -150,37 +147,36 @@ prepare_grub_to_access_device ()
esac
# Abstraction modules aren't auto-loaded.
- abstraction=`${grub_probe} --device $@ --target=abstraction`
+ abstraction=`${grub_probe} --device $@ --target=abstraction`
for module in ${abstraction} ; do
echo insmod ${module}
done
- fs=`${grub_probe} --device $@ --target=fs`
+ fs=`${grub_probe} --device $@ --target=fs`
for module in ${fs} ; do
echo insmod ${module}
done
if [ x$GRUB_ENABLE_CRYPTODISK = xy ]; then
- for uuid in `${grub_probe} --device $@ --target=cryptodisk_uuid`; do
+ for uuid in `${grub_probe} --device $@ --target=cryptodisk_uuid`; do
echo cryptomount -u $uuid
done
fi
# If there's a filesystem UUID that GRUB is capable of identifying, use it;
# otherwise set root as per value in device.map.
- fs_hint=`${grub_probe} --device $@ --target=compatibility_hint`
+ fs_hint=`${grub_probe} --device $@ --target=compatibility_hint`
if [ x$fs_hint != x ]; then
echo set root='$fs_hint'
fi
- if fs_uuid=`${grub_probe} --device $@ --target=fs_uuid 2 /dev/null` ; then
-hints=`${grub_probe} --device $@ --target=hints_string 2 /dev/null` || hints=
+ if fs_uuid=`${grub_probe} --device $@ --target=fs_uuid 2 /dev/null` ; then
+hints=`${grub_probe} --device $@ --target=hints_string 2 /dev/null` || hints=
echo if [ x\$feature_platform_search_hint = xy ]; then
echo search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}
echo else
echo search --no-floppy --fs-uuid --set=root ${fs_uuid}
echo fi
fi
- IFS=$old_ifs
if [ x${loop_file} != x ]; then
loop_mountpoint=$(awk ''${loop_file}' ~ ^$2 $2 != / { print $2 }' /proc/mounts | tail -n1)
@@ -193,16 +189,12 @@ prepare_grub_to_access_device ()
grub_get_device_id ()
{
- old_ifs=$IFS
- IFS='
-'
device=$1
- if fs_uuid=`${grub_probe} --device ${device} --target=fs_uuid 2 /dev/null` ; then
+ if fs_uuid=`${grub_probe} --device ${device} --target=fs_uuid 2 /dev/null` ; then
echo $fs_uuid;
else
-echo $device |sed 's, ,_,g'
+echo $device
fi
- IFS=$old_ifs
}
grub_file_is_not_garbage ()
@@ -310,18 +302,13 @@ gettext_printf () {
uses_abstraction () {
device=$1
- old_ifs=$IFS
- IFS='
-'
- abstraction=`${grub_probe} --device ${device} --target=abstraction`
+ abstraction=`${grub_probe} --device ${device} --target=abstraction`
for module in ${abstraction}; do
if test x${module} = x$2; then
- IFS=$old_ifs
return 0
fi
done
- IFS=$old_ifs
return 1
}
--- a/util/grub-probe.c
+++ b/util/grub-probe.c
@@ -479,10 +479,7 @@ probe (const char *path, char **device_n
grub_util_fprint_full_disk_name (stdout, map, dev);
printf (' );
}
- if (curdrive[1])
- printf ( );
- else
- printf (\n);
+ printf (\n);
grub_device_close (dev);
continue;
signature.asc
Description: This is a digitally signed message part.
Bug#741342: /usr/sbin/update-grub: update-grub writes root=UUID= to grub.cfg for LVM2, renders machine unbootable
Hi
While using UUIDs for lvm2 logical volumes works within grub2 itself,
it does blow up in the initramfs integration hooks of lvm2:
http://anonscm.debian.org/viewvc/pkg-lvm/lvm2/trunk/debian/initramfs-tools/lvm2/scripts/local-top/lvm2?view=markup
[line 40ff]
# Make sure that we have a d-m path
dev=${dev#/dev/mapper/}
if [ $dev = $1 ]; then
return 1
fi
so without a root=/dev/mapper/[...] definition for the rootfs, the
default provider of linux-initramfs-tool in Debian never even tries
to assemble the volume groups that make up the rootfs. Out of curiosity
I rigged that particular regexp to be always false, but lvm2 didn't
manage to find a rootfs on a logical volume then either (complaining
that UUIDs were not valid for logical volumes).
Accordingly there would be several changes and versioned dependencies
(Breaks) needed to the lvm2 initramfs-tools hooks, before using
anything but /dev/mapper/... rootfs definitions might be viable for
grub2.
Regards
Stefan Lippers-Hollmann
signature.asc
Description: This is a digitally signed message part.
Bug#740490: [Pkg-lirc-maint] Bug#740490: Change hardware.conf defaults
Hi On Sunday 02 March 2014, Marc MAURICE wrote: [...] I suggest the following patch for hardware.conf: This has already changed significantly in the packaging Vcs, to the extent that the next uploaded won't have a hardware.conf (in favour of /etc/default/grub[1], pending automated migration support) anymore. --- /tmp/hardware.conf2014-03-02 10:52:28.229878749 + +++ /etc/lirc/hardware.conf 2014-03-02 10:55:30.005150849 + @@ -12,10 +12,12 @@ #Try to load appropriate kernel modules LOAD_MODULES=true +# You can set a driver here if your device is not supported by the lirc kernel modules # Run lircd --driver=help for a list of supported drivers. -DRIVER=UNCONFIGURED +#DRIVER=UNCONFIGURED + According to the current package in the archive, changing this would introduce a bug, as UNCONFIGURED has a special meaning to the initscript and the maintainer scripts. Even if you would rely on it falling back to the default driver, using #DRIVER=UNCONFIGURED however would document a wrong default. # usually /dev/lirc0 is the correct setting for systems using udev -DEVICE= +DEVICE=/dev/lirc0 MODULES= This can be done (and actually has been rectified in the packaging Vcs already), but it's not necessary as /dev/lirc0 is only one of several possible options - in the light of modern RC_CORE based drivers not even necessarily the most common one. # Default configuration files for your hardware if any This way: * We document the fact that setting the DRIVER is not mandatory. DRIVER is mandatory, there are 'default' == 'devinput' vs. several userspace drivers, falling back to 'default' however does make sense (and is already done in the packaging Vcs). Supported drivers: accent alsa_usb asusdh atilibusb atwf83 audio_alsa awlibusb bte bw6130 commandir creative creative_infracd default devinput dfclibusb dsp dvico ea65 ftdi i2cuser irlink livedrive_midi livedrive_seq logitech macmini mp3anywhere mplay mplay2 mouseremote mouseremote_ps2 null pcmak pinsys pixelview samsung sb0540 silitek srm7500libusb tira tira_raw udp uirt2 uirt2_raw usb_uirt_raw usbx * lircd will work by default for all devices supported by kernel drivers It still needs a valid /etc/lirc/lircd.conf and the dæmon won't start without it being present (falling back to /usr/share/lirc/remotes/devinput/lircd.conf.devinput is not impossible, but might be harder to implement with systemd). * to my knowledge /dev/lirc0 is the right device name used by kernel drivers. Otherwise lircd default /dev/lirc is used. This depends, /dev/lirc0 is only default for the lirc protocol, however not for the various IR protocols (e.g. rc-5, nec, rc-6, etc.) which are the default setting for the various RC_CORE based kernel drivers (the lirc protocol needs to be chosen explicitly). I also filed an lircd issue upstream to ask to change the default /dev/lirc to /dev/lirc0: https://sourceforge.net/apps/mantisbt/lirc/view.php?id=2 [...] This has been changed upstream, unreleased/ after 0.9.0, as well commit d0175df5cd2ac4a261332ea21a67179f2c85072c Author: Jarod Wilson ja...@redhat.com Date: Fri Dec 2 14:10:21 2011 -0500 userspace: use /dev/lirc0 as default device The lirc_dev kernel driver results in a first lirc chardev of /dev/lirc0, not /dev/lirc, so lets default to that now. The old way is from pre-udev days or something, I think... While we're at it, update the adjacent comment about the daemon socket locations to reflect current reality too. Signed-off-by: Jarod Wilson ja...@redhat.com At the moment, I haven't decided yet between leaving this bug open (and closing it with the next package upload) or closing it now, as your (mostly valid) suggestions don't apply (at least not as explained here) to the current package in the archive. Regards Stefan Lippers-Hollmann [1] http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/lirc.default?view=markup signature.asc Description: This is a digitally signed message part.
Bug#700870: [pkg-wpa-devel] Bug#700870: building eapol_test
Hi
On Monday 18 February 2013, Matthew Newton wrote:
[...]
The wpa_supplicant package contains a really useful tool,
eapol_test. It is not currently packaged, and it would be great if
this could be. Use of this, for example, often comes up on the
FreeRADIUS mailing list for RADIUS administrators to test their
EAP configuration.
It's fairly easy to build from source, but our use case has it
installed on all our RADIUS servers for system monitoring. In this
case, having it packaged would make things much easier to deploy
and maintain.
It doesn't build by default, and is generally only of interest to
administrators, so probably is not worth putting in the
wpasupplicant package, although that would be an option.
I've created two small patches to the build system (for
squeeze/0.6.10-2.1 and unstable/1.0-3) that build eapol_test and
create a new 'eapoltest' package.
Please would you consider adding this?
[...]
At the moment, as of wpa_supplicant 1.1, this causes too many build
problems, e.g. right now (after fixing the first one), I'm at:
cc -c -o ../src/rsn_supp/wpa_ie.o -g -O2 -fPIE -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -MMD -Wall
-D_FORTIFY_SOURCE=2 -I../src -I../src/utils -Werror -DEAPOL_TEST
-DCONFIG_BACKEND_FILE -DCONFIG_IEEE80211W -DCONFIG_IEEE80211R -DCONFIG_PEERKEY
-DCONFIG_IBSS_RSN -DCONFIG_P2P -DCONFIG_INTERWORKING -DCONFIG_DRIVER_WIRED
-DCONFIG_DRIVER_NL80211 -DCONFIG_LIBNL20 `pkg-config --cflags libnl-3.0`
-DCONFIG_DRIVER_NONE -DCONFIG_DRIVER_WEXT -DCONFIG_WIRELESS_EXTENSION
-DEAP_TLS -DEAP_PEAP -DEAP_TTLS -DEAP_MD5 -DEAP_MSCHAPv2 -DEAP_GTC -DEAP_OTP
-DEAP_SIM -DEAP_LEAP -DEAP_PSK -DEAP_AKA -DEAP_AKA_PRIME -DEAP_FAST -DEAP_PAX
-DEAP_SAKE -DEAP_GPSK -DEAP_GPSK_SHA256 -DEAP_PWD -DCONFIG_WPS2 -DCONFIG_WPS
-DEAP_WSC -DCONFIG_WPS_ER -DCONFIG_WPS_UPNP -DCONFIG_WPS_REG_DISABLE_OPEN
-DEAP_IKEV2 -DEAP_TNC -DIEEE8021X_EAPOL -DCONFIG_AP -DCONFIG_NO_RADIUS
-DCONFIG_NO_ACCOUNTING -DCONFIG_NO_VLAN -DEAP_SERVER -DEAP_SERVER_IDENTITY
-DCONFIG_IEEE80211N -DNEED_AP_MLME -DEAP_SERVER_WSC -DCONFIG_NO_RADIUS
-DPCSC_FUNCS -I/usr/include/PCSC -DPKCS12_FUNCS -DCONFIG_SMARTCARD
-DCONFIG_TLSV11 -DEAP_TLS_OPENSSL -DCONFIG_SHA256 -DALL_DH_GROUPS
-DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DCONFIG_CTRL_IFACE_DBUS
-DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/dbus-1.0
-I/usr/lib/i386-linux-gnu/dbus-1.0/include -DCONFIG_CTRL_IFACE_DBUS_NEW
-DCONFIG_CTRL_IFACE_DBUS_INTRO -I/usr/include/dbus-1.0
-I/usr/lib/i386-linux-gnu/dbus-1.0/include -DCONFIG_DBUS -DCONFIG_SME
-DCONFIG_DEBUG_SYSLOG -DLOG_HOSTAPD=LOG_DAEMON -DCONFIG_DEBUG_FILE
-DCONFIG_DELAYED_MIC_ERROR_REPORT -DCONFIG_BGSCAN_SIMPLE -DCONFIG_BGSCAN
-DCONFIG_GAS -DCONFIG_OFFCHANNEL ../src/rsn_supp/wpa_ie.c
../src/utils/wpa_debug.c: In function '_wpa_hexdump':
../src/utils/wpa_debug.c:196:10: error: format '%lu' expects argument of type
'long unsigned int', but argument 4 has type 'size_t' [-Werror=format=]
title, len, display);
with CONFIG_EAPOL_TEST=y enabled, another problem is the missing
manpage for the eapoltest binary. The number of (trivial) build
problems however indicates that this build target is barely tested
upstream.
I will revisit this once we've switched to wpa 2.1 (very soon), but
won't make any promises yet; an updated and slightly fixed variant of
your patch is attached.
Regards
Stefan Lippers-Hollmann
Index: debian/config/wpasupplicant/kfreebsd
===
--- debian/config/wpasupplicant/kfreebsd (revision 1858)
+++ debian/config/wpasupplicant/kfreebsd (working copy)
@@ -223,7 +223,7 @@
CONFIG_PCSC=y
# Development testing
-#CONFIG_EAPOL_TEST=y
+CONFIG_EAPOL_TEST=y
# Select control interface backend for external programs, e.g, wpa_cli:
# unix = UNIX domain sockets (default for Linux/*BSD)
Index: debian/config/wpasupplicant/linux
===
--- debian/config/wpasupplicant/linux (revision 1858)
+++ debian/config/wpasupplicant/linux (working copy)
@@ -222,7 +222,7 @@
CONFIG_PCSC=y
# Development testing
-#CONFIG_EAPOL_TEST=y
+CONFIG_EAPOL_TEST=y
# Select control interface backend for external programs, e.g, wpa_cli:
# unix = UNIX domain sockets (default for Linux/*BSD)
Index: debian/control
===
--- debian/control (revision 1858)
+++ debian/control (working copy)
@@ -96,3 +96,12 @@
association with IEEE 802.11i networks.
.
This is a udeb of wpasupplicant for use by the debian-installer.
+
+Package: eapoltest
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: EAPoL testing utility
+ eapol_test allows testing EAP authentication methods without using
+ a full 802.1X connection. It is frequently used to test the EAP
+ configuration of RADIUS systems. It is an administrator tool and not
+ required for standard 802.1X
Bug#737939: postinst requires /etc/{passwd, group}, but doesn't depend on base-passwd, breaking cdebootstrap
Package: base-files Version: 7.2 Severity: important Tags: patch X-Debbugs-Cc: Bastian Blank wa...@debian.org, Debian Install System Team debian-b...@lists.debian.org, Colin Watson cjwat...@debian.org Hi [ CC'ing the maintainers of the other involved packages, cdebootstrap, base-passwd and cdebconf/ libdebconfclient0 ] Trying to cdebootstrap Debian unstable fails starting with the 2014-01-10 22:01:06[2] dinstall (2014-01-10 16:12:15[1]) is still o.k.) by throwing the following error condition: # cdebootstrap --arch=amd64 --flavour=minimal --debug --verbose sid /mnt/ http://ftp.de.debian.org/debian/ […] O: Setting up libdebconfclient0:amd64 (0.187) ... P: Configuring package libdebconfclient0:amd64 O: Setting up base-files (7.2) ... P: Configuring package base-files D: Updating base-files to status 3 O: chown: invalid user: 'root:root' O: dpkg: error processing package base-files (--configure): O: subprocess installed post-installation script returned error exit status 1 […] O: Processing triggers for libc-bin (2.17-97) ... O: Errors were encountered while processing: O: base-files O: bash D: Status: 256 E: Internal error: install The cause for this appears to be a subtile change of the implicit package configuration order under cdebootstrap, triggered by libdebconfclient0 gaining multi-arch qualifiers with 0.186 -- 0.187. This results in base-passwd now being configured after base-files, while base-files already depends on /etc/passwd and /etc/group from its postinst: --- 20140110T161215Z +++ 20140110T220106Z @@ -245,7 +245,7 @@ P: Unpacking package tar P: Unpacking package libtinfo5:amd64 P: Unpacking package mawk P: Unpacking package base-files -P: Unpacking package libdebconfclient0 +P: Unpacking package libdebconfclient0:amd64 P: Unpacking package base-passwd P: Unpacking package sensible-utils P: Unpacking package debianutils @@ -309,8 +309,6 @@ P: Configuring package debianutils P: Configuring package bsdutils P: Configuring package perl-base P: Configuring package diffutils -P: Configuring package libdebconfclient0 -P: Configuring package base-passwd P: Configuring package mawk P: Configuring package hostname P: Configuring package findutils @@ -324,9 +322,11 @@ P: Configuring package libsepol1:amd64 P: Configuring package tzdata P: Configuring package zlib1g:amd64 P: Configuring package libgcc1:amd64 +P: Configuring package libdebconfclient0:amd64 P: Configuring package base-files P: Configuring package libattr1:amd64 P: Configuring package e2fslibs:amd64 +P: Configuring package base-passwd P: Configuring package libcomerr2:amd64 P: Configuring package libacl1:amd64 P: Configuring package libslang2:amd64 I think this should be solvable by declaring a dependency on base-passwd to base-files, so base-passwd gets configured before base-files' postinst tries to use chown: diff -Nrup a/debian/control b/debian/control --- a/debian/control +++ b/debian/control @@ -8,6 +8,7 @@ Package: base-files Provides: base Architecture: any Pre-Depends: awk +Depends: base-passwd Essential: yes Priority: required Replaces: base, miscutils, dpkg (= 1.15.0) Given that this cdebootstrap breakage affects the first bootstrap phase, I have not been able to actually test this patch, but I hope it fixes the problem. Regards Stefan Lippers-Hollmann [1] http://snapshot.debian.org/archive/debian/20140110T161215Z/debian/ [ok] [2] http://snapshot.debian.org/archive/debian/20140110T220106Z/debian/ [broken] signature.asc Description: This is a digitally signed message part.
Bug#737109: [pkg-wpa-devel] Bug#737109: hostapd: Bridged interface dropped from bridge
Hi On Thursday 30 January 2014, Mark Hindley wrote: [...] I am using hostapd in a bridged wlan/eth setup. The wifi card is 00:08.0 Ethernet controller: Atheros Communications Inc. AR5212/AR5213 Wireless Network Adapter (rev 01) [...] When using hostapd/stable, clients using the wlan are sometimes suddenly unable to communicate through the bridge and wlan0 is no longer present in the output of brctl show br0. At the same time syslog shows: /var/log/syslog.2.gz:Jan 19 11:31:07 titan kernel: device wlan0.sta1 entered promiscuous mode /var/log/syslog.2.gz:Jan 19 11:31:07 titan kernel: br0: port 3(wlan0.sta1) entering forwarding state /var/log/syslog.2.gz:Jan 19 11:31:07 titan kernel: br0: port 3(wlan0.sta1) entering forwarding state /var/log/syslog.2.gz:Jan 19 11:31:11 titan ntpd[3468]: Listen normally on 19 wlan0.sta1 fe80::20f:3dff:feaa:96f0 UDP 123 /var/log/syslog.2.gz:Jan 19 11:31:18 titan kernel: wlan0.sta1: no IPv6 routers present /var/log/syslog.2.gz:Jan 19 11:31:22 titan kernel: br0: port 3(wlan0.sta1) entering forwarding state /var/log/syslog.2.gz:Jan 19 11:31:22 titan kernel: device wlan0.sta1 left promiscuous mode /var/log/syslog.2.gz:Jan 19 11:31:22 titan kernel: br0: port 3(wlan0.sta1) entering disabled state /var/log/syslog.2.gz:Jan 19 11:31:24 titan ntpd[3468]: Deleting interface #19 wlan0.sta1, fe80::20f:3dff:feaa:96f0#123, interface stats: received=0, sent=0, dropped=0, active_time=13 secs Wireless traffic across the bridge can be restored by adding wlan0 back to the bridge with brctl addif br0 wlan0 There is a similar ticket in the OpenWRT lists at https://dev.openwrt.org/ticket/9257 Their fix is https://dev.openwrt.org/changeset/26724 I have rebuilt hostapd with an updated version of the same patch and it also seems to fix the problem for me. Perhaps you would consider including it? My patch below. The only change I made to the OpenWRT version was to reflect the move of drv-ioctl_sock to drv-global-ioctl_sock and to refresh the line numbers. [...] Thanks a lot for investigating this so well and providing a patch, which seems to have gotten decent testing and looks to be pretty straight forward. However I'm concerned that this particular patch appears to be around three years old, without having been merged into hostapd upstream, despite the patch author usually being quite active in upstream development[1] of these wireless needs... Given that the old bugtracker at w1.fi no longer exists, I can't confirm at the moment if this patch had been submitted upstream and/ or if it has been rejected for any reasons, which makes me a bit reluctant to apply it to Debian. So far I haven't come to a conclusion yet and while this patch might not be part of the very next wpa upload, I'll keep it in mind. Regards Stefan Lippers-Hollmann [1] I'm aware that OpenWrt is probably the only party actively working on 4addr support signature.asc Description: This is a digitally signed message part.
Bug#735155: postinst creates rogue /0755 directory in the rootfs
Package: emacsen-common Version: 2.0.6 Severity: serious Tags: patch Justification: Policy 9.1.1 Hi emacsen-common 2.0.6 creates a rogue /0755 directory in the rootfs, instead of just using the according create mode. --- a/debian/postinst +++ b/debian/postinst @@ -17,6 +17,6 @@ fi #DEBHELPER# -mkdir -p 0755 /var/lib/emacsen-common/state/package/installed +mkdir -p -m 0755 /var/lib/emacsen-common/state/package/installed touch /var/lib/emacsen-common/state/package/installed/emacsen-common /usr/lib/emacsen-common/emacs-package-install --postinst emacsen-common -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-7.slh.1-aptosid-amd64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#678147: [pkg-wpa-devel] Bug#678147: Bug#678147: wpasupplicant: Consider enabling IBSS RSN support
Hi On Thursday 05 December 2013, Nat Meysenburg wrote: Hi folks, Would it be possible to apply the changes from r1787 to the 1.0-3 source so that this feature can make it into sid before all the new stuff from 1.1? I have been using this change for a couple of months now, on different hardware, and haven't observed any odd behavior. It is well supported upstream, and works in several non-Debian environments that I've tried. As always, I'm happy to test and patch, and would really love to see this hit sid. There is not technical reason not to use it with 1.0, but there definately won't be a 1.0-? upload anymore - and given that 1.1 is rather stale/ not actually fixing anything important relative to 1.0 (this would be different if we had enabled WiFi direct support, but it's disabled in 1.0-3), it's very, very unlikely that 1.1 will be uploaded to Debian either. While the 2.0 upstream release is broken, we hope to upload 2.1 soon(ish) - or a snapshot from the 2.x branch, if unavoidable. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#728647: missing dependencies on ifupdown and net-tools
Package: pppoeconf
Version: 1.20
Severity: serious
Tags: patch
Hi
pppoeconf depends on ifupdown and net-tools (ifconfig) without
declaring an explicit dependency on either of these packages. Due to
ifupdown having switched its own reliance on net-tools to iproute2,
new jessie installs are particularly prone to this problem, as ifconfig
is no longer guaranteed to be available.
Rather than just declaring net-tools as a dependency, I've ported
pppoeconf to use iproute2 instead, thereby following ifupdown and
reducing the dependency chain as a whole. Existing configurations will
not be migrated to iproute2 automatically, as doing so would be a
policy violation, but existing -upgraded- installations should still
have net-tools/ ifconfig available (and pppoeconf will adapt it when
reconfiguring an interface).
I'll follow up this bug with a, tested, 2-patch patch series (which
also fixes the newly introduced i18n changes), once I receive the bug
number, but the changes are basically these:
*** Please apply the two patches mailed as follow-up to this bug, ***
*** rather than this patch which is only meant for demonstrating ***
*** the changes ***
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Standards-Version: 3.9.2
Package: pppoeconf
Architecture: all
-Depends: ${misc:Depends}, whiptail-provider | whiptail, ppp (=
2.4.2+20040428-2) | pppoe (= 3.0), ppp (= 2.4.1.uus2-4), gettext-base (=
0.13), sed (= 3.95)
+Depends: ${misc:Depends}, whiptail-provider | whiptail, ppp (=
2.4.2+20040428-2) | pppoe (= 3.0), ppp (= 2.4.1.uus2-4), gettext-base (=
0.13), sed (= 3.95), ifupdown (= 0.7.44~), iproute2
Recommends: locales
Suggests: xdialog
Description: configures PPPoE/ADSL connections
--- a/pppoeconf
+++ b/pppoeconf
@@ -101,7 +101,7 @@ if test $* ; then
list=$*
force_manual=1
else
- list=$( LANG=C /sbin/ifconfig -a | grep Ethernet | grep -v irlan | cut
-f1 -d )
+ list=$( LANG=C /bin/ip -f link -o addr list | awk
'/^[0-9]*\:.*link\/ether/{print $2}' | grep -v irlan | cut -f1 -d: )
fi
if test $list ; then
@@ -189,7 +189,7 @@ Webnetix:
fi
touch $TMP/pppoe.scan
-ifconfig $iface up
+ip link set $iface up
($DISCOVERY_PROGRAM $mmm -A -I $iface $TMP/$iface.pppoe ; rm
$TMP/pppoe.scan)
( time=0 ; while test -f $TMP/pppoe.scan ; do time=`expr $time +
6`; echo $time; sleep 1; done ) | $DIALOG --title $title --gauge $text
$mmode 10 60 0
@@ -253,9 +253,12 @@ Continue with configuration?')
# interface activation code - this sucks here, pppd plugin should do
it as needed
#sed -i -e s,pre-up
/sbin/ifconfig[[:space:]]\+[^[:space:]]\+[[:space:]]\+up.#.line.maintained.by.pppoeconf,pre-up
/sbin/ifconfig $ifacenocomma up # line maintained by pppoeconf, $INTFILE
# FIXME: Make sure that it gets added to correct iface stanza! (Because
it's not always added above)
-PATTERN_PREUP_IFACE=pre-up
/sbin/ifconfig[[:space:]]\+[^[:space:]]\+[[:space:]]\+up.#.line.maintained.by.pppoeconf
-REPLACE_PREUP_IFACE=pre-up /sbin/ifconfig $ifacenocomma up # line
maintained by pppoeconf
-if grep -q $PATTERN_PREUP_IFACE $INTFILE; then
+PATTERN_PREUP_IFACE_LEGACY=pre-up
/sbin/ifconfig[[:space:]]\+[^[:space:]]\+[[:space:]]\+up.#.line.maintained.by.pppoeconf
+PATTERN_PREUP_IFACE=pre-up /bin/ip link
set[[:space:]]\+[^[:space:]]\+[[:space:]]\+up.#.line.maintained.by.pppoeconf
+REPLACE_PREUP_IFACE=pre-up /bin/ip link set $ifacenocomma up # line
maintained by pppoeconf
+if grep -q $PATTERN_PREUP_IFACE_LEGACY $INTFILE; then
+sed -i -e s,$PATTERN_PREUP_IFACE_LEGACY,$REPLACE_PREUP_IFACE,
$INTFILE
+elif grep -q $PATTERN_PREUP_IFACE $INTFILE; then
sed -i -e s,$PATTERN_PREUP_IFACE,$REPLACE_PREUP_IFACE, $INTFILE
else
sed -i -e s,[^#]*\(iface dsl-provider.*\),\1\n$REPLACE_PREUP_IFACE,
$INTFILE
@@ -461,7 +464,7 @@ Note that this situation is not expected and you should
consider submitting a bu
cd /
pon dsl-provider
title=$(gettext 'CONNECTION INITIATED')
- text=$(gettext 'The DSL connection has been triggered. You can use the
plog command to see the status or ifconfig ppp0 for general interface
info.')
+ text=$(gettext 'The DSL connection has been triggered. You can use the
plog command to see the status or ip addr show ppp0 for general interface
info.')
$DIALOG --title $title --clear --msgbox $text 10 60
;;
1)
*** Please apply the two patches mailed as follow-up to this bug, ***
*** rather than this patch which is only meant for demonstrating ***
*** the changes ***
Regards
Stefan Lippers-Hollmann
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.11-6.slh.3-aptosid-amd64 (SMP w/8 CPU
Bug#728647: [PATCH 1/2] add missing package dependencies on ifupdown and net-tools.
---
debian/changelog | 6 ++
debian/control | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index d4c3578..28cc385 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+pppoeconf (1.21) UNRELEASED; urgency=low
+
+ * add missing package dependencies on ifupdown and net-tools.
+
+ -- Stefan Lippers-Hollmann s@gmx.de Sun, 03 Nov 2013 16:23:07 +0100
+
pppoeconf (1.20) unstable; urgency=low
* Fix pppoeconf.desktop (Closes: #590202)
diff --git a/debian/control b/debian/control
index 85e5d84..cc99e6c 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Standards-Version: 3.9.2
Package: pppoeconf
Architecture: all
-Depends: ${misc:Depends}, whiptail-provider | whiptail, ppp (=
2.4.2+20040428-2) | pppoe (= 3.0), ppp (= 2.4.1.uus2-4), gettext-base (=
0.13), sed (= 3.95)
+Depends: ${misc:Depends}, whiptail-provider | whiptail, ppp (=
2.4.2+20040428-2) | pppoe (= 3.0), ppp (= 2.4.1.uus2-4), gettext-base (=
0.13), sed (= 3.95), ifupdown, net-tools
Recommends: locales
Suggests: xdialog
Description: configures PPPoE/ADSL connections
--
1.8.4.2
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
