Bug#896251: Bug #896251 in python-changelog marked as pending

[andrew . shadura]

Control: tag -1 pending

Hello,

Bug #896251 in python-changelog reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/python-team/modules/python-changelog/commit/46f9873ea3eafa53c69e13f17e0228c0ea543a01


Build-depend on sphinx, don't use compat code

Closes: #896251



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/896251

Bug#862899: rsync: insufficient escaping/quoting of arguments

[Andrew Shadura]

Control: severity -1 normal

On Thu, 18 May 2017 13:16:23 +0200 Thorsten Glaser  wrote:
> Package: rsync
> Version: 3.1.2-2
> Severity: serious
> Tags: security upstream
> Justification: security-relevant
Since there wasn’t any activity on this bug, and there’s no sign of this
to be fixed any time soon, and rsync provides ways to work this around,
I don’t think having this bug marked as serious is justified.

If you disagree, please comment/update.

-- 
Cheers,
  Andrew

Bug#895320: ps2pdf crashes

[Andrew Shadura]

Control: reassign -1 ghostscript

It doesn't seem like a bug in mk-configure, I don't see anything
criminal in the .tex source.

-- 
Cheers,
  Andrew

Bug#888235: closing 888235

[Andrew Shadura]

close 888235 
thanks
-- 
-- 
Cheers,
  Andrew

Bug#833507: wpasupplicant: Unable to connect WLAN (wlan0: CTRL-EVENT-SCAN-FAILED ret=-22)

[Andrew Shadura]

On 9 December 2017 at 17:25, YOSHINO Yoshihito  wrote:
> Package: wpasupplicant
> Version: 2:2.6-13
> Followup-For: Bug #833507
>
> Dear Maintainer,
>
> I use /etc/network/interfaces to configure networking, not network-manager.
> Upgrading wpasupplicant to >= 2:2.6 my machine (MacBook Air with broadcom-sta
> wl module) fails to connect to a wi-fi network, with a lot of syslog messages
> of "CTRL-EVENT-SCAN-FAILED ret=-22".
> Downgrading the package to 2:2.4-1.1 restores it to work fine.
>
> I do not know how to configure ifupdown to disable random mac address
> usage just as how network-manager does in
> /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf .

So how about NM? Does it work for you if you use NM?

-- 
Cheers,
  Andrew

Bug#833507: [pkg-wpa-devel] Bug#833507: Bug#833507: wpasupplicant: workaround wifi.scan-rand-mac-address=no

[Andrew Shadura]

On 05/12/17 09:31, Noël Köthe wrote:
> Hello Andrew,
> 
> Am Dienstag, den 05.12.2017, 08:57 +0100 schrieb Andrew Shadura:
> 
>>> I remember a workaround for this problem from the past to add
>>> into /etc/NetworkManager/NetworkManager.conf the following:
>>>
>>> [device]
>>> wifi.scan-rand-mac-address=no
>>>
>>> which fixed it again for me.
> 
>> Just to be sure, are you absolutely sure it doesn't work with the
>> latest wpasupplicant without the NM snippet? 
> 
> Yes. Wifi worked until Tue or Wed last week and with my daily sid
> update I didn't get it working again. Module unloading and loading or
> network-manager restarts or complete reboots didn't helped.
> Until yesterday when I added the NM lines again.

Thanks.

>> I have put a similar one
>> into the wpasupplicant package, but a driver-specific one.
> 
> OK.
> 
>> Could you please let me know what driver are you using?
> 
> wl module/driver with the broadcom-sta-dkms 6.30.223.271-7
> 
> 03:00.0 Network controller: Broadcom Limited BCM4360 802.11ac Wireless
> Network Adapter (rev 03) on a MacBook Pro
> 03:00.0 0280: 14e4:43a0 (rev 03)
> 
>> You should be able to find out by running:
>>
>> nmcli -f GENERAL.DRIVER,GENERAL.DRIVER-VERSION device show
> 
> # nmcli -f GENERAL.DRIVER,GENERAL.DRIVER-VERSION device show
> GENERAL.DRIVER: tg3
> GENERAL.DRIVER-VERSION: 3.137
> 
> GENERAL.DRIVER: wl
> GENERAL.DRIVER-VERSION: 6.30.223.271 (r587334)

Right, so it is wl indeed.

> GENERAL.DRIVER: bridge
> GENERAL.DRIVER-VERSION: 2.3
> 
> GENERAL.DRIVER: unknown
> GENERAL.DRIVER-VERSION: --
> 
> GENERAL.DRIVER: tun
> GENERAL.DRIVER-VERSION: 1.6
> 
>> Please bear in mind the file I'm shipping doesn't work with old NM,
>> what version are you using?
> 
> network-manager 1.10.0-1

This should be recent enough.

> It is a sid system with no package on hold.
> 
> If I can help you with more information just tell me.

Thanks. Please have a look at
/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf.

There should be a line:

match-device=driver:rtl8723bs,…

Please add driver:wl to this comma-separated list, remove your previos
NetworkManager.conf addition, restart NM and try again. If this helps,
we can close the bug. If it doesn't, please check whether the config is
being parsed at all by runnin /usr/sbin/NetworkManager --print-config.

Thanks!

-- 
Cheers,
  Andrew

Bug#833507: [pkg-wpa-devel] Bug#833507: wpasupplicant: workaround wifi.scan-rand-mac-address=no

[Andrew Shadura]

On 4 December 2017 at 20:29, Noël Köthe  wrote:
> Package: wpasupplicant
> Version: 2:2.6-11
> Followup-For: Bug #833507
>
> Dear Maintainer,
>
> with one of the sid updates last week my wireless stop
> working again with the
> wpa_supplicant[737]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
>
> I remember a workaround for this problem from the past to add
> into /etc/NetworkManager/NetworkManager.conf the following:
>
> [device]
> wifi.scan-rand-mac-address=no
>
> which fixed it again for me.
>
> ...
> network-manager (1.4.0-4) unstable; urgency=medium
> ...
>   * Fix MAC address randomization.
> Cherry-pick a couple of upstream commits which work around driver bugs
> when MAC address randomization is used. (Closes: #835822, #835553)
> ...
>
> Because the last network-manager was from 2017-11-10 and my wlan problem
> started last week I'm a bit unsure where the root cause is.
>
> Maybe the workaround helps someone.

Just to be sure, are you absolutely sure it doesn't work with the
latest wpasupplicant without the NM snippet? I have put a similar one
into the wpasupplicant package, but a driver-specific one.

Could you please let me know what driver are you using?
You should be able to find out by running:

nmcli -f GENERAL.DRIVER,GENERAL.DRIVER-VERSION device show

Please bear in mind the file I'm shipping doesn't work with old NM,
what version are you using?

Thanks.

-- 
Cheers,
  Andrew

Bug#849122: unmerging 849122, bug 849122 is forwarded to https://github.com/lwfinger/rtl8188eu/issues/237

[Andrew Shadura]

unmerge 849122
forwarded 849122 https://github.com/lwfinger/rtl8188eu/issues/237
severity 849122 normal
thanks

Hi,

I'm unmerging 849122 as should be a separate bug. It should have been worked
around since I uploaded an NM snippet to blacklist it for MAC address
randomisation, so I'm downgrading the severity. lwfinger's repository seems
to be the upstream, so I have reported the bug there.

Please let me know if this is still an issue with the latest wpasupplicant
upload.

-- 
Cheers,
  Andrew

Bug#849077: [pkg-wpa-devel] Bug#849077: please upgrade wpa and report your experience

[Andrew Shadura]

On 27/11/17 22:52, Nicolas Kuttler wrote:
> On 2017-11-25 10:06, Andrew Shadura wrote:
>> I've just uploaded wpa 2.6 into unstable once again. Please upgrade,
>> test and let me know if it works for you.
> 
> Hm, installing wpasupplicant:amd64 2:2.6-8 lead to me not being able to
> connect to wireless networks again.
> 
> Adding the following lines to /etc/NetworkManager/NetworkManager.conf
> fixed this problem:
> 
> [device]
> wifi.scan-rand-mac-address=no

Okay, thanks.

I'm losing my patience with this issue, so I am just going to ship this
snippet within the wpasupplicant package.

-- 
Cheers,
  Andrew

Bug#849077: please upgrade wpa and report your experience

[Andrew Shadura]

Hi,

I've just uploaded wpa 2.6 into unstable once again. Please upgrade,
test and let me know if it works for you.

-- 
Cheers,
  Andrew

Bug#866194: etcd service fails to start on ppc64le architecture when installing etcd

[Andrew Shadura]

Control: tags -1 moreinfo

On Wed, 28 Jun 2017 01:54:08 -0500 Harish Sriram 
wrote:
> Package: etcd
> Version: 3.1.8+dfsg-1
> Severity: serious
> Justification: 4
> 
> Dear Maintainer,

> Service fails to start while installing etcd package
> 
> I tried installing the etcd package and service of the package failed to
> start on ppc64le.
> 
> Expected: Service should be up and running

Could you please test the latest package version?

Thanks!

-- 
Cheers,
  Andrew

Bug#849077: [pkg-wpa-devel] Bug#849122: Please adjust the BTS version tracking info

[Andrew Shadura]

Hi,

On 1 July 2017 at 23:32, Francesco Poli  wrote:
> Dear Debian wpasupplicant Maintainers,
> I noticed that these 3 RC bugs (#849122, #849077, #849875) are marked
> as found in wpa/2.6-2, which is now superseded by versions with epoch 2.
> What seems to have happened (please correct me, if I am wrong) is that
> the upstream version 2.4 was reintroduced into unstable (with epoch 2)
> and then migrated to stretch (before the stretch release as stable).
>
> Hence, I would say that those three bugs only affect experimental and
> are not in stretch, buster or sid.
>
> Could you please confirm that these 3 bugs should be marked as fixed in
> wpa/2:2.4-1 and found in wpa/2:2.6-4 ?

Yes, your understanding is correct, sorry for not replying earlier,
somehow this whole thread fell through the cracks in my email
processing.

-- 
Cheers,
  Andrew

Bug#866656: sparkleshare and webkit1

[Andrew Shadura]

On 11 August 2017 at 23:16, Jeremy Bicha <jbi...@ubuntu.com> wrote:
> On Fri, Aug 11, 2017 at 11:09 PM, Andrew Shadura <andre...@debian.org> wrote:
>> That's quite a surprise to me. The weekend starts in less than an hour, and
>> I get to know only now?
>
> I apologize. I think the problem is that you were only listed as
> Uploader instead of Maintainer. I believe the Maintainer gets emails
> about autoremovals in advance. And the maintainer should have received
> my initial RC bug.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866656
>
> You can subscribe to your packages you are interested in with the new
> Debian package tracker:
> https://tracker.debian.org/pkg/sparkleshare
>
> My understanding of autoremovals is that simply *commenting* on the RC
> bug will reset the timer so you have more time before the removal
> happens.
>
>
> Check out this page
> https://udd.debian.org/cgi-bin/autoremovals.cgi
>
> It lists these packages of interest to you:
> Andrew Shadura <andre...@debian.org>
>nfstrace: flagged for removal in 7.8 days
>sparkleshare: buggy deps webkitgtk-sharp3, flagged for removal in 37 hours
>webkitgtk-sharp3: flagged for removal in 37 hours
>wxhexeditor: flagged for removal in 7.8 days

Okay, let's see.

-- 
Cheers,
  Andrew

Bug#856271: xfonts-base: FTBFS on arm64 due to out of date autoconf files

[Andrew Shadura]

Package: xfonts-base
Version: 1:1.0.4+nmu1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

Your package fails to build from source on arm64:

dpkg-buildpackage: source package xfonts-base
dpkg-buildpackage: source version 1:1.0.4+nmu1
dpkg-buildpackage: source distribution unstable
 dpkg-source --before-build BUILD
dpkg-buildpackage: host architecture arm64
 fakeroot debian/rules clean
dh_testdir
rm -f config.cache config.log config.status
rm -f */config.cache */config.log */config.status
rm -f conftest* */conftest*
rm -rf autom4te.cache */autom4te.cache
rm -rf *-build
rm -rf debian/stamps
dh_clean
dh_clean: Compatibility levels before 9 are deprecated (level 7 in use)
 dpkg-source -b BUILD
dpkg-source: warning: no source format specified in debian/source/format, see 
dpkg-source(1)
dpkg-source: warning: source directory 'BUILD' is not 
- 'xfonts-base-1.0.4+nmu1'
dpkg-source: info: using source format '1.0'
dpkg-source: info: building xfonts-base in xfonts-base_1.0.4+nmu1.tar.gz
dpkg-source: info: building xfonts-base in xfonts-base_1.0.4+nmu1.dsc
 debian/rules build
mkdir -p debian/stamps
mkdir -p debian/stamps
mkdir -p font-arabic-misc-build
mkdir -p font-cursor-misc-build
cd font-cursor-misc-build && \
../font-cursor-misc/configure \
--prefix=/usr \
--mandir=\${prefix}/share/man \
--infodir=\${prefix}/share/info \
--build=aarch64-linux-gnu
cd font-arabic-misc-build && \
../font-arabic-misc/configure \
--prefix=/usr \
--mandir=\${prefix}/share/man \
--infodir=\${prefix}/share/info \
--build=aarch64-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... checking for a BSD-compatible 
install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... checking whether to enable 
maintainer-specific portions of Makefiles... no
yes
checking for style of include used by make... checking whether to enable 
maintainer-specific portions of Makefiles... no
GNU
checking for style of include used by make... checking for gcc... gcc
GNU
checking for gcc... gcc
checking whether the C compiler works... checking whether the C compiler 
works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... 
checking whether we are cross compiling... no
checking for suffix of object files... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... none
checking for gcc option to accept ISO C99... none needed
checking dependency style of gcc... none
checking for gcc option to accept ISO C99... none needed
checking how to run the C preprocessor... none needed
checking how to run the C preprocessor... gcc -E
gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... checking for grep that handles long lines 
and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/types.h... yes
yes
checking for sys/stat.h... checking for sys/stat.h... yes
yes
checking for stdlib.h... checking for stdlib.h... yes
yes
checking for string.h... checking for string.h... yes
yes
checking for memory.h... checking for memory.h... yes
yes
checking for strings.h... checking for strings.h... yes
yes
checking for inttypes.h... checking for inttypes.h... yes
checking for stdint.h... yes
checking for stdint.h... yes
yes
checking for unistd.h... checking for unistd.h... yes
yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... checking for pkg-config... 
/usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
yes
checking build system type... checking build system type... Invalid 
configuration `aarch64-linux-gnu': machine `aarch64' not recognized
Invalid configuration `aarch64-linux-gnu': machine `aarch64' not recognized
configure: error: /bin/bash ../font-arabic-misc/config.sub aarch64-linux-gnu 
failed
configure: error: /bin/bash ../font-cursor-misc/config.sub aarch64-linux-gnu 
failed
debian/rules:49: recipe for target 'debian/stamps/build-font-arabic-misc' failed
make: *** 

Bug#856259: [pkg-wpa-devel] Bug#856259: wpasupplicant: missing dependency on ifupdown

[Andrew Shadura]

Control: tags -1 moreinfo

On 27/02/17 04:33, Michael Gilbert wrote:
> package: wpasupplicant
> severity: serious
> justification: policy 3.5
> version: 2.5-2+v2.4-3, 2:2.4-1
> 
> wpasupplicant relies on ifupdown, but there is no relationship to it
> declared in the packaging.
> 
> For example, without ifupdown installed running these commands:
> 
> # ifconfig wlan0 create wlandev iwn0
> # wpa_supplicant -i wlan0 -c wpa.conf
> 
> causes the wpa_supplicant process to hang using 100% CPU.
> 
> Once ifupdown is installed, the exact same set of commands and same
> conf file, wpasupplicant correctly connects to my access point.

wpa_supplicant doesn't require ifupdown and doesn't use it in any way on
its own.

Please provide more logs or debug info.

-- 
Cheers,
  Andrew

Bug#849077: [pkg-wpa-devel] Bug#849077: new version of wpa-supplicant uploaded -- please test

[Andrew Shadura]

Hi,

On 23 February 2017 at 19:37, Scott Mcdermott
<scott.m.mcderm...@gmail.com> wrote:
> On Thu, 26 Jan 2017 18:36:08 +0100 Andrew Shadura <and...@shadura.me> wrote:
>> I have cherry-picked a few patches from the upstream Git repository.
>
> I tried this on my mbpr 11,1 with wl.ko and still same result.  Scan failure
> in endless loop return -22 just like in my previously attached log dump.
>
>> Please test this version, ensuring you have the latest NM/wicd/whatever
>
> Again I'm NOT using NetworkManager, wicd or anything else.  Just
> wpa_supplicant with a dead simple configuration and an ordinary
> WAP.
>
> 2.5-2+v2.4-3+b1 is the last version that works.

Right. Please report this to the upstream at
hos...@lists.infradead.org. Please bear in mind "2.5-2+v2.4-3+b1" is,
in fact, 2.4, not 2.5, despite the confusing version number. I will
upload another update to 2.4 with a fix for another bug fixed in 2.5
soon. 2.6 will be available in experimental.

-- 
Cheers,
  Andrew

Bug#854719: [pkg-wpa-devel] Bug#854719: Bug#854719: hostapd: Failed to set beacon parameters

[Andrew Shadura]

On 10/02/17 00:05, Vincent Danjean wrote:
> Le 09/02/2017 à 23:20, Andrew Shadura a écrit :
>> Hi,
>>
>> On 9 February 2017 at 21:10, Vincent Danjean <vdanj...@debian.org> wrote:
>>> Package: hostapd
>>> Version: 1:2.5-2+v2.4-3+b1
>>> Severity: grave
>>> Justification: renders package unusable
>>>
>>>   Hi,
>>>
>>>   I just upgraded a machine from jessie to stretch. With the stretch
>>> version of hostapd, the deamon does not start:
>>> # hostapd /etc/hostapd/hostapd.conf
>>> Configuration file: /etc/hostapd/hostapd.conf
>>> Using interface wlan0 with hwaddr f4:ec:38:c5:fd:94 and ssid "dino-wpa1"
>>> Failed to set beacon parameters
>>> Interface initialization failed
>>> wlan0: interface state UNINITIALIZED->DISABLED
>>> wlan0: AP-DISABLED
>>> wlan0: Unable to setup interface.
>>> wlan0: interface state DISABLED->DISABLED
>>> wlan0: AP-DISABLED
>>> hostapd_free_hapd_data: Interface wlan0_2 wasn't started
>>> wlan0: AP-DISABLED
>>> hostapd_free_hapd_data: Interface wlan0_1 wasn't started
>>> wlan0: AP-DISABLED
>>> hostapd_free_hapd_data: Interface wlan0 wasn't started
>>> nl80211: deinit ifname=wlan0 disabled_11b_rates=0
>>> #
>>>
>>>   If I downgrade the hostapd package to the jessie version
>>> (1:2.3-1+deb8u4), then it works perfectly:
>>> # apt-get install --reinstall hostapd/jessie
>>> [...]
>>> Les paquets suivants seront mis à une VERSION INFÉRIEURE :
>>>   hostapd
>>> 0 mis à jour, 0 nouvellement installés, 1 remis à une version inférieure, 0 
>>> à enlever et 44 non mis à jour.
>>> [...]
>>> Préparation du dépaquetage de .../hostapd_1%3a2.3-1+deb8u4_amd64.deb ...
>>> Dépaquetage de hostapd (1:2.3-1+deb8u4) sur (1:2.5-2+v2.4-3+b1) ...
>>> Paramétrage de hostapd (1:2.3-1+deb8u4) ...
>>> [...]
>>> #  hostapd /etc/hostapd/hostapd.conf
>>> Configuration file: /etc/hostapd/hostapd.conf
>>> Using interface wlan0 with hwaddr f4:ec:38:c5:fd:94 and ssid "dino-wpa1"
>>> Using interface wlan0_1 with hwaddr f4:ec:38:c5:fd:95 and ssid "dino"
>>> Using interface wlan0_2 with hwaddr f4:ec:38:c5:fd:96 and ssid
>>> "dino-guess"
>>> wlan0: interface state UNINITIALIZED->ENABLED
>>> wlan0: AP-ENABLED
>>> [.. and then authentifications from client...]
>>>
>>>   So, it seems there is a major regression in the hostapd package.
>>> Feel free to ask more information if required.
>>
>> I'm going to ask you to tell me what hardware you use.
> 
> From lspci:
> 04:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter 
> (PCI-Express) (rev 01)
> If you need more information, just tell me where to look at.
> 
>> Also, please try
>> and get more logs please, especially those wpa_supplicant produces with
>> -dt (you can add it with a systemd override file).
> 
> I do not use wpa_supplicant. I only run hostapd. I use this computer
> (and this wireless card) as an AP at home.
> You can find in attachment the output of
> # hostapd -dd /etc/hostapd/hostapd.conf
> - for the testing version
> - for the stable version
> - for the unstable version

Here, I meant hostapd. However, wpa_supplicant and hostapd are two parts
of the same software package, and they use the same drivers AFAIK.

>>>   Note that the unstable version works. So I will mark this bug as fixed
>>> for the 1:2.6-3 version as soon as I get its number
>>
>> That's pretty much a bad news, as 2.6 breaks networking for lot more
>> people, it seems.
>>
>> There's a thread about a related issue:
>> http://lists.infradead.org/pipermail/hostap/2017-January/037042.html
>>
>> Please have a look and let me know whether what you're observing is the
>> same bug or not, and whether the patch works.
> 
> I'm not using wpa_supplicant, so it does not seem the same bug.
> Moreover, the proposed patch in
> http://lists.infradead.org/pipermail/hostap/2017-January/037060.html
> do not apply at all for the testing sources.
> In the testing sources, in the wpa_driver_nl80211_set_ap function,
> the "if (beacon_set)" test do not have any "else" clause to patch.

That doesn't sound good. Maybe try emailing the hostap mailing list?

-- 
Cheers,
  Andrew

Bug#854719: [pkg-wpa-devel] Bug#854719: hostapd: Failed to set beacon parameters

[Andrew Shadura]

Hi,

On 9 February 2017 at 21:10, Vincent Danjean  wrote:
> Package: hostapd
> Version: 1:2.5-2+v2.4-3+b1
> Severity: grave
> Justification: renders package unusable
>
>   Hi,
>
>   I just upgraded a machine from jessie to stretch. With the stretch
> version of hostapd, the deamon does not start:
> # hostapd /etc/hostapd/hostapd.conf
> Configuration file: /etc/hostapd/hostapd.conf
> Using interface wlan0 with hwaddr f4:ec:38:c5:fd:94 and ssid "dino-wpa1"
> Failed to set beacon parameters
> Interface initialization failed
> wlan0: interface state UNINITIALIZED->DISABLED
> wlan0: AP-DISABLED
> wlan0: Unable to setup interface.
> wlan0: interface state DISABLED->DISABLED
> wlan0: AP-DISABLED
> hostapd_free_hapd_data: Interface wlan0_2 wasn't started
> wlan0: AP-DISABLED
> hostapd_free_hapd_data: Interface wlan0_1 wasn't started
> wlan0: AP-DISABLED
> hostapd_free_hapd_data: Interface wlan0 wasn't started
> nl80211: deinit ifname=wlan0 disabled_11b_rates=0
> #
>
>   If I downgrade the hostapd package to the jessie version
> (1:2.3-1+deb8u4), then it works perfectly:
> # apt-get install --reinstall hostapd/jessie
> [...]
> Les paquets suivants seront mis à une VERSION INFÉRIEURE :
>   hostapd
> 0 mis à jour, 0 nouvellement installés, 1 remis à une version inférieure, 0 à 
> enlever et 44 non mis à jour.
> [...]
> Préparation du dépaquetage de .../hostapd_1%3a2.3-1+deb8u4_amd64.deb ...
> Dépaquetage de hostapd (1:2.3-1+deb8u4) sur (1:2.5-2+v2.4-3+b1) ...
> Paramétrage de hostapd (1:2.3-1+deb8u4) ...
> [...]
> #  hostapd /etc/hostapd/hostapd.conf
> Configuration file: /etc/hostapd/hostapd.conf
> Using interface wlan0 with hwaddr f4:ec:38:c5:fd:94 and ssid "dino-wpa1"
> Using interface wlan0_1 with hwaddr f4:ec:38:c5:fd:95 and ssid "dino"
> Using interface wlan0_2 with hwaddr f4:ec:38:c5:fd:96 and ssid
> "dino-guess"
> wlan0: interface state UNINITIALIZED->ENABLED
> wlan0: AP-ENABLED
> [.. and then authentifications from client...]
>
>   So, it seems there is a major regression in the hostapd package.
> Feel free to ask more information if required.

I'm going to ask you to tell me what hardware you use. Also, please try
and get more logs please, especially those wpa_supplicant produces with
-dt (you can add it with a systemd override file).

>   Note that the unstable version works. So I will mark this bug as fixed
> for the 1:2.6-3 version as soon as I get its number

That's pretty much a bad news, as 2.6 breaks networking for lot more
people, it seems.

There's a thread about a related issue:
http://lists.infradead.org/pipermail/hostap/2017-January/037042.html

Please have a look and let me know whether what you're observing is the
same bug or not, and whether the patch works.

Thanks!

-- 
Cheers,
  Andrew

Bug#849122: [pkg-wpa-devel] Bug#849122: Wifi stop working with wpasupplicant 2.6-2

[Andrew Shadura]

Hi,

On 14 Jan 2017 16:16, "marcelomen...@gmail.com" 
wrote:

Hi, I'm having this issue as well. For weeks now, every time I forget
about it and do an aptitude upgrade I have to manually downgrade to
2.5-2+v2.4-3+b1 because my dongle USB stop working. I'm afraid that in
some more upgrades the package won't install and I get stuck without
wifi! :-)

Device:
Bus 001 Device 004: ID 0bda:8179 Realtek Semiconductor Corp.
RTL8188EUS 802.11n Wireless Network Adapter


dmesg got filled with:

[ 1182.365621] IPv6: ADDRCONF(NETDEV_UP): wlxe8de271f313a: link is not ready
[ 1183.650554] R8188EU: ERROR indicate disassoc

/var/log/syslog

Jan 14 10:56:18 debian wpa_supplicant[3966]: Successfully initialized
wpa_supplicant
Jan 14 10:56:18 debian NetworkManager[3929]:   [1484405778.9175]
supplicant: wpa_supplicant running
Jan 14 10:56:18 debian NetworkManager[3929]:   [1484405778.9182]
device (wlxe8de271f313a): supplicant interface state: init -> starting
Jan 14 10:56:18 debian wpa_supplicant[3966]: nl80211: Driver does not
support authentication/association or connect commands
Jan 14 10:56:18 debian wpa_supplicant[3966]: nl80211: deinit
ifname=wlxe8de271f313a disabled_11b_rates=0
Jan 14 10:56:18 debian wpa_supplicant[3966]: ioctl[SIOCSIWAP]:
Operation not permitted
Jan 14 10:56:18 debian wpa_supplicant[3966]: ioctl[SIOCSIWENCODEEXT]:
Invalid argument
Jan 14 10:56:18 debian wpa_supplicant[3966]: ioctl[SIOCSIWENCODEEXT]:
Invalid argument
Jan 14 10:56:18 debian NetworkManager[3929]:   [1484405778.9751]
sup-iface[0x55d776f7c0a0,wlxe8de271f313a]: supports 1 scan SSIDs
Jan 14 10:56:18 debian kernel: [ 1232.450878] IPv6:
ADDRCONF(NETDEV_UP): wlxe8de271f313a: link is not ready
Jan 14 10:56:18 debian NetworkManager[3929]:   [1484405778.9761]
device (wlxe8de271f313a): supplicant interface state: starting ->
ready
Jan 14 10:56:18 debian NetworkManager[3929]:   [1484405778.9762]
device (wlxe8de271f313a): state change: unavailable -> disconnected
(reason 'supplicant-available') [20 30 42]
Jan 14 10:56:18 debian kernel: [ 1232.457289] R8188EU: ERROR indicate
disassoc
Jan 14 10:56:19 debian NetworkManager[3929]:   [1484405779.0836]
device (wlxe8de271f313a): set-hw-addr: new MAC address
XX:XX:XX:XX:XX:XX not successfully set (scanning)


--
"Free Software is not the only way, but it's a correct way."
Marcelo Mendes
http://underlabs.org
mmendes @ IRC [OFTC-Freenode]
Gtalk: marcelomendes at gmail dot com

___
Pkg-wpa-devel mailing list
pkg-wpa-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-wpa-devel


It seems it's the randomisation issue.

Have you tried 2.6 with an upgraded NetworkManager, and if that doesn't
help, try disabling MAC randomisation?

-- 
Cheers,
  Andrew

Bug#851204: libdigidoc: drop the uninstallable libdigidoc-dbg package

[Andrew Shadura]

Control: reopen -1

On 13 January 2017 at 20:11, Andrew Shadura <and...@shadura.me> wrote:
> On 12 January 2017 at 23:12, Andreas Beckmann <a...@debian.org> wrote:
>> the libdigidoc package builds both a -dbg and a -dbgsym package. The
>> libdigidoc-dbg is now uninstallable in sid - please remove it from
>> debian/control.
>
> Thanks for the bug report. I don't plan to ship this package in
> stretch, so I will fix it as soon as testing migrations stop.

To be honest, I’m fairly unhappy that you went ahead and uploaded an
NMU without asking me first and without pasting an nmudiff in this
bug. I explicitly mentioned this intention in the other bug
discussion, I’m not sure why you have decided to ignore it.

Please avoid doing so in the future.

Thanks.

-- 
Cheers,
  Andrew

Bug#851204: libdigidoc: drop the uninstallable libdigidoc-dbg package

[Andrew Shadura]

Hi,

On 12 January 2017 at 23:12, Andreas Beckmann  wrote:
> the libdigidoc package builds both a -dbg and a -dbgsym package. The
> libdigidoc-dbg is now uninstallable in sid - please remove it from
> debian/control.

Thanks for the bug report. I don't plan to ship this package in
stretch, so I will fix it as soon as testing migrations stop.

-- 
Cheers,
  Andrew

Bug#849122: Fwd: With 2.6-2 i dont have the wifi adapter in the (network-manager) list available.

[Andrew Shadura]

-- Forwarded message --
From: data cruncher <dcrunch...@gmail.com>
Date: 11 January 2017 at 03:40
Subject: Re: With 2.6-2 i dont have the wifi adapter in the
(network-manager) list available.
To: Andrew Shadura <and...@shadura.me>


Hi

Unfortunately not really, there are no error messages nor similar in
the log files.
When i update to 2.6.2, it continues working, until the next reboot,
then i cannot "access" the device anymore
(although visible with ifconfig -a i cant ifup nor ifconfig wlx... up,
nor network-manager sees the device).

When downgrading to 2.5-2+v2.4-3+b1 (and reboot), everything works
normally again.

I recompiled the nic driver having wpasuplicant 2.6.2 installed, didnt help.
Restarting network-manager, wpa_supplicant, all didnt help.

I suspect dbus as it happens after the restart, but can't be sure...
Also it seems only to happen when one has compiled the module himself,
other (usb) cards works fine.

If you know what information you would need just let me know.


Regards


On Tue, Jan 10, 2017 at 5:14 PM, Andrew Shadura <and...@shadura.me> wrote:
>
> Control: tag -1 moreinfo
>
> On Thu, 22 Dec 2016 20:41:31 +0100 cruncher <dcrunch...@gmail.com> wrote:
> > Me too, i have also that problem.
> >
> > When installing 2.6-2, i cant see even the device anywhere (ifconfig nor
> > network-manager), downgrading to 2.5-2+v2.4-3+b1 works again.
> >
> > I'm building the driver module (8188eu) also myself for this device:
> > Wifi adapter: 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n 
> > Wireless
> > Network Adapter
>
> Have you resolved this issue? Could you please provide more details,
> logs, anything?
>
> --
> Cheers,
>   Andrew




-- 
Cheers,
  Andrew

Bug#849077: [pkg-wpa-devel] Bug#849077: wpasupplicant: [Regression] Updating wpasupplicant makes not possible to connect to encrypted WiFi

[Andrew Shadura]

On Mon, 26 Dec 2016 16:39:43 -0300 Lisandro
=?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer <perezme...@gmail.com>
wrote:
> On lunes, 26 de diciembre de 2016 20:04:08 ART Andrew Shadura wrote:
> > On 26/12/16 19:28, Lisandro Damián Nicanor Pérez Meyer wrote:
> > > Thanks to Eduard Bloch at [bug] I've tried adding
> > > 
> > > [device]
> > > wifi.scan-rand-mac-address=no
> > > 
> > > to /etc/NetworkManager/NetworkManager.conf
> > > 
> > > and updating wpasupplicant... and voilá, WiFi is on again.
> > > 
> > > [bug] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849034#15>
> > > 
> > > I don't know if it's a bug in the driver, NM or wpasupplicant, but at
> > > least
> > > things now work.
> > 
> > Lisandro, what NM version are you using? A related bug has been fixed by
> > mbiebl recently:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835822#67
> 
> Interesting. I was using 1.4.2-3. After trying this workaround/fix I updated 
> to 1.4.4-1 which is what I'm currently using.
> 
> Thanks!

Lisandro, could you please confirm this indeed was the issue with MAC
randomization and it indeed is solved by an NM update?

-- 
Cheers,
  Andrew

Bug#849122: With 2.6-2 i dont have the wifi adapter in the (network-manager) list available.

[Andrew Shadura]

Control: tag -1 moreinfo

On Thu, 22 Dec 2016 20:41:31 +0100 cruncher  wrote:
> Me too, i have also that problem.
> 
> When installing 2.6-2, i cant see even the device anywhere (ifconfig nor
> network-manager), downgrading to 2.5-2+v2.4-3+b1 works again.
> 
> I'm building the driver module (8188eu) also myself for this device:
> Wifi adapter: 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n 
> Wireless
> Network Adapter

Have you resolved this issue? Could you please provide more details,
logs, anything?

-- 
Cheers,
  Andrew

Bug#849077: [pkg-wpa-devel] Bug#849077: wpasupplicant: [Regression] Updating wpasupplicant makes not possible to connect to encrypted WiFi

[Andrew Shadura]

On 26/12/16 19:28, Lisandro Damián Nicanor Pérez Meyer wrote:
> Thanks to Eduard Bloch at [bug] I've tried adding
> 
> [device]
> wifi.scan-rand-mac-address=no
> 
> to /etc/NetworkManager/NetworkManager.conf
> 
> and updating wpasupplicant... and voilá, WiFi is on again.
> 
> [bug] 
> 
> I don't know if it's a bug in the driver, NM or wpasupplicant, but at least 
> things now work.

Lisandro, what NM version are you using? A related bug has been fixed by
mbiebl recently:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835822#67

-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

Bug#849077: [pkg-wpa-devel] Bug#849077: wpasupplicant: [Regression] Updating wpasupplicant makes not possible to connect to encrypted WiFi

[Andrew Shadura]

On 22/12/16 17:23, Lisandro Damián Nicanor Pérez Meyer wrote:
> 0c:00.0 Network controller: Broadcom Limited BCM4322 802.11a/b/g/n Wireless 
> LAN Controller (rev 01) using broadcom-sta-dkms to get the proprietary driver 
> (sadly the libre one hangs too much). Note: I've checked with both the 
> testing 
> and sid versions of broadcom-sta-dkms and both fail in the same way.
> 
> I could not make the systemd override file, but stopping the service and 
> running it by hand gave me:
> 
> # /sbin/wpa_supplicant -d -t -u -s -O /run/wpa_supplicant
> 1482423134.657501: Scan SSID - hexdump_ascii(len=8):
>  68 65 72 6d 69 6f 6e 65   hermione

> This log happened while trying quite a lot of times to connect.
> 
> As an interesting note: even if I was running wpa_supplicant "by hand", after 
> downgrading the package in order to be able to send this mail I had to reboot 
> the computer to make it work.
> 
> Of course feel free to send more more debugging tips as you need.

Sadly, that doesn't give much information to me. However, googling for
the exact error code together with the hardware led me to this:

https://bbs.archlinux.org/viewtopic.php?pid=1216302#p1216302

I don't know whether that makes sense or not, but could you please try that?

-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

Bug#849077: [pkg-wpa-devel] Bug#849077: wpasupplicant: [Regression] Updating wpasupplicant makes not possible to connect to encrypted WiFi

[Andrew Shadura]

On 22/12/16 17:41, Andrew Shadura wrote:
> On 22/12/16 17:23, Lisandro Damián Nicanor Pérez Meyer wrote:
>> 0c:00.0 Network controller: Broadcom Limited BCM4322 802.11a/b/g/n Wireless 
>> LAN Controller (rev 01) using broadcom-sta-dkms to get the proprietary 
>> driver 
>> (sadly the libre one hangs too much). Note: I've checked with both the 
>> testing 
>> and sid versions of broadcom-sta-dkms and both fail in the same way.
>>
>> I could not make the systemd override file, but stopping the service and 
>> running it by hand gave me:
>>
>> # /sbin/wpa_supplicant -d -t -u -s -O /run/wpa_supplicant
>> 1482423134.657501: Scan SSID - hexdump_ascii(len=8):
>>  68 65 72 6d 69 6f 6e 65   hermione
> 
>> This log happened while trying quite a lot of times to connect.
>>
>> As an interesting note: even if I was running wpa_supplicant "by hand", 
>> after 
>> downgrading the package in order to be able to send this mail I had to 
>> reboot 
>> the computer to make it work.
>>
>> Of course feel free to send more more debugging tips as you need.
> 
> Sadly, that doesn't give much information to me. However, googling for
> the exact error code together with the hardware led me to this:
> 
> https://bbs.archlinux.org/viewtopic.php?pid=1216302#p1216302
> 
> I don't know whether that makes sense or not, but could you please try that?

Also, there's https://bugs.debian.org/833507 and a related
https://bugs.debian.org/838096, could you please check whether they're
related to your failure?

-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

Bug#849077: [pkg-wpa-devel] Bug#849077: wpasupplicant: [Regression] Updating wpasupplicant makes not possible to connect to encrypted WiFi

[Andrew Shadura]

Hi,

On 22 December 2016 at 16:46, Lisandro Damián Nicanor Pérez Meyer
 wrote:
> Not that I can imagine of, but please do not heasitate in telling me which
> details/data might help you.
>
> So far all I know is what I wrote above.

Well, first of all please tell me what hardware you use, and then try
to get more logs please, especially those wpa_supplicant produces with
-dt (you can add it with a systemd override file).


-- 
Cheers,
  Andrew

Bug#849077: [pkg-wpa-devel] Bug#849077: wpasupplicant: [Regression] Updating wpasupplicant makes not possible to connect to encrypted WiFi

[Andrew Shadura]

Hi,

On 22 December 2016 at 15:22, Lisandro Damián Nicanor Pérez Meyer
 wrote:
> Package: wpasupplicant
> Version: 2.6-2
> Severity: serious
> Justification: Makes package unusable
>
> I upgraded form testing's 2.5-2+v2.4-3+b1 to sid's 2.6-2 and I can't no
> longer connect to encrypted WiFi networks.
>
> Going back to the version in testing makes my WiFI work again.
>
> With 2.6-2 I'm getting:
>
> wpa_supplicant[868]: wlp12s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1

Any more details please? I've been using this for a month at least
with no issues.

-- 
Cheers,
  Andrew

Bug#842354: git-phab 1.0.0-2 inaccurate .dsc Dgit field

[Andrew Shadura]

Control: severity -1 normal

On Fri, 28 Oct 2016 12:27:09 +0100 Ian Jackson
 wrote:
> Package: git-phab
> Version: 1.0.0-2
> Severity: serious

Well, I disagree it’s serious, at least, it’s not a serious bug in
git-phab packaging.

> You've told me you're going to stop using dgit.

I really like some things about dgit, but the fact it doesn’t forgive
people’s mistakes makes me uneasy about using it.

> That's fine, of
> course, but the current state of the dgit-repos and the archive are
> not consistent.  Even if a new version is uploaded, anyone doing
> archaeology will probably find that their attempts to use `dgit
> import-dsc' on git-phab 1.0.0-2 will fail.

Honestly, keeping that state might have proven my point, but, well, I
tried to convince you yesterday and I failed, and I don’t wish to
continue the argument.

> You requested that I rewind history on the dgit git server, or delete
> the git-phab repository there.  I have declined to do this on the
> grounds that this history should continue to be available to dgit
> users; that deleting or rewinding there is contrary to the design and
> therefore to the promises made to downstreams, so there may exist
> downstreams or mirrors which would break or signal an exception; and
> that either of these proposals would cause `dgit import-dsc' to fail
> on historical git-phab .dscs (from snapshot.d.o).
> 
> Having slept on it, I still think that is the right decision.
> 
> I think the best way to sort this out is for me to do a dgit-based
> no-change NMU, of a branch which is descended from the commit named in
> 1.0.0-2's .dsc as well as from 1.0.0-1.  This will ensure that the
> commits referenced by all previously-uploaded git-phab .dsc's will be
> findable.
> 
> For this to work it is not necessary for my NMU to actually make it to
> the archive.  So unless you object I intend to make this NMU to
> DELAYED-14.  You may then use dcut, or upload a later version.

If you wish to fix the dgit repository, feel free to do so, but please
make sure that whatever you upload doesn’t end up in the archive.

> If you object before I actually make the NMU I can arrange to simulate
> the effect of my uploading to DELAYED-14 and you running dcut, by
> making my NMU and pushing it only to the dgit git server but arranging

(the rest of the email’s got cut off when replying via a browser link —
is that a limitation of the BTS?)

> I intend to use the version number 1.0.0-2+nmu0dgit but I'm happy to
> use a different version number if you prefer - just say.

I don’t have an opinion on what version number it should have, as I
don’t plan to use dgit for this package anymore. I’m not sure about
other packages, but the dgit repo for git-phab is borken to the point of
no return, and as you refuse to unbork it properly (for my definition of
‘properly’) I don’t care too much about the exact way you are going to
make it internally consistent.

-- 
Cheers,
  Andrew

Bug#839446: closing 839446

[Andrew Shadura]

fixed 839446 4.6.1.3+dfsg-1
close 839446 4.6.1.3+dfsg-1
thanks
-- 
-- 
Cheers,
  Andrew

Bug#821543: Bumping severity of PHP 7.0 transition bugs to serious

[Andrew Shadura]

On 29/09/16 00:35, Sylvestre Ledru wrote:
> Le 28/09/2016 à 15:54, Andrew Shadura a écrit :
>> On Wed, 28 Sep 2016 13:56:19 +0200 Andrew Shadura wrote:
>>>> I am bumping the severity of this bug to serious, as we are going to
>>>> remove src:php5 from Debian and your package is blocking the first
>>>> step which is removal of php5 from testing.  Please either update your
>>>> package to support PHP 7.0 or remove the package from Debian unstable
>>>> alltogether.
>>> Ondř™ej, are the changes in
>>> https://launchpad.net/ubuntu/+source/phabricator/0~git20160124-1ubuntu1
>>> enough to fix this bug?
>> Ondřej, Richard, I have uploaded an NMU to DELAYED/4.
>>
> You can upload directly, no need to have a delay

I wanted to give the maintainer a chance to say "NO, STOP, WHAT ARE YOU
DOING" :)

-- 
Cheers,
  Andrew

Bug#821543: Bumping severity of PHP 7.0 transition bugs to serious

[Andrew Shadura]

On Thu, 5 May 2016 10:20:56 +0200 =?utf-8?B?T25kxZllaiBTdXLDvQ==?=
 wrote:
> Dear maintainer(s),
> 
> I am bumping the severity of this bug to serious, as we are going to
> remove src:php5 from Debian and your package is blocking the first
> step which is removal of php5 from testing.  Please either update your
> package to support PHP 7.0 or remove the package from Debian unstable
> alltogether.

Ondřej, are the changes in
https://launchpad.net/ubuntu/+source/phabricator/0~git20160124-1ubuntu1
enough to fix this bug?

-- 
Cheers,
  Andrew

Bug#823162: pseudo: wrong update-alternatives call in postinst

[Andrew Shadura]

On 1 May 2016 at 18:40, Gian Piero Carrubba  wrote:
> This bug is presumably related to #805937, but I'm reporting it alone as
> it prevents a smooth installation of the package.

> The pseudo package does not contain the fakeroot-pseudo wrapper (as a
> fix for #805937 ?):

Oops, that was a mistake. I'll upload a fixed version tomorrow.

-- 
Cheers,
  Andrew

Bug#806714: caffeine: FTBFS (missing comma in the dependencies)

[Andrew Shadura]

On 30/11/15 12:58, Stephen Kitt wrote:
> caffeine 2.8.3-2 doesn't build from source because "python3-gi" needs
> a comma in the Depends: stanza of debian/control. Since you did a
> source-only upload (nice) it's not available for anyone in unstable!

Oops.

-- 
Cheers,
  Andrew

Bug#802908: requires python3-gi to run

[Andrew Shadura]

On 24/10/15 23:59, Modestas Vainius wrote:
> caffeine uses modules from python3-gi and needs them to run (see below):
> 
> Traceback (most recent call last):
>   File "/usr/bin/caffeine", line 25, in 
> from gi.repository import GObject, Gtk, GLib

Thanks Modestas, I'll check it and fix it!

-- 
Cheers,
  Andrew

Bug#796303: guessnet: FTBFS: undefined reference to `std::__cxx11::basic_stringchar, std::char_traits [..]

[Andrew Shadura]

On 21/08/15 11:03, Chris Lamb wrote:
 guessnet fails to build from source on testing/amd64:

Chris,

I don't maintain or use this package anymore. Also, I know little to
nothing about C++11 and the transition, so I don't think I can actually
fix this breakage. Should you prepare a patch to fix the issue, please
feel free to do an NMU.

-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

Bug#791230: [pkg-xtuple-maintainers] Bug#791230: nmu diff for openrpt 3.3.7-1.1

[Andrew Shadura]

Please do.

Bug#787515: tortoisehg: uninstallable in sid

[Andrew Shadura]

Hello,

I've made an NMU (3.4-0.1) to the DELAYED/2 queue.

-- 
Cheers,
  Andrew


pgplOH0IhX4HJ.pgp
Description: OpenPGP digital signature

Bug#760281: Not fixed

[Andrew Shadura]

,Hi.

On 10 February 2015 at 16:44, Serge Hallyn serge.hal...@ubuntu.com wrote:
 Quoting Andrew Shadura (and...@shadura.me):
 Well, I'm running sid. It could happen that a version from testing was
 installed, but I'm not sure. One more question: is by any chance a
 reboot mandatory for this to work? I'd like to avoid that as much as I
 can for various reasons.

 No a reboot should not be necessary.  Just to be clear, could you
 describe exactly what symptoms you are seeing, and give the version
 numbers of cgmanager and systemd-shim?

I'm not currently at the computer I'm talking about, so I can't give
you precise versions.

I'm normally running wmii and mounting devices using pmount. However,
I decided to install XFCE for another user who's not as tech-savvy as
I am. So I went on with replacing slim by lightdm (I still have
troubles convincing it to still use wmii for my user and XFCE for the
second user only), and then I installed XFCE, console-kit and bunch of
other stuff. Logged into the new user with XFCE, configured things,
noticed clicking on media icons gives an error policykit not
running. Okay, I thought, give it what it wants. Installed policykit,
systemd-shim and something else, logged out, restarted lightdm just to
be sure. Logging back in, polkit not running, disks don't get mounted.
Okay, let's force-start policykit. Try mounting again, now it says
udisks not authorised or something like this. Okay, fsck it all,
removed polkit, systemd-shim and accountsservice and resorted to
pmount as my normal user on request.

And then I see John's post and realise I'm not alone with this issue.

When I get home I may try to reproduce it once again and give you more details.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#760281: Not fixed

[Andrew Shadura]

Hello,

On Wed, 10 Dec 2014 20:43:57 -0600 John Goerzen jgoer...@complete.org
wrote:
 I have a Jessie system running XFCE, just dist-upgraded yet again
 today, and I'm still seeing this same issue.  I am willing to do
 whatever I can to help.  systemd-shim is installed and I am booting
 with sysvinit.

I have installed XFCE as the second DE yesterday and also bumped into
this issue.

-- 
Cheers,
  Andrew


pgpaRMf8skRbp.pgp
Description: OpenPGP digital signature

Bug#760281: Not fixed

[Andrew Shadura]

Hi,

On 10 February 2015 at 15:36, Serge Hallyn serge.hal...@ubuntu.com wrote:
 Quoting Andrew Shadura (and...@shadura.me):
 Hello,

 On Wed, 10 Dec 2014 20:43:57 -0600 John Goerzen jgoer...@complete.org
 wrote:
  I have a Jessie system running XFCE, just dist-upgraded yet again
  today, and I'm still seeing this same issue.  I am willing to do
  whatever I can to help.  systemd-shim is installed and I am booting
  with sysvinit.

 I have installed XFCE as the second DE yesterday and also bumped into
 this issue.

 Indeed, the jessie version is frozen so this is not fixed there.  With
 the sid version it should be fixed.  Please do let me know if you have
 this issue with 0.35-1.

Well, I'm running sid. It could happen that a version from testing was
installed, but I'm not sure. One more question: is by any chance a
reboot mandatory for this to work? I'd like to avoid that as much as I
can for various reasons.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766943: reassign 766943 to systemd

[Andrew Shadura]

Hello,

On Thu, 27 Nov 2014 01:13:23 +0100
Michael Biebl bi...@debian.org wrote:

 Christoph, thanks for testing and confirming that it works.

 Andrew, do you have any input/further questions on patch v2?
 If not, would you be willing to add it to ifupdown and upload it so it
 get's into jessie?

I will upload it, I just haven't had time to prepare the upload.
There's one more issue I'd like to fix.

 I know that a few months ago I asked you to remove the allow-hotplug
 handling from /etc/init.d/networking and now I'm asking you to add it
 back. But given the freeze, I think adding the allow-hotplug handling
 back and using udevadm settle is the least intrusive change which
 has a chance to be accepted by the release team.

 And a more elaborate/nicer solution will have to be postponed for
 jessie+1.

Sure.

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature

Bug#769511: Processed (with 5 errors): Re: Bug#769511: netscript-2.4: installation fails

[Andrew Shadura]

Control: severity -1 wishlist
Control: tag -1 wontfix

Hello,

I don't think I really want to fix this. At least, not at the moment.

Sorry.

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature

Bug#762520: Bug report about the package clearlooks-phenix-theme 5.0.2-1 (unstable)

[Andrew Shadura]

Control: severity -1 normal

Hello,

I've uploaded 5.0.2-2, it should fix most of the issues. I'm aware of
colours not fully matching, minor glitches with scrollbars and pop-over
menus, but this is all I can do for now.

I'm reducing severity to normal as the package should be useful now
(even though bug not fixed yet).

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature

Bug#762520: Bug report about the package clearlooks-phenix-theme 5.0.2-1 (unstable)

[Andrew Shadura]

Hello,

On 25 September 2014 17:29, Etienne MAHE yitiane...@gmail.com wrote:
 Justification: bad graphical integration with apps based on adwaïta theme.

 On some apps based on Adwaïta theme and built on the gtk3 architecture like
 Synaptic or evince, the clearlooks phenix theme let to appear ugly boxes in
 the menu of the app, and that are not well integrated with the graphical
 window. This bug seems to appear since the new version of this theme. So I
 am waiting for any fixes and meanwhile, I am using the clearlooks theme
 built on gtk2. If we could delete these boxes and get an interface like in
 the previous version, it would be great.

If you run GTK+ 3.14 (Debian unstable), this is a known issue. GTK+
broke the compatibility again, and Jean-Philippe (the upstream author)
is aware of that. Unfortunately, he doesn't have 3.14 yet, so he's not
very enthusiastic about updating the theme.

However, the freeze is Real Soon Now, in November, and we should
probably fix this until the end of October. I'll try to do something
with it myself, but I can't guarantee anything, as theming engine
seems to have changed significantly.

-- 
Cheers,
  Andrew


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762520: clearlooks-phenix-theme: theme is completely broken since the last GTK update

[Andrew Shadura]

Hello,

On Tue, 23 Sep 2014 04:04:33 +0200
Christoph Anton Mitterer cales...@scientia.net wrote:

 I guess since the most recent upgrade of GTK the theme is completely
 broken.
 
 Most important, checkboxes and radio buttons are no longer displayed,
 you just see an empty space where they should be.
 When you click them, you can see the check for a few milliseconds,
 than it becomes invisible again.
 
 Further, the colours seem to no longer match, as the attached
 screenshot should show quite well, the default background seems to be
 white now, while the the background for frames, radio buttons and
 check boxes is still the proper grey.
 
 The screenshots are from cinnamon,... under gnome classic, I've seen
 that also some grey tones seem to no longer match (again grey tone of
 check boxes/etc. vs. the default background grey).

Oh. WHY?! Why do they do this AGAIN and AGAIN?! Why just one breakage
per year is NOT ENOUGH?!

Okay, I'll try to fix it when I have more time. Thanks for the report.

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature

Bug#759825: audtty: FTBFS: main.c:20:31: fatal error: audacious/audctrl.h: No such file or directory

[Andrew Shadura]

Package: src
Followup-For: Bug #759825

Hi,

Łukasz Zemczak from Ubuntu have written a patch:
https://patches.ubuntu.com/a/audtty/audtty_0.1.12-4ubuntu1.patch

It would be great if you applied it. Or, I could NMU the package.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#759241: wmauda: FTBFS - audacious/dbus.h: No such file or directory

[Andrew Shadura]

Hi,

I've uploaded an NMU fixing this bug to the DELAYED/7 queue.

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature

Bug#753705: conky: FTBFS with audacious 3.5: libaudclient removed

[Andrew Shadura]

Hello,

On Tue, 8 Jul 2014 14:18:15 +0100 Colin Watson cjwat...@ubuntu.com
wrote:
  It looks like upstream hasn't done any porting work to drop
  libaudclient, and nobody else has done so either; e.g. Fedora has
  gone ahead and just dropped audacious support [1], so I plan on
  doing the same thing soon unless someone steps up with a patch.

 Thanks.  That sounds reasonable - please do.

Upstream says the interface has been deprecated since 2009, and MPRIS
2.0 should be used instead.

However, I have packaged libaudclient as a separate package, and it's
in NEW now.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753402: gosh segfaults on s390x causing libguess to FTBFS

[Andrew Shadura]

Hello,

On Mon, 14 Jul 2014 17:52:15 +0200
Aurelien Jarno aurel...@aurel32.net wrote:

 The problem is once again the infamous setjmp/longjmp ABI breakage on
 s390x [1]. Simply rebuilding gauche would fix the problem, but I am
 not sure it is the best way to deal with it.

So, anything new on this? This blocks libguess from migrating to
testing, which blocks audacious from migrating too.

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature

Bug#752443: upower 0.99 transition started

[Andrew Shadura]

Hello,

On 16 July 2014 12:38, Emilio Pozuelo Monfort po...@debian.org wrote:
 Andreas, I'd expect a patch from you prior to the upload of a newer
 upower. I currently have no time nor desire to review the API changes
 to perform the porting, so a tested and working patch would really
 help.

 This package is orphaned and abandoned upstream, so I didn't consider it a
 blocker for the transition. If you care about it, perhaps you can fix this bug
 and adopt the package? I haven't checked how much porting work is needed here,
 but upower.c is small so hopefully it's not too bad.

The package is orphaned but not abandoned. I'm the original author of
upower.c. As it worked for me, there was no need to rewrite it until
the new upower introduced the breakage. I still have the old upower,
and I don't have time to check what's broken.

Anyway, this feels really weird. We've been told that using /proc and
/sys is bad, as those interfaces are unstable and can change any time.
Also we've been told that upower is Teh Stable Interface to use. Okay,
we use it. And now it breaks, while users of /sys don't have any
problems at all.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752443: upower 0.99 transition started

[Andrew Shadura]

On 16 July 2014 13:10, Andrew Shadura andre...@debian.org wrote:
 Hello,

 On 16 July 2014 12:38, Emilio Pozuelo Monfort po...@debian.org wrote:

 The package is orphaned but not abandoned. I'm the original author of
 upower.c. As it worked for me, there was no need to rewrite it until
 the new upower introduced the breakage. I still have the old upower,
 and I don't have time to check what's broken.

Okay, it seems Samuli Suominen has written a patch already. I'll try
it tonight and upload new wmbattery and sleepd if it works.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752443: upower 0.99 transition started

[Andrew Shadura]

Hello,

On 14 July 2014 11:25, Andreas Henriksson andr...@fatal.se wrote:
 The upower transitions (#751953) has now been started and this
 makes your package fail to build from source in unstable.

Andreas, I'd expect a patch from you prior to the upload of a newer
upower. I currently have no time nor desire to review the API changes
to perform the porting, so a tested and working patch would really
help.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753402: gosh segfaults on s390x causing libguess to FTBFS

[Andrew Shadura]

Control: reassign -1 gauche

Hi,

It seems like a bug in gauche is causing libguess to FTBFS.
Could you please look into this?

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753684: ifupdown: Dead symlinks in /etc/network/if-pre-up.d block networking

[Andrew Shadura]

Hello,

On Fri, 04 Jul 2014 12:37:43 +0200
Matthias Urlichs matth...@urlichs.de wrote:

 Package: ifupdown
 Version: 0.7.48.1
 Severity: serious
 Justification: Policy 10.7 (?)

 # ln -s /not/an/existing/file /etc/network/if-pre-up.d/buggy
 # ifup eth0
 [ one error message and no networking ]

 … which is fun if you remote-admin something.

Um. Don't do that then. Or get it fixed in run-parts. Commands for
pre-up *must* succeed, otherwise the precondition for getting an
interface up wouldn't be met. So it doesn't precisely sound like a bug
in ifupdown.

Meanwhile, I don't see how this violates Policy 10.7.

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature

Bug#753402: libguess: FTBFS on s390x

[Andrew Shadura]

Hi,

On 1 July 2014 16:40, Sebastian Ramacher sramac...@debian.org wrote:
 libguess failed to build on s390x. Please take a look at it. The full
 build log is available at
 https://buildd.debian.org/status/fetch.php?pkg=libguessarch=s390xver=1.2~git20131128.cc43cefc-1stamp=1403693117

This is a very strange failure. I thought it's accidental and would
disappear on the next upload, but this didn't happen.

By the way,

  * debian/control: Bump libguess-dev to = 1.2~ in Build-Depends. Starting
with 3.5 audacious requires libguess 1.2.

Actually, it wouldn't if it weren't needlessly calling guess_init.
There aren't any other API differences between 1.1 and 1.2, so
Audacious could compile with 1.1 either.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753402: libguess: FTBFS on s390x

[Andrew Shadura]

Hi,

On 2 July 2014 11:17, Sebastian Ramacher sramac...@debian.org wrote:
 But unless configure (it explicitely checks for = 1.2) and the
 guess_init call are patched, it FTBFS with libguess 1.1 as seen on
 s390x:
 https://buildd.debian.org/status/fetch.php?pkg=audaciousarch=s390xver=3.5-1stamp=1404220109

I know, I had that change already, but forgot to commit it, actually.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739370: the problem hasn't been resolved

[Andrew Shadura]

Hello,

On Tue, 18 Feb 2014 05:37:07 +
Raf Czlonka rafal.czlo...@gmail.com wrote:

 New uploaded version hasn't resolved the issue because both 0.9.4-2
 and 0.9.5-1, and possibly earlier, versions introduced a bug where
 they create '/usr/share/pkg-config-crosswrapper' directory with
 'pkg-config-crosswrapper' shell script inside it.
 
 Whoever installed any of those versions will get into this problem:
 
 dpkg-divert: error: cannot divert directories
 
 Which is correct, since 'dpkg-divert' has the wrong information -
 since 'dpkg-divert' entries are in 'pkgconf.preinst' script,
 diversion takes place *before* the directory gets created so there
 aren't any installation issues. However, upon deinstallation, the
 directory being there, causes an issue with 'dpkg-divert' which
 expects a 'pkg-config-crosswrapper' file, not a directory.
 
 Package version 0.9.5-2 installs just fine on a system where none of
 the above versions were installed, but does not resolve the issues
 introduced by either of the earlier versions of the package.

Yes, that's true; I don't currently know how to solve that issue
properly. I've added a check in preinst script to remove that bogus
directory, but that won't help with removing broken versions of the
package co-installed with pkg-config: the only way to fix them is to
upgrade then to a new version (or to fix the issue manually).

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature

Bug#739370: the problem hasn't been resolved

[Andrew Shadura]

Hello,

On 18 February 2014 13:31, Raf Czlonka rafal.czlo...@gmail.com wrote:
 Yes, that's true; I don't currently know how to solve that issue
 properly. I've added a check in preinst script to remove that bogus
 directory, but that won't help with removing broken versions of the
 package co-installed with pkg-config: the only way to fix them is to
 upgrade then to a new version (or to fix the issue manually).

 Such, such check (like the one below) will only work if the package is
 upgraded, not removed. Broken packages can only be fixed by manua
 intervention when a user decides to purge them from the system, rather
 than trying to install to a newer version.

 Something like this would at least allow users to get passed the broken
 package state, install the new version and, if they choose to do so,
 remove the package from their system using apt/dpkg.

Actually, this is exactly what I added in a -3 version: it allows
users to unbreak things by upgrading the package.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732291: files in src/* have license GPLv2+

[Andrew Shadura]

Hello,

On Mon, 16 Dec 2013 13:28:05 +0100 (CET)
Thorsten Alteholz deb...@alteholz.de wrote:

 as opposed to debian/copyright, which states that the license of all
 files is GPLv2, the files in src/* have a license of GPLv2+. Please
 update debian/copyright for the new upstream version (1.0.1)
 accordingly.

I don't think it's a bug. If source is distributed as GPL-2+, you're
free to take it as either GPL-2, or any later version. As GPL-2 and
GPL-3 are incompatible, to link against GPL-2 sources, you must take
GPL-2+ sources under GPL-2 or you violate the license.

That said, I think GPL-2 is the best choice here.

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature

Bug#732291: Bug#732291: files in src/* have license GPLv2+

[Andrew Shadura]

Hello,

(First of all, I'm not the maintainer of a package.)

On Thu, 09 Jan 2014 15:24:59 +0100
Jonas Smedegaard d...@jones.dk wrote:
  I don't think it's a bug. If source is distributed as GPL-2+,
  you're free to take it as either GPL-2, or any later version. As
  GPL-2 and GPL-3 are incompatible, to link against GPL-2 sources,
  you must take GPL-2+ sources under GPL-2 or you violate the license.

  That said, I think GPL-2 is the best choice here.

 debian/copyright is not only about stating the licensing we choose
 for our work (the source of packaging and the binary compiled code),
 but also about documenting the licensing of upstream parts.

The upstream distributes their sources under ‘GPL version 2 or later’,
which means that it is either under GPL-2, or GPL-3, or GPL-2+ when it
comes to actually using the source. It is therefore correct to state
that the license of upstream's code is GPL-2, as it is one of the
options upstream gives. Furthermore, if there are other parts of the
code are still GPL-2, and they link against code under src/, it'd not be
legal to take that source under GPL-3.

 Please document upstream licensing.  If you _also_ want to document
 the resulting combined licensing of the full redistributed work, do
 that separately in _addition_ (in the header section, if using DEP-3
 format).

My opinion that this is more a nitpicking, under which I mean this is a
change that's better to be done, but it definitely doesn't qualify as
an RC bug. Closer to wishlist severity, actually.

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature

Bug#727073: [ifupdown] Anything new here?

[Andrew Shadura]

Hello,

On 21 November 2013 10:23, David Baron d_ba...@012.net.il wrote:
 Updated now to 0.7.46-1. Anything new. Bug is a month old.

Well, it's not strictly a bug... It's rather incorrect usage. If you
use static IPv6 address assignment, you must wait for DAD to complete
before using the address. If you use allow-hotplug, it brings the
interface up asynchronously, and apache and other services start before
DAD has completed.

So basically there are two ways of solving the issue:

 * Use auto, not allow-hotplug, and leave DAD check enabled.
 * Disable DAD check; it's not guaranteed then IPv6 address will
   be ready when services start.

 Related to  #723184 posted around same time?

No, unrelated. In that bug report, there's probably some kernel issue;
the original bug posted still hasn't provided any details.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727073: [ifupdown] Anything new here?

[Andrew Shadura]

Hello,

On 21 November 2013 10:51, David Baron d_ba...@012.net.il wrote:
 So a changes notification with instructions may be in order.
 Issue might not even apply to my setup, but if I do encounter it, where do I
 change the options?

The problem here is that I'm not sure what to do with this bug. I
could patch udev's script which implements allow-hotplug so it would
ignore inet6 static interfaces before ‘networking’ init script has
run, but this won't solve the issue completely... If a service could
depend on a interface being up, not on ‘networking’, that would make
it much easier to do something with this.

More thinking required.

-- 
Cheers,
  Andrew


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728092: ifupdown: ifup -v displays wpa-password in cleartext

[Andrew Shadura]

Control: reassign -1 wpasupplicant

Hi, this is a bug in wpa-supplicant's scripts.

Bug#728092: Fwd: Re: Bug#728092: ifupdown: ifup -v displays wpa-password in cleartext

[Andrew Shadura]

Control: reassign -1 wpasupplicant

Hi, this is a bug in wpa-supplicant's scripts.

Bug#728092: ifupdown: ifup -v displays wpa-password in cleartext

[Andrew Shadura]

Hi,

One more thought: wpasupplicant.conf may be what you want.

Bug#724195: Unable to upload a fix for 724195 (RC, FTBFS)

[Andrew Shadura]

Hi,

On 24 October 2013 05:41, Rogério Brito rbr...@ime.usp.br wrote:
 I have just tried to upload a fix for this bug, but it seems that, with the
 transition from the DMUA flags, I lost the privileges of uploading this one.
 You can find an updated packaging in any of the following repositories:

 https://github.com/rbrito/pkg-hfsprogs

I've uploaded this one.

 ssh://git.debian.org/git/collab-maint/youtube-dl.git

And this one you probably don't want ;)

-- 
WBR, Andrew


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#727073: ifupdown: current version somehow brings the ifaces up too late

[Andrew Shadura]

Hello,

On Tue, 22 Oct 2013 20:11:46 +0200
Christoph Anton Mitterer cales...@scientia.net wrote:

  The major difference between 0.7.44 and 0.7.45 is that 0.7.45 waits
  for DAD to complete for 'inet6 static' interfaces.
 Well couldn't that be connected? Since my it seem to be exactly the
 inet6 addrs that are not _yet_ configured.
 (They are though configured, once I log in.)

It's definitely connected, I can't understand how, however. When
waiting for DAD, it says ‘Waiting for DAD...’, which I don't see in the
logs you gave me. Also, DAD is usually quick, and anyway apache and
bind shouldn't start until interfaces finished configuring, as
interface configuration is blocking... unless it's initiated by udev.
Do you have your eth0 as allow-hotplug? Try changing it to auto and see
what happens.

Also, please note the new dad-attempts parameter. If you set it to 0,
it behaves as in 0.7.44.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#727073: ifupdown: current version somehow brings the ifaces up too late

[Andrew Shadura]

Hello,

On Tue, 22 Oct 2013 04:27:37 +0200
Christoph Anton Mitterer cales...@scientia.net wrote:

 Since 0.7.45 I see a problem, that many deamons fail to start during
 boot, since some of the configured addresses are not yet ready,
 See the following bootlogd snipped, where apache, and bind fail:
 Going back to 0.7.44 fixes the problem.

The major difference between 0.7.44 and 0.7.45 is that 0.7.45 waits for
DAD to complete for 'inet6 static' interfaces. That shouldn't prevent
the address from being assigned, however. Could you please get some
more information from the system?

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#723184: ifupdown: All interfaces fail to come up after 2nd boot. ifup fails to bring up all interfaces.

[Andrew Shadura]

Hello,

On Tue, 17 Sep 2013 00:09:00 -0700
Mandana lovely.mand...@gmail.com wrote:

 If I manually run:
 
 ifup lo
 
 it says link: error fetching interface information: Device not found
 
 for ifup eth0 it says:
 
 addr: error feching interface information: Device not found

I guess you have something wrong with udev, as kernel modules for your
devices don't get loaded. Ifconfig probes modules for network devices,
whereas iproute apparently doesn't, so if the device module isn't
already loaded it fails.

Try to find out why modules don't get loaded. A workaround would be to
add them manually to /etc/modules, so they will be loaded anyway on
boot.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#708997: closing 708997

[Andrew Shadura]

close 708997 
thanks

Probably not relevant anymore. Please reopen if the problem persists.

-- 
WBR, Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#709548: libgtk-3-0: most recent gtk upload breaks.... (nearly) everything (in GNOME)

[Andrew Shadura]

Hello,

On Sat, 25 May 2013 11:23:34 +0200
Loïc Favory loic.fav...@gmail.com wrote:

 Without downgrading, I succeed to switch back to Adwaita using Gnome 
 Classic session from gdm3...
 Logging back to gnome shell, and everything is fine with Adwaita.

By the way, yesterday I uploaded Clearlooks-Phénix to unstable, if that
matters.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#709548: libgtk-3-0: most recent gtk upload breaks.... (nearly) everything (in GNOME)

[Andrew Shadura]

Control: reassign -1 libgtk-3-0

Well, I guess, then it makes sense to assign the bug back to gtk package.

-- 
WBR, Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#707041: ifupdown.postinst: 102: /var/lib/dpkg/info/ifupdown.postinst: Syntax error: else unexpected

[Andrew Shadura]

Hello,

On Tue, 07 May 2013 05:59:45 +0200
Michael Biebl bi...@debian.org wrote:

 Todays upgrade failed with the following error message:

 Setting up ifupdown (0.7.41) ...
 /var/lib/dpkg/info/ifupdown.postinst: 102:
 /var/lib/dpkg/info/ifupdown.postinst: Syntax error: else unexpected
 dpkg: error processing ifupdown (--configure):
  subprocess installed post-installation script returned error exit
  status 2
  Errors were encountered while processing:
   ifupdown

:(

Last minute edits don't end well...

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#707048: /etc/network/interfaces error

[Andrew Shadura]

Hello,

On 7 May 2013 14:34, szelag bernard bernard.sze...@univ-lille1.fr wrote:
 after installing new package ifupdown , ifup, ifdown and ifquery
 exit with error:

Already fixed in 0.7.43, see #707052.

-- 
WBR, Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#705456: Processed: cloning 705268, reassign -1 to vlan, retitle -1 to don't act on VLAN interfaces supported by ifupdown

[Andrew Shadura]

A patch fixing the issue.

-- 
WBR, Andrew


vlan.diff
Description: Binary data

Bug#696642: ifupdown: fails to bring up eth0.xx alias in bridge/vlan setup

[Andrew Shadura]

Hello,

On Mon, 25 Mar 2013 20:31:35 -0400
Michael Gilbert mgilb...@debian.org wrote:

  Just because it's getting close to the release doesn't mean you
  can just bypass maintainers when they're actively working on
  issues.  Please stop pulling crap like this...

 What are you talking about?  This bug stagnated for 2 months, then got
 done in an experimental upload, then got ignored for another 3 weeks.

No. The fix was ready for two months already. It wasn't ignored, I
waited for approval from Julien to upload it and other changes.

 Anyway, the nmu prodded the maintainer to get back to work, so
 ultimately, it was useful.

No, it wasn't. I only made sure I can't trust you, and that your NMUs
won't be acknowledged in the changelog.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#703922: ifupdown: freeze during shutting down

[Andrew Shadura]

Hello,

On Mon, 25 Mar 2013 21:08:07 +0100
Samuel Hym samuel@gmail.com wrote:

 After upgrading to version 0.7.6, ifupdown froze my system during shut
 down, stopping at the DHCPRELEASE step.
 Reverting to version 0.7.5+nmu1 in testing solves the issue.

Thanks for the report, I will upload a version without that change in
tonight, as we don't have enough time to deal with this issue now.

However, I'd like you to help me with solving it properly. Please try
to gather as much valuable debug information with 0.7.6 as you can, and
post here.

Thanks in advance.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#703922: ifupdown: freeze during shutting down

[Andrew Shadura]

Hello,

On Tue, 26 Mar 2013 00:11:50 +0100
Samuel Hym samuel@gmail.com wrote:

 I just had a look to try and see what's going wrong.
 ifdown gets stuck waiting for
 dhclient -6 -r -pf /run/dhclient6.eth0.pid -lf
 /var/lib/dhcp/dhclient6.eth0.leases eth0
 to complete, which it never does. Even running that command directly
 does the same result, never returns.

Yes, I've just tried it, and got the similar result. I thought that
could be because I didn't have DHCPv6 setup, but it seems that's not
the case. Did you have the interface still up when you tried running it
(just to be sure).

 Version 0.7.5+nmu1 does not try to launch dhclient -6 at shut down.

Yes, I've uploaded 0.7.7 which doesn't try doing this.

 Does it help? Any suggestion of something I should look?

I think we need some help from dhclient maintainers.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#695906: ifupdown: removal of /etc/network/interfaces is not preserved

[Andrew Shadura]

Hello,

On Sun, 3 Mar 2013 05:52:39 -0500
Michael Gilbert mgilb...@debian.org wrote:

 On Thu, 14 Feb 2013 20:11:16 +0100
  Yes, please, dcut it. I plan to incorporate it into the next upload,
  but it's not yet ready, and I'd prefer to avoid NMUs at this point.

 I know you didn't want your package nmu'd, but there has been too
 little activity for too long, and its unnecessarily delaying the
 release, so I went ahead and did one.  Please see attached patch.
 Apologies in advance.

If I didn't do an upload, I had a good reason for that. We still have
enough RC or close-to-RC bugs which can't wait too long either, and I'm
working on them. Please, don't NMU my packages when I explicitly ask not
to. Or at least ask me beforehand, not notify afterwards.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#695906: ifupdown: diff for NMU version 0.7.5+nmu1

[Andrew Shadura]

Hello,

On Thu, 14 Feb 2013 20:11:16 +0100
Josselin Mouette j...@saya.malsain.org wrote:

 I've prepared an NMU for ifupdown (versioned as 0.7.5+nmu1) and
 uploaded it to DELAYED/2. Please feel free to tell me if I
 should delay it longer.

Yes, please, dcut it. I plan to incorporate it into the next upload,
but it's not yet ready, and I'd prefer to avoid NMUs at this point.

P.S. Your message didn't go to my inbox for some reason. Any hints why?

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#692110: [ifupdown] ifupdown renders system unbootable

[Andrew Shadura]

Hello,

On Fri, 2 Nov 2012 11:39:01 +0100
Christian Frommeyer deb...@frommeyer.name wrote:

 after updating some packages yesterday the system did not boot any
 more today. The boot sequence always just stopped after resolvconf.
 The system would not do anything else than respond to Ctrl+Alt+Del
 for reboot. After some fiddeling around I realised that booting with
 the .legacy- bootordering file in place would work but issue an error
 message in /etc/network/if-up.d/upstart that the return statement in
 line 15 is not allowed. Initially Version 0.7.3 was installed.
 Ubdating to 0.7.4 did not change the situation. Even downgrading did
 not remove the defective files. I now purged ifupdown and reinstalled
 0.7.2 which works again.

I'm really really sorry that I've done two consecutive releases which
had these terrible bugs. I'll fix it soon and do an upload.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#684994: ifup: fails to open statefile, does not bring up the network

[Andrew Shadura]

Hello,

On Wed, 15 Aug 2012 17:14:09 +0200
Thorsten Glaser t...@mirbsd.de wrote:

 After upgrading to sid today, ifup does not work any more:

 $ sudo ifup eth0
 ifup: failed to open statefile /run/network/ifstate: No such file or
 directory

 The network is not brought up at all, even e.g. postfix did not start.
 Other stuff does exist in /run/ though.

Could you please check if /etc/init.d/networking gets run at all? And
if it does, please try to set -x-debug it to see what happens.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#684994: ifup: fails to open statefile, does not bring up the network

[Andrew Shadura]

Hello,

On Thu, 16 Aug 2012 12:02:56 +0200 (CEST)
Thorsten Glaser t.gla...@tarent.de wrote:

 thanks for the quick response. Indeed, /etc/init.d/networking,
 when run manually, does work.

 The current sysvinit configuration (with file-rc) is as follows:

 tglase@tglase-nb:~ $ fgrep netw /etc/runlevel.conf
 35  -   0,6 /etc/init.d/networking

 Might this have something to do with the recent (IMHO not good)
 decision of the file-rc people to switch to using insserv?

Don't know; I suggest you to contact file-rc people to check what's
wrong.

P.S. MirBSD.de's MX doesn't accept mail from me:

550 5.0.0 We don't accept mail from spammers. Your freemail provider
(Google Mail) is unresponsive to abuse requests.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#679672: ifupdown: ifup doesn't recognize aliases IPs for vlan in form ethX.Y:A

[Andrew Shadura]

Hello,

On Mon, 02 Jul 2012 19:21:07 +0300
Adrian Ban adrian@mantech.ro wrote:

 This patch is integrated in ifup?
 I'll try to check if is working.

You can try it from here:
http://ifupdown.org/ifupdown/diff/ifupdown.nw?diff2=bbb51c127dcfdiff1=3852b8ca1fb8

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#679672: ifupdown: ifup doesn't recognize aliases IPs for vlan in form ethX.Y:A

[Andrew Shadura]

Hello,

On Sat, 30 Jun 2012 19:37:57 +0300
Adrian Ban adrian@mantech.ro wrote:

 After an upgrade of the system the ifup command doesn't recognize
 anymore the aliases for the VLANs. I have severals vlans configured
 in /etc/network/interfaces like this:

I've just committed a fix.

For this:

iface eth2.2:3 inet static
  address 3.4.5.6/23

It now runs the following:

if test -d /sys/class/net/eth2 -a ! -d /sys/class/net/eth2.2 ; 
then ip link set up dev eth2; ip link add link eth2 name eth2.2 
type vlan id 2; fi
ip addr add 3.4.5.6/255.255.254.0 broadcast 3.4.5.255 dev eth2.2:3 label 
eth2.2:3
ip link set dev eth2.2:3   up

Please check if that's correct.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#656584: initscripts: /run transition: Please update /etc/network/if-up.d/mountnfs

[Andrew Shadura]

Hello,

On Mon, 18 Jun 2012 10:12:03 +0200
MAG4 Piemonte m...@aruba.it wrote:

  Forgot to ask, which exactly versions? You need initscripts (=
  2.88dsf-25).

 Hi Andrew, we are on Testing so ifupdown version is 0.7 and
 initscripts version is 2.88dsf-22.1. Regards!

Please update to the *latest* version. Install it from unstable please.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#656584: initscripts: /run transition: Please update /etc/network/if-up.d/mountnfs

[Andrew Shadura]

Hello,

On Mon, 18 Jun 2012 16:27:26 +0200
MAG4 Piemonte m...@aruba.it wrote:

 Hi Andrew, we update initscripts to version 2.88dsf-27 from unstable
 and we found that:

 - Without network-manager boot doesn't stall 3 minutes every NFS
 mount and they result automatically mounted (everything is ok).

 - With network-manager boot doesn't stall 3 minutes every NFS mount
 anymore, but after they don't result automatically mounted and we
 have to do it manually (if we comment or not
 in /etc/network/interfaces the line auto eth0 is no more relevant).

Great! It's now the time to either make a small change to
network-manager, or to initscripts.

Michael, ADDRFAM=NetworkManager in the dispatcher script, why is it
there? I don't quite remember, are there any hook scripts which depend
on this exact value? Because actually when it's passed there, most of
the scripts will ignore the fact they're called. So either the script
should pass inet or inet6 depending on the type of the interface, or we
should check for it too in mountnfs (and, probably, somewhere else).

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#656584: ifupdown's changed hook handling breaks other packages.

[Andrew Shadura]

Hello,

On Sat, 16 Jun 2012 19:05:06 +0200
Michael Biebl bi...@debian.org wrote:

  Reassigning it back as it really is a bug in NetworkManager.

 I've asked for further justification.
 Just saying really isn't.
 If it is a bug in NetworkManager, then please show me where.

auto eth0

#NetworkManager#iface eth0 ...

is not a valid syntax.

So when we have interfaces 'defined' like this, initscripts' hook
thinks we've got all 0 interfaces up so it can start. Of course, this
needs to be fixed so it won't even try to do so. But the source of the
problem is that NetworkManager was abusing a bug in ifupdown's parser.

If you really wanted to 'hide' an interface, you should have commented
out all the 'auto' and 'allow-' lines, not 'iface', leaving 'auto'
intact, which apparently doesn't work.

Also calling ifupdown's hooks at random moments isn't a good idea
either.

 If you suddenly decide to change the behaviour of ifupdown, then
 please co-ordinate such a change and get affected packages fixed
 beforehand. And let packages know what they need to change.

That wasn't suddenly. It's been documented always but didn't work a
little bit as expected. Exploiting a bug in a parser is always bad, and
there's no excuse for doing that. I can't possibly know every person
who's tried to misuse this software, and that's really a problem of
those persons. Or shouldn't bugs get fixed at all then if anyone
exploits them all the time?

I think that reassigning a bug to network-manager in a first place was
a clear enough message that something needs to be changed, so
reassigning it back multiple times isn't a good way of communication
either.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#656584: initscripts: /run transition: Please update /etc/network/if-up.d/mountnfs

[Andrew Shadura]

Hello,

On Fri, 15 Jun 2012 11:25:21 +0200
MAG4 Piemonte m...@aruba.it wrote:

 Hi Andrew, we try the latest ifupdown and initscripts and we found
 that:

Forgot to ask, which exactly versions? You need initscripts (= 2.88dsf-25).

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#675016: ifupdown: don't use PPP updetach option by default

[Andrew Shadura]

Hello,

On Tue, 29 May 2012 03:28:46 -0700
Ian Bruce ian_br...@fastmail.net wrote:

 I have specified this bug as critical/breaks the whole system,
 because its effect is that if an external PPP link does not come up
 for some reason, the system boot fails. It actually gets wedged so
 hard that you cannot even boot into recovery mode to fix it; the
 problem can only be resolved with a rescue disk. This is completely
 unacceptable.

I agree with many points of yours, but please explain how does it break
the boot sequence. Networking initscript allows ifup to fail as far as
I can see. How exactly does it break for you?

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#675016: ifupdown: don't use PPP updetach option by default

[Andrew Shadura]

Hello,

On Tue, 29 May 2012 06:34:59 -0700
ian_br...@fastmail.net wrote:

 pppd persist maxfail 0 updetach does not return until the PPP link
 comes up. If this does not happen for some reason, it never returns at
 all, and the boot sequence stops before any console is available, even
 in recovery mode. It's easy to reproduce the problem: enable the
 persist and maxfail 0 options, unplug the ethernet cable to the
 modem, and reboot.

 Simple solution: take the updetach out of the ifup binary, as it was
 until recently, and if necessary, put it in /etc/network/interfaces,
 since this is now allowed to specify arbitrary options.

Okay, makes sense. 

 Better solution: find some dependency mechanism with hotplug or udev
 that also works for DHCP or any other network configuration system.

Not in the next month as freeze is soon.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#674786: netbase: Ignores /etc/network/interfaces except for ipv4 eth0 and lo0

[Andrew Shadura]

tags 674786 moreinfo
thanks


Hello,

On Sun, 27 May 2012 18:05:22 +0200
Jan Huijsmans huysm...@koffie.nu wrote:

 After upgrade to netbase 5.0 from 4.47 all entries
 in /etc/network/interfaces except for eth0 ipv4 and lo0 ipv4 are
 completely ignored. No virtual interfaces or ipv6 addresses are set
 at all.

Either you provide full information about your configuration *and* it's
not invalid as last time, or it's not a bug.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#674775: netbase: Netbase ignores /etc/network/interfaces ipv6 settings

[Andrew Shadura]

Hello,

On Sun, 27 May 2012 17:24:38 +0200
Jan Huijsmans huysm...@koffie.nu wrote:

 Package: netbase
 Version: 5.0
 Severity: critical
 Tags: ipv6
 Justification: breaks the whole system
 
 Dear Maintainer,
 
 Upgrade from 4.47 to 5.0 resulted in failure to add every static ipv6
 address configured in /etc/network/interfaces. Looks like ipv6 is
 completely ignored. Adding manually works.

If you did read what does it say, you could see the following:

Error: an inet prefix is expected rather than 2001:610:611:2::42/64/64.
Failed to bring up eth0.

Which means that you have specified the netmask twice:

 iface eth0 inet6 static
 address 2001:610:611:2::42/64
 netmask 64

Previously, ifupdown was using ifconfig which would silently swallow
this and just set it up, but iproute (which we use now) does complain.
Probably, in the next upload I will teach ifupdown to cope with this,
but this isn't strictly a valid configuration.

 up /sbin/ifconfig eth0 inet6 add 2001:610:611:2::4/64 
 up /sbin/ifconfig eth0 inet6 add 2001:610:611:2::140/64 
 up /sbin/ifconfig eth0 inet6 add 2001:610:611:2::141/64 
 up /sbin/ifconfig eth0 inet6 add 2001:610:611:2::142/64 
 up /sbin/ifconfig eth0 inet6 add 2001:610:611:2::143/64 
 up /sbin/ifconfig eth0 inet6 add 2001:610:611:2::144/64 
 up /sbin/ifconfig eth0 inet6 add 2001:610:611:2::145/64 
 up /sbin/ifconfig eth0 inet6 add 2001:610:611:2::146/64 
 up /sbin/ifconfig eth0 inet6 add 2001:610:611:2::642/64 

This is not needed any more, by the way, you can specify as many 'iface
eth0 inet6 static' sections as you want. Also, I promise to come up
with a better syntax to the next release ;)

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#673043: new ifupdown does not understand comments in interfaces, breaking existing setups

[Andrew Shadura]

Hello,

On Tue, 15 May 2012 21:26:17 +0400
Michael Tokarev m...@tls.msk.ru wrote:

 Interesting.  The manpage actually says that in-line coments are
 NOT supported, but I've never actually noticed this till today.
 It has always worked, and I guess it was more by incident not by
 design.  But I'd say it is a wrong design, since using comments
 like this is very handy and natural thing to do, too.  Pity... :(

I don't know, they could be a good idea but I'm afraid their
introduction can possibly break something now.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#665773: is sid affected?

[Andrew Shadura]

Hello,

On Sun, 29 Apr 2012 02:36:49 +0200
Robert Millan r...@debian.org wrote:

 2012/4/28 Andrew Shadura bugzi...@tut.by:
  Really, I don't know, and that doesn't really matter as the version
  currently in experimental is going to be uploaded to unstable soon
  (with one modification), so this bug won't be present in sid anyway.

 You mean a fixed version?  #665773 is not registered as fixed in any
 version yet, is that a mistake?

Yes, that's true, I forgot to mention the bug number.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#665773: is sid affected?

[Andrew Shadura]

Hello,

On Sat, 28 Apr 2012 17:39:18 +0200
Robert Millan r...@debian.org wrote:

 Also, this bug is tagged sid but the only version where it was found
 (0.7~beta1) is not in sid.  Are the versions in Wheezy / Sid affected?

Really, I don't know, and that doesn't really matter as the version
currently in experimental is going to be uploaded to unstable soon
(with one modification), so this bug won't be present in sid anyway.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#667018: avahi-daemon: add support for kFreeBSD native tools

[Andrew Shadura]

Hello,

On Tue, 03 Apr 2012 14:52:11 +0200
Michael Biebl bi...@debian.org wrote:

 could you clarify what the problem is and why this has RC severity.

Severity --- probably not, feel free to justify it to your taste :)

The problem is unconditional calls of Linux ifconfig and Linux route
from /usr/lib/avahi/avahi-daemon-check-dns.sh. In kFreeBSD, native
tools have different syntax and output format, and wrappers are to be
removed soon (maybe already removed, not sure).

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#667018: avahi-daemon: add support for kFreeBSD native tools

[Andrew Shadura]

Hello,

On Tue, 03 Apr 2012 14:59:28 +0200
Michael Biebl bi...@debian.org wrote:

 Are you saying route doesn't exist on kfreebsd or that it doesn't
 accept the -n command line argument?

It does accept it, but acts differently:

root@debian:~# route -n
usage: route [-dnqtv] command [[modifiers] args]

 Sorry, this bug report is still a bit too vague. It is not clear to me
 what I'm supposed to fix and how.

Please read previous messages on the thread as well.

-- 
WBR, Andrew


signature.asc
Description: PGP signature